directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Custine" <ccust...@apache.org>
Subject Re: Spring config / Config in DIT
Date Thu, 12 Jul 2007 15:17:57 GMT
On 7/12/07, Aron Sogor <aron@theatlantis.net> wrote:
>
> It is late but let my creative comments fly, no offense Chris is a very
> helpful guy, I am his fan(even if the rest would contradict).


I HOPE the rest would not contradict!  :-D

Please consider that to me and perhaps others embedding ApacheDS, having
> an xml to edit is a great thing!


I probably didn't make it clear, but one of my main goals is to preserve
this for you.  The idea of loading the config via command line is probably
not the way to do it, but if I can get buy-in from everyone I don't see why
we can't just do a file check like we do with ldif files, and load the
server.xml from disk if it was edited.  There may be a few issues to work
around, but it doesn't seem too difficult.

Loading things into a DIT is less pleasant:
> - if it is not LDIF, and I have to start bootstrap the thing to create
> my own config. Like the situation of the schema system right now where I
> have to modify the build and work in your source tree to create my
> custom bootstrap package.


Like I said above, this may not be necessary.  As far as the custom schema,
we want to fix all of this too...

- if LDIF... it is still a weird syntax to use for IOC assembly. I would
> like to modify, add my custom interceptors, and components. One of the
> thing that is less fortunate about the Store procedures and triggers
> that I needed serialized class files, which is hassle for embedding. For
> a build I would have to setup, config, dump config, teardown.


I would rather gouge my eyes out than edit ldif to configure beans, thats
why I am being contrary on this ;-)  As far as the stored proc and triggers,
Ersin has been working on a scripting interface (currently Java 6 only) so
we are hoping to address the usability of the triggers and procs soon.

- I would not like to put/encode xml into an LDIF file.....
>
> I realize that admin tools, vs embedding is in a constant battle.
> embedding needs configuration without actually running the DS.
> admin tool want to configure a bare instance, any possible aspects after
> the DS is started.
>
> Both are legit cases, with very different objectives.


Yes, you are absolutely correct.  This isn't an easy thing for us to
resolve, but we are making a genuine effort to make most people happy.
Because of that, the approach may change several times here before we get it
right.  Obviously, any input and ideas are welcome.

I like DS because it is a Lego toolkit glued together by the IOC, Please
> do not take that way from me.
> DS is great because it is embeddable easy to customize keep that aspect
> alive!


I think in the end you will be happy, but keep giving us feedback on the
ideas that we toss around here on the list.

Thanks,
Chris

Aron
>
> Chris Custine wrote:
> > This is basically a response to some of the other threads regarding
> > server.xml and Config in DIT, but I don't want to derail those threads
> > if this turns out to be a stupid idea.
> >
> > I have been thinking about this for a while, and I have to admit that
> > I am one of the guys that likes Spring and the xml config files.
> > Because of that I have been thinking about possible interim steps so
> > that we can get a good grip on the needs and wants of the users while
> > still solving some of our internal problems that we want to address in
> > the short term.  Based on the recent threads about this topic, I get
> > the distinct feeling that we might be underestimating the affect this
> > subject has as far as user impact and user preferences and stand a
> > good chance of irritating some people.
> >
> > My latest idea seems really obvious the more I think about it...  For
> > the time being, why don't we just move towards storing the server.xml
> > in its entirety as a string attribute under ou=system somewhere and
> > restructure the startup sequence to properly read and load the Spring
> > context from there?  This sounds crazy, but bear with me for a
> > moment...  This would give us the ability to "configure in DIT" so to
> > speak, but would also expose some really interesting options for
> > remote configuration, like modifying the current Apache DS
> > Configuration plugin that Pierre-Arnaud has already written to just
> > read from and save to the server it is currently connected to.  We
> > could also do an interceptor or something similar on the server to
> > write the file out to disk after a remote edit and allow a startup
> > option or quick command line script to load a new file after you edit
> > it in vi or similar.  This CLI could even put the data directly to the
> > JDBM tables so that you can make edits without the server running.
> >
> > I have a couple of reasons for bringing this to the table.  First of
> > all, I am one of those dirty, sadistic perverts that likes editing xml
> > files by hand as opposed to many other forms of config...  xml is like
> > a second language to me  :-)
> >
> > Second and most importantly for ApacheDS, is that an approach like
> > this will give us a great short term benefit of remote config and
> > admin capability, without all of the work.  The server config editor
> > that PAM wrote looks fantastic to me and (hopefully) we can just
> > extend the concept and hack it to do what is needed for this without
> > re-writing all of it.  This way we can do the Config in DIT in an
> > incremental fashion and possibly save some grief that we may encounter
> > later.  We will also be able to move on more quickly to more serious
> > tasks and implement high visibility features.
> >
> > I am sure there are some technicalities that may be obstacles to this
> > idealistic approach, but I have had worse ideas, so I thought I would
> > bring it up and present it.  What do you guys think?
> >
> > Thanks,
> > Chris
>
>

Mime
View raw message