I concur with all of this.

Given that org.apache.naming is already packaged separately, I'll grab the latest stable binary release of the org.apache.naming stuff and use that, rather than tomcat CVS.

I'll talk over the approach for achieving a better separation of org.apache.naming from tomcat with Remy. I don't mind doing any necessary work to achieve that one, because I suspect that some of the stuff I write ought to end up similarly located.

As for involving Remy, I will certainly pester him with questions, but only after I have had a bit more of a look into it. (There is nothing more annoying than questions from someone who has obviously not read the docs - especially when they ought to know better! I want to avoid putting myself in that category.) On the surface of things, the naming code looks like I should be able to just drop it in and fire it up.

I intend to try to knock off a fairly simple phase one in the next few weeks. This ought to give us a working JNDI tree and a way to put things in there through the use of a configuration file. I will make this a separate configuration file to the standard James config.xml, because it ought to be generally applicable.

Any fancy classloader stuff and context separation can wait until after this. It will bear a little more thinking about and that is best done with some experience of the JNDI implementation under our belts.

Lastly, my apologies to anyone (particularly the Avalon crowd) who thought my obsolescent rut comment was directed at them. It was not intended that way at all, but seems to have been taken that way. The intent was simply to point out that making our own build of the naming stuff and depending on that was a step toward a hard-to-unmaintain codebase.

Cheers

ADK



Noel J. Bergman wrote:

Aaron,

I agree that we've reached a suitable consensus to move forward.

Please use org.apache.james.naming. JNDI is a Sun trademark. Yes, parts of
the code will be an Avalon component, but as you noted other parts will be
more generic. We need it here for active development, not in the Avalon
repositories. We can deal with any handoff afterwards.

Tomcat produces three jars related to this issue: naming-common.jar,
naming-factory.jar, and naming-resources.jar. Right now org.apache.naming
is managed with Catalina, either in the Tomcat 4 module, or the newly
separated jakarta-catalina module.

We should contact Remy & Co (I'll cc him), and let them know of our plans to
use the code. We might ask Remy two questions: (1) about moving commonly
useable portions of org.apache.naming into a naming sub-project (perhaps of
Commons), and (2) about his helping out over here a bit, just to help us get
going with JNDI inside of James. But from what I see, the code has been
extremely stable, so I don't know that you should worry about it changing
out from under us.

With respect to Avalon that is different, but you also shouldn't worry about
it. Those issues are being worked out. The Avalon Community was in a bit
of turmoil, but there is very much a new awareness that they have a
responsibility to support Avalon consumers differently from how it was done
previously. And for our part, we will be more proactive about ensuring that
we are only distributing release copies of their jar files (other than in a
deliberate test build).

--- Noel

-----Original Message-----
From: Aaron Knauf [mailto:[EMAIL PROTECTED]]

Hi again,

For the moment, I am putting my code in org.apache.james.jndi. Before I
get too far down the track, we will need to agree whether this is
appropriate. One thing to consider is whether or not this work should
be specific to James, or whether it should be a commons package, or even
an Avalon thing.

-----Original Message-----
From: Aaron Knauf [mailto:[EMAIL PROTECTED]]

Hi,

I believe that enough of a consensus has been reached that we can safely
say that JNDI support will be including in an upcoming James release.
The details of exactly what it will be used for (and how) are still to
be finalised.

I am beginning work on providing a useable JNDI facility, based on
org.apache.naming. This will be an Avalon Component. For the moment, I
am simply experimenting to familiarise myself with the apache nameing
code and also with Avalon, so I will develop against the CVS version of
apache naming. Moving forward, we will need to agree on the correct way
to establish this dependency.

Two things seem obvious to me here:

1. We don't want to depend on the whole tomcat project just to get
the Naming stuff.
2. We don't want to get stuck in an obsolescent rut, as we are with
our stone age Avalon release.


Any ideas on the best way to do this?


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to