Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <dev@avalon.apache.org>
Message-ID: <006601c33c9c$1504d9b0$da041c0a@dsifwk009>
From: "Laurent Rieu" <partner45@fnac.tm.fr>
To: "Avalon Developers List" <dev@avalon.apache.org>
References: 
 <03334AAF1DF8D2119B1000A0C9E32F5803EE2FD5@us-pb-xmsg-2.am.sony.com>
Subject: Re: [RT] container extensions
Date: Fri, 27 Jun 2003 13:05:56 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Aaron,

I agree with you about the container extensions. I'm currently thinking of
adding JMX support to Merlin. While I can have a lifecycle extension
automatically register specific components (components that implement the
Manageable interface for example) as MBean in an avalonized MBeanServer, I
would like to dynamically instrument these components (ie build their
associated MBean) based on component meta-data. For example, we could have a
specific management section within a xinfo file (I don't know, maybe this is
already the case in Phoenix ?) describing the management interface with the
constructor / operations / attributes / notifications the component want to
expose it its management view (tags could be used to generate the management
part of the descriptor). An (easy ?) way to have something running would be
to use the Commons Modeler and have it build ModelMBean for each Manageable
component based on reflection / deployment descriptor.

I need more thinking about this JMX extension, but I can see two main phases
:
    - the possiblity to automatically build a management view of a component
based on reflection / deployment descriptor: this could lead to a portable
(ie container agnostic) JMX extension for Avalon components.
    - the instrumentation of the container itself so that the container
could use the JMX Notification system to handle component-lifecycle-related
events. The container (ie its internals) could use the component dependency
graph to build a JMX notification graph so that (for example) when a
component is suspended, all the dependent components are also suspended.

Well, this could be tough to implement, but regarding its intenals I think
Merlin has the potential to achieve it (or part of it) !

Laurent

----- Original Message -----
From: "Farr, Aaron" <Aaron.Farr@am.sony.com>
To: "avalon-dev" <dev@avalon.apache.org>
Sent: Thursday, June 26, 2003 5:57 PM
Subject: [RT] container extensions


Greetings.

After a couple weeks of wrestling with all three Avalon containers I've
found a couple of issues that I can't seem to get around easily.

1. Container Extensions

Sure I can extends Fortress's DefaultContainer or hack away at Merlin and
Phoenix internals, but if I want to add something like JNDI, JMX, or
whatever, I'd rather not have to do that.  In particular, I'd like a way to
write a single extension/component which works in all three containers.
Currently we have lifecycle extensions, but these are not yet supported by
Phoenix.  Lifecycle extensions are wonderful, but only go so far.  You do
not have, for example, access to assembly level meta-data.  No access to
configuration, dependencies, or whatnot.  Only access to the object itself
and the context.

What I'm looking for is a way to extend the basic services of a container
without having to extend the base container class.  If this were possible,
then adding JNDI, JMX, SOAP, and whatnot would be much easier.  Moreover, it
could be possible to do it once and then have it work for all three
containers.  As it stands, Phoenix has JMX support.  To get JMX support in
Fortress, you'd have to pull it out of Phoenix and integrate it directly
into Fortress.

I want a way to dynamically add new base services like a JNDI, SOAP, JMX,
etc.  These services are more than just lifecycle extensions -- they're
container extensions.  They need access to assembly level data.  As I see
it, to accomplish this we would need to:

- Standardize assembly process and meta-data
- Define Container Extension API (possibly based on Lifecycle Extensions)
- Provide support in the main Avalon containers

Not simple, but not impossible either.  This is probably something more
along the lines of Spearhead, but I suppose support for it could end up in
Merlin without too much trouble.

2. Managing a Context

I may be mistaken, but from what I can see, between the three containers
there is:
- no standard set of context values
- no standard context naming convention
- no standard way to add things to the context without extending the base
container

We've all seen the problem of relying on something like BlockContext, but
BlockContext exists because it's, well, very useful.  There's a need for it.
But no other container supports it or has a viable alternative.

Perhaps we could:
- Provide a way to include parameters/properties in the context
- Provide a way to manipulate context values before general
contextualization begins
  (this could be one of those container extensions I mentioned)

The context is great idea, but I find myself avoiding it because it seems
like using Context ties me to a particular container more than I would like.
Perhaps I just don't know how to use it properly, in which case, more
documentation or examples, would be nice.


I was also going to add something about handling resources and deployable
files (think sars, jars, ears, wars, eobs, ...), but the Source Resolver
package handles that fairly well.  I suppose my uneasiness comes from the
lack of conformity in resource structure even within the Avalon containers.
Since a common server feature is loading and deploying resources like wars
and sars, it seems like there would be a more complete framework (and more
conformity) within Avalon for that.  I'll have to ponder this one a bit
more.

Thanks!

J. Aaron Farr
SONY ELECTRONICS
DDP-CIM
(724) 696-7653


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


************************************************************************
Ce message a ete inspecte par un anti-virus

Nous vous rappelons que la taille des messages  ne doit pas depasser 1.5 Mo
************************************************************************

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