jumping into something a bit later here...some loose comments
- 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 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
- 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):
- commandline arguments
- environment variables (as little as possible please; environment
variables generally suck for management imo)
- ~/.merlin-config.xml
- /etc/merlin/conf/config.xml
- $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.
// fragments
class KernelManager
{
Kernel getInstance()
{
return new KernelImpl( buildConfig() );
}
KernelConfig buildConfig()
{
/* ... */source4 = ConfigurationUtil.fromProperties( System.getProperties() );
/* ... */
config = ConfigUtil.merge( source1, source2, source3, source4 );
/* ... */
String defaultWorkDirectory = DEFAULT_WORK_DIRECTORY; // or set using System.properties
if(options.hasOption("--work-directory"))
defaultWorkDirectory = options.get("--work-directory").value();File workDirectory = new File(
config.getChild("properties")
.getchild("home-directory")
.getValue( defaultWorkDirectory ) );/* ... */
return new KernelConfig( workDirectory, /* ... */ ); } }
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() );m_workDirectory = f; } }
this is sweet because it leads to clean component code, where most configuration has been offloaded to a seperate class:
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!
[EMAIL PROTECTED] wrote:
Steve,
Really quick I wanted to say the Map idea may be better I just did not know if it was definitively. Might be the better route to go.
disagree :D
1. I think KernelParameters should go into a seperate package that other packages (such as kernel) depend on. This will make it easier when creating the bootstrap process.
disagree! Recognize the tight coupling between config and component and reflect it :D
2. Rename KernelParameters to KernelBean? Everything about it seems to be beenish in nature.
KernelBean sounds too much like it is the kernel itself as a bean don't you think?
Suggestion: ***Config.
cheers!
- LSD
PS: could we trim our quotes please?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
