On 7/11/07, David Jencks <email@example.com> wrote:
I would hope at some point these could be generated from
the functional objects through something like xbean-spring + jaxb or
Hmmm not sure what you're suggesting here. You mean like having annotations in
the component (a.k.a. functional object) that are used to define the configuration data?
Something we discovered in geronimo is that most
people don't like to have to specify any metadata in their objects --
our attempt to ask people to tell us what their component looked like
(GBeanInfo) has met only resistance. I don't fully understand why
you need the configuration objects with spring, rather than having
spring create the functional objects directly.
This is to make it easier to map config data into LDAP data types without having
funky rules on how it is interpreted. Data in LDAP entries directly translate into
properties in configuration beans without some kind of extra interpretation which
may require instantiating functional objects. The Spring configuration has many
extra implicit meanings in how it builds beans: it's not just about simple configuration
I'm still worried by the configuration in ldap idea..... I sure hope
its comprehensible without living in eclipse.
It's really not that big of a deal since LDAP can be used from the command line as
well. Also having the configuration in the DIT will make using JMX to access and
manage the configuration easier as well.
The XML stuff can still be used to override the smart defaults the server would use
in the DIT also. So you just get the best of all worlds.
On Jul 11, 2007, at 9:48 PM, Alex Karasulu wrote:
> Hi all,
> Here and there I started experimenting with moving the
> configuration into the DIT. The first
> obstacle I encountered was the way in which our configuration
> really carries functional objects
> in it rather than configuration data which is primarily due to
> advantages in using Spring for
> configuration. Let me elaborate more with a specific example.
> Take the interceptors: these entities in the Spring configuration
> file, server.xml, are listed as
> beans which instantiate the actual interceptor classes themselves.
> Let's take a look into the
> <property name="interceptorConfigurations">
> <property name="name" value="normalizationService" />
> <property name="interceptor">
> vice " />
> <property name="name" value="authenticationService" />
> <property name="interceptor">
> class="org.apache.directory.server.core.authn.AuthenticationService" /
> As you can see the standard interceptor configuration object
> carries in it the interceptor bean. The
> interceptor's class is loaded and instantiated using the default
> constructor and setter injected into
> the interceptor property of the MutableInterceptorConfiguration
> object which is also instantiated.
> The problem here is that the configuration object contains the
> functional components themselves.
> This is not good if we just want to have purely configuration based
> beans. What we want in the
> interceptor configuration is the name of the service and the fully
> qualified class name of the
> interceptor to instantiate along with any custom properties
> associated with the configuration.
> As an experiment I modified the MutableInterceptorConfiguration
> bean class to have two String
> properties. One for the name of the interceptor (really the id)
> and another for the fully qualified
> name of the interceptor class. Then I modified the initialization
> sequence to load this class
> from the configuration rather than let Spring do it. So if we are
> to do this across the board we're
> going to have to apply this pattern of operations:
> 1. Modify all configuration beans to hold non-functional
> objects which contain *only* config data
> 2. Modify the initialization sequence for the respective
> components to use configuration beans
> to drive instantiation and dependency injection for these
> Once all the configuration beans contain no functional objects
> (components) themselves but just
> the information needed to instantiate components and inject
> dependencies then we are ready to
> model configuration beans using an LDAP schema. This is perhaps
> another topic to consider
> after getting the server.xml working with just these changes.
> I'm going to go ahead and commit my changes to the trunk and begin
> working on making partition
> configurations use just configuration data instead of functional
> objects. I know we're close to a
> release but I think I can get it done quickly. Let me know if
> anyone has any objections.