To clarify: the above isn't from the @Startup @Singleton @PostConstruct - that has "resolved itself" (probably because we managed to fix what now seems to have been the root issue - I've been unable to reproduce it since switching to static weaving).
The @ConversationScoped @PostConstruct is happening from a JSF component which accesses said bean. Thus, there is a request, and there is already a (putative) session (or, should be created by the container if it doesn't exist).
Think of it this way:
<page.xhtml>
...
<h:outputText value="#{conversation.someValue}"/>
...
</page.xhtml>
And
@Named
@ConversationScoped
public class Conversation implements Serializable {
@Inject
private Conversation conversation;
@PostConstruct
protected void init() {
if (this.conversation.isTransient()) {
this.conversation.begin();
// FIXME: Unelegant workaround since JBoss has no default injector for HttpSession
// As I understand it, this violates Servlet and CDI specs for JEE6
ExternalContext ctx = FacesContext.getCurrentInstance().getExternalContext();
HttpServletRequest req = HttpServletRequest.class.cast(ctx.getRequest());
HttpSession session = req.getSession(true);
this.conversation.setTimeout(session.getMaxInactiveInterval() * 1000);
}
}
public String getSomeValue() { return "bla"; }
}
When one hits page.xhtml is when we get the above stack trace for @ConversationScoped @PostConstruct blablabla...
We also get the other "associate() before activate()" error on our form authentication page, and that one doesn't touch the conversation.
If we can fix these, I think we have a legitimate shot at finishing our port (and then I'll ask some rather silly questions about how to properly do JNDI name mapping so I can avoid code changes - all the docs I've found date back to JBoss 3 or earlier).