directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <brett.por...@gmail.com>
Subject Re: [naming] jar dependency on tomcat?
Date Fri, 30 Dec 2005 03:59:14 GMT
Either 1) or 2). Preference for 2), but not to the extent of it becoming 3).

Did Tomcat give a reason? Was it a matter of access for committing, or
something else?

- Brett

On 12/30/05, Phil Steitz <psteitz@apache.org> wrote:
> I noticed that tomcat naming jars are now available on ibiblio.  The
> code in naming-core, naming-factory, naming-resources and naming-java
> is substantially the same as the tomcat code in the jars with those
> names (with s/core/common).  Given that the tomcat folks were not
> receptive to introducing dependency on [naming] when we asked them a
> while back, I am thinking now that it might be better to go the other
> way, assuming we want to move [naming] forward.
>
> I have managed to get all of the "value add" pieces in [naming] to
> work with the tomcat 5.0.28  jars - XmlConfigurator,
> SynchronizedContext, federation using JNDI URLs,
> JndiURLContextFactory, NamingContextFactory - by just pulling out and
> repackaging [naming]-specific classes.  The remoting capability that I
> have been thinking about using Mina or RMI could also be accomplished
> using the TC jars.
>
> For those unfamiliar with the code, the "value add" in [naming] today
> beyond what is in tomcat is
> * support for synchronized contexts
> * a simple and generic XML configuration capability (similar to
> tomcat, but not limited to J2EE ENC)
> * ability to configure and use "federated" naming contexts where names
> can be resolved across different in-memory local contexts as well as
> ldap-based remote contexts.
>
> So, here is a little poll.  I would appreciate some community feedback
> on the following options.  Any lurkers out there interested in working
> on any of this, pls chime in.
>
> 1) eliminate forked tc code and move to jar dependency, focussing on
> config, federation and remoting support.
> 2) try again to get tomcat interested in having us maintain the core
> code, which they could depend on
> 3) clean up and release the full code base, with tc overlap
> 4) let [naming] go dormant and go work on something else ...
>
> Thanks!
>
> Phil
>

Mime
View raw message