geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <>
Subject Re: An idea for defining custom valves in config.xml
Date Thu, 16 Oct 2008 08:08:19 GMT
Hi David,

You are correct: the underpinning philosophy of these approaches is  
to make it easier to modify pre-canned plugins through extension points.

This may be a good approach to improve further the packaging model of  
dependencies and services. Let's say that an end-user wants to add a  
connector to the tomcat6 plugin. Instead of using the admin console  
or updating his config.xml, he can simply deploy a cumulative plan.  
This notion of cumulative plan is the key differentiator as users can  
share their cumulative plans "as-is" - i.e. w/o knowing what the  
plugin to be modified looks like.  To some extent, providing a plan  
ready to be deployed instead of deployment instructions is better for  

I will work on the Groovy builder approach and post back more details  
as I go.


On 16/10/2008, at 10:59 AM, David Jencks wrote:

> Hi Gianny,
> First, I'd like to make sure I understand the philosophy behind  
> your proposals.  IIUC they both involve the idea of making it easy  
> to modify an existing plugin rather than making it easy to replace  
> an existing plugin with a similar one.
> Why is this a good idea?  My idea has been that we should make it  
> easier to replace a plugin with a similar one than modify an  
> existing one, and then we will have the best of all worlds.
> All this being said, I think your ideas are both quite  
> interesting.  I'm especially interested in the groovy builder  
> approach.
> I'll be fairly unavailable until next week but might keep thinking  
> about this anyway.
> thanks!
> david jencks
> On Oct 15, 2008, at 3:46 AM, Gianny Damour wrote:
>> On 15/10/2008, at 4:16 AM, David Jencks wrote:
>>> That's one of the main missing bits of functionality.  Right now  
>>> the only way to get the g-p.xml is to use c-m-p or to export the  
>>> plugin from a server it's been deployed into, or to do something  
>>> by hand with jar packing and unpacking.
>>> The biggest problem here, in my mind, is that jsr88 only wants  
>>> you to have one "plan": to deploy something you get to specify  
>>> the artifact and one "plan".  Our deployment system is built  
>>> around jsr88 so we either have to condense the g-p.xml and plan  
>>> into one "plan" or abandon jsr88.
>>> At the moment I'm thinking that one satisfactory solution might  
>>> be to more or less embed the plan into g-p.xml.  Perhaps we could  
>>> avoid duplicating most of the dependency info by adding the  
>>> <import> element to the dependencies in g-p.xml.  I guess we'd  
>>> expect a more or less empty <environment> element in the plan and  
>>> fill in the dependencies from the g-p.xml when deploying.
>>> I guess another possibility might be to include the info from g- 
>>> p.xml in the environment element of the plan.
>>> I've been thinking about this on and off for a long time and  
>>> don't have any solution I'm entirely happy with so discussion and  
>>> more ideas are more than welcome :-)
>> Hi,
>> Another possible solution would be to allow the extension of a  
>> given configuration by other configurations. This could work like  
>> the web.xml fragment mechanism of the upcoming servlet specs which  
>> allows framework libraries to transparently install Web components  
>> to the baseline components defined by the web.xml DD.
>> When a configuration starts it looks for complementing  
>> configurations whose responsibility is to alter the baseline  
>> configuration. The identification of complementing configurations  
>> could be based on a simple naming convention scheme, e.g. if the  
>> base configuration is org/tomcat6//car then all the configurations  
>> matching the pattern org/tomcat6-transform-DiscriminatorName//car  
>> are identified as complementing configurations.
>> If there are complementing configurations, then the baseline  
>> ConfigurationData could be passed to them for arbitrary  
>> transformation, e.g. add, update or remove dependencies. An  
>> updated ConfigurationData is passed back and actually loaded by  
>> the kernel.
>> The main drawback of this approach is the added configuration  
>> complexity. The main benefits is that it provides application  
>> server configuration traceability and a mean to perform very  
>> simple changes to a baseline configuration w/o having to redefine  
>> in its entirety the configuration to be slightly changed.
>> In another thread about scripting language integration, I  
>> suggested an even simpler approach whereby a script is executed to  
>> perform ConfigurationData transformations.
>> If any of these two options are plausible solutions, then I am  
>> happy to move forward with an implementation.
>> Thanks,
>> Gianny
>>> thanks
>>> david jencks

View raw message