A switch is reasonable, but I think it needs to disable more than just annotation-defined managed beans support. My understanding is that a JSF managed bean defined in faces-config.xml can still have a @PostConstruct annotation that gets processed (same with the other life cycle annotations and the @EJB annotation). Then it's still possible that there is an instance of an application-scoped eager bean in the JSF managed bean container. Same would go for beans in other scopes.

We should state that it's possible to inject a managed or enterprise bean into a JSF managed bean because the injection, as you said, is based on the EL.

If the injection goes the other way, the instance is the one created by JSR-299 and not the instance created by JSF; an important point to understand. Therefore, there could be two instances of a bean per scope. And from what you proposed, the JSR-299 bean always wins if it has the same name as a JSF managed bean.

-Dan On Sun, Aug 2, 2009 at 6:38 PM, Pete Muir <pmuir(a)redhat.com&gt; wrote: Hi I realized we have a potential conflict between JSF and 299 to do with EE defined managed beans, which we need to address. Imagine the following scenario: A managed bean is defined using @ManagedBean in a war in which both JSF and Web Beans is enabled. In this case both JSF and Web Beans will attempt to manage the bean, however according to the latest note sent by Roberto Chinnici to the EE expert group, if 299 is present, 299 should manage the bean. We need to address how to deal with this for both Web Beans and Mojarra. Some points to consider: * 90% of the time there is no problem, the Web Beans ELResolver is installed before the JSF ManagedBeanELResolver. However the corner case of an eager instantiated, application scoped managed bean with a post construct lifecycle callback will cause us a problem. There may also be other corner cases we haven't considered. For this reason, I think we should consider being able to explicitly disable JSF managed beans * this doesn't affect other specs which may use managed beans as much, (a) as Mojarra works in other containers than GlassFish, such as Tomcat, where Web Beans may not be present (b) 299 specifically states that JSF should use an ELResolver as it's integration point (other specs integration point is programatic and so can use an SPI if or similar - Ken's suggestion from our latest meeting for those who were there) * Mojarra will need to continue to provide xml-defined managed beans when Web Beans/299 is present. My suggested solution is to simply have a switch in Mojarra we can use to "turn off" annotation-defined managed beans support (either automatic via detection of WEB-INF/beans.xml or manual via web.xml or programatically). Pete On 31 Jul 2009, at 20:11, Barbara Louis wrote: > - How we deal with jsf managed beans when 299 is present? > - 299 requires managed beans > - JSF RI will need to make the change - the ques to ask is: should > jsf manage the managed beans or should I let the EE container to > manage it for me? > - Pete will send an email on webbeans dev mailing list on this topic > and include Mojarra mailing list (webtier(a)glassfish.dev.java.net) _______________________________________________ webbeans-dev mailing list webbeans-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/webbeans-dev -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan

We should state that it's possible to inject a managed or enterprise bean into a JSF managed bean because the injection, as you said, is based on the EL. Why? If you are using 299 you aren't using JSF managed beans. If you are aren't using 299 then this isn't relevant. If the injection goes the other way, the instance is the one created by JSR-299 and not the instance created by JSF; an important point to understand. Therefore, there could be two instances of a bean per scope. And from what you proposed, the JSR-299 bean always wins if it has the same name as a JSF managed bean. Again, no, if 299 is active *it* manages the beans, so there are no JSF managed beans. I'm saying if both containers are allowed to instantiate beans, you would be in this situation. So if you can get JSF managed beans to be disabled, then yes, 299 will manage the beans. But if we don't lay down some rules, then we will be in a situation where both containers are creating beans. That's all I'm saying.

I think it's better to address this by disabling JSF managed beans when 299 is present, rather than by creating extra rules about how the two interact. Any reason to take the latter approach? My only concern here is that someone writes an application that they have been deploying to Tomcat or Jetty and then they turn around and deploy it to JBoss AS for production (or pre-production). All of a sudden, the playing field changes. This seems like a very realistic scenario, especially for people migrating.