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@redhat.com> 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@glassfish.dev.java.net)

_______________________________________________
webbeans-dev mailing list
webbeans-dev@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