Berin Loritsch wrote:
>>From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>>
>>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.
>
A kernel is a component as a such you can create other components with
dependecies on a kernel. You could for example create a kernel
programatically to manage a hierachy of system services that you want to
use in another component. You just need to declare a new compoent that
has dependecies on a Kernel. In this scenario, the componet is outside
of contasiner space and can access and navigate the container hierachy,
add new containers, install components into the hierachy, etc.
>
>
>
>> 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.
>
>
Basical principals are the same in Merlin. A context object flows down
the hierachy of containers - however, this is different to the context
object supplied to components. Components onbly get context information
that declare that they need.
>>>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:
>
><jdbc-datasource>
> <!-- config info -->
></jdbc-datasource>
>
>as opposed to this:
>
><component interface="......" class="......" handler="......."/>
>
>All of those are (or *should* be) handled in metadata.
>
>
You going have to expand the example before I can give you an answer on
this one.
>
>
>>>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".
>
>
Merlin 1.0 has TRANSIENT and SINGELTON.
Merlin 2.0 is only SINGLETON with a plan to add add pluggable handlers.
The idea is that the core Merlin framework will never need anything
more that singleton and the ability to dynamcially load other handlers.
>
>
>>> 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.
>
It's called evolution.
;-)
>>>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.
>
>"cocoon.root.fooapp.generator.file-generator"
>
>or something like that. Is that possible with Merlin?
>
>
>
Yes.
Logging is always relative to the container the object is created in.
If you have a container hierachy aaa/bbb/ccc and you add component xxx
you will get a logging category of aaa.bbb.ccc.xxx. Also, any logging
categories declared i the metamodel for the compoennt type will appear
as subcatagories of xxx (i.e. aaa.bbb.ccc.xxx.my-sub-catefory). All
Merlin substems are seperated out into seperate categories (type loader,
registry, assembly system, export, etc). See doc on logging for
additional information.
Cherrs, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
