directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrique Rodriguez" <>
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 03:24:51 GMT
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.  I don't
see why I would put a client into kerberos-shared.  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.

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.

Kerberos-shared is a shared library, intended to be shared by servers
*or* clients.  The clients could be CLI or GUI, Swing or RCP.  All the
ASN.1 codecs are in kerberos-shared.  For example, the commit in
question is ASN.1 support for decoding ErrorMessages and will be used
by client-side Kerberos and client-side Change Password.

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

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


View raw message