avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: Merger of Merlin/Fortress - first steps ?
Date Thu, 08 Aug 2002 19:14:36 GMT
> From: Stephen McConnell [mailto:mcconnell@apache.org] 
> Berin Loritsch wrote:
> >* How to programatically add and remove containers from the kernel
> >
> The approach dependes on if you "inside container space" or 
> "outside". 

Could you elaberate on this.  My line of thinking is completely inside
container space.  That is how Fortress is meant to work, and I really
don't see how "outside container space" is really applicable.  Of course
that might be because I view the Kernel as a container of containers.

>  If you define a specilized container and you declare this as part of 
> the container declaration in the kernel.xml file, you can intercept 
> things like initialization and so forth.  You could for 
> example control 
> the population of the container (component profiles and 
> sub-containers). 
>  Here is the code for creating a new sub-container.
>   ReferenceDescriptor containerInterface =
>     new ReferenceDescriptor( 
> "org.apache.excalibur.merlin.container.Container" );
>   ContainerDescriptor descriptor =
>     (ContainerDescriptor) manager.getProfile( containerInterface );
>   Container container =
>     createSubContainer( "my-container", descriptor, new 
> ClasspathDescriptor() );
> Component addition is simpler - you simply create or locate a 
> component 
> profile and install it into the container.  The container will do the 
> rest of the work (validation, assembly, etc).

I figured Component addition is fairly simple.

My view on a hierarchical container system is that a parent container
completely manages its child containers, and if there is any central
management, those commands are filtered through the container hierarchy.
At least this is how I designed Fortress.  I originally meant Fortress
as a Container framework--but instead it became its own entity in its
own rite.

> >
> >I like the shortened name, and I would want to do whatever I can to 
> >keep the notion, even if it is implemented in a different manner.
> >
> My guess is the in the majority of cases the shorthand name will 
> actually be replaced by a meta-info class and accessor method.  For 
> example, to get the logging catagories specific to a particular 
> component - I call something like:
>    CategoriesDescriptor categories = profile.getCategories();

Right.  Just as long as I can do this:

  <!-- config info -->

as opposed to this:

<component interface="......" class="......" handler="......."/>

All of those are (or *should* be) handled in metadata.

> >
> >He has an idea of how to express the meta-info, but like his 
> version of 
> >the Lifecycle Extensions I doubt it follows the same interfaces.
> >
> Before going in this direction there is more optimization needed in 
> Merlin in the lifestyle area.  Currently the assumptions concerning 
> singleton policies are restricted to two classes and I want 
> to get this 
> down to only one.  With that done, I will have a good idea of 
> what the 
> patterns of interaction are and what parameters are needed.  The 
> solution will not be identical to Fortress because the solution will 
> involve the passing around of meta-info and meta-data to the target 
> handlers.  

Ok.  Right now, you have a "TRANSIENT" and a "SINGLETON" or something
like that in your lifestyle declaration.  All I want to do is grab that
value and add semantics for "POOLED" and "PER-THREAD".

> >	Stephen mentioned to me that Merlin's logging management is
> >	different than both Phoenix and ECM/Fortress. He mentioned to me
> >	the possibility of supporting the ECM style configuration, I
> >        guess we need to cover this one in a bit more detail.
> >
> >Why does this not surprise me?
> >
> Ouch!

Please don't take offense, but you have a track record for redoing
everything as opposed to reusing stuff.

> >I am very curious as to what exactly is different.	
> >
> Both Phoenix and the Excalibur Logging configuration stules 
> mix together 
> the logging setup for the manager with catagories for 
> components.  I.e. 
> you are forced to declare everything in a single location.  In Merlin 
> components can be packagd with profiles which contain 
> information about 
> default priorities, and type information which declares the logging 
> categories for the component type. Before putting together the Merlin 
> logging model I went over the Phoenix and Excalibur Logging 
> in detail. 
> The good things about Phoenix 1.0 logging was simplicity.  The good 
> thing about Excalibur Logging was breath of coverage. 
> However, both mix 
> information from type, profile and system domains so 
> something new was a 
> necessity.  Keep in mind that every <thing/> in the type and profile 
> defintion in Merlin gets translated into a class of some kind 
> - so its 
> not just a question of using the same XML - its much more a 
> question of 
> achieving a clean API.

All that Fortress/ECM does is expose a logger="foo" attribute which is
used to give the component a separate logging category.

Currently Fortress has separate categories for all its internal systems
so that we can tune the log files to the tightest degree.

One thing that I like is the ability to have categories relative to
a root name.  For instance, something like Cocoon has a hierarchical
container system (the sitemap) that has different instances of
components in the different sitemaps.  It would be useful to know
which component from what sitemap is generating the information.


or something like that.  Is that possible with Merlin?

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

View raw message