[webbeans-dev] How does JSF deal with managed beans when Web Beans/299 is present?

[Dan Allen]

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 at 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 at glassfish.dev.java.net)
>
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20090803/f4b1ed6e/attachment.html