avalon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mcconn...@apache.org
Subject cvs commit: jakarta-avalon-excalibur/assembly README.TXT
Date Thu, 22 Aug 2002 01:15:52 GMT
mcconnell    2002/08/21 18:15:51

  Modified:    assembly README.TXT
  Log:
  Update on project status, recent activities and refreshing the to-do list based
  on recently achievements.
  
  Revision  Changes    Path
  1.14      +11 -12    jakarta-avalon-excalibur/assembly/README.TXT
  
  Index: README.TXT
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-excalibur/assembly/README.TXT,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- README.TXT	12 Aug 2002 02:33:05 -0000	1.13
  +++ README.TXT	22 Aug 2002 01:15:51 -0000	1.14
  @@ -1,6 +1,6 @@
   
  -Merlin2  an open service management architecture.
  -==================================================
  +Merlin 2  an open service management architecture.
  +===================================================
   
   This package contains work in progress originating from the Merlin container.  It includes
a set of dealing with the definition of a system kernel, container hierarchies, component
assembly, and component deployment and decommissioning.  Everything is this package is ALPHA
and is subject to change. A demonstration of current status is normally possible by invoking
the following ant targets:
   
  @@ -12,12 +12,15 @@
   Status
   ------
   
  +22-AUG-2002
  +Introduction of a LifestyleManager into the kernel abstraction. Upgrading of the lifestyle
management systems to support pooled and per-thread component creation from Berin Loritsch.
 Lifestyle extension management solution inspired by Marcus Crafter and resolved following
joint Merlin/Fortress co-development.  Updgrading of nested kernel behaviour (nested kernel
root container appears as just another nested container).  Documentation updates and enhancements.
 Seperation of the lifestyle interfaces and abstract implementation to excalibur/container
and seperation of the meta-info model to excalibur/meta.  Modification of APIs in relation
to the phase/stage terminology discussion.  System validation against the cornerstone component
suite, several components in Avalon Apps (ORB, PSS, Time) and several non-opensource components.
  +
   12-AUG-2002 
   Container abstraction seperated out such that a container is managed as a classic component
with 
   potential dependecies, extensions, and consumers.  Container creation is independent of
the 
   DefaultContainer base class (any implementation of the Container interface is usable).
Creation 
   of a new container hierachy by a container component is now possible via creation of an
embedded
  -Kernel and requesting theb kernel's root container. 
  +Kernel and requesting the kernel's root container. 
   
   04-AUG-2002 
   Independent threads for containers.
  @@ -48,19 +51,15 @@
   To-Do
   -----
   
  -Short-term:
  -
  -1. Addition of pooled support under a service manager variant as per Merlin 1 is pending.
  -
  -Medium-Term:
  -
   1. Introduction of component factories will be required as a complement to the <component/>
directive - e.g <factory/>.
   
  -4. Upgrading of error handling against classic fail scenarios (class not in classpath,
manifest errors, informative configuration errors).
  +2. Upgrading of error handling against classic fail scenarios (class not in classpath,
manifest errors, informative configuration errors).
  +
  +3. Gentle degrade of service deployment profile on error - if a component cannot be deployed,
disable the activation of all of the dependent service but continue on with deployment of
the remaining services (currently the situation is somewhat of a domino failure effect - if
a supplier service fails, a dependent will fail because the supplier failed - this situation
can be avoided by disabling depenedent services in fail conditions).
   
  -5. Gentle degrade of service deployment profile on error - if a component cannot be deployed,
disable the activation of all of the dependent service but continue on with deployment of
the remaining services (currently the situation is somewhat of a domino failure effect - if
a supplier service fails, a dependent will fail because the supplier failed - this situation
can be avoided by disabling depenedent services in fail conditions).
  +4. Inclusion of explicit directives concerning assembly should be included although quite
complex dependecy maps are readily managable using strait-forward logic based assembly of
suppliers and consumers.
   
  -6. Inclusion of explicit directives concerning assembly should be included although quite
complex dependecy maps are readily managable using strait-forward logic based assembly of
suppliers and consumers.
  +5. Unit testing.
   
   Stephen McConnell
   mcconnell@apache.org
  
  
  

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


Mime
View raw message