Farr, Aaron wrote:
-----Original Message----- From: Stephen McConnell [mailto:[EMAIL PROTECTED]
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 idea:
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 sub-containers).
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 architecture.
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.
Thanks.
J. Aaron Farr SONY ELECTRONICS DDP-CIM (724) 696-7653
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
