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.

-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