avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: [A5] Current State of affairs
Date Tue, 18 Jun 2002 00:28:56 GMT


Berin Loritsch wrote:

>Currently what we have decided on so far--i.e. the agreements are:
>
>1) Better documentation in the package.html for the correct way to
>   use and extend Context.
>

Can be addressed independetly of A5 as part of A4 ongoing development.

>
>
>2) Most agree that we should consider using Commons Logging instead of
>   maintaining our own.  Any dissenters I missed?
>

Can I hold onto an option to dissent?
I love log kit configurability and structure from a management point of 
view.  Provindg changes don't eliminate any of that functionality I'll 
be happy.  Otherwise you will be pushing me to dissent. :-)

>
>
>3) Configuration and Parameters are essentially the same concern, and
>   most likely should be merged into one *able interface.  I.e. either
>   write a Parameters.fromConfiguration() in the configurable method
>   or pass them both.  I prefer the first option.
>

There are some guys over on the OpenORB project who are using 
paramerarizable specifically to avoidd the more expensive loading and 
parsing of an XML doucment.  A parameter from a properties file is far 
more efficient.  I would prefer that these two stayed seperate (i.e. no 
change).

>
>
>4) Activity: Maintain the same setup as A4.  I.e. separate Initializable
>   and Disposable.  Oh yeah, and Nicola doesn't like that or context. ;P
>
>5) CM should at least look like this:
>
>interface ComponentLocater /* or ServiceLocator */
>{
>    Object lookup(String role) throws ComponentException;
>    boolean hasComponent(String role);
>}
>

Which is basically equivalent to A4 ServiceManager assuming release() is 
depricated.  As far as A4 is concerned I thinkk we should introduce this 
into the service package (renamed to ServiceLocator for package 
consistency), update ServiceManager to extend from ServiceLocator for 
backward compatability, and declare ServiceManager as a depricated 
interface.  That provides a complete migration path now - now need to 
wait for A5.

>
>
>class ComponentException extends Exception
>{
>   // ... skip constructors and impls.
>
>   String getRole();
>   Throwable getCause();
>}
>

+1
Could be added to the current A4 defintion of ComponentException and 
ServiceException without brreaking anything.

>
>All dissent is on anything extra.
>

I think the main thing missing in the above is the work on getting a 
formal meta model in place as part of the framework.  This can be viewed 
as an A4 activitiy because there are not obsticles and no changes needed 
to put it in place.

One final note - given the above - I'm really questioning the necessity 
for an A5 any time soon (blame that on Pete Royal for putting the 
thought into my head, and yourself for presenting the above summary 
which seems to negate a requirement for package name changes).  

If instead if I look at the hot topics - Avalon 4.2

  - doc updates
  - putting a locator in the framework.service package
  - update the ComponentException/ServiceException to hold a role reference
  - focused activities on framework metadata
  - focussed activites on common logging and how that relates to logkit
  - focussed activites on common container services (assembly, security 
policy, etc.)
  - other commons related stuff to ensure communication of framework 
resources
    such as configuration
  - component demos
  - more demo
 
Then I get everything I wanted from 5.0.  
ECM has a migration path via the service package.  
Nothing breaks.  

Cheers, Steve.

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message