Quoting Arthur T Smyles <[EMAIL PROTECTED]>:
> While I understand that J2EE spec has a standard way of getting
> resources,(including I imagine other JNDI Contexts), I still think that
> this
> approach should also be allowed for the following reasons:
Ok, I don't really know what we're talking about anymore.
There are three different naming environments which are provided to a servlet
in the upcoming TC4b2.
- The first one is the "java:" naming environment. It is a read only and the
declaration of its contents is proprietary on the server administrator side. It
is created and initialized in the servlet container, and later accessed through
a proxy context. I don't see any way to have this naming environment handle
properly the env you specify when you call new InitialContext, and I don't
think it should either.
- A standard read/write naming context is also provided to the servlet. It
supports federation and references. It should also use the environment you
specify. If it's failing to load your factory, then it's probably because of
classloading problems.
I'm not using NamingManager.getStateToBind when binding objects yet (but I can
fix that one easily).
- The last one is a DirContext which can be used to access static resources. It
does not support references or federation. It is created by the servlet
container.
> 1. It follows the JNDI Tutorial nicely (making it easy for new users to
> use);
Most of the JNDI features are optional in an implementation (federation,
references, ...), so any particular example in the JNDI tutorial may or may not
work depending on what's supported.
> 2. It is backwards-compatible with non-J2EE sevlet engines (those that
> follow
> the 2.1 spec for example). This is important in my case since that is
> what I am
> currently using for my production environment.
> 3. It doesn't break J2EE or Servlet 2.3 compliance.
> 4. It wouldn't hurt anything. After all, just because OTHER projects
> don't allow
> it doesn't mean Tomcat shouldn't :)
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
