Hi Gianny,
Have you made any progress with this? Are you targeting this for the 2.2
release (whenever that happens to be)?
Thanks!
On Fri, Oct 17, 2008 at 8:11 PM, Gianny Damour <
[EMAIL PROTECTED]> wrote:
> 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 <
>> [EMAIL PROTECTED]> 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
>>
>
>
--
~Jason Warner
