You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by "Farr, Aaron" <Aa...@am.sony.com> on 2003/06/26 17:57:02 UTC
[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
Re: [RT] container extensions
Posted by Leo Simons <le...@apache.org>.
Anton Tagunov wrote:
> Hi, Leo!
>
> LS> Peter did write a common framework for that a few times (catalina, it
>
> Is that Tomcat 4?
uhm, yes. The framework I tried to mentioned was called "camelot". Duh!
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re[2]: [RT] container extensions
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hi, Leo!
LS> Peter did write a common framework for that a few times (catalina, it
Is that Tomcat 4?
LS> was called), but for reasons I can't remember that resulted in feature
LS> flexibility and ugly, hard-to-debug callstacks.
-Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] container extensions
Posted by Leo Simons <le...@apache.org>.
Farr, Aaron wrote:
> 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.
that will take some time yet :D
> Currently we have lifecycle extensions, but these are not yet supported by
> Phoenix.
patches welcome though!
> What I'm looking for is a way to extend the basic services of a container
> without having to extend the base container class.
>
> 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.
I would suggest targetting merlin for this stuff for now.
Standardisation before you know your use cases is not a very good idea.
As to API, I think we keep bumping into the fact that you cannot predict
what you will need from the container inside an extension. It is very
difficult to predict size, scope and needs of an extension. One way to
solve that is "expose everything". This implies you trust your extension
and you allow it to do anything it pleases. You can make something like
that more explicit by adding a few pipelines and queues of extensions in
the assembly process.
With merlin, that might mean:
<block>
<engine>
<extensions>
<extension role="my-extension"/>
</extensions>
</engine>
<component role="my-extension" class="my.ExtensionImpl"/>
</block>
---
interface Extension
{
void process( Object component, Type type, Profile profile, Appliance
callbackReference, StageDescriptor stage ) throws Exception;
}
---
and somewhere inside the code that handles assembly:
LinkedList extensions = getExtensions( config );
while( extensions.hasNext() )
{
extension = extensions.next();
extension.process( obj, type, profile, getAppliance(), stage );
}
---
however, figuring out a truely generic Extension interfaces has proven
to be extremely difficult. The way out is to simply say "expose
everything". You end up with something like:
<block>
<engine>
<interceptors>
<interceptor class="myHandler" preGoal="contextualize"/>
</interceptors>
</engine>
</block>
interface Handler
{
Event handle( Event event ) throws Exception;
}
class MyHandler implements Handler
{
Event handle( Event event )
throws Exception
{
Map ctx = event.getMessage();
Phase p = (Phase)ctx.get( "nextphase" );
if( p.getStage() == "contextualize" )
return handleContextualize( event );
}
Event handleContextualize( Event event )
{
context.put( "secret", "this is cumbersome." );
}
}
For those of you who do not like examples, some complex prose...
It is very difficult to predict in advance where the vector of change
for container architecture internals lies, since many modifications to
those internals are domain-specific. Hence we must strike a balance
between type safety and flexibility. Maximum flexibility is gained
through utilizing container internals that use "flexibility patterns"
like interceptors, pipelines, events, scripting and declarative assembly.
Current containers (phoenix its kernel.xml is a good example) excel at
declarative assembly while maintaining strong typing. This means that
container code is manageable as long as the provided container
decomposition fits the domain-specific needs. When that does not apply,
any customization immediately starts feeling "hacky".
Merlin goes one step beyond in providing a more generic and more formal
decomposition.
But I do not think that exposing more and more externals (as per the
first example) is manageable. We will end up with a plethora of
not-actually-strongly-typed extension components and no set rules for
their interoperability, raising concerns about system stability.
Hence you end up at adding more flexibility features at the sacrifice of
strong typing and predicatability. But my experiments so far show that
adding one of these things (like interceptors to fortress using nanning)
is far from trivial.
Dillemma.
> 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.
The root of the problem here is that no agreemnt exists between the
containers about how much their contexts need to provide. Like "part of
the container-component contract is that the container will provide a
'working directory' to the component on request, and that this working
directory will be available through the context".
Merlin tries to solve this by allowing you to build your context from
declarative xml, fortress tries to solve this by not bothering with
contextualization at all and allowing you to pass in a passthrough
context, and phoenix just decided on its contracts before
cross-container portability became an issue.
> 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.
Peter did write a common framework for that a few times (catalina, it
was called), but for reasons I can't remember that resulted in feature
flexibility and ugly, hard-to-debug callstacks.
It's nontrivial.
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] container extensions
Posted by Stephen McConnell <mc...@apache.org>.
J Aaron Farr wrote:
>On Fri, 2003-06-27 at 21:19, Stephen McConnell wrote:
>
>
>
>>I think its achievable.
>>
>>In fact Aaron's appliance extension provides a good entry point for
>>plugging in of a JMX extension without having to sub-class
>>DefaultAppliance. This deals with the component side of things - but we
>>will need something closer to appliance itself something like an
>>ApplianceListener and ApplianceEvent which get registered during the
>>appliance initialization phase. This would address the need for
>>registration of the appliance as a managable entity before deployment of
>>components.
>>
>>
>
>ApplianceEvent and ApplianceListener, eh?
>
>So when would events be fired? On deployment? On access? I agree that
>some way of registering appliances would be a nice feature.
>
In principal it should be possible to launch a container based on
deployment model that is supplied to it. Currently Merlin builds that
deployment model as part of container startup (based on all of the XML -
kernel.xml, block.xml, xinfo, xservice, config, etc.). However - I'm
thinking ahead towards a scenario where XML is just one of multiple
sources for the declaration of a deployment scenario.
Let's assume that the entire deployment model is provided as a single
serializable meta-data instance. Secondly, let's assume that the a
kernel is already registered with a JMX server. Thirdly, let's assume
that the kernel is provided with the meta-data (deployment scenario) by
the JMX server (i.e. an administrator has finished playing with a
persistent deployment scenario and is requesting scenario execution by a
container).
On execution of the scenario the container would need to fire back to
the server the progress relative to scenario execution.
The type of events would include:
1. scenario deployment event
signals the initiation of scenario deployment
during which appliance instances are instantiated
and associated relative to services and dependencies
imported and exported by the respective component
types
1.1. appliance creation event
1.2. appliance assembly event
2. scenario runtime event
runtime events signaling the deployment of components,
suspension, redeployment, and decommissioning of
components
2.1 appliance deployment event(s)
a) component instantiation event
b) component logging event
c) component context event
d) ...
2.2 appliance suspension event(s)
2.3 appliance redeployment event(s)
2.3 appliance decommissioning event(s)
a) component stop event
b) component disposal event
3. scenario decommissioning
during which appliance instance associations are
disassembled and destroyed
3.1 appliance disassembly event
3.2 appliance disposal event
If we combine the above information with a remotely accessible
appliance, we have something that starts to look *really* interesting.
Cheers, Steve.
>
>>Ummm, thinking, thinking ...
>>
>>
>
>Me too. :P
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] container extensions
Posted by J Aaron Farr <ja...@yahoo.com>.
On Fri, 2003-06-27 at 21:19, Stephen McConnell wrote:
>
> I think its achievable.
>
> In fact Aaron's appliance extension provides a good entry point for
> plugging in of a JMX extension without having to sub-class
> DefaultAppliance. This deals with the component side of things - but we
> will need something closer to appliance itself something like an
> ApplianceListener and ApplianceEvent which get registered during the
> appliance initialization phase. This would address the need for
> registration of the appliance as a managable entity before deployment of
> components.
ApplianceEvent and ApplianceListener, eh?
So when would events be fired? On deployment? On access? I agree that
some way of registering appliances would be a nice feature.
> Ummm, thinking, thinking ...
Me too. :P
--
jaaron <http://jadetower.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] container extensions
Posted by Stephen McConnell <mc...@apache.org>.
Laurent Rieu wrote:
Hi Laurent!
>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).
>
The Phoenix approach is to declare a management-access-point - here is
an example from the James component descriptor for Phoenix:
<!-- interfaces that may be exported to manange this block -->
<management-access-points>
<service name="org.apache.james.JamesMBean"/>
</management-access-points>
>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.
>
This would make a lot of sence for managable components.
>
>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.
>
+1
> - 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.
>
One of the things I've been thinking about above and beyond JMX
notification is the application of the JMXC relations model to describe
associations between appliance instances, and association between an
appliance and its managable components.
>
>Well, this could be tough to implement, but regarding its intenals I think
>Merlin has the potential to achieve it (or part of it) !
>
>
I think its achievable.
In fact Aaron's appliance extension provides a good entry point for
plugging in of a JMX extension without having to sub-class
DefaultAppliance. This deals with the component side of things - but we
will need something closer to appliance itself something like an
ApplianceListener and ApplianceEvent which get registered during the
appliance initialization phase. This would address the need for
registration of the appliance as a managable entity before deployment of
components.
Ummm, thinking, thinking ...
Cheers, Steve.
>Laurent
>
>----- Original Message -----
>From: "Farr, Aaron" <Aa...@am.sony.com>
>To: "avalon-dev" <de...@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
>
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] container extensions
Posted by Laurent Rieu <pa...@fnac.tm.fr>.
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" <Aa...@am.sony.com>
To: "avalon-dev" <de...@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
Re: [RT] container extensions
Posted by Stephen McConnell <mc...@apache.org>.
Farr, Aaron wrote:
>Greetings.
>
Hi!
>
>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.
>
At the pub the other night we were talking about JMX enablement using
the appliance implementation. Later I was thinking that an open
mechanisms is needed to plug this sort of functionality into an
appliance - i.e. eliminate the need for new appliance types.
>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
>
+1
>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.
>
I agree.
>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
>
>
All of the above are *required* services if we want portability.
>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)
>
>
You may want to take a look at the DefaultContextualizationService. This
was originally created to enable the declaration of replacable
strategies - however, overall context managent is not a trivial thing -
as it turns out it is more interesting to look at how the kernel and
containment environments can be enhanced with context providers
installed under container scope.
>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.
>
>
Given a complete meta-info description of the context criteria - this
problem becomes manageble.
Cheers, Steve.
(who has a lot of emails to catchup on)
>
>
>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
>
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] container extensions
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Farr, Aaron wrote, On 26/06/2003 17.57:
>
>> 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.
>
>
> I will not reply to this mail (yet) as I don't have much time now, but
> I'd like to send you my compliments for spotting these things out in
> just two weeks! What you describe is IMHO a nice summary of the final
> objectives we want to pursue.
>
> Personally, I think that the way out is not rewriting again from
> scratch, as it will kill our momentum, but standardize on the things
> that bug us and work on refactoring.
+100
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] container extensions
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Farr, Aaron wrote, On 26/06/2003 17.57:
> 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.
I will not reply to this mail (yet) as I don't have much time now, but
I'd like to send you my compliments for spotting these things out in
just two weeks! What you describe is IMHO a nice summary of the final
objectives we want to pursue.
Personally, I think that the way out is not rewriting again from
scratch, as it will kill our momentum, but standardize on the things
that bug us and work on refactoring.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] container extensions
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello Aaron!
FA> then adding JNDI, JMX, SOAP, and whatnot would be much easier.
We could also hook regular http requests into avalon components
this way by establishing a mapping to/from http request uri-s =)
BL> SOAP, AltRMI, RMI, etc. are all remoting protocols.
So is "raw" http in some sense :)
This would
* replace the mapping machinery currenlty available from
maveric/struts
* provide a single uniform framework for web/web-services/rpc-style
applications
* work for all our containers
That's magnificent - Woo - worth rubbing fingers into blood for!
-Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] container extensions
Posted by Berin Loritsch <bl...@apache.org>.
Farr, Aaron wrote:
> 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.
Dropping a hefty RT right before I go on vacation... How dare you ;P
Seriously, you are talking about things we want to tackle.
> 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.
I hear you. We agree. If you have some more concrete ideas (something we
can start brainstorming and moving toward) for this, please let them be
known.
> 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.
This is something we have been thinking about designing for in the next
generation container Spearhead. It is easier to play around in a new work
that noone is dependent on yet to get it right, then backport it.
> 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
Agreed, Agreed, and Agreed.
>
> 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
There are only a couple of standard context values (between Fortress and
Phoenix). Merlin uses the more verbose URN notation.
We have started toward standardizing a base set of context values, but that
got stalled somewhere.
>
> 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)
Merlin provides support to validate those context values, but having them
set in a cross-platform manner is tricky.
> 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.
Something we started on and probably need to resume.
>
> 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.
It is another thing we need to explore. A good set of standards will help.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org