On Wed, Mar 24, 2010 at 11:59 AM, David Allen <drallendc(a)gmail.com> wrote:
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>
> 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> wrote:
> > But how do you solve that in SE? Or even in a web
> > more and more web environment are getting away from
> > 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
> > 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
> It does not necessarily require a server. It is just an API
> and a
> simple implementation can always be used to provide the
> functionality within an SE.
> Here's one example:
> 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
definition in context.xml (and similar for Jetty). To me, that's
just an unnecessary requirement. I'm being tough because a lot of end
developers are going to see this requirement and be like "forget it, too
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597