Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <437F7DBF.8050001@steitz.com>
Date: Sat, 19 Nov 2005 12:32:15 -0700
From: Phil Steitz <phil@steitz.com>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [naming] statuses and use to replace tomcat read-only jndi
References: <5a2cf1f60511190440s6bcd8b4n732c00ab6ff54f69@mail.gmail.com>
In-Reply-To: <5a2cf1f60511190440s6bcd8b4n732c00ab6ff54f69@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

jerome lacoste wrote:
> Hi.
> 
> I am trying to port an application to tomcat. The application
> currently uses JNDI to register an RMI server for webstart clients to
> connect to. The application currently does this registration
> dynamically, i.e. write the entry in JDNI after startup. This doesn't
> work in JNDI because the Tomcat's JNDI is read-only.

Does the initialization happen just once, at startup, or do these things 
come up and down over the life of the app?
> 
> I see several alternatives:
> - force Tomcat's JNDI to be read-write. This can be achieved by using
> some reflection tricks and a making my application priviledged.
> Downsides: it adds some container dependant code to my webapp. Worse,
> it might even make my Tomcat upgrades harder.

Probably not a good idea, for the reasons you state.
> 
> - register my JNDI service inside Tomcat in the JNDI configuration.
> Once again a web container specific implementation.

What exactly do you mean here and why would it not be portable?
> 
> - use a separate read-writeable JNDI implementation, bundled in my web
> app. Here comes the Apache directory naming project. I've tried that
> and so far, it looks like the packaged application is not taken into
> account (Tomcat's JNDI is still used).

That is because tomcat's initialization sets a javaURLContextFactory, 
which makes it use the tomcat in-memory provider to resolve names 
beginning with the "java:" scheme.  You can probably get the full 
replacement configured to work, but I would not recommend that, mostly 
for upgrade and maintenance reasons.  Also see spec comments below.

Do you have to use the "java:comp/env" namespace to locate your 
resources?  (I assume that is where they are now).  If not, though I 
have not tried this, we should be able to configure the "jndi:" 
namespace to work without replacing tomcat's provider for the java 
namespace. This may require some repackaging, but I would be willing to 
help if you want to go in this direction.
> 
> - change the way my webstart application and my web applications
> interact. JNDI is just used to get a reference to the server through
> RMI. Ditch that. E.g. I could make the stubs accessible on the server
> and use a URL ClassLoader to retrieve them.

Not knowing any of the details, this may not be a bad option.
> 
> I am not 100% happy with any of the alternatives (why is Tomcat's JNDI
> read-only?)?

You would have to ask that question on tomcat-dev to get a definitive 
response, but I bet at least part of the response would be that this 
would violate the J2EE spec, if the write access is permitted of an 
application component instance at runtime.  See section 5.2 of the J2EE 
platform spec. The statement there is that component instances are not 
allowed to modify the environment at runtime.

Another reason that the tc devs would probably give is part of what 
motivates the statement in the spec - if component instances in a 
container are allowed to modify their shared environment at runtime, you 
need to worry about synchronization and environment consistency.  The 
spec does not require that the environment be mutable - in fact 
disallows it - so they do not synchronize access.
> 
> Any idea/advice?

I don't know about all of the other containers, but if you are worried 
about portability, I would not recommend building a dependency in your 
web app on java:comp/env being mutable.
> 
> 
> Statuses: latest code change on the Naming project was in April. Does
> that mean that the project is stable or abandonned? (I would lean on
> #1, just want some confirmation)
> 

The core code, taken from tomcat, is very stable.  Not much has happened 
  recently, though.  If you do use this and want to use the "jndi:" 
namespace, you should use either svn head or the 0.9 snapshot jars in 
http://cvs.apache.org/repository/directory-naming/jars/ until we get the 
0.9 release out.

I will be making some updates to the docs this week as part of the 0.9 
release prep, so keep an eye on the web site for more info on federation 
and the "jndi:" namespace.  For now, to get an idea of how this works, 
see the test classes in the config, core, and factory packages.

Post questions here and bugs (and patches :-) in Jira.

Thanks!

Phil