directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: svn commit: r542072 - /directory/apacheds/trunk/kerberos-shared/src/main/java/org/apache/directory/server/kerberos/shared/io/decoder/
Date Mon, 28 May 2007 04:30:49 GMT
On 5/27/07, Enrique Rodriguez <> wrote:
> On 5/27/07, Alex Karasulu <> wrote:
> > Just wondering if your kerberos client will use the kerberos shared
> library?
> >  If so I'm wondering if it should
> > go into shared/kerberos?  However I guess it does depend on the core
> right
> > and this is why it is in the apacheds
> > project?
> That question wasn't totally clear on account of the "it"'s.

Yes I see that ambiguity as well now that I read it again.  My point was
if you are putting client PDU code for the kerberos codec into the kerberos
shared module in apacheds then this means any client like a LoginModule
which you write will have a dependency on the kerberos-shared jar.

I don't
> see why I would put a client into kerberos-shared.

I thought from your commit log that you were putting client PDUs into
the kerberos-shared module.  If I'm wrong that's fine.

What other modules
> would share a client?  Instead, other modules would share components
> providing client-side support so what makes sense is to put shared
> Kerberos functionality in kerberos-shared, such as ASN.1 codecs and
> components for requesting TGTs and service tickets, which could be
> shared by different types of clients, be they CLI or RCP.

Ok I see so I was right that you are putting client PDUs into this module.
This just means that clients will now have a dependency on ApacheDS
jars since kerberos-shared is technically an ApacheDS module.  This is
so because it depends on core transitively through the protocol-shared

This might not be a good thing.  If you build a CLI or RCP based client
then it will pull in these dependencies.  You see where I'm going with this?

The Kerberos client I am working on is a CLI client with a dependency
> on Commons CLI.  The CLI Kerberos client currently does depend on
> kerberos-shared, hence my codec commits to kerberos-shared.  This
> Kerberos client should be mostly wiring together Commons CLI with
> codecs and the aforementioned ticket request components.

Yep I get that but it also depends on apacheds-core.

Kerberos-shared is a shared library, intended to be shared by servers
> *or* clients.

Ok this is exactly why it might be better put into the shared project rather
thank keeping it in the apacheds project.  Basically it would be analogous
to the shared/ldap module which does not depend on the core but can be
used by it as well as any clients.  We do not want these shared libraries
for various protocols to be pulling in dependencies from the server.


If you're wondering how this could work with enhancements to
> LdapStudio, then I was picturing LdapStudio plugins would depend on
> kerberos-shared and not pick up any of the CLI-specific code in
> clients-kerberos.

No that's fine. I'm just thinking we might want to move the kerberos-shared
module into the shared subproject instead of keeping it in the apacheds
and removing the dependency on core.  This probably just means replacing or
duplicating (if small) the code that the kerberos-shared module depends on
the protocol-shared module.  Or another option is to move the code that is
depended on into the kerberos-shared module.  I'm sure there are other
as well but the whole point is to remove the dependency that kerberos-shared
has transitively to the apacheds core.

kerberos-shared shouldn't have any dependencies on core.  I think it
> is mostly in apacheds trunk for legacy reasons.

Hmmm it depends on protocol-shared which depends on apacheds-core even
if it may not need the dependency.  Probably there's some small peice of
in protocol-shared that depends on core code but that's not used by the
shared module.  Regardless though you have a dependency imposed due to the
Maven dependency graph which will cause the apacheds-core jar to be pulled
down.  If we can do away with this it will be best.

Though, it does have
> a dependency on ConfigurationException, but that's easy to either get
> rid of or, since it occurs in single vs. multi-base searches, replace
> when we have a better solution for multi-base searching.
> If you're wondering if kerberos-shared can be moved to the shared code
> outside of trunk, then I think that makes sense, with a little
> refactoring to remove minor deps on core.

Yes this the point.


View raw message