avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [merlin] Lifecycle Extension Support
Date Sat, 30 Aug 2003 15:42:25 GMT

Farr, Aaron wrote:

>>-----Original Message-----
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>Nope - the intention is to replace it with something that passes a
>>DeploymentModel instance instead of an Appliance.  The problem with
>>passing an appliance is that it exposes too much info to the extension.
>>Secondly, there has been some shuffling of things around at the level of
>>the kernel - now the kernel creates a root container and I'm thinking
>>about how we can use this to locate privaliged componenents (such as
>>extensions).  One of the issues you should aware of is that if you
>>deploy an extension with access to a model, we need Merlin to provide
>>the privaliged classloader.  Currently the classloader provides nothing
>>more than the APIs and privaliged content needs the SPIs as well.  This
>>means when Merlin locates an extension - it needs to provide the
>>extension with an extended classloader.
>After some more digging, I have some other thoughts/questions about this
>1. Extension Scope:
>  What is the scope for an extension (lifecycle or otherwise)?  Is it
>  only within its container and sub-containers?  Can extensions be 
>  allowed to handle _all_ components?

I don't like the notion of extensions that handle all components.  I 
prefer the idea of extensions existing inside a container scope (and as 
such applicable to anything within the container - including 

>2. Extension Declaration:
>   Should an extension be declared within the container declaration
>   (ie- in the block.xml) or can/should extensions be declared at the
>   kernel level (in the kernel.xml or in some /ext directory).

When we talk about the kernel we are in fact talking about the *root* 
container.  The difference between the root container and other 
containers is that we can be much more relaxed about what goes into the 
root because its defined under the kernel.xml file as distinct from 
containers which are added as children.

I.e. a solution to extensions at the container level will implicity be 
available to the kernel root container.

>3. Extension Hooks:
>   At what point should extensions be allowed?  Deployment?  Component
>   Access?  Shutdown?

Extensions (in my mind) are simply classes that exist on the container 
side of the equation.  This could be an alternative container import 
model, a different context manager, an interceptor, an alternative 
appliance, etc.  A particular group of extensions deal with lifecycle 
aspects in which case they are handled at a particular point in the 
deployment process (e.g. the excalibur lifecycle extensions).

>4. Extension Architecture:
>   At one point ideas where thrown around about using an Event based 
>   extension API (which I think is cool).  Alternatively we could
>   use an Interceptor approach or something like Excalibur Lifecycle.

I'm also leaning towards the event approach as a part of the overall 

>As for the classloader issue, do blocks get a privileged classloader?  Does
>anything currently get a privileged classloader?

Nothing gets a privileged classloader.

Some internal notes - Merlin establishes three classloaders:

  1. root-api
  2. root-spi extends root-api
  3. root-impl extends root-spi

During launch of the system, merlin creates containers that are added to 
the root container.  The creation process (executing under the main 
merlin thread) has the full root-impl classloader.  When a container is 
created, the root-api classloader is assigned as the parent and anything 
declared in the container's classloader is added.  The resulting 
classloader is assigned as the context classloader in the thread that 
the container is running within.

This works fine for the broad spectrum of things (including 
excalibur-extension style content bacause the excalibur extension API is 
the the classloader shared by merlin and the extension implementation is 
in the container classloader). 

The same approach could be taken for the suite of SPI classes - i.e. 
include all SPI classes in the classloader supplied to the root 
container.  The disavantage of this approach is that the classloader 
supplied to the runtime component contains extension classes (which is 
not a good thing).

One way to handle this is to make a destinction between a classloader 
provided to the container as opposed to the classloader set as context 
classloader.  The context classloader is the classloader accessible by 
components whereas extensions would be placed in the delegating 
classloader.  The extension classes would naturally need access to (a) 
the parent containers privileged classes, (b) the normal component 
classes in the containment scope, and (c) other privileged classes in 
the containment scope.

Just for my own benefit - I'll try and summarise this:

  * Create a new privileged classloader.  Class loader
  * will attempt to load classes using supplied privileged
  * parent loader and if not found, will attempt to load the
  * class from the supplied classic classloader.
  * @param parent the privileged parent classloader
  * @param classic the classic component classloader
  * @param urls urls to include in the privileged loader
  PriviligedClassLoader( ClassLoader parent, ClassLoader classic, URL[] 
urls )
      super( parent, urls );
      m_delegate = classic;

     // stuff to handle delegation

Inside the merlin code - the context classloader is never used.  All 
referrences are to an explicity declared classloader so adding in 
something like a privileged loader would not be so difficult. The nice 
thing about the this approach is that extension classes in a parent 
container become available to extension classes in sub-containers.  
Secondly, extension classes are properly isolated.

Conclusion - in ther shaort term we could include the SPI classes in the 
root loader.  This would let us work on getting the advanced extension 
handlers in place quickly and easily.  We could then deal with 
delegation at a later stage with minimal disruption.

>Extensions I'm currently interested in include:  JNDI (via AltRMI perhaps?),
>JMX, and JMS.  I had a JMS extension working for the older Merlin version
>and I want to get it up to date for Merlin 3.0 before I release.  

Can you give me a summary of what information you were accessing on the 
appliance.  I figure we can get an equivalent extention in place 
reasonably easily if the same information is available vie the 
DeploymentModel class.

>What about
>JMX, I know there was work being done for JMX in merlin, but I haven't seen
>much in CVS lately (perhaps I'm looking in the wrong places).

The merlin/merlin-extensions/merlin-jmx is working against 3.0 - also 
the merlin-test/merlin-jmx-demo has been updated. Once the extension 
handling is sorted out - I want to get into JMX extension of container 
internals plus support for JMX registration of managable components.

Cheers, Steve.

>J. Aaron Farr
>  (724) 696-7653
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org


Stephen J. McConnell

Sent via James running under Merlin as an NT service.

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

View raw message