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 06:11:32 GMT
OK this is exactly what I was thinking regarding ServiceConfiguration not
extending (core)
Configuration ... I just changed the subject on this thread for searching
archives and posted
my response to the list.  I think we're talking about the same exact thing

And BTW kerberos-shared once moved to shared/kerberos should be just like
shared/ldap in
that it should contain the protocol PDU elements.  It should not contain
anything that is specific
to a client or specific to the service that plugs into apacheds.  The
shared-ldap module for
example contains the client and server (req/resp) PDUs for LDAP.  It does
not contain the
LDAP protocol service which is in apacheds. Is this analogous with what is
to be shared/kerberos?


On 5/28/07, Enrique Rodriguez <> wrote:
> On 5/27/07, Enrique Rodriguez <> wrote:
> > ...
> > I can make that happen by moving kerberos-shared and protocol-shared
> > to the shared subproject.  protocol-shared should move since it was
> > intented to be shared by protocols.  That leaves core Configuration
> > deps.  Any thoughts there?  I think we talked at one point about
> > moving Configuration to its own module.  We may need a separate base
> > class for service (protocol) configuration vs. core configuration.
> > That makes a lot of sense and of course Spring doesn't care.  I
> > thought there was some requirement that a core Configuration had to be
> > in the env when obtaining a context using CoreContextFactory but I
> > could be mistaken.
> I did some more checking.  Most protocols had the following line in
> their env setup for using CoreContextFactory:
> env = new Hashtable<String, Object>( config.toJndiEnvironment() );
> The 'config.toJndiEnvironment()' required that every
> ServiceConfiguration extend core Configuration or an exception is
> thrown for ServiceConfiguration not being an instance of
> Configuration.  If I just remove this line, I can make
> ServiceConfiguration the base of its own hierarchy and everything
> appears to work just fine.  Any clue what that was there for and if I
> can just remove it?  Tests pass and the server runs fine in
> server-main.
> With that gone and ServiceConfiguration not extending Configuration,
> the deps from protocol-shared can be easily removed.  In fact, I have
> the deps totally removed now and after more testing I will likely
> commit the changes on Monday.  I also apparently have to move all
> interceptors into the core.  I have 3 interceptors (password policy,
> key derivation, and key export) and of course interceptors have tight
> deps to the core.
> I will commit everything on Monday after I test more.
> Enrique

View raw message