> On Wed, Mar 24, 2010 at 11:24 AM, David Allen <
drallendc@gmail.com>
> 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@hibernate.org> 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.