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 <[EMAIL PROTECTED]> 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 >
