avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: Migrating from ECM
Date Wed, 17 Jul 2002 19:32:41 GMT


Robert wrote:

>Hhmm... ok, let me see if I understand this, using ECM as an example.
>
>I currently have a roles.xml file and a config.xml file. If I read the
>merlin site correctly, the role (no pun intended) of the roles.xml file
>is replaced with the <component-class>.xinfo files? And the container
>definition has the equivelant of my config.xml file is handled by the
>container definition for Merlin. 
>

Sounds correct (but keep in mind that I havn't used ECM). In Merlin the 
<component-class>.xinfo fiel holds information about the type - its 
dependencies, tyhe services that it is capable of providing to other 
compoennts, the context information it needs and any type related 
attributes.  

Given type defintions, then next thing your concerned about is 
instantiating an instance of the type and tha's where profiles come in. 
 The container defintion contains <component> declarations (which are 
the instantiation profiles) and as you point out - are equivalent to a 
manually supply a configuration (except that profiles let you setup 
logging characteristics like debugging levels, and other stuff that 
enables a happy compoennt).

>
>Did I get that all right? 
>

I think so :-)

>I know there are a few other things that
>merlin has/needs, but is that crossover correct? 
>
>As for dependencies, you are right that they are a complex thing and
>I've seen threads on this list about them in the past. From my usage, I
>don't really need 'startup' dependencies, i.e. during the config
>process, but after all the config/init has happened and it all starts
>'running'. Maybe if I could have a component tell its container "hey,
>I'm good to go", and be able to config the container so that unless all
>components are good, don't service anybody, that would be good enough
>for me. 
>

If you can draw a graph on a piece of paper that states which links 
<compoent-class> --> <service> --> <dependecy> --> <compoent-class>
and 
you don't end up in a circle, then Merlin will run this without problem 
and 7you only need to declare the inital component in you container 
(Merlin will figure out the rest for you).

>Right now I know something isn't right because I have a ton of
>logging going on, but from the top, or user level, they error/exception
>doesn't say a whole lot because it is really nested down. Make sense? 
>

Yep.
Something you will appreciate is the Merlin logging management.  You can 
control logging priorities at any level and nest the defintion of these 
anywhere in the kernel, container, or component - Merlin will 
automatically take care of linking these logging declarations together 
to create a single logging hierachy and ensure defaults flow for the top 
down through any logging category.  This means you can easily swith on 
logging for a particular area to see what's happening.


>I
>know Merlin doesn't do what I'm suggesting, but do you have any thoughts
>on where/how I could maybe subclass DefaultContainer to provide such
>functionality in the future (like 4 - 6 months down the road).
>  
>

First step will be enabling specilizations of Kernel.  A specialization 
of kerenl publishes the services it has established bu the defintion of 
kernel does not say how services are established.  The pricipal is that 
you can wrap complex legacy applications as pure kernels and use these 
as "dynamic component types" - i.e. components that declare their 
available services after initialization (refer Kernel getResources() 
method).  These kerenels can then be used in classic component 
dependency management as candidate service providers  - but this is 
advanced stuff (think of it as direction for the moment).

Cheers, Steve.


>Thanks a bunch,
>Robert
>
>-----Original Message-----
>From: Stephen McConnell [mailto:mcconnell@osm.net] 
>Sent: Wednesday, July 17, 2002 1:45 PM
>To: Avalon Developers List
>Subject: Re: Migrating from ECM
>
>
>
>Robert wrote:
>
>  
>
>>Thanks for the info about Merlin. I'm looking through the docs now and
>>will download and play with the demo as well. I'm not using the context
>>lifecycle, but I think I could really use the dependencies that you
>>mention. 
>>
>>    
>>
>
>Great!
>Some things to me careful of!
>1. make sure you include new component definitions in your jar maniest 
>(see execalibu/assembly/demo/src/etc/demo.mf for an example)
>2. make sure you include the <component-class>.xinfo file in your jar
>file
>3. make sure you inlcude your jar file in a classpath declaration in 
>either the kernel or container level (see 
>excalibur/assembly/src/etc/kenel.xml for examples).
>
>Exception reporting on the above cases needs more user friendly messages
>
>(its in the plan).
>
>  
>
>>One problem I have right now is that if one of my components does not
>>configure properly, I have no real way of 'knowing' this from other
>>components or the container. I'm using 4 components right now and they
>>are all interdependent at some level. In a nutshell what would be nice
>>is that if a component does not configure the container/service
>>    
>>
>manager,
>  
>
>>etc would know about and not allow it to be active. This might break a
>>few rules and from what I know right now, there is no callback from the
>>component to say "I'm not ready/configured".
>> 
>>
>>    
>>
>
>Interdependecies between a family components generally means circular 
>dependecies which will result in a failure.  The solution to this is to 
>handle the components "as a family" where the container knows about the 
>inter-relationships the the lifecycle sequencing that will work.  The 
>Merlin architecture has this in mind - I want to provide pluggable 
>containers implementations and pluggable kernels that hide "family" 
>issues like your describing.  Currently the Merlin implemenmtation 
>supports a DefaultKernel and a DefaultContainer - these assume 
>non-circulare dependency conditions - however, I also need solutions for
>
>"family"based  lifecycle management and as such will be introducting 
>support for this as soon as the core framework is completed.
>
>One of the nice things about the framework is that the seperation of 
>kernel and container hierachy allowing for the inclusion of a kernel in 
>a container.  This means that a kernel can container a kernel which 
>means that a one kernel can act as a resource/facilities publisher to a 
>parent when the parent is preparing and building another set of 
>components.  I.e. you get to control phasing of sub-sets of component 
>assembly which is really nice in a complex compoent model.
>
>Cheers, Steve.
>
>
>  
>
>>- Robert
>>
>>
>>-----Original Message-----
>>From: Stephen McConnell [mailto:mcconnell@osm.net] 
>>Sent: Wednesday, July 17, 2002 12:17 PM
>>To: Avalon Developers List
>>Subject: Re: Migrating from ECM
>>
>>
>>
>>Robert wrote:
>>
>> 
>>
>>    
>>
>>>I have been planning on moving our product off of ECM since it isn't
>>>   
>>>
>>>      
>>>
>>the
>> 
>>
>>    
>>
>>>preferred container anymore (?), and was wondering which one should I
>>>   
>>>
>>>      
>>>
>>go
>> 
>>
>>    
>>
>>>to. I don't think I need phoenix as the container needs to lightweight
>>>enough to run in a single, fat-client environment, so I think either
>>>Fortress or Merlin would be my choices. So, with that in mind:
>>>
>>>- Which one is closer to production ready
>>>
>>>   
>>>
>>>      
>>>
>>Merlin is under active development - but its already running
>>    
>>
>compoenents
>  
>
>>really nicely, providing:
>>
>>   (a) the component is thred-safe
>>   (b) the component does not declare a context dependecy (that still 
>>in progress)
>>   (c) the component does not declare a default configfuration (that's
>>    
>>
>
>  
>
>>also in progess)
>>
>>My guess is that the real question concerns point (a) because ECM 
>>compoents don;t know about default configuration or dependecies.  The 
>>excalibur/assembly package contains several example compoents with 
>>Merlin doing the automated dependency resolution and lifecycle 
>>management - take a look at the demo and see if this fits with your 
>>needs.  After a couple of other priority items I would like to focus on
>>    
>>
>
>  
>
>>Fortress/ECM style handler integration for pooled components but thats 
>>at least three bullet points down the list.
>>
>> 
>>
>>    
>>
>>>- I need configuration as easy as, or close to as easy, as ECM was
>>>
>>>   
>>>
>>>      
>>>
>>I'm confident you will find Merlin configuration easier than enything 
>>else in Avalon.  
>>
>> 
>>
>>    
>>
>>>- I am currently using the connection pooling from Excalibur and would
>>>like to continue using it.
>>>
>>>Any thoughts?
>>>
>>>
>>>   
>>>
>>>      
>>>
>>If you want to trial Merlin 2.0 (excalibur/assembly) post me an emil 
>>off-line and I'll try to help you with the job of getting things 
>>running.  In the meantime, the javadoc for Merlin 2 is really solid -
>>    
>>
>it
>  
>
>>will giove you a reasonably good picture of what is possible today and 
>>what is in the pipeline.
>>
>>Cheers, Steve.
>>
>> 
>>
>>    
>>
>>>Thanks,
>>>Robert
>>>- 
>>>
>>>
>>>--
>>>To unsubscribe, e-mail:
>>>   
>>>
>>>      
>>>
>><mailto:avalon-dev-unsubscribe@jakarta.apache.org>
>> 
>>
>>    
>>
>>>For additional commands, e-mail:
>>>   
>>>
>>>      
>>>
>><mailto:avalon-dev-help@jakarta.apache.org>
>> 
>>
>>    
>>
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>
>  
>

-- 

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