> - I suggest you take a look at the fortress setup (SomeComponent,
> SomeComponentManager, SomeComponentConfig). That works nicely as a
> 'bootstrap' until you have container services available (it works nicely
> in general, but that's another story)
I think the Loader serves the purpose of SomeComponentManager - please correct me if
I'm mistaken. Now with the KernelConfig is the SomeComponentConfig and the Kernel
itself is the SomeComponent.
> - I like strongly typed configurations (JavaBeans), with a
> bean-per-component-to-be-configured. Add to that a frontend which sets
> up those beans based on some policy :D
I'm there with you.
> - As to policy....using USER_HOME can be problematic for server apps;
> imnhso one should stear clear of userspace. Nevertheless...my preference
> is something like (order of decreasing importance):
I disagree. I think people can embed Merlin into GUI's and other user space
applications. There is also the possibility of running Merlin as a regular user on a
larger system where you don't have access to anything other than your home directory.
Makes sense to use it when no central installation (config) is available.
> - commandline arguments
+1
> - environment variables (as little as possible please; environment
+1
> - ~/.merlin-config.xml
Again I feel that limitations on the kernel embedding jar forces us for the time being
to stay away from the use of XML. I think this will change later. Key thing is to
keep the code that loads the properties or xml separate so it can be swapped out later.
> - /etc/merlin/conf/config.xml
Presumes UNIX layout no?
> - $MERLIN_HOME/conf/config.xml (as little as possible please)
> - ${CLASSPATH}/META-INF/merin-config.xml
> - defaults (maybe using System.properties)
> - fallback (DEFAULT_XXX static variables)
>
> - use xml instead of properties files! XML has many advantages over
> properties files, like the possibility of validation using a DTD.
Again I agree but we need to wait until the population of JDK's used all have an XML
parser to keep the jar footprint down. Perhaps in the next year or two.
> Note that the config builder is responsible for creating the File and
> other non-string arguments as well. If you couple that with
>
> class KernelConfig
> {
> setWorkDirectory( File f )
> {
> Assert.assertNotNull(f); /* natural place for validation :D */
> Assert.assertTrue( f.exists() );
> Assert.assertTrue( f.isAccessible() );
> Assert.assertTrue( f.isWriteable() );
> Assert.assertTrue( f.isDirectory() );
Ahhh you're already using the new JDK features that's why you don't mind using XML.
;-)
>
> this is sweet because it leads to clean component code, where most
> configuration has been offloaded to a seperate class:
>
Yes it is a very clean approach that nicely separates vaidation like you said below.
I like it alot.
> KernelImpl
> {
> KernelImpl( KernelConfig conf )
> {
> Assert.asserNotNull( conf );
> setConfig( conf );
> }
> void doStuff()
> {
> File f = new File( config.getWorkDirectory() + "tmp.txt" );
> // ...
> }
> }
>
> the KernelImpl, in particular, doesn't need to do any kind of argument
> validation! Clean!
>
With this said I'll start working on pulling this altogether. If there are some
serious objections please let me know.
BU,
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
