At the last Seam team meeting, the issue came up (once again) of how to get the BeanManager from a non-contextual resource. The reality is that there are certain lifecycle classes in Java EE that did not get categorized as components (e.g., PhaseListener) and therefore do not support injection. They are "outside" of CDI. We are working on an SPI for JSF to make these classes CDI beans, but there will always be other cases. In the current version of the spec, the standard way of looking up the BeanManager is to use JNDI. However, JNDI is not consistently supported in environments for which we want to write portable extensions (whether we like it or not, people use servlet containers). Weld puts the BeanManager in a servlet context attribute equal to the FQCN of BeanManager. Pete suggested that we submit a change request to have this location standardized when running in a servlet environment. With this change, the BeanManager can be obtained as follows: BeanManager manager = (BeanManager) getServletContext().getAttribute(BeanManager.class.getName()); This requires no change in Weld, since Weld is already doing this. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

But how do you solve that in SE? Or even in a web environment, more and more web environment are getting away from the servlet API imposed constraint.

Am Mittwoch, den 24.03.2010, 11:11 -0400 schrieb Dan Allen: > On Wed, Mar 24, 2010 at 3:38 AM, Emmanuel Bernard > <emmanuel(a)hibernate.org&gt; wrote: > But how do you solve that in SE? Or even in a web environment, > more and more web environment are getting away from the > servlet API imposed constraint. > > > Sigh. And that's why this problem is more difficult than it has to be. > Because we can't even handle the 80-90% case. > > > But you did get me thinking. Maybe the way to address the problem is > to see this more as an integration concern for the SPI. So if I'm > running in a servlet environment (whether it be a servlet container or > Java EE), then I'm providing an implementation that standardizes on > the servlet context. But we can define other mappings for other known > environments, or unknown environments can supply the SPI impl. > > > Btw, it's not like JNDI is all that portable to SE either ;) Actually JNDI is quite simple and can be used in any Java application. It does not necessarily require a server. It is just an API and a simple implementation can always be used to provide the necessary functionality within an SE. Here's one example: http://www.osjava.org/simple-jndi/index.html

Am Mittwoch, den 24.03.2010, 11:36 -0400 schrieb Dan Allen: > On Wed, Mar 24, 2010 at 11:24 AM, David Allen <drallendc(a)gmail.com&gt; > wrote: > Am Mittwoch, den 24.03.2010, 11:11 -0400 schrieb Dan Allen: > > On Wed, Mar 24, 2010 at 3:38 AM, Emmanuel Bernard > > <emmanuel(a)hibernate.org&gt; wrote: > > But how do you solve that in SE? Or even in a web > environment, > > more and more web environment are getting away from > the > > servlet API imposed constraint. > > > > > > Sigh. And that's why this problem is more difficult than it > has to be. > > Because we can't even handle the 80-90% case. > > > > > > But you did get me thinking. Maybe the way to address the > problem is > > to see this more as an integration concern for the SPI. So > if I'm > > running in a servlet environment (whether it be a servlet > container or > > Java EE), then I'm providing an implementation that > standardizes on > > the servlet context. But we can define other mappings for > other known > > environments, or unknown environments can supply the SPI > impl. > > > > > > Btw, it's not like JNDI is all that portable to SE either ;) > > > Actually JNDI is quite simple and can be used in any Java > application. > It does not necessarily require a server. It is just an API > and a > simple implementation can always be used to provide the > necessary > functionality within an SE. > > Here's one example: > http://www.osjava.org/simple-jndi/index.html > > > What I meant by portable is that an extension can assume it is > present. We can only assume it is present in Java EE, because it is > only required there. Servlet containers, while they do have JNDI, > don't have a writable java:comp/env JNDI namespace, so that's pretty > much the same as it not being there. That's the whole reason we are in > this fix. Yeah, this might be true in general; however, we do have Weld working in Tomcat, and I believe it is entered into JNDI there as well. It took some work to do that, though, since that space is normally read-only at runtime. And actually that was done under the old java:app namespace. Maybe this is even more difficult under java:comp/env. My understanding was that onus is on the developer to include the

Hi Dan, This sounds good. Should this be submitted to the Expert Group?