Re: [weld-dev] standard servlet context attribute for the BeanManager

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