So I think that the idea of making the components container agnostic
is a great idea and I think the best way to do that is to start by
removing the configuration objects and dealing directly with the
functional components, as Chris and I have been suggesting.
I also think you are seriously underestimating the effort involved in
storing fine grained configuration information in ldap without hand
coding the translation between the data store and actually creating
the objects. It took at least 5 years to come up with jaxb, which
finally seems to be a usable approach for xml. jdo/jpa also has been
under various kinds of development for at least 5 years. IIRC Ole
said he could come up with a ldap - object mapping in a couple of
weekends, but that was 6 months ago and he is still saying it will be
done in a couple of weekends. I may be wrong but with the number of
technologies that he usually mentions I have a hard time believing
his solution will be sufficiently lightweight.
I think you are also seriously underestimating the difficulty of
writing a usable container framework. AFAIK Spring doesn't do too
much except act as a wiring framework, but at least it works and is
well understood. IIUC it does not really do dependency management
which I think is required for changing configuration without
restarting the entire server on any change. When I looked at OSGI it
had a nice classloader and a big spec, but I couldn't find a wiring
framework or component model or component dependency management.
(I'm sure I missed a lot of OSGI). Geronimo makes you describe the
component metadata in a rather inconvenient java form although it has
a wiring framework and dependency management.
I think a reasonable path to follow would be to:
-- stop abusing spring, i.e. remove the configuration objects and
make the functional objects container agnostic.
-- consider xbean-spring to make type-checked configuration files
-- do some experiments to see about ldap <> component mappings.
Maybe Ole's system will be lightweight enough to be used for server
startup. Maybe you can write something else that works and is easy
to extend to new components.
-- if those experiments succeed, try storing the configuration in the
dit.
I still think that editing the configuration in ldap is going to be a
lot more unpleasant than in an xml file with a schema telling you
what's legal.
Are the distinguishing features of config-in-dit of big importance to
users (replicated configuration changes and configuration change
history, IIUC)?
A couple more comments inline below...
thanks
david jencks
On Jul 17, 2007, at 9:16 PM, Alex Karasulu wrote:
Hi Chris (you spring lover you :) ),
More inline but not snipping much since it's all very relevant ...
On 7/17/07, Chris Custine < [EMAIL PROTECTED]> wrote:
On 7/17/07, Alex Karasulu <[EMAIL PROTECTED]> wrote:
Hi David,
On 7/17/07, David Jencks < [EMAIL PROTECTED]> wrote:
On Jul 15, 2007, at 8:03 PM, Alex Karasulu wrote:
Hi all,
Here's that thread on discussing the CiDIT agenda. Let's take a
look at the following
link before beginning:
http://directory.apache.org/apacheds/1.5/configuration-in-dit-
cidit.html
Thoughts? Comments?
Yikes, I'm afraid this will take 6 months to a year to do, and
unless you write "jdo for ldap", including an enhancer, I think
its' going to be pretty painful to add new configuration elements.
Yes it would take considerable time if we did it by hand. I think
we can avoid this with a solid persistence mechanism for LDAP which
also generates the LDAP schema from bean interfaces.
What is this enhancer you talk about above?
In jdo or jpa you run an enhancer on your persistence capable classes
and it takes the starting pojo class and changes the bytecode to
actually talk to the persistence framework so your objects are loaded
correctly and modifications saved correctly. What the enhanced
bytecode does is moderately similar to a lot of the code in the "hand
enhanced" persistence objects in my copy of triplesec. I'm not all
that familiar with jaxb, and its goals are much more modest than jdo/
jpa, but IIUC it manages to do xml<> object translation with just the
aid of a whole lot of metadata. Since you appear to want to be able
to replicate single-property changes I think you'll need something
more like jdo/jpa than jaxb.
Someone suggested a while back that we avoid the "jdo for ldap"
problem by just storing server.xml in ldap as text. IIUC this
could be done in a couple of days. Exactly how much really useful
functionality would this lose compared to the fine grained approach?
This has a few issues but the most important one is that I want
eventually to replicate
the configuration within a cluster. Yes this would still be
possible but I don't want to
replicate the entire configuration ... just the parts of it that
should be shared across the
cluster. With a blob in the DIT you have to replicate the whole
thing.
Another issue is with LDIF exports of the blob. I like the idea of
dumping the configuration and then importing it perhaps with
changes. This becomes more of a problem with a big XML blob. Hand
exiting an XML embedded within an LDIF is a PITA.
So lets not do it :-)
The point I was trying to make is that people will export the
server's configuration as LDIF with
the CiDIT approach with pure LDAP entries that do not have XML in
it. Then they can load it
into another server.
I don't like the idea of editing LDIF to affect configuration
changes on the server. If we store the XML (or snippets) directly,
we don't need the LDIF and we can bypass it.
Well another problem is tracking changes. Don't forget that we
will have a change log and if
we store things in XML blobs we will simply obscure what is
actually being changed. It's going
to take more code to figure out the exact changes made.
I have a lot of notes that I will post about how we can do this
very easily without a lot of demolition of current code.
But the question still in my mind is whether or not this is the
right approach. LDAP is
ideal for storing configuration information. Why are we resorting
to XML and not eating our
own dog food.
The whole attribute value with the XML blob must be replaced for
even the simplest changes to the configuration. You also cannot
easily determine exactly what changed to notify the component
corresponding to the configuration object that changed.
I'm not sure how plausible this is until we go to OSGi so maybe we
should defer that goal anyway?
Well we will defer the actual implementation but we still have to
keep an eye out to make sure
that what we are doing today does not close any doors tomorrow. I
don't want to be stuck in
a perpetual state of stepping backwards every time we have to
introduce new features like this.
You cannot easily search and modify configurations through simple
LDAP clients.
This is a hack.
What if each component/bean configuration were stored as xml text
separately, each with a (unique) name, and the links were
determined by the names?
Sure that could be done as well but why not just bang it out if
you're going to wrestle with
all this anyway.
BTW, unless you write a fancy dependency tracking system ( i.e. the
geronimo kernel) I think that any change basically requires
stopping and restarting the server, so I'm not sure there is really
much advantage to splitting up each bean separately.
The dynamic reconfiguration capabilities will be reserved until we
do have such a system: OSGi based most likely.
And finally, why are there all these configuration objects that
spring creates that then go and create the actual runtime objects,
rather than having spring create the runtime object directly? In
particular, why is there an interceptor configuration object rather
than just interceptors?
They were there since the beginning. I have no idea why they were
put there. What I do know is that I want to get Spring out of the
picture and make this server container agnostic. Then we can wrap
it up in any kind of container we like.
A point that I have been trying to make is that if we remove the
configuration beans and let the components contain their own
settings, that is achieving container independence too,
The problem with this is that you're still going to have some
grouping of settings no? If the
functional interface of a component is 3 methods and there are 10
properties for settings
then those 3 methods are going to be obscured. Composite classes
grouping these settings
will surely emerge. Then we are back to having beans again.
Can you provide a concrete example of what you are talking about
here? So far to me I can't imagine how removing the configuration
objects could do anything but make the code simpler cleaner and much
easier to understand.
and that is the way it should be. At that point, ANY framework can
configure the components, whether it is Spring, OSGi, Java
instantiation, etc. I really think the configuration beans are the
root of all evil in this discussion and it seems like we keep
coming back to them as either the cause or symptom of something.
So lets toss 'em and configure the components so that we can keep a
1:1 relationship.
Essentially I think we're going to have to do the same things to
get to this state. We need to
factor out the init code that uses these beans from various
components that configure subcomponents.
How we expose the settings on the component interfaces is a minor
point: whether using a complex
object as one setting property or having several setting
properties. It makes no difference.
Are you finding that Spring has some limitations that you are
running into? Otherwise why eliminate it?
Same reason I keep OSGi out of the core or why I stripped out
Avalonisms. Let's stay container agnostic.
Well, as I said above, the configuration beans and removing the
ability to directly configure the functional components directly
seem to be the limiting factor to me.
Hmmm loosing you here a bit. You mean to say 'enabling' rather
than 'removing' here? I
thought you want the container to handle the functional component
directly right?
If we used Spring the way we should be using it, I think we can
have our cake, and eat most of it ;-)
My problem is proposing Spring to do this. The container discussion
about which one
to use should come after we have prepared the server to enable the
direct configuration
of the functional components.
Alex
