[ApacheDS] Refactoring out the Configuration bean from core (was: svn commit: r542072)

[Alex Karasulu <ak...@apache.org>]

On 5/28/07, Enrique Rodriguez <en...@gmail.com> wrote:
>
> On 5/27/07, Alex Karasulu <ak...@apache.org> wrote:


SNIP ...

> 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
> > code
> > in protocol-shared that depends on core code but that's not used by the
> > kerberos
> > 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.
>
> The major culprit is ServiceConfiguration, which depends on
> Configuraton and ConfigurationUtil, both of which are in the core.
> Everything else in protocol-shared is easy to deal with.
>
> > > 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.
>
> I can make that happen by moving kerberos-shared and protocol-shared
> to the shared subproject.


Perhaps protocol shared should stay in apacheds?  However if this
Configuration class
is the only issue then I guess it can go into shared.

protocol-shared should move since it was
> intented to be shared by protocols.


OK but will it depend on the core once this Configuration dependency is
fixed?

That leaves core Configuration
> deps.  Any thoughts there?


Service configuration classes need not depend on Configuration.  I think we
are loading too much
functionality into them.  These configuration classes should simply contain
getters and setters for
the properties of the service or other complex properties. They should
simply be used to enable
Spring to intialize and set the required properties on them.

I think we talked at one point about
> moving Configuration to its own module.


Yes I think so but this specific context may not be involved with that.
There is no need for
ServiceConfiguration to extend Configuration is there?

We may need a separate base
> class for service (protocol) configuration vs. core configuration.


Yep I agree.  I just can't figure out why ServiceConfiguration would extend
core Configuration.
Are you using the functionality in it which embeds the bean into the JNDI
context some way?

This Configuration bean is a big problem.  It has some bogus logic which
embeds a
MutableStartupConfiguration into an enviroment Hashtable using for JNDI
environments.  This
MutableStartupConfiguration also contains a slew of references to core
classes.  It's all very
tightly coupled.  I'd like to fix that but where to start is the big
question.  I think the best
solution for the immediate problem at hand is to not extend from
Configuration in ServiceConfiguration.

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.


This is true that an InitialContextFactory needs a Configuration object in
it's environment
however why would for example the KerberosConfiguration need this?

Alex

Re: [ApacheDS] Refactoring out the Configuration bean from core (was: svn commit: r542072)

[Enrique Rodriguez <en...@gmail.com>]

On 5/28/07, Enrique Rodriguez <en...@gmail.com> wrote:
> ...
> 1)  In about 4 hrs. (~11pm EST) I'm going to do a set of commits to
> break the deps between kerberos-shared, protocol-shared, and the core.
>  I expect to move quickly through the commits, but it could mean a
> window where the trunk doesn't compile.  Note, this will NOT include
> the move of kerberos-shared and protocol-shared to the shared
> subproject.

OK, this is done.  Check out the deps for protocol-shared.

> 2)  Also, I'm going to move the 4 new interceptors into a 'kerberos'
> package in core.  I can see these interceptors growing into 3 separate
> packages, for kerberos keys, password policy, and multi-realm, but for
> now I just want to get this dep situation cleared-up so I'm going to
> move them into 1 package.

I moved KeyDerivationService and PasswordPolicyService but not
KeyExportService nor CatalogService.  I'll keep working on them and
get them in later this week.

Enrique

Re: [ApacheDS] Refactoring out the Configuration bean from core (was: svn commit: r542072)

[Enrique Rodriguez <en...@gmail.com>]

On 5/27/07, Enrique Rodriguez <en...@gmail.com> wrote:
> On 5/27/07, Alex Karasulu <ak...@apache.org> wrote:
> > ...
> > Are you using the functionality in it which embeds the bean into the JNDI
> > context some way?
>
> Consider the dep gone.

1)  In about 4 hrs. (~11pm EST) I'm going to do a set of commits to
break the deps between kerberos-shared, protocol-shared, and the core.
 I expect to move quickly through the commits, but it could mean a
window where the trunk doesn't compile.  Note, this will NOT include
the move of kerberos-shared and protocol-shared to the shared
subproject.

2)  Also, I'm going to move the 4 new interceptors into a 'kerberos'
package in core.  I can see these interceptors growing into 3 separate
packages, for kerberos keys, password policy, and multi-realm, but for
now I just want to get this dep situation cleared-up so I'm going to
move them into 1 package.

Enrique

Re: [ApacheDS] Refactoring out the Configuration bean from core (was: svn commit: r542072)

[Enrique Rodriguez <en...@gmail.com>]

On 5/27/07, Alex Karasulu <ak...@apache.org> wrote:
> On 5/28/07, Enrique Rodriguez <en...@gmail.com> wrote:
> > ...
> > I can make that happen by moving kerberos-shared and protocol-shared
> > to the shared subproject.
>
> Perhaps protocol shared should stay in apacheds?  However if this
> Configuration class
> is the only issue then I guess it can go into shared.

The Configuration class was the only issue, but it is gone now in my
working copy.  I recommend we just move protocol-shared to shared.

> > protocol-shared should move since it was
> > intented to be shared by protocols.
>
> OK but will it depend on the core once this Configuration dependency is
> fixed?

No, the only deps left are logging and junit (which may even be
inheritable from some parent).

> ...
> > I think we talked at one point about
> > moving Configuration to its own module.
>
> Yes I think so but this specific context may not be involved with that.
> There is no need for
> ServiceConfiguration to extend Configuration is there?

No, and it is gone in my working copy.  I'm not sure of the history of
the JNDI_KEY but it doesn't appear to be needed for services.

> ...
> > We may need a separate base
> > class for service (protocol) configuration vs. core configuration.
>
> Yep I agree.  I just can't figure out why ServiceConfiguration would extend
> core Configuration.
> Are you using the functionality in it which embeds the bean into the JNDI
> context some way?

Consider the dep gone.

Enrique