|
Home > Archive > Apache Directory Project > December 2005 > [naming] jar dependency on tomcat?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[naming] jar dependency on tomcat?
|
|
| Phil Steitz 2005-12-30, 2:45 am |
| 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
| |
| Brett Porter 2005-12-30, 2:45 am |
| 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-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.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
>
| |
| Phil Steitz 2005-12-30, 2:45 am |
| On 12/29/05, Brett Porter <brett.porter-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Either 1) or 2). Preference for 2), but not to the extent of it becoming =
3).
Thanks.
>
> Did Tomcat give a reason? Was it a matter of access for committing, or
> something else?
No reason. No response actually.
Phil
|
|
|
|
|