geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <gianny.dam...@optusnet.com.au>
Subject Re: An idea for defining custom valves in config.xml
Date Sat, 18 Oct 2008 00:11:25 GMT
Hi,

I am proposing the following implementation to start with:

1. In the META-INF folder of a config, we scan for files matching the  
patterns "dependencies-(.*).groovy" and "extentions-(.*).groovy".

2. We execute the scripts "dependencies-(.*).groovy" which modify  
dependencies. For instance, such scripts may look like:

configurationData + dependency(groupId: 'group', artifactId:  
'artifact', version: '1.1', type: 'jar', importType: importType) --  
add the declared dependency
configurationData - dependency(groupId: 'group', artifactId:  
'artifact', version: '1.0', type: 'jar') -- remove the declared  
dependency

This gives us the final classloader of the config.

3. We execute the scripts "extentions-(.*).groovy" which update the  
GBeans, For instance, such scripts may look like:

gBeanBuilder.configure {
     addGBean(BasicNodeInfo) { -- add a GBean
         attribute(name: 'node1')
         attribute(extendedJMXConnectorInfo: new  
BasicExtendedJMXConnectorInfo(...))
         reference(referenceName) {
             pattern('aPattern')
             pattern('aSecondPattern')
         }
     }
     removeGBeansMatching('aPattern')
}

gBeanBuilder.updatedConfigurationData

The implementation of such scripts should be as simple as the  
modification of config.xml.

The fact that they are collocated with the configuration they modify  
increases cohesion. It would be neat to have such scripts instead of  
the native or XStream serializations of config.ser.

Let me know your thoughts?

Thanks,
Gianny


On 16/10/2008, at 11:17 PM, Jason Warner wrote:

> While David is more interested in the philosophy, I'd prefer to  
> know a little bit more about your thoughts on implementation.   
> Specifically what do you imagine would be involved in defining this  
> configuration?  Would it be as simple as a definition in config.xml?
>
> On Thu, Oct 16, 2008 at 4:08 AM, Gianny Damour  
> <gianny.damour@optusnet.com.au> wrote:
> 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 novices.
>
> I will work on the Groovy builder approach and post back more  
> details as I go.
>
> Thanks,
> Gianny
>
>
> 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
>
>
>
>
>
>
> -- 
> ~Jason Warner


Mime
View raw message