Re: An idea for defining custom valves in config.xml

[Gianny Damour]

Hi Jason,

This is now checked-in. I had to change some naming conventions to  
have better stack trace information when a Groovy script fails.  
Scripts must match the patterns Dependencies(.*).groovy and GBeans 
(.*).groovy to be picked up.


Let me know how you go!

Thanks,
Gianny


On 30/10/2008, at 4:37 AM, Jason Warner wrote:

There's no need to check in what you have if you don't feel it's  
quite done yet.  I was just wondering where you were at.  I was  
eager to have a solution for the original issue find its way into  
the 2.2 release, and it seems that would be the case.  I think that  
improving the classloading isolation would be the best approach to  
solve the issue you raised.  I'm not too familiar with the  
classloader as is, though, so I'm not sure what impact that would  
have.  From a purely user point of view, it seems like the correct  
way to go.  Let me know if you need any help testing or coding any  
of this.  As I said, I'm not too familiar with the classloader, but  
if I flop around in the code enough I might be able to make a few  
small waves ;)


Thanks!

On Tue, Oct 28, 2008 at 4:53 PM, Gianny Damour  
<[EMAIL PROTECTED]> wrote:

Hi Jason,

It is implemented and I will check-in over the week-end.

Here is the design:
1. When a ConfigurationData is loaded from a ConfigurationStore,  
its dependencies can be altered based on scripts matching the  
pattern dependencies-(.*).groovy. Here is the script I have been  
using to perform my integration test:


configurationDataBuilder.configure {
   addDependency(groupId: "org.springframework", artifactId:  
"spring-core", version: "2.0.5", type: "jar")

}

2. When the GBeans of a configuration are loaded, i.e. when a  
Configuration instance is created, GBeans can be updated based on  
scripts matching the pattern gbeans-(,*).groovy. Here is my  
integration test script:


import org.springframework.core.SpringVersion

gbeanDataBuilder.configure {
   addGBean(name: 'name', gbean: SpringVersion) {
   }
}

Scripts are searched in the configuration directory, i.e. in the  
same folder of the META-INF folder of a configuration. This can be  
easily changed by implementing a ScriptLocater strategy.


I had to add a groovy dependency to the j2ee-system config which is  
not ideal as all the configurations will now see the Groovy  
classes. Ideally, I would like to add another configuration where  
ConfigurationDataTransformers can be declared and the out-of-the- 
box GroovyTransformer can be specified. This is problematic as such  
a configuration needs to be started after j2ee-system and before  
any other configurations. I could add a dependency to this  
configuration on the innermost configuration after j2ee-system.


Another approach would be to improve the isolation of configuration  
classloaders, which should also address classloading problems  
reported by users and the need to fiddle with hidden-classes  
declarations. Assuming that I stick to the current configuration  
approach where I declare a GroovyTransformer in j2ee-system, the  
improvement I am thinking about is:
1) add a new classloading declaration element, maybe hidden-for- 
children, where users can specify a pattern a la hidden-classes.
2) The above declarations are used to build a classloader which  
simply delegates to the configuration classloader and filter out  
classes matching the hidden-for-children declarations.
3) Children configurations are provided with the above classloader  
instead of the configuration classloader.


With this thing in place, I will be able to add a groovy dependency  
to j2ee-system w/o having to thing about the impacts to children  
configurations as I can hide the groovy classes.


If you want me to check-in "as-is" this scripting stuff and revisit  
the implementation as soon as I figure out which of the two  
approaches, i.e. add another config or improve classloading  
isolation, is the best, then let me know.


Thanks,
Gianny



On 29/10/2008, at 2:21 AM, Jason Warner wrote:

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 t

Re: An idea for defining custom valves in config.xml

[Jason Warner]

There's no need to check in what you have if you don't feel it's quite done
yet.  I was just wondering where you were at.  I was eager to have a
solution for the original issue find its way into the 2.2 release, and it
seems that would be the case.  I think that improving the classloading
isolation would be the best approach to solve the issue you raised.  I'm not
too familiar with the classloader as is, though, so I'm not sure what impact
that would have.  From a purely user point of view, it seems like the
correct way to go.  Let me know if you need any help testing or coding any
of this.  As I said, I'm not too familiar with the classloader, but if I
flop around in the code enough I might be able to make a few small waves ;)

Thanks!

On Tue, Oct 28, 2008 at 4:53 PM, Gianny Damour <
[EMAIL PROTECTED]> wrote:

> Hi Jason,
>
> It is implemented and I will check-in over the week-end.
>
> Here is the design:
> 1. When a ConfigurationData is loaded from a ConfigurationStore, its
> dependencies can be altered based on scripts matching the pattern
> dependencies-(.*).groovy. Here is the script I have been using to perform my
> integration test:
>
> configurationDataBuilder.configure {
>addDependency(groupId: "org.springframework", artifactId: "spring-core",
> version: "2.0.5", type: "jar")
> }
>
> 2. When the GBeans of a configuration are loaded, i.e. when a Configuration
> instance is created, GBeans can be updated based on scripts matching the
> pattern gbeans-(,*).groovy. Here is my integration test script:
>
> import org.springframework.core.SpringVersion
>
> gbeanDataBuilder.configure {
>addGBean(name: 'name', gbean: SpringVersion) {
>}
> }
>
> Scripts are searched in the configuration directory, i.e. in the same
> folder of the META-INF folder of a configuration. This can be easily changed
> by implementing a ScriptLocater strategy.
>
> I had to add a groovy dependency to the j2ee-system config which is not
> ideal as all the configurations will now see the Groovy classes. Ideally, I
> would like to add another configuration where ConfigurationDataTransformers
> can be declared and the out-of-the-box GroovyTransformer can be specified.
> This is problematic as such a configuration needs to be started after
> j2ee-system and before any other configurations. I could add a dependency to
> this configuration on the innermost configuration after j2ee-system.
>
> Another approach would be to improve the isolation of configuration
> classloaders, which should also address classloading problems reported by
> users and the need to fiddle with hidden-classes declarations. Assuming that
> I stick to the current configuration approach where I declare a
> GroovyTransformer in j2ee-system, the improvement I am thinking about is:
> 1) add a new classloading declaration element, maybe hidden-for-children,
> where users can specify a pattern a la hidden-classes.
> 2) The above declarations are used to build a classloader which simply
> delegates to the configuration classloader and filter out classes matching
> the hidden-for-children declarations.
> 3) Children configurations are provided with the above classloader instead
> of the configuration classloader.
>
> With this thing in place, I will be able to add a groovy dependency to
> j2ee-system w/o having to thing about the impacts to children configurations
> as I can hide the groovy classes.
>
> If you want me to check-in "as-is" this scripting stuff and revisit the
> implementation as soon as I figure out which of the two approaches, i.e. add
> another config or improve classloading isolation, is the best, then let me
> know.
>
> Thanks,
> Gianny
>
>
>
> On 29/10/2008, at 2:21 AM, Jason Warner wrote:
>
>  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(...))

Re: An idea for defining custom valves in config.xml

[Gianny Damour]

Hi Jason,

It is implemented and I will check-in over the week-end.

Here is the design:
1. When a ConfigurationData is loaded from a ConfigurationStore, its  
dependencies can be altered based on scripts matching the pattern  
dependencies-(.*).groovy. Here is the script I have been using to  
perform my integration test:


configurationDataBuilder.configure {
addDependency(groupId: "org.springframework", artifactId:  
"spring-core", version: "2.0.5", type: "jar")

}

2. When the GBeans of a configuration are loaded, i.e. when a  
Configuration instance is created, GBeans can be updated based on  
scripts matching the pattern gbeans-(,*).groovy. Here is my  
integration test script:


import org.springframework.core.SpringVersion

gbeanDataBuilder.configure {
addGBean(name: 'name', gbean: SpringVersion) {
}
}

Scripts are searched in the configuration directory, i.e. in the same  
folder of the META-INF folder of a configuration. This can be easily  
changed by implementing a ScriptLocater strategy.


I had to add a groovy dependency to the j2ee-system config which is  
not ideal as all the configurations will now see the Groovy classes.  
Ideally, I would like to add another configuration where  
ConfigurationDataTransformers can be declared and the out-of-the-box  
GroovyTransformer can be specified. This is problematic as such a  
configuration needs to be started after j2ee-system and before any  
other configurations. I could add a dependency to this configuration  
on the innermost configuration after j2ee-system.


Another approach would be to improve the isolation of configuration  
classloaders, which should also address classloading problems  
reported by users and the need to fiddle with hidden-classes  
declarations. Assuming that I stick to the current configuration  
approach where I declare a GroovyTransformer in j2ee-system, the  
improvement I am thinking about is:
1) add a new classloading declaration element, maybe hidden-for- 
children, where users can specify a pattern a la hidden-classes.
2) The above declarations are used to build a classloader which  
simply delegates to the configuration classloader and filter out  
classes matching the hidden-for-children declarations.
3) Children configurations are provided with the above classloader  
instead of the configuration classloader.


With this thing in place, I will be able to add a groovy dependency  
to j2ee-system w/o having to thing about the impacts to children  
configurations as I can hide the groovy classes.


If you want me to check-in "as-is" this scripting stuff and revisit  
the implementation as soon as I figure out which of the two  
approaches, i.e. add another config or improve classloading  
isolation, is the best, then let me know.


Thanks,
Gianny


On 29/10/2008, at 2:21 AM, Jason Warner wrote:


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

Re: An idea for defining custom valves in config.xml

[Jason Warner]

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  element to the
>> dependencies in g-p.xml.  I guess we'd expect a more or less empty
>>  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

Re: An idea for defining custom valves in config.xml

[Gianny Damour]

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  
 element to the dependencies in g-p.xml.  I guess we'd  
expect a more or less empty  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 whi

Re: An idea for defining custom valves in config.xml

[Jason Warner]

On Wed, Oct 15, 2008 at 7:59 PM, David Jencks <[EMAIL PROTECTED]>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.
>

I think, from a user perspective, the best of all possible worlds is to have
both options available.  Thinking in the context of the original custom
valve scenario, since we seem to have expanded the scope a little, it
shouldn't be necessary for a straight user to delve into the world of
plugins to deploy a valve.  Regardless of how simple we make deploying a
plugin, that's still an added level of complexity that we shouldn't require
of a user who is working solely in the realm of a webapp.  I realize I made
this argument earlier, but after tinkering with your proposed approach and
thinking about it some more, I've come back around to my original line of
thinking, though hopefully better informed this time.  I understand the
objections to the original proposal of using an attribute, but if
sufficiently simple to define, Gianny's approach might be the right way to
accomplish the same goal.  At the same time,  I'm still all for improving
and simplifying the method in which we deploy plugins.

>
> 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  element to
>>> the dependencies in g-p.xml.  I guess we'd expect a more or less empty
>>>  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

Re: An idea for defining custom valves in config.xml

[Jason Warner]

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  element to
 the dependencies in g-p.xml.  I guess we'd expect a more or less empty
  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 plausi

Re: An idea for defining custom valves in config.xml

[Gianny Damour]

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  
 element to the dependencies in g-p.xml.  I guess we'd  
expect a more or less empty  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

Re: An idea for defining custom valves in config.xml

[David Jencks]

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  
 element to the dependencies in g-p.xml.  I guess we'd  
expect a more or less empty  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

Re: An idea for defining custom valves in config.xml

[Gianny Damour]

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  
 element to the dependencies in g-p.xml.  I guess we'd  
expect a more or less empty  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

Re: An idea for defining custom valves in config.xml

[Jason Warner]

David,

I've been trying to follow your steps and seem to be having issues
accomplishing the goal.  Please see questions inline.

On Wed, Oct 8, 2008 at 6:55 PM, David Jencks <[EMAIL PROTECTED]> wrote:

>
> On Oct 8, 2008, at 1:55 PM, Joe Bohn wrote:
>
>  Jason Warner wrote:
>>
>>> Thanks for the explanation, David.  I don't disagree with anything you've
>>> explained, but I'm not sure you've addressed my concern about the disparity
>>> in the effort required to deploy a custom valve on tomcat and on geronimo.
>>>  Even with the a streamlined process involving a tomcat server portlet and
>>> using the tomcat6 plugin as a base, the user still has to become a plugin
>>> developer to deploy their valve on geronimo.  If that's how it has to be,
>>> then I suppose that's how it has to be.  I'm just concerned that it could
>>> turn off users that might have otherwise lived happily with geronimo.  I'm
>>> not really sure how widespread the use of custom valves are, though, so
>>> maybe it's just a small minority this would even effect.  I'd be curious to
>>> get some feedback from some other developers and see if they have any
>>> thoughts on the matter.  Anyone else out there keeping an eye on this
>>> thread?
>>>
>>
>> I've been keeping an eye on it and I agree with you Jason that there is a
>> disparity in the work required to add a valve to tomcat versus that required
>> to add a valve to tomcat embedded in Geronimo.  I also agree with David that
>> the current Tomcat process does not lend itself to a reproducible
>> configuration.
>>
>> In cases like this I tend to think like a politician and advocate a
>> both/and rather than an either/or.  I suspect that some users will want
>> things in Geronimo to be as similar to Tomcat as possible ... and so will
>> want a simple configuration solution.  Doing so might convince them to move
>> over to Geronimo and over time they may gain a greater appreciation for a
>> more Geronimo like solution.  Others might be coming in with more knowledge
>> of Geronimo and expect something that is more consistent with Geronimo and
>> can be reproduced.  Can we give them both what they want?
>>
>> It seems like we could help the Tomcat centric folks with a simple
>> configuration attribute that we can use to extend the classpath.  For the
>> more sophisticated Geronimo user we can direct them to rebuild/redeploy the
>> Tomcat module with the additional dependency on the valve jar ... perhaps
>> using c-m-p and then their own custom assembly. Even while providing the
>> first approach we can highly recommend the second approach.
>>
>> It seems to me that the attribute/classpath extension is a simple thing to
>> implement and will provide a high level of value to users that are
>> accustomed to Tomcat.  The Tomcat module rebuild/redeploy is just a matter
>> of documentation ... correct?
>>
>
> I guess I'm trying to argue that we should be making doing the "right
> thing" as easy as modifying tomcat to have a custom valve.
>
> I'm not convinced we're all that far off:
>
> tomcat -stop server
> geronimo - server restart may be needed later.
>
> tomcat - add jar to server/lib (?)
> geronimo - add jar to repository
>
> tomcat - edit server.xml
> geronmo -edit tomcat6 plam.xml
>
> geronimo - add artifact-alias (this could probably be automated into part
> of the next step).  Basically this should be editing the
> geronimo-plugin.xml.


Which geronimo-plugin.xml am I editing here?  I tried  editing the  original
tomcat6 plugin  but that didn't seem to work.

>
> geronimo - deploy modified tomcat6 plan.xml, resulting in a new plugin.
>

> tomcat - restart
> geronimo - restart tomcat-dependent plugins/apps
>

Was your intention to have this new plugin run in parallel with the original
tomcat6 plugin?  I'm not sure it would be necessary to have them both run.

>
>
> There's basically only one more step in geronimo.  I'm not sure how well
> the "obsoletes" functionality works at the moment but ideally we could have
> the new plugin obsolete the original and so installing it would shut down
> the old one, shut down the plugins depending on it, and restart the
> dependencies after install.  This is the same number of steps.
>
> One missing bit here is that there is no good way to deploy an app with an
> external geronimo-plugin.xml to end up immediately with a plugin.
>

I'm confused.  One of your steps said to deploy the plan.xml and that would
result in a new plugin.  Here you are saying that there's good way to do
this.  When I deployed the plan.xml, the resultant directory in the
repository was missing a geronimo-plugin.xml.

>
> thanks
> david jencks
>
>
>
>
>
>>
>> Joe
>>
>>  On Wed, Oct 8, 2008 at 2:25 PM, David Jencks <[EMAIL PROTECTED]>> [EMAIL PROTECTED]>> wrote:
>>>   On Oct 8, 2008, at 11:04 AM, Jason Warner wrote:
>>>
   I'm not sure if these steps are reasonable from a purely user
   perspective.  When using plain old tomcat, you can download a
   binary, add your cust

Re: An idea for defining custom valves in config.xml

[Jason Warner]

On Wed, Oct 8, 2008 at 6:55 PM, David Jencks <[EMAIL PROTECTED]> wrote:

>
> On Oct 8, 2008, at 1:55 PM, Joe Bohn wrote:
>
>  Jason Warner wrote:
>>
>>> Thanks for the explanation, David.  I don't disagree with anything you've
>>> explained, but I'm not sure you've addressed my concern about the disparity
>>> in the effort required to deploy a custom valve on tomcat and on geronimo.
>>>  Even with the a streamlined process involving a tomcat server portlet and
>>> using the tomcat6 plugin as a base, the user still has to become a plugin
>>> developer to deploy their valve on geronimo.  If that's how it has to be,
>>> then I suppose that's how it has to be.  I'm just concerned that it could
>>> turn off users that might have otherwise lived happily with geronimo.  I'm
>>> not really sure how widespread the use of custom valves are, though, so
>>> maybe it's just a small minority this would even effect.  I'd be curious to
>>> get some feedback from some other developers and see if they have any
>>> thoughts on the matter.  Anyone else out there keeping an eye on this
>>> thread?
>>>
>>
>> I've been keeping an eye on it and I agree with you Jason that there is a
>> disparity in the work required to add a valve to tomcat versus that required
>> to add a valve to tomcat embedded in Geronimo.  I also agree with David that
>> the current Tomcat process does not lend itself to a reproducible
>> configuration.
>>
>> In cases like this I tend to think like a politician and advocate a
>> both/and rather than an either/or.  I suspect that some users will want
>> things in Geronimo to be as similar to Tomcat as possible ... and so will
>> want a simple configuration solution.  Doing so might convince them to move
>> over to Geronimo and over time they may gain a greater appreciation for a
>> more Geronimo like solution.  Others might be coming in with more knowledge
>> of Geronimo and expect something that is more consistent with Geronimo and
>> can be reproduced.  Can we give them both what they want?
>>
>> It seems like we could help the Tomcat centric folks with a simple
>> configuration attribute that we can use to extend the classpath.  For the
>> more sophisticated Geronimo user we can direct them to rebuild/redeploy the
>> Tomcat module with the additional dependency on the valve jar ... perhaps
>> using c-m-p and then their own custom assembly. Even while providing the
>> first approach we can highly recommend the second approach.
>>
>> It seems to me that the attribute/classpath extension is a simple thing to
>> implement and will provide a high level of value to users that are
>> accustomed to Tomcat.  The Tomcat module rebuild/redeploy is just a matter
>> of documentation ... correct?
>>
>
> I guess I'm trying to argue that we should be making doing the "right
> thing" as easy as modifying tomcat to have a custom valve.
>
> I'm not convinced we're all that far off:
>
> tomcat -stop server
> geronimo - server restart may be needed later.
>
> tomcat - add jar to server/lib (?)
> geronimo - add jar to repository
>
> tomcat - edit server.xml
> geronmo -edit tomcat6 plam.xml
>
> geronimo - add artifact-alias (this could probably be automated into part
> of the next step).  Basically this should be editing the
> geronimo-plugin.xml.
> geronimo - deploy modified tomcat6 plan.xml, resulting in a new plugin.


I seem to be having issues with this step.  It's probably something I'm
doing, though.  Is there a good example of the artifact-alias element in
action?  My issue seems to be that I can't disable the tomcat6 plugin
because modules that are dependent upon it restart it automatically when the
server is started.  At least, this is what I believe is happening.  This
results in port conflicts and such when my custom tomcat6 module is
started.  Shouldn't the artifact-alias be pointing the dependent modules to
the  custom module instead of the default tomcat6 plugin?  If not, perhaps
that's functionality we should add.  It's possible I'm specifying the
artifact-alias incorrectly or in the wrong place, which is why I'm asking
for an example where this is done.  I see it mentioned a few times in the
documentation, but it's usually either out of context or not detailed
enough.

Thanks!


>
> tomcat - restart
> geronimo - restart tomcat-dependent plugins/apps
>
>
> There's basically only one more step in geronimo.  I'm not sure how well
> the "obsoletes" functionality works at the moment but ideally we could have
> the new plugin obsolete the original and so installing it would shut down
> the old one, shut down the plugins depending on it, and restart the
> dependencies after install.  This is the same number of steps.
>
> One missing bit here is that there is no good way to deploy an app with an
> external geronimo-plugin.xml to end up immediately with a plugin.
>
> thanks
> david jencks
>
>
>
>
>
>>
>> Joe
>>
>>  On Wed, Oct 8, 2008 at 2:25 PM, David Jencks <[EMAIL PROTECTED]>> [EMAIL PROTECTED]>> wrote:
>>>   On Oct 8

Re: An idea for defining custom valves in config.xml

[David Jencks]

On Oct 8, 2008, at 1:55 PM, Joe Bohn wrote:


Jason Warner wrote:
Thanks for the explanation, David.  I don't disagree with anything  
you've explained, but I'm not sure you've addressed my concern  
about the disparity in the effort required to deploy a custom valve  
on tomcat and on geronimo.  Even with the a streamlined process  
involving a tomcat server portlet and using the tomcat6 plugin as a  
base, the user still has to become a plugin developer to deploy  
their valve on geronimo.  If that's how it has to be, then I  
suppose that's how it has to be.  I'm just concerned that it could  
turn off users that might have otherwise lived happily with  
geronimo.  I'm not really sure how widespread the use of custom  
valves are, though, so maybe it's just a small minority this would  
even effect.  I'd be curious to get some feedback from some other  
developers and see if they have any thoughts on the matter.  Anyone  
else out there keeping an eye on this thread?


I've been keeping an eye on it and I agree with you Jason that there  
is a disparity in the work required to add a valve to tomcat versus  
that required to add a valve to tomcat embedded in Geronimo.  I also  
agree with David that the current Tomcat process does not lend  
itself to a reproducible configuration.


In cases like this I tend to think like a politician and advocate a  
both/and rather than an either/or.  I suspect that some users will  
want things in Geronimo to be as similar to Tomcat as possible ...  
and so will want a simple configuration solution.  Doing so might  
convince them to move over to Geronimo and over time they may gain a  
greater appreciation for a more Geronimo like solution.  Others  
might be coming in with more knowledge of Geronimo and expect  
something that is more consistent with Geronimo and can be  
reproduced.  Can we give them both what they want?


It seems like we could help the Tomcat centric folks with a simple  
configuration attribute that we can use to extend the classpath.   
For the more sophisticated Geronimo user we can direct them to  
rebuild/redeploy the Tomcat module with the additional dependency on  
the valve jar ... perhaps using c-m-p and then their own custom  
assembly. Even while providing the first approach we can highly  
recommend the second approach.


It seems to me that the attribute/classpath extension is a simple  
thing to implement and will provide a high level of value to users  
that are accustomed to Tomcat.  The Tomcat module rebuild/redeploy  
is just a matter of documentation ... correct?


I guess I'm trying to argue that we should be making doing the "right  
thing" as easy as modifying tomcat to have a custom valve.


I'm not convinced we're all that far off:

tomcat -stop server
geronimo - server restart may be needed later.

tomcat - add jar to server/lib (?)
geronimo - add jar to repository

tomcat - edit server.xml
geronmo -edit tomcat6 plam.xml

geronimo - add artifact-alias (this could probably be automated into  
part of the next step).  Basically this should be editing the geronimo- 
plugin.xml.

geronimo - deploy modified tomcat6 plan.xml, resulting in a new plugin.

tomcat - restart
geronimo - restart tomcat-dependent plugins/apps


There's basically only one more step in geronimo.  I'm not sure how  
well the "obsoletes" functionality works at the moment but ideally we  
could have the new plugin obsolete the original and so installing it  
would shut down the old one, shut down the plugins depending on it,  
and restart the dependencies after install.  This is the same number  
of steps.


One missing bit here is that there is no good way to deploy an app  
with an external geronimo-plugin.xml to end up immediately with a  
plugin.


thanks
david jencks






Joe

On Wed, Oct 8, 2008 at 2:25 PM, David Jencks  
<[EMAIL PROTECTED] > wrote:

   On Oct 8, 2008, at 11:04 AM, Jason Warner wrote:

   I'm not sure if these steps are reasonable from a purely user
   perspective.  When using plain old tomcat, you can download a
   binary, add your custom valve jar, make a config change and then
   use your server with its custom valve.  To accomplish the same
   task in geronimo, we are asking the user to download and install
   maven as well as grab source code for the tomcat plugin.  I'd
   really like to have a way we can accomplish the same goal while
   allowing the users to maintain a user level of interaction with
   geronimo.

   I think (1) is really a more realistic approach philosophically so
   I'll only discuss it more.
   Lets consider the results of the modifications on tomcat and  
geronimo. In tomcat, the user has modified their server  
installation and has
   no built-in record of what they did.  If they install another  
server

   somewhere else they have to look in their notes or try to remember
   what they did or ??? to get the same result.
   In geronimo + maven they have a reproducible and a

Re: An idea for defining custom valves in config.xml

[Joe Bohn]

Jason Warner wrote:
Thanks for the explanation, David.  I don't disagree with anything 
you've explained, but I'm not sure you've addressed my concern about the 
disparity in the effort required to deploy a custom valve on tomcat and 
on geronimo.  Even with the a streamlined process involving a tomcat 
server portlet and using the tomcat6 plugin as a base, the user still 
has to become a plugin developer to deploy their valve on geronimo.  If 
that's how it has to be, then I suppose that's how it has to be.  I'm 
just concerned that it could turn off users that might have otherwise 
lived happily with geronimo.  I'm not really sure how widespread the use 
of custom valves are, though, so maybe it's just a small minority this 
would even effect.  I'd be curious to get some feedback from some other 
developers and see if they have any thoughts on the matter.  Anyone else 
out there keeping an eye on this thread?


I've been keeping an eye on it and I agree with you Jason that there is 
a disparity in the work required to add a valve to tomcat versus that 
required to add a valve to tomcat embedded in Geronimo.  I also agree 
with David that the current Tomcat process does not lend itself to a 
reproducible configuration.


In cases like this I tend to think like a politician and advocate a 
both/and rather than an either/or.  I suspect that some users will want 
things in Geronimo to be as similar to Tomcat as possible ... and so 
will want a simple configuration solution.  Doing so might convince them 
to move over to Geronimo and over time they may gain a greater 
appreciation for a more Geronimo like solution.  Others might be coming 
in with more knowledge of Geronimo and expect something that is more 
consistent with Geronimo and can be reproduced.  Can we give them both 
what they want?


It seems like we could help the Tomcat centric folks with a simple 
configuration attribute that we can use to extend the classpath.  For 
the more sophisticated Geronimo user we can direct them to 
rebuild/redeploy the Tomcat module with the additional dependency on the 
valve jar ... perhaps using c-m-p and then their own custom assembly. 
Even while providing the first approach we can highly recommend the 
second approach.


It seems to me that the attribute/classpath extension is a simple thing 
to implement and will provide a high level of value to users that are 
accustomed to Tomcat.  The Tomcat module rebuild/redeploy is just a 
matter of documentation ... correct?


Joe



On Wed, Oct 8, 2008 at 2:25 PM, David Jencks <[EMAIL PROTECTED] 
> wrote:



On Oct 8, 2008, at 11:04 AM, Jason Warner wrote:


I'm not sure if these steps are reasonable from a purely user
perspective.  When using plain old tomcat, you can download a
binary, add your custom valve jar, make a config change and then
use your server with its custom valve.  To accomplish the same
task in geronimo, we are asking the user to download and install
maven as well as grab source code for the tomcat plugin.  I'd
really like to have a way we can accomplish the same goal while
allowing the users to maintain a user level of interaction with
geronimo.


I think (1) is really a more realistic approach philosophically so
I'll only discuss it more.

Lets consider the results of the modifications on tomcat and geronimo. 


In tomcat, the user has modified their server installation and has
no built-in record of what they did.  If they install another server
somewhere else they have to look in their notes or try to remember
what they did or ??? to get the same result.

In geronimo + maven they have a reproducible and automated way to
generate the customization that is suitable for storing in scm,
auditing, running through qa, etc etc.

Its also possible to fish the plan out of the tomcat6 plugin, modify
it a bit, and deploy it using gshell or (if you didn't start it)
using the console.  I think you could add the geronimo-plugin.xml
using the admin console and add the artifact-aias.  This on export
would result in a reusable plugin.  I'm not sure if you could turn
around and install the plugin on the server it was generated on to
install the artifact alias so on the next startup you'd get the new
tomcat plugin.

My philosophical objection to adding valves to the existing tomcat
config is that you've changed it in a fundamental way so you should
have a new, replacement, plugin instead.  By this point you can add
the extra jar(s) anyway as dependencies.

Maybe we could have a tomcat server portlet that would help with
 generating tomcat server plans with custom valves and connectors
and such stuff.  I think that right now that is still the hardest part.

thanks
david jencks




On Wed, Oct 8, 2008 at 1:22 PM, David Jencks
<[EMAIL PROTECTED] > wrote:


  

Re: An idea for defining custom valves in config.xml

[Jason Warner]

Thanks for the explanation, David.  I don't disagree with anything you've
explained, but I'm not sure you've addressed my concern about the disparity
in the effort required to deploy a custom valve on tomcat and on geronimo.
Even with the a streamlined process involving a tomcat server portlet and
using the tomcat6 plugin as a base, the user still has to become a plugin
developer to deploy their valve on geronimo.  If that's how it has to be,
then I suppose that's how it has to be.  I'm just concerned that it could
turn off users that might have otherwise lived happily with geronimo.  I'm
not really sure how widespread the use of custom valves are, though, so
maybe it's just a small minority this would even effect.  I'd be curious to
get some feedback from some other developers and see if they have any
thoughts on the matter.  Anyone else out there keeping an eye on this
thread?

On Wed, Oct 8, 2008 at 2:25 PM, David Jencks <[EMAIL PROTECTED]> wrote:

>
> On Oct 8, 2008, at 11:04 AM, Jason Warner wrote:
>
> I'm not sure if these steps are reasonable from a purely user perspective.
> When using plain old tomcat, you can download a binary, add your custom
> valve jar, make a config change and then use your server with its custom
> valve.  To accomplish the same task in geronimo, we are asking the user to
> download and install maven as well as grab source code for the tomcat
> plugin.  I'd really like to have a way we can accomplish the same goal while
> allowing the users to maintain a user level of interaction with geronimo.
>
>
> I think (1) is really a more realistic approach philosophically so I'll
> only discuss it more.
>
> Lets consider the results of the modifications on tomcat and geronimo.
>
> In tomcat, the user has modified their server installation and has no
> built-in record of what they did.  If they install another server somewhere
> else they have to look in their notes or try to remember what they did or
> ??? to get the same result.
>
> In geronimo + maven they have a reproducible and automated way to generate
> the customization that is suitable for storing in scm, auditing, running
> through qa, etc etc.
>
> Its also possible to fish the plan out of the tomcat6 plugin, modify it a
> bit, and deploy it using gshell or (if you didn't start it) using the
> console.  I think you could add the geronimo-plugin.xml using the admin
> console and add the artifact-aias.  This on export would result in a
> reusable plugin.  I'm not sure if you could turn around and install the
> plugin on the server it was generated on to install the artifact alias so on
> the next startup you'd get the new tomcat plugin.
>
> My philosophical objection to adding valves to the existing tomcat config
> is that you've changed it in a fundamental way so you should have a new,
> replacement, plugin instead.  By this point you can add the extra jar(s)
> anyway as dependencies.
>
> Maybe we could have a tomcat server portlet that would help with
>  generating tomcat server plans with custom valves and connectors and such
> stuff.  I think that right now that is still the hardest part.
>
> thanks
> david jencks
>
>
>
> On Wed, Oct 8, 2008 at 1:22 PM, David Jencks <[EMAIL PROTECTED]>wrote:
>
>>
>> On Oct 8, 2008, at 7:45 AM, Jason Warner wrote:
>>
>> David,
>>
>> Could you describe to me in a little more detail what you were thinking in
>> regards to defining a new tomcat server in a child classloader?  I'm still
>> working on creating an example, but I found some documentation confirming
>> tomcat's use of a TCCL in loading components and would like to continue the
>> discussion.  It seems you are proposing that a user create a plugin that
>> defines a new tomcat instance that includes their custom valve.  Am I
>> understanding correctly?  I've taken a look at the app-per-port sample you
>> described and this does not seem like a trivial task.
>>
>>
>> app-per-port is complicated by the additional features there of:
>> - only one artifact (an ear) instead of 2 or 3 plugins
>> - starting the connectors after the web app has started
>>
>> If neither of these features is needed you can just build a plugin with
>> the tomcat server + custom valve.  There are two strategies:
>> 1. replace the tomcat6 plugin
>> 2. use the (stopped) tomcat6 plugin as a parent for the new plugin.
>>
>> In either case I'd build the new plugin with maven and start by copying
>> the tomcat6 plugin and renaming it appropriately.  Then modify the plan to
>> include the custom valve.
>>
>> for (1), you'd just add the jar with the custom valve as a pom dependency.
>>  Use an artifact-alias so your tomcat plugin will replace the usual tomcat6
>> plugin.
>> for (2), you'd replace the pom dependencies with a dependency on the
>> tomcat6 plugin, and add the custom valve jar dependency.  In the c-m-p
>> configuration you'll want to specify the import on the tomcat^ plugin as
>> "classes" so it wont get started.  An artifact alias won't work here so
>> don't

Re: An idea for defining custom valves in config.xml

[David Jencks]

On Oct 8, 2008, at 11:04 AM, Jason Warner wrote:

I'm not sure if these steps are reasonable from a purely user  
perspective.  When using plain old tomcat, you can download a  
binary, add your custom valve jar, make a config change and then use  
your server with its custom valve.  To accomplish the same task in  
geronimo, we are asking the user to download and install maven as  
well as grab source code for the tomcat plugin.  I'd really like to  
have a way we can accomplish the same goal while allowing the users  
to maintain a user level of interaction with geronimo.


I think (1) is really a more realistic approach philosophically so  
I'll only discuss it more.


Lets consider the results of the modifications on tomcat and geronimo.

In tomcat, the user has modified their server installation and has no  
built-in record of what they did.  If they install another server  
somewhere else they have to look in their notes or try to remember  
what they did or ??? to get the same result.


In geronimo + maven they have a reproducible and automated way to  
generate the customization that is suitable for storing in scm,  
auditing, running through qa, etc etc.


Its also possible to fish the plan out of the tomcat6 plugin, modify  
it a bit, and deploy it using gshell or (if you didn't start it) using  
the console.  I think you could add the geronimo-plugin.xml using the  
admin console and add the artifact-aias.  This on export would result  
in a reusable plugin.  I'm not sure if you could turn around and  
install the plugin on the server it was generated on to install the  
artifact alias so on the next startup you'd get the new tomcat plugin.


My philosophical objection to adding valves to the existing tomcat  
config is that you've changed it in a fundamental way so you should  
have a new, replacement, plugin instead.  By this point you can add  
the extra jar(s) anyway as dependencies.


Maybe we could have a tomcat server portlet that would help with   
generating tomcat server plans with custom valves and connectors and  
such stuff.  I think that right now that is still the hardest part.


thanks
david jencks




On Wed, Oct 8, 2008 at 1:22 PM, David Jencks  
<[EMAIL PROTECTED]> wrote:


On Oct 8, 2008, at 7:45 AM, Jason Warner wrote:


David,

Could you describe to me in a little more detail what you were  
thinking in regards to defining a new tomcat server in a child  
classloader?  I'm still working on creating an example, but I found  
some documentation confirming tomcat's use of a TCCL in loading  
components and would like to continue the discussion.  It seems you  
are proposing that a user create a plugin that defines a new tomcat  
instance that includes their custom valve.  Am I understanding  
correctly?  I've taken a look at the app-per-port sample you  
described and this does not seem like a trivial task.


app-per-port is complicated by the additional features there of:
- only one artifact (an ear) instead of 2 or 3 plugins
- starting the connectors after the web app has started

If neither of these features is needed you can just build a plugin  
with the tomcat server + custom valve.  There are two strategies:

1. replace the tomcat6 plugin
2. use the (stopped) tomcat6 plugin as a parent for the new plugin.

In either case I'd build the new plugin with maven and start by  
copying the tomcat6 plugin and renaming it appropriately.  Then  
modify the plan to include the custom valve.


for (1), you'd just add the jar with the custom valve as a pom  
dependency.  Use an artifact-alias so your tomcat plugin will  
replace the usual tomcat6 plugin.
for (2), you'd replace the pom dependencies with a dependency on the  
tomcat6 plugin, and add the custom valve jar dependency.  In the c-m- 
p configuration you'll want to specify the import on the tomcat^  
plugin as "classes" so it wont get started.  An artifact alias won't  
work here so don't deploy things that depend on tomcat6 as that will  
result in the tomcat6 plugin starting and having port conflicts with  
your plugin.


Building a custom server including your plugin or installing it on a  
framework server via gshell is likely to work better than trying to  
replace the tomcat6 plugin while it's running through the admin  
console.


hope this helps
david jencks







Thanks,

On Mon, Oct 6, 2008 at 3:08 PM, Jason Warner <[EMAIL PROTECTED]>  
wrote:



On Mon, Oct 6, 2008 at 1:59 PM, David Jencks  
<[EMAIL PROTECTED]> wrote:


On Oct 6, 2008, at 10:35 AM, Jason Warner wrote:




On Mon, Oct 6, 2008 at 11:56 AM, David Jencks <[EMAIL PROTECTED] 
> wrote:


On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:




On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <[EMAIL PROTECTED] 
> wrote:


On Oct 3, 2008, at 12:51 PM, Jason Warner wrote:

  Hey all.  I'm working on an idea for allowing custom valves to  
be defined in config.xml.  Currently this isn't possible since  
the tomcat classloader would not contain the custom classes

Re: An idea for defining custom valves in config.xml

[Jason Warner]

I'm not sure if these steps are reasonable from a purely user perspective.
When using plain old tomcat, you can download a binary, add your custom
valve jar, make a config change and then use your server with its custom
valve.  To accomplish the same task in geronimo, we are asking the user to
download and install maven as well as grab source code for the tomcat
plugin.  I'd really like to have a way we can accomplish the same goal while
allowing the users to maintain a user level of interaction with geronimo.

On Wed, Oct 8, 2008 at 1:22 PM, David Jencks <[EMAIL PROTECTED]> wrote:

>
> On Oct 8, 2008, at 7:45 AM, Jason Warner wrote:
>
> David,
>
> Could you describe to me in a little more detail what you were thinking in
> regards to defining a new tomcat server in a child classloader?  I'm still
> working on creating an example, but I found some documentation confirming
> tomcat's use of a TCCL in loading components and would like to continue the
> discussion.  It seems you are proposing that a user create a plugin that
> defines a new tomcat instance that includes their custom valve.  Am I
> understanding correctly?  I've taken a look at the app-per-port sample you
> described and this does not seem like a trivial task.
>
>
> app-per-port is complicated by the additional features there of:
> - only one artifact (an ear) instead of 2 or 3 plugins
> - starting the connectors after the web app has started
>
> If neither of these features is needed you can just build a plugin with the
> tomcat server + custom valve.  There are two strategies:
> 1. replace the tomcat6 plugin
> 2. use the (stopped) tomcat6 plugin as a parent for the new plugin.
>
> In either case I'd build the new plugin with maven and start by copying the
> tomcat6 plugin and renaming it appropriately.  Then modify the plan to
> include the custom valve.
>
> for (1), you'd just add the jar with the custom valve as a pom dependency.
>  Use an artifact-alias so your tomcat plugin will replace the usual tomcat6
> plugin.
> for (2), you'd replace the pom dependencies with a dependency on the
> tomcat6 plugin, and add the custom valve jar dependency.  In the c-m-p
> configuration you'll want to specify the import on the tomcat^ plugin as
> "classes" so it wont get started.  An artifact alias won't work here so
> don't deploy things that depend on tomcat6 as that will result in the
> tomcat6 plugin starting and having port conflicts with your plugin.
>
> Building a custom server including your plugin or installing it on a
> framework server via gshell is likely to work better than trying to replace
> the tomcat6 plugin while it's running through the admin console.
>
> hope this helps
> david jencks
>
>
>
>
>
>
> Thanks,
>
> On Mon, Oct 6, 2008 at 3:08 PM, Jason Warner <[EMAIL PROTECTED]> wrote:
>
>>
>>
>> On Mon, Oct 6, 2008 at 1:59 PM, David Jencks <[EMAIL PROTECTED]>wrote:
>>
>>>
>>> On Oct 6, 2008, at 10:35 AM, Jason Warner wrote:
>>>
>>>
>>>
>>> On Mon, Oct 6, 2008 at 11:56 AM, David Jencks <[EMAIL PROTECTED]>wrote:
>>>

 On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:



 On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <[EMAIL PROTECTED]>wrote:

>
> On Oct 3, 2008, at 12:51 PM, Jason Warner wrote:
>
>   Hey all.  I'm working on an idea for allowing custom valves to be
> defined in config.xml.  Currently this isn't possible since the tomcat
> classloader would not contain the custom classes for the valve.  I've 
> create
> a jira for tracking this issue [1] and it contains a few links to
> workarounds.  IMHO, The solution we should be looking for is a way to add
> classes to a module without having to undeploy, modify the module config,
> and redeploying.
>
>
> People have suggested stuff like this before.  IMO it pretty much goes
> against the fundamental idea of geronimo of having fairly fixed plugins 
> with
> only a few knobs to turn to adjust things in config.xml and
> config-substitutions.properties.
>
> Why is changing the classloader contents in config.xml a good idea?
>  What is so hard about redeploying the app if you want to change its
> classloader significantly?  If you want to change a class in the app you
> have to redeploy it why is this situation different?
>

 The specific instance I have in mind for this change is using a custom
 valve for tomcat, so I think the scope really should be limited to just the
 tomcat module.  I can't think of another instance where this would be
 useful, so it's probably not necessary or desirable to expand it further.  
 I
 believe this situation is different because the structure of geronimo is
 causing a disconnect between the functionality of tomcat and the
 functionality of tomcat as it is embedded in geronimo.  As Don just said in
 the middle of my typing this, I don't believe we should expect the average
 user to have to re

Re: An idea for defining custom valves in config.xml

[David Jencks]

On Oct 8, 2008, at 7:45 AM, Jason Warner wrote:


David,

Could you describe to me in a little more detail what you were  
thinking in regards to defining a new tomcat server in a child  
classloader?  I'm still working on creating an example, but I found  
some documentation confirming tomcat's use of a TCCL in loading  
components and would like to continue the discussion.  It seems you  
are proposing that a user create a plugin that defines a new tomcat  
instance that includes their custom valve.  Am I understanding  
correctly?  I've taken a look at the app-per-port sample you  
described and this does not seem like a trivial task.


app-per-port is complicated by the additional features there of:
- only one artifact (an ear) instead of 2 or 3 plugins
- starting the connectors after the web app has started

If neither of these features is needed you can just build a plugin  
with the tomcat server + custom valve.  There are two strategies:

1. replace the tomcat6 plugin
2. use the (stopped) tomcat6 plugin as a parent for the new plugin.

In either case I'd build the new plugin with maven and start by  
copying the tomcat6 plugin and renaming it appropriately.  Then modify  
the plan to include the custom valve.


for (1), you'd just add the jar with the custom valve as a pom  
dependency.  Use an artifact-alias so your tomcat plugin will replace  
the usual tomcat6 plugin.
for (2), you'd replace the pom dependencies with a dependency on the  
tomcat6 plugin, and add the custom valve jar dependency.  In the c-m-p  
configuration you'll want to specify the import on the tomcat^ plugin  
as "classes" so it wont get started.  An artifact alias won't work  
here so don't deploy things that depend on tomcat6 as that will result  
in the tomcat6 plugin starting and having port conflicts with your  
plugin.


Building a custom server including your plugin or installing it on a  
framework server via gshell is likely to work better than trying to  
replace the tomcat6 plugin while it's running through the admin console.


hope this helps
david jencks







Thanks,

On Mon, Oct 6, 2008 at 3:08 PM, Jason Warner <[EMAIL PROTECTED]> wrote:


On Mon, Oct 6, 2008 at 1:59 PM, David Jencks  
<[EMAIL PROTECTED]> wrote:


On Oct 6, 2008, at 10:35 AM, Jason Warner wrote:




On Mon, Oct 6, 2008 at 11:56 AM, David Jencks  
<[EMAIL PROTECTED]> wrote:


On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:




On Fri, Oct 3, 2008 at 6:55 PM, David Jencks  
<[EMAIL PROTECTED]> wrote:


On Oct 3, 2008, at 12:51 PM, Jason Warner wrote:

  Hey all.  I'm working on an idea for allowing custom valves to  
be defined in config.xml.  Currently this isn't possible since  
the tomcat classloader would not contain the custom classes for  
the valve.  I've create a jira for tracking this issue [1] and it  
contains a few links to workarounds.  IMHO, The solution we  
should be looking for is a way to add classes to a module without  
having to undeploy, modify the module config, and redeploying.


People have suggested stuff like this before.  IMO it pretty much  
goes against the fundamental idea of geronimo of having fairly  
fixed plugins with only a few knobs to turn to adjust things in  
config.xml and config-substitutions.properties.


Why is changing the classloader contents in config.xml a good  
idea?  What is so hard about redeploying the app if you want to  
change its classloader significantly?  If you want to change a  
class in the app you have to redeploy it why is this situation  
different?


The specific instance I have in mind for this change is using a  
custom valve for tomcat, so I think the scope really should be  
limited to just the tomcat module.  I can't think of another  
instance where this would be useful, so it's probably not  
necessary or desirable to expand it further.  I believe this  
situation is different because the structure of geronimo is  
causing a disconnect between the functionality of tomcat and the  
functionality of tomcat as it is embedded in geronimo.  As Don  
just said in the middle of my typing this, I don't believe we  
should expect the average user to have to rebuild one of our  
modules to add something that can be added in a much simpler way  
within tomcat itself.


Could you explain more about the circumstances for this custom  
valve?  Is it intended to be for every app deployed on this tomcat  
server instance rather than for one particular app?  Will it work  
if it is in a child classloader of the tomcat plugin classloader?


When a valve is added to the tomcat valve chain, it becomes  
part of the request processing pipeline.  Every request that is  
made to that tomcat server instance passes through this valve chain  
as it's processed regardless of whether the valve will act upon it  
or not.  It's possible that a single web app will be the only app  
to use the valve, and for that instance it is already possible to  
define the valve in the context of the web app

Re: An idea for defining custom valves in config.xml

[Jason Warner]

David,

Could you describe to me in a little more detail what you were thinking in
regards to defining a new tomcat server in a child classloader?  I'm still
working on creating an example, but I found some documentation confirming
tomcat's use of a TCCL in loading components and would like to continue the
discussion.  It seems you are proposing that a user create a plugin that
defines a new tomcat instance that includes their custom valve.  Am I
understanding correctly?  I've taken a look at the app-per-port sample you
described and this does not seem like a trivial task.

Thanks,

On Mon, Oct 6, 2008 at 3:08 PM, Jason Warner <[EMAIL PROTECTED]> wrote:

>
>
> On Mon, Oct 6, 2008 at 1:59 PM, David Jencks <[EMAIL PROTECTED]>wrote:
>
>>
>> On Oct 6, 2008, at 10:35 AM, Jason Warner wrote:
>>
>>
>>
>> On Mon, Oct 6, 2008 at 11:56 AM, David Jencks <[EMAIL PROTECTED]>wrote:
>>
>>>
>>> On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:
>>>
>>>
>>>
>>> On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <[EMAIL PROTECTED]>wrote:
>>>

 On Oct 3, 2008, at 12:51 PM, Jason Warner wrote:

   Hey all.  I'm working on an idea for allowing custom valves to be
 defined in config.xml.  Currently this isn't possible since the tomcat
 classloader would not contain the custom classes for the valve.  I've 
 create
 a jira for tracking this issue [1] and it contains a few links to
 workarounds.  IMHO, The solution we should be looking for is a way to add
 classes to a module without having to undeploy, modify the module config,
 and redeploying.


 People have suggested stuff like this before.  IMO it pretty much goes
 against the fundamental idea of geronimo of having fairly fixed plugins 
 with
 only a few knobs to turn to adjust things in config.xml and
 config-substitutions.properties.

 Why is changing the classloader contents in config.xml a good idea?
  What is so hard about redeploying the app if you want to change its
 classloader significantly?  If you want to change a class in the app you
 have to redeploy it why is this situation different?

>>>
>>> The specific instance I have in mind for this change is using a custom
>>> valve for tomcat, so I think the scope really should be limited to just the
>>> tomcat module.  I can't think of another instance where this would be
>>> useful, so it's probably not necessary or desirable to expand it further.  I
>>> believe this situation is different because the structure of geronimo is
>>> causing a disconnect between the functionality of tomcat and the
>>> functionality of tomcat as it is embedded in geronimo.  As Don just said in
>>> the middle of my typing this, I don't believe we should expect the average
>>> user to have to rebuild one of our modules to add something that can be
>>> added in a much simpler way within tomcat itself.
>>>
>>>
>>> Could you explain more about the circumstances for this custom valve?  Is
>>> it intended to be for every app deployed on this tomcat server instance
>>> rather than for one particular app?  Will it work if it is in a child
>>> classloader of the tomcat plugin classloader?
>>>
>>
>> When a valve is added to the tomcat valve chain, it becomes part of
>> the request processing pipeline.  Every request that is made to that tomcat
>> server instance passes through this valve chain as it's processed regardless
>> of whether the valve will act upon it or not.  It's possible that a single
>> web app will be the only app to use the valve, and for that instance it is
>> already possible to define the valve in the context of the web app rather
>> than the tomcat server.  We need to be able to define a valve as part of
>> tomcat server instance as well, though, to be consistent with tomcat.
>> Currently we can only define the valves on the per web app basis.
>> I don't think this would work in a child classloader of the tomcat
>> plugin classloader.  When we start up the tomcat module now, the currently
>> defined valves are processed and added to the engine.  The custom valves
>> would need to be added to the valves already in the tomcat engine to be
>> available in the way described previously.  Once the valves were added to
>> the engine (which would be using the tomcat classloader, I believe) the
>> class def not found issues we currently see would pop back up.  For this to
>> work, the custom valve classes and the tomcat engine would need to share the
>> same classloader.
>>
>>
>> Could you try this to be sure?  I would hope that tomcat would use a TCCL
>> or supplied classloader for loading components rather than something like
>> TomcatEngine.class.getClassLoader() which I believe is what you are
>> suggesting it does.
>>
>> One example of an inconvenient tomcat configuration is the app-per-port
>> sample where we set up a whole additional tomcat server in a child
>> configuration.  I think all the server components in that example are also

Re: An idea for defining custom valves in config.xml

[Jason Warner]

On Mon, Oct 6, 2008 at 1:59 PM, David Jencks <[EMAIL PROTECTED]> wrote:

>
> On Oct 6, 2008, at 10:35 AM, Jason Warner wrote:
>
>
>
> On Mon, Oct 6, 2008 at 11:56 AM, David Jencks <[EMAIL PROTECTED]>wrote:
>
>>
>> On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:
>>
>>
>>
>> On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <[EMAIL PROTECTED]>wrote:
>>
>>>
>>> On Oct 3, 2008, at 12:51 PM, Jason Warner wrote:
>>>
>>>   Hey all.  I'm working on an idea for allowing custom valves to be
>>> defined in config.xml.  Currently this isn't possible since the tomcat
>>> classloader would not contain the custom classes for the valve.  I've create
>>> a jira for tracking this issue [1] and it contains a few links to
>>> workarounds.  IMHO, The solution we should be looking for is a way to add
>>> classes to a module without having to undeploy, modify the module config,
>>> and redeploying.
>>>
>>>
>>> People have suggested stuff like this before.  IMO it pretty much goes
>>> against the fundamental idea of geronimo of having fairly fixed plugins with
>>> only a few knobs to turn to adjust things in config.xml and
>>> config-substitutions.properties.
>>>
>>> Why is changing the classloader contents in config.xml a good idea?  What
>>> is so hard about redeploying the app if you want to change its classloader
>>> significantly?  If you want to change a class in the app you have to
>>> redeploy it why is this situation different?
>>>
>>
>> The specific instance I have in mind for this change is using a custom
>> valve for tomcat, so I think the scope really should be limited to just the
>> tomcat module.  I can't think of another instance where this would be
>> useful, so it's probably not necessary or desirable to expand it further.  I
>> believe this situation is different because the structure of geronimo is
>> causing a disconnect between the functionality of tomcat and the
>> functionality of tomcat as it is embedded in geronimo.  As Don just said in
>> the middle of my typing this, I don't believe we should expect the average
>> user to have to rebuild one of our modules to add something that can be
>> added in a much simpler way within tomcat itself.
>>
>>
>> Could you explain more about the circumstances for this custom valve?  Is
>> it intended to be for every app deployed on this tomcat server instance
>> rather than for one particular app?  Will it work if it is in a child
>> classloader of the tomcat plugin classloader?
>>
>
> When a valve is added to the tomcat valve chain, it becomes part of the
> request processing pipeline.  Every request that is made to that tomcat
> server instance passes through this valve chain as it's processed regardless
> of whether the valve will act upon it or not.  It's possible that a single
> web app will be the only app to use the valve, and for that instance it is
> already possible to define the valve in the context of the web app rather
> than the tomcat server.  We need to be able to define a valve as part of
> tomcat server instance as well, though, to be consistent with tomcat.
> Currently we can only define the valves on the per web app basis.
> I don't think this would work in a child classloader of the tomcat
> plugin classloader.  When we start up the tomcat module now, the currently
> defined valves are processed and added to the engine.  The custom valves
> would need to be added to the valves already in the tomcat engine to be
> available in the way described previously.  Once the valves were added to
> the engine (which would be using the tomcat classloader, I believe) the
> class def not found issues we currently see would pop back up.  For this to
> work, the custom valve classes and the tomcat engine would need to share the
> same classloader.
>
>
> Could you try this to be sure?  I would hope that tomcat would use a TCCL
> or supplied classloader for loading components rather than something like
> TomcatEngine.class.getClassLoader() which I believe is what you are
> suggesting it does.
>
> One example of an inconvenient tomcat configuration is the app-per-port
> sample where we set up a whole additional tomcat server in a child
> configuration.  I think all the server components in that example are also
> in a standard tomcat server but its a similar situation to what I'm thinking
> of here in terms of configuring a tomcat server in a child classloader.
>
>
Sure.  It'll take me a bit as I don't actually have any examples prepared
yet.

>
>
>> At the moment I would MUCH rather see us make it easier for users to
>> deploy new/different/modified tomcat servers (and other plugins) than
>> introduce a hack to modify classloaders of existing plugins.  Our
>> customization story is already  too complicated, IMO we don't need to glue
>> on more bits that don't actually fit well.
>>
>> IMO the best end result for users is to have a new tomcat plugin with the
>> needed extra jars and valve configuration.  Lets look for a way to make it
>> really easy for our user

Re: An idea for defining custom valves in config.xml

[David Jencks]

On Oct 6, 2008, at 10:35 AM, Jason Warner wrote:




On Mon, Oct 6, 2008 at 11:56 AM, David Jencks  
<[EMAIL PROTECTED]> wrote:


On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:




On Fri, Oct 3, 2008 at 6:55 PM, David Jencks  
<[EMAIL PROTECTED]> wrote:


On Oct 3, 2008, at 12:51 PM, Jason Warner wrote:

  Hey all.  I'm working on an idea for allowing custom valves to  
be defined in config.xml.  Currently this isn't possible since the  
tomcat classloader would not contain the custom classes for the  
valve.  I've create a jira for tracking this issue [1] and it  
contains a few links to workarounds.  IMHO, The solution we should  
be looking for is a way to add classes to a module without having  
to undeploy, modify the module config, and redeploying.


People have suggested stuff like this before.  IMO it pretty much  
goes against the fundamental idea of geronimo of having fairly  
fixed plugins with only a few knobs to turn to adjust things in  
config.xml and config-substitutions.properties.


Why is changing the classloader contents in config.xml a good  
idea?  What is so hard about redeploying the app if you want to  
change its classloader significantly?  If you want to change a  
class in the app you have to redeploy it why is this situation  
different?


The specific instance I have in mind for this change is using a  
custom valve for tomcat, so I think the scope really should be  
limited to just the tomcat module.  I can't think of another  
instance where this would be useful, so it's probably not necessary  
or desirable to expand it further.  I believe this situation is  
different because the structure of geronimo is causing a disconnect  
between the functionality of tomcat and the functionality of tomcat  
as it is embedded in geronimo.  As Don just said in the middle of  
my typing this, I don't believe we should expect the average user  
to have to rebuild one of our modules to add something that can be  
added in a much simpler way within tomcat itself.


Could you explain more about the circumstances for this custom  
valve?  Is it intended to be for every app deployed on this tomcat  
server instance rather than for one particular app?  Will it work if  
it is in a child classloader of the tomcat plugin classloader?


When a valve is added to the tomcat valve chain, it becomes part  
of the request processing pipeline.  Every request that is made to  
that tomcat server instance passes through this valve chain as it's  
processed regardless of whether the valve will act upon it or not.   
It's possible that a single web app will be the only app to use the  
valve, and for that instance it is already possible to define the  
valve in the context of the web app rather than the tomcat server.   
We need to be able to define a valve as part of tomcat server  
instance as well, though, to be consistent with tomcat.  Currently  
we can only define the valves on the per web app basis.
I don't think this would work in a child classloader of the  
tomcat plugin classloader.  When we start up the tomcat module now,  
the currently defined valves are processed and added to the engine.   
The custom valves would need to be added to the valves already in  
the tomcat engine to be available in the way described previously.   
Once the valves were added to the engine (which would be using the  
tomcat classloader, I believe) the class def not found issues we  
currently see would pop back up.  For this to work, the custom valve  
classes and the tomcat engine would need to share the same  
classloader.


Could you try this to be sure?  I would hope that tomcat would use a  
TCCL or supplied classloader for loading components rather than  
something like TomcatEngine.class.getClassLoader() which I believe is  
what you are suggesting it does.


One example of an inconvenient tomcat configuration is the app-per- 
port sample where we set up a whole additional tomcat server in a  
child configuration.  I think all the server components in that  
example are also in a standard tomcat server but its a similar  
situation to what I'm thinking of here in terms of configuring a  
tomcat server in a child classloader.






At the moment I would MUCH rather see us make it easier for users to  
deploy new/different/modified tomcat servers (and other plugins)  
than introduce a hack to modify classloaders of existing plugins.   
Our customization story is already  too complicated, IMO we don't  
need to glue on more bits that don't actually fit well.


IMO the best end result for users is to have a new tomcat plugin  
with the needed extra jars and valve configuration.  Lets look for a  
way to make it really easy for our users to get there.


I agree that a whole new plugin with all desired functionality  
included would be best for users.  Any ideas how to make this easier  
than it currently is?  Perhaps the attribute idea mentioned by Joe  
could serve as a temporary solution until we

Re: An idea for defining custom valves in config.xml

[Jason Warner]

On Mon, Oct 6, 2008 at 11:56 AM, David Jencks <[EMAIL PROTECTED]>wrote:

>
> On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:
>
>
>
> On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <[EMAIL PROTECTED]>wrote:
>
>>
>> On Oct 3, 2008, at 12:51 PM, Jason Warner wrote:
>>
>>   Hey all.  I'm working on an idea for allowing custom valves to be
>> defined in config.xml.  Currently this isn't possible since the tomcat
>> classloader would not contain the custom classes for the valve.  I've create
>> a jira for tracking this issue [1] and it contains a few links to
>> workarounds.  IMHO, The solution we should be looking for is a way to add
>> classes to a module without having to undeploy, modify the module config,
>> and redeploying.
>>
>>
>> People have suggested stuff like this before.  IMO it pretty much goes
>> against the fundamental idea of geronimo of having fairly fixed plugins with
>> only a few knobs to turn to adjust things in config.xml and
>> config-substitutions.properties.
>>
>> Why is changing the classloader contents in config.xml a good idea?  What
>> is so hard about redeploying the app if you want to change its classloader
>> significantly?  If you want to change a class in the app you have to
>> redeploy it why is this situation different?
>>
>
> The specific instance I have in mind for this change is using a custom
> valve for tomcat, so I think the scope really should be limited to just the
> tomcat module.  I can't think of another instance where this would be
> useful, so it's probably not necessary or desirable to expand it further.  I
> believe this situation is different because the structure of geronimo is
> causing a disconnect between the functionality of tomcat and the
> functionality of tomcat as it is embedded in geronimo.  As Don just said in
> the middle of my typing this, I don't believe we should expect the average
> user to have to rebuild one of our modules to add something that can be
> added in a much simpler way within tomcat itself.
>
>
> Could you explain more about the circumstances for this custom valve?  Is
> it intended to be for every app deployed on this tomcat server instance
> rather than for one particular app?  Will it work if it is in a child
> classloader of the tomcat plugin classloader?
>

When a valve is added to the tomcat valve chain, it becomes part of the
request processing pipeline.  Every request that is made to that tomcat
server instance passes through this valve chain as it's processed regardless
of whether the valve will act upon it or not.  It's possible that a single
web app will be the only app to use the valve, and for that instance it is
already possible to define the valve in the context of the web app rather
than the tomcat server.  We need to be able to define a valve as part of
tomcat server instance as well, though, to be consistent with tomcat.
Currently we can only define the valves on the per web app basis.
I don't think this would work in a child classloader of the tomcat
plugin classloader.  When we start up the tomcat module now, the currently
defined valves are processed and added to the engine.  The custom valves
would need to be added to the valves already in the tomcat engine to be
available in the way described previously.  Once the valves were added to
the engine (which would be using the tomcat classloader, I believe) the
class def not found issues we currently see would pop back up.  For this to
work, the custom valve classes and the tomcat engine would need to share the
same classloader.

>
> At the moment I would MUCH rather see us make it easier for users to deploy
> new/different/modified tomcat servers (and other plugins) than introduce a
> hack to modify classloaders of existing plugins.  Our customization story is
> already  too complicated, IMO we don't need to glue on more bits that don't
> actually fit well.
>
> IMO the best end result for users is to have a new tomcat plugin with the
> needed extra jars and valve configuration.  Lets look for a way to make it
> really easy for our users to get there.
>

I agree that a whole new plugin with all desired functionality included
would be best for users.  Any ideas how to make this easier than it
currently is?  Perhaps the attribute idea mentioned by Joe could serve as a
temporary solution until we can come up with something better.

>
> How would you deal with this in an osgi or spring environment?
>

> thanks
> david jencks
>
>
>
> Thanks!
>
>>
>> thanks
>> david jencks
>>
>>
>> I think this can be done by allowing a user to indicate jars that should
>> be loaded by a module within the config.xml.  These jars can then be added
>> to the module's classloader for use by the module.  I'm not extremely
>> familiar with how our classloader works, but I've taken a look through the
>> code and I think the ability to add to the classloader can be implemented
>> without too much difficulty.  I'm not quite sure what type of scope to give
>> this change, though.  Shou

Re: An idea for defining custom valves in config.xml

[David Jencks]

On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:




On Fri, Oct 3, 2008 at 6:55 PM, David Jencks  
<[EMAIL PROTECTED]> wrote:


On Oct 3, 2008, at 12:51 PM, Jason Warner wrote:

  Hey all.  I'm working on an idea for allowing custom valves to be  
defined in config.xml.  Currently this isn't possible since the  
tomcat classloader would not contain the custom classes for the  
valve.  I've create a jira for tracking this issue [1] and it  
contains a few links to workarounds.  IMHO, The solution we should  
be looking for is a way to add classes to a module without having  
to undeploy, modify the module config, and redeploying.


People have suggested stuff like this before.  IMO it pretty much  
goes against the fundamental idea of geronimo of having fairly fixed  
plugins with only a few knobs to turn to adjust things in config.xml  
and config-substitutions.properties.


Why is changing the classloader contents in config.xml a good idea?   
What is so hard about redeploying the app if you want to change its  
classloader significantly?  If you want to change a class in the app  
you have to redeploy it why is this situation different?


The specific instance I have in mind for this change is using a  
custom valve for tomcat, so I think the scope really should be  
limited to just the tomcat module.  I can't think of another  
instance where this would be useful, so it's probably not necessary  
or desirable to expand it further.  I believe this situation is  
different because the structure of geronimo is causing a disconnect  
between the functionality of tomcat and the functionality of tomcat  
as it is embedded in geronimo.  As Don just said in the middle of my  
typing this, I don't believe we should expect the average user to  
have to rebuild one of our modules to add something that can be  
added in a much simpler way within tomcat itself.


Could you explain more about the circumstances for this custom valve?   
Is it intended to be for every app deployed on this tomcat server  
instance rather than for one particular app?  Will it work if it is in  
a child classloader of the tomcat plugin classloader?


At the moment I would MUCH rather see us make it easier for users to  
deploy new/different/modified tomcat servers (and other plugins) than  
introduce a hack to modify classloaders of existing plugins.  Our  
customization story is already  too complicated, IMO we don't need to  
glue on more bits that don't actually fit well.


IMO the best end result for users is to have a new tomcat plugin with  
the needed extra jars and valve configuration.  Lets look for a way to  
make it really easy for our users to get there.


How would you deal with this in an osgi or spring environment?

thanks
david jencks



Thanks!

thanks
david jencks


I think this can be done by allowing a user to indicate jars that  
should be loaded by a module within the config.xml.  These jars can  
then be added to the module's classloader for use by the module.   
I'm not extremely familiar with how our classloader works, but I've  
taken a look through the code and I think the ability to add to the  
classloader can be implemented without too much difficulty.  I'm  
not quite sure what type of scope to give this change, though.   
Should I leave it as a change aimed solely at tomcat valves or  
should it be expanded to encompass any configuration?  I realize  
this is only a rough idea of what i plan to do, but I'm still  
working out the details of how to proceed.  I'm hoping for some  
feedback on what I intend to do and possibly some alternate ideas  
if anyone has some.


Thanks!


[1]  https://issues.apache.org/jira/browse/GERONIMO-4335

--
~Jason Warner





--
~Jason Warner

Re: An idea for defining custom valves in config.xml

[Joe Bohn]

Jason Warner wrote:



On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <[EMAIL PROTECTED] 
> wrote:



On Oct 3, 2008, at 12:51 PM, Jason Warner wrote:


  Hey all.  I'm working on an idea for allowing custom valves to
be defined in config.xml.  Currently this isn't possible since the
tomcat classloader would not contain the custom classes for the
valve.  I've create a jira for tracking this issue [1] and it
contains a few links to workarounds.  IMHO, The solution we should
be looking for is a way to add classes to a module without having
to undeploy, modify the module config, and redeploying. 


People have suggested stuff like this before.  IMO it pretty much
goes against the fundamental idea of geronimo of having fairly fixed
plugins with only a few knobs to turn to adjust things in config.xml
and config-substitutions.properties.

Why is changing the classloader contents in config.xml a good idea?
 What is so hard about redeploying the app if you want to change its
classloader significantly?  If you want to change a class in the app
you have to redeploy it why is this situation different?


The specific instance I have in mind for this change is using a custom 
valve for tomcat, so I think the scope really should be limited to just 
the tomcat module.  I can't think of another instance where this would 
be useful, so it's probably not necessary or desirable to expand it 
further.  I believe this situation is different because the structure of 
geronimo is causing a disconnect between the functionality of tomcat and 
the functionality of tomcat as it is embedded in geronimo.  As Don just 
said in the middle of my typing this, I don't believe we should expect 
the average user to have to rebuild one of our modules to add something 
that can be added in a much simpler way within tomcat itself. 


Assuming that you can add a new valve to Tomcat with a simple 
configuration change then I agree that we should be able to do the same 
thing within Geronimo without requiring a user to redeploy the Tomcat 
plugin.


I also agree that it seems this would be a tomcat module specific change 
and not a general purpose thing (at least for now).


I know that David Jencks will cringe  but it seems like we should be 
able to do this in a similar fashion to how we extend the classloader in 
SharedLib.java.   We can just add an attribute or two on the Tomcat 
GBean so the user can specify the location(s) of their valve jars and 
then extend the classpath when the bean is constructed.


Joe




Thanks!


thanks
david jencks



I think this can be done by allowing a user to indicate jars that
should be loaded by a module within the config.xml.  These jars
can then be added to the module's classloader for use by the
module.  I'm not extremely familiar with how our classloader
works, but I've taken a look through the code and I think the
ability to add to the classloader can be implemented without too
much difficulty.  I'm not quite sure what type of scope to give
this change, though.  Should I leave it as a change aimed solely
at tomcat valves or should it be expanded to encompass any
configuration?  I realize this is only a rough idea of what i plan
to do, but I'm still working out the details of how to proceed. 
I'm hoping for some feedback on what I intend to do and possibly

some alternate ideas if anyone has some.

Thanks!
 


[1]  https://issues.apache.org/jira/browse/GERONIMO-4335

-- 
~Jason Warner





--
~Jason Warner

Re: An idea for defining custom valves in config.xml

[Jason Warner]

On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <[EMAIL PROTECTED]> wrote:

>
> On Oct 3, 2008, at 12:51 PM, Jason Warner wrote:
>
>   Hey all.  I'm working on an idea for allowing custom valves to be defined
> in config.xml.  Currently this isn't possible since the tomcat classloader
> would not contain the custom classes for the valve.  I've create a jira for
> tracking this issue [1] and it contains a few links to workarounds.  IMHO,
> The solution we should be looking for is a way to add classes to a module
> without having to undeploy, modify the module config, and redeploying.
>
>
> People have suggested stuff like this before.  IMO it pretty much goes
> against the fundamental idea of geronimo of having fairly fixed plugins with
> only a few knobs to turn to adjust things in config.xml and
> config-substitutions.properties.
>
> Why is changing the classloader contents in config.xml a good idea?  What
> is so hard about redeploying the app if you want to change its classloader
> significantly?  If you want to change a class in the app you have to
> redeploy it why is this situation different?
>

The specific instance I have in mind for this change is using a custom valve
for tomcat, so I think the scope really should be limited to just the tomcat
module.  I can't think of another instance where this would be useful, so
it's probably not necessary or desirable to expand it further.  I believe
this situation is different because the structure of geronimo is causing a
disconnect between the functionality of tomcat and the functionality of
tomcat as it is embedded in geronimo.  As Don just said in the middle of my
typing this, I don't believe we should expect the average user to have to
rebuild one of our modules to add something that can be added in a much
simpler way within tomcat itself.

Thanks!

>
> thanks
> david jencks
>
>
> I think this can be done by allowing a user to indicate jars that should be
> loaded by a module within the config.xml.  These jars can then be added to
> the module's classloader for use by the module.  I'm not extremely familiar
> with how our classloader works, but I've taken a look through the code and I
> think the ability to add to the classloader can be implemented without too
> much difficulty.  I'm not quite sure what type of scope to give this change,
> though.  Should I leave it as a change aimed solely at tomcat valves or
> should it be expanded to encompass any configuration?  I realize this is
> only a rough idea of what i plan to do, but I'm still working out the
> details of how to proceed.  I'm hoping for some feedback on what I intend to
> do and possibly some alternate ideas if anyone has some.
>
> Thanks!
>
>
> [1]  https://issues.apache.org/jira/browse/GERONIMO-4335
>
> --
> ~Jason Warner
>
>
>


-- 
~Jason Warner

Re: An idea for defining custom valves in config.xml

[Donald Woods]

In-line below.


David Jencks wrote:


On Oct 3, 2008, at 12:51 PM, Jason Warner wrote:

  Hey all.  I'm working on an idea for allowing custom valves to be 
defined in config.xml.  Currently this isn't possible since the tomcat 
classloader would not contain the custom classes for the valve.  I've 
create a jira for tracking this issue [1] and it contains a few links 
to workarounds.  IMHO, The solution we should be looking for is a way 
to add classes to a module without having to undeploy, modify the 
module config, and redeploying. 


People have suggested stuff like this before.  IMO it pretty much goes 
against the fundamental idea of geronimo of having fairly fixed plugins 
with only a few knobs to turn to adjust things in config.xml and 
config-substitutions.properties.


Why is changing the classloader contents in config.xml a good idea? 
 What is so hard about redeploying the app if you want to change its 
classloader significantly?  If you want to change a class in the app you 
have to redeploy it why is this situation different?




We shouldn't expect every Geronimo user to have to setup a local build 
environment to perform such Tomcat reconfiguration.  Especially given 
what Jason is trying to do doesn't require Tomcat users to rebuild 
Tomcat  This is a deficiency in Geronimo that needs to be resolved.





thanks
david jencks


I think this can be done by allowing a user to indicate jars that 
should be loaded by a module within the config.xml.  These jars can 
then be added to the module's classloader for use by the module.  I'm 
not extremely familiar with how our classloader works, but I've taken 
a look through the code and I think the ability to add to the 
classloader can be implemented without too much difficulty.  I'm not 
quite sure what type of scope to give this change, though.  Should I 
leave it as a change aimed solely at tomcat valves or should it be 
expanded to encompass any configuration?  I realize this is only a 
rough idea of what i plan to do, but I'm still working out the details 
of how to proceed.  I'm hoping for some feedback on what I intend to 
do and possibly some alternate ideas if anyone has some.


Thanks!
 


[1]  https://issues.apache.org/jira/browse/GERONIMO-4335

--
~Jason Warner

Re: An idea for defining custom valves in config.xml

[David Jencks]

On Oct 3, 2008, at 12:51 PM, Jason Warner wrote:

  Hey all.  I'm working on an idea for allowing custom valves to be  
defined in config.xml.  Currently this isn't possible since the  
tomcat classloader would not contain the custom classes for the  
valve.  I've create a jira for tracking this issue [1] and it  
contains a few links to workarounds.  IMHO, The solution we should  
be looking for is a way to add classes to a module without having to  
undeploy, modify the module config, and redeploying.


People have suggested stuff like this before.  IMO it pretty much goes  
against the fundamental idea of geronimo of having fairly fixed  
plugins with only a few knobs to turn to adjust things in config.xml  
and config-substitutions.properties.


Why is changing the classloader contents in config.xml a good idea?   
What is so hard about redeploying the app if you want to change its  
classloader significantly?  If you want to change a class in the app  
you have to redeploy it why is this situation different?


thanks
david jencks


I think this can be done by allowing a user to indicate jars that  
should be loaded by a module within the config.xml.  These jars can  
then be added to the module's classloader for use by the module.   
I'm not extremely familiar with how our classloader works, but I've  
taken a look through the code and I think the ability to add to the  
classloader can be implemented without too much difficulty.  I'm not  
quite sure what type of scope to give this change, though.  Should I  
leave it as a change aimed solely at tomcat valves or should it be  
expanded to encompass any configuration?  I realize this is only a  
rough idea of what i plan to do, but I'm still working out the  
details of how to proceed.  I'm hoping for some feedback on what I  
intend to do and possibly some alternate ideas if anyone has some.


Thanks!


[1]  https://issues.apache.org/jira/browse/GERONIMO-4335

--
~Jason Warner