directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject [ApacheDS] Refactoring out the Configuration bean from core (was: svn commit: r542072)
Date Mon, 28 May 2007 06:04:24 GMT
On 5/28/07, Enrique Rodriguez <enriquer9@gmail.com> wrote:
>
> On 5/27/07, Alex Karasulu <akarasulu@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

Mime
View raw message