avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <aok...@bellsouth.net>
Subject Re: Embedding and standardizing kernel parameter handling and discovery
Date Thu, 23 Oct 2003 18:29:58 GMT
Ok I sat down to start implementing the search policy for kernel parameters and would like
to run the default value discovery order by the Avalon folks:

1). First check for parameter value in a merlin.properties file packaged within the same package
as this KernelDefaults file.  

2). If a merlin installation is found based on a non-null MERLIN_HOME use installation base
relative paths to override jar file merlin.properties based values.

3). Check for overriding values in a merlin.properties file anywhere on the classpath.  If
there is more than one merlin.properties file with a value for the property, then the last
path component with a value is used as the effective default property value.

4). Check for overriding values in a dot prefixed (hidden) version of the merlin.properties
file (.merlin.properties) within the user's home directory.

5). Check for default override values within the System properties.


These rules once followed may or may not explicitly set a value for each parameter.  Obviously
null and false will be returned if no value can be found in any property file or env parameter.
 When the default constructor is used to create a KernelParameters bean instance, the search
for parameters occurs and sets the defaults.

Also I can add a method to return a Map representation of the KernelParameters bean if we
want that option as well.  Should I do that?  I will set the property keys (KernelDefaults
constants) to reflect the ones used by Steve in previous emails where I can.

Alex

> 
> From: <aok123@bellsouth.net>
> Date: 2003/10/23 Thu PM 12:17:36 EDT
> To: <dev@avalon.apache.org>
> Subject: Embedding and standardizing kernel parameter handling and discovery
> 
> Steve,
> 
> After doing some research on Merlin for the sake of embedding I've come to some conclusions.
> 
> First I see multiple places where kernel parameters are gathered and handled to configure
a kernel.  Merlin.java, MerlinBean.java, CLIKernelLoader and even in the DefaultEmbeddedKernel.
 Some kernel parameters are present as properties in beans like the KernelContext and in other
places some parameters are put into an associative hash.
> 
> Overall I think we need to find a generalized mechanism for providing these parameters
and standardize the mechanism everywhere in Merlin (as you already stated).  I think you started
to do that with these map arguments.  This is probably the most flexible means to do so especially
when the variables used are in flux but it does not have strict type checking.  Conversely,
using a bean like a KernelParameters object rather than a map would give you strict type checking.
> 
> As I expressed before I think we need to leave parameter gathering up to the embedding
application.  However there are some default kernel parameter discovery mechanisms that should
be provided like getting the MERLIN_HOME parameter from the shell environment.
> 
> I've followed your advice to create an Env class that gets operating system and shell
specific environment parameters.  I'm trying to come up with a parameter discovery process
to default populate a KernelParameters bean's members taking the following steps:
> 
> 1). Check for environment variables first
> 2). Check for properties files on the path with specific names or in the user's home
directory to see if we can get some defaults
> 3). Check the System properties for parameter overrides
> 4). et cetera.
> 
> What do you and the others see for this discovery process?
> 
> You already seemed to design the Kernel Loader using the factory or builder pattern.
 We can stick to the Map approach which gives more flexibility but is less type safe or we
can use a bean like the KernelParameters bean which is less flexible but more type safe. 
Or we could just do both providing alternative create method overloads within the Loader:
it's up to you on how to deal with these trade offs.
> 
> Now we need to centralize the code that implements the default kernel parameter discovery
process and agree on the search order and document it.  If we go with the Map approach we
might create a default map in a Loader.   The Map would contain the defaults and then the
API user provided Map argument to the create call would have its properties overlaid onto
the defaults Map.
> 
> With the KernelParameters bean approach the default constructor can automatically set
member properties using the default kernel parameter value discovery policy based class. 
Whooo thatÂ’s a mouth full.  Anyway I have some mock classes ready to just look at for the
bean based approach.
> 
> Personally I think we need to pick one approach and retrofit it to all the classes that
build a kernel.  IMHO we should not differentiate between embedding the kernel and the CLI
based use of the kernel; everything is an embedding situation.
> 
> So in conclusion which ever kernel parameter aggregation/passing mechanism we pick (bean
based or Map based) we need it to be standardized and well documented.  The default value
discovery policy also must be well documented and the policy code should be separate and isolated
in one place.
> 
> I have mocked up a KernelParameters bean and a utility class to start building a policy
around it.  There is very little code here but I will add it once we agree on a kernel default
parameter discovery policy.   Attached you'll find the Env variable access utility class and
other classes for managing kernel parameters.  Excuse the ugly code for the time being - I
shall beautify once we decide to go a particular route.
> 
> Alex
> 
> P.S. I made the KernelParameters an interface with the DefaultKernelParameters being
the implementation class just in case.
> 
> 
> 

Mime
View raw message