Re: An idea for defining custom valves in config.xml
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 the
GBeans, For
Re: An idea for defining custom valves in config.xml
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(...))
reference(referenceName) {
pattern('aPattern')
pattern('aSecondPattern')
}
}
removeGBeansMatching('aPattern')
}
Re: An idea for defining custom valves in config.xml
Hi Gianny,
Have you made any progress with this? Are you targeting this for the 2.2
release (whenever that happens to be)?
Thanks!
On Fri, Oct 17, 2008 at 8:11 PM, Gianny Damour
[EMAIL PROTECTED] wrote:
Hi,
I am proposing the following implementation to start with:
1. In the META-INF folder of a config, we scan for files matching the
patterns dependencies-(.*).groovy and extentions-(.*).groovy.
2. We execute the scripts dependencies-(.*).groovy which modify
dependencies. For instance, such scripts may look like:
configurationData + dependency(groupId: 'group', artifactId: 'artifact',
version: '1.1', type: 'jar', importType: importType) -- add the declared
dependency
configurationData - dependency(groupId: 'group', artifactId: 'artifact',
version: '1.0', type: 'jar') -- remove the declared dependency
This gives us the final classloader of the config.
3. We execute the scripts extentions-(.*).groovy which update the GBeans,
For instance, such scripts may look like:
gBeanBuilder.configure {
addGBean(BasicNodeInfo) { -- add a GBean
attribute(name: 'node1')
attribute(extendedJMXConnectorInfo: new
BasicExtendedJMXConnectorInfo(...))
reference(referenceName) {
pattern('aPattern')
pattern('aSecondPattern')
}
}
removeGBeansMatching('aPattern')
}
gBeanBuilder.updatedConfigurationData
The implementation of such scripts should be as simple as the modification
of config.xml.
The fact that they are collocated with the configuration they modify
increases cohesion. It would be neat to have such scripts instead of the
native or XStream serializations of config.ser.
Let me know your thoughts?
Thanks,
Gianny
On 16/10/2008, at 11:17 PM, Jason Warner wrote:
While David is more interested in the philosophy, I'd prefer to know a
little bit more about your thoughts on implementation. Specifically what do
you imagine would be involved in defining this configuration? Would it be
as simple as a definition in config.xml?
On Thu, Oct 16, 2008 at 4:08 AM, Gianny Damour
[EMAIL PROTECTED] wrote:
Hi David,
You are correct: the underpinning philosophy of these approaches is to
make it easier to modify pre-canned plugins through extension points.
This may be a good approach to improve further the packaging model of
dependencies and services. Let's say that an end-user wants to add a
connector to the tomcat6 plugin. Instead of using the admin console or
updating his config.xml, he can simply deploy a cumulative plan. This notion
of cumulative plan is the key differentiator as users can share their
cumulative plans as-is - i.e. w/o knowing what the plugin to be modified
looks like. To some extent, providing a plan ready to be deployed instead
of deployment instructions is better for novices.
I will work on the Groovy builder approach and post back more details as I
go.
Thanks,
Gianny
On 16/10/2008, at 10:59 AM, David Jencks wrote:
Hi Gianny,
First, I'd like to make sure I understand the philosophy behind your
proposals. IIUC they both involve the idea of making it easy to modify an
existing plugin rather than making it easy to replace an existing plugin
with a similar one.
Why is this a good idea? My idea has been that we should make it easier
to replace a plugin with a similar one than modify an existing one, and then
we will have the best of all worlds.
All this being said, I think your ideas are both quite interesting. I'm
especially interested in the groovy builder approach.
I'll be fairly unavailable until next week but might keep thinking about
this anyway.
thanks!
david jencks
On Oct 15, 2008, at 3:46 AM, Gianny Damour wrote:
On 15/10/2008, at 4:16 AM, David Jencks wrote:
That's one of the main missing bits of functionality. Right now the only
way to get the g-p.xml is to use c-m-p or to export the plugin from a server
it's been deployed into, or to do something by hand with jar packing and
unpacking.
The biggest problem here, in my mind, is that jsr88 only wants you to have
one plan: to deploy something you get to specify the artifact and one
plan. Our deployment system is built around jsr88 so we either have to
condense the g-p.xml and plan into one plan or abandon jsr88.
At the moment I'm thinking that one satisfactory solution might be to more
or less embed the plan into g-p.xml. Perhaps we could avoid duplicating
most of the dependency info by adding the import element to the
dependencies in g-p.xml. I guess we'd expect a more or less empty
environment element in the plan and fill in the dependencies from the
g-p.xml when deploying.
I guess another possibility might be to include the info from g-p.xml in
the environment element of the plan.
I've been thinking about this on and off for a long time and don't have
any solution I'm entirely happy with so discussion and more ideas are more
than welcome :-)
Hi,
Another possible
Re: An idea for defining custom valves in config.xml
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,
You are correct:
Re: An idea for defining custom valves in config.xml
Hi,
I am proposing the following implementation to start with:
1. In the META-INF folder of a config, we scan for files matching the
patterns dependencies-(.*).groovy and extentions-(.*).groovy.
2. We execute the scripts dependencies-(.*).groovy which modify
dependencies. For instance, such scripts may look like:
configurationData + dependency(groupId: 'group', artifactId:
'artifact', version: '1.1', type: 'jar', importType: importType) --
add the declared dependency
configurationData - dependency(groupId: 'group', artifactId:
'artifact', version: '1.0', type: 'jar') -- remove the declared
dependency
This gives us the final classloader of the config.
3. We execute the scripts extentions-(.*).groovy which update the
GBeans, For instance, such scripts may look like:
gBeanBuilder.configure {
addGBean(BasicNodeInfo) { -- add a GBean
attribute(name: 'node1')
attribute(extendedJMXConnectorInfo: new
BasicExtendedJMXConnectorInfo(...))
reference(referenceName) {
pattern('aPattern')
pattern('aSecondPattern')
}
}
removeGBeansMatching('aPattern')
}
gBeanBuilder.updatedConfigurationData
The implementation of such scripts should be as simple as the
modification of config.xml.
The fact that they are collocated with the configuration they modify
increases cohesion. It would be neat to have such scripts instead of
the native or XStream serializations of config.ser.
Let me know your thoughts?
Thanks,
Gianny
On 16/10/2008, at 11:17 PM, Jason Warner wrote:
While David is more interested in the philosophy, I'd prefer to
know a little bit more about your thoughts on implementation.
Specifically what do you imagine would be involved in defining this
configuration? Would it be as simple as a definition in config.xml?
On Thu, Oct 16, 2008 at 4:08 AM, Gianny Damour
[EMAIL PROTECTED] wrote:
Hi David,
You are correct: the underpinning philosophy of these approaches is
to make it easier to modify pre-canned plugins through extension
points.
This may be a good approach to improve further the packaging model
of dependencies and services. Let's say that an end-user wants to
add a connector to the tomcat6 plugin. Instead of using the admin
console or updating his config.xml, he can simply deploy a
cumulative plan. This notion of cumulative plan is the key
differentiator as users can share their cumulative plans as-is -
i.e. w/o knowing what the plugin to be modified looks like. To
some extent, providing a plan ready to be deployed instead of
deployment instructions is better for novices.
I will work on the Groovy builder approach and post back more
details as I go.
Thanks,
Gianny
On 16/10/2008, at 10:59 AM, David Jencks wrote:
Hi Gianny,
First, I'd like to make sure I understand the philosophy behind
your proposals. IIUC they both involve the idea of making it easy
to modify an existing plugin rather than making it easy to replace
an existing plugin with a similar one.
Why is this a good idea? My idea has been that we should make it
easier to replace a plugin with a similar one than modify an
existing one, and then we will have the best of all worlds.
All this being said, I think your ideas are both quite
interesting. I'm especially interested in the groovy builder
approach.
I'll be fairly unavailable until next week but might keep thinking
about this anyway.
thanks!
david jencks
On Oct 15, 2008, at 3:46 AM, Gianny Damour wrote:
On 15/10/2008, at 4:16 AM, David Jencks wrote:
That's one of the main missing bits of functionality. Right now
the only way to get the g-p.xml is to use c-m-p or to export the
plugin from a server it's been deployed into, or to do something by
hand with jar packing and unpacking.
The biggest problem here, in my mind, is that jsr88 only wants you
to have one plan: to deploy something you get to specify the
artifact and one plan. Our deployment system is built around
jsr88 so we either have to condense the g-p.xml and plan into one
plan or abandon jsr88.
At the moment I'm thinking that one satisfactory solution might be
to more or less embed the plan into g-p.xml. Perhaps we could
avoid duplicating most of the dependency info by adding the
import element to the dependencies in g-p.xml. I guess we'd
expect a more or less empty environment element in the plan and
fill in the dependencies from the g-p.xml when deploying.
I guess another possibility might be to include the info from g-
p.xml in the environment element of the plan.
I've been thinking about this on and off for a long time and don't
have any solution I'm entirely happy with so discussion and more
ideas are more than welcome :-)
Hi,
Another possible solution would be to allow the extension of a
given configuration by other configurations. This could work like
the web.xml fragment mechanism of the upcoming servlet specs
Re: An idea for defining custom valves in config.xml
Hi David, You are correct: the underpinning philosophy of these approaches is to make it easier to modify pre-canned plugins through extension points. This may be a good approach to improve further the packaging model of dependencies and services. Let's say that an end-user wants to add a connector to the tomcat6 plugin. Instead of using the admin console or updating his config.xml, he can simply deploy a cumulative plan. This notion of cumulative plan is the key differentiator as users can share their cumulative plans as-is - i.e. w/o knowing what the plugin to be modified looks like. To some extent, providing a plan ready to be deployed instead of deployment instructions is better for novices. I will work on the Groovy builder approach and post back more details as I go. Thanks, Gianny On 16/10/2008, at 10:59 AM, David Jencks wrote: Hi Gianny, First, I'd like to make sure I understand the philosophy behind your proposals. IIUC they both involve the idea of making it easy to modify an existing plugin rather than making it easy to replace an existing plugin with a similar one. Why is this a good idea? My idea has been that we should make it easier to replace a plugin with a similar one than modify an existing one, and then we will have the best of all worlds. All this being said, I think your ideas are both quite interesting. I'm especially interested in the groovy builder approach. I'll be fairly unavailable until next week but might keep thinking about this anyway. thanks! david jencks On Oct 15, 2008, at 3:46 AM, Gianny Damour wrote: On 15/10/2008, at 4:16 AM, David Jencks wrote: That's one of the main missing bits of functionality. Right now the only way to get the g-p.xml is to use c-m-p or to export the plugin from a server it's been deployed into, or to do something by hand with jar packing and unpacking. The biggest problem here, in my mind, is that jsr88 only wants you to have one plan: to deploy something you get to specify the artifact and one plan. Our deployment system is built around jsr88 so we either have to condense the g-p.xml and plan into one plan or abandon jsr88. At the moment I'm thinking that one satisfactory solution might be to more or less embed the plan into g-p.xml. Perhaps we could avoid duplicating most of the dependency info by adding the import element to the dependencies in g-p.xml. I guess we'd expect a more or less empty environment element in the plan and fill in the dependencies from the g-p.xml when deploying. I guess another possibility might be to include the info from g- p.xml in the environment element of the plan. I've been thinking about this on and off for a long time and don't have any solution I'm entirely happy with so discussion and more ideas are more than welcome :-) Hi, Another possible solution would be to allow the extension of a given configuration by other configurations. This could work like the web.xml fragment mechanism of the upcoming servlet specs which allows framework libraries to transparently install Web components to the baseline components defined by the web.xml DD. When a configuration starts it looks for complementing configurations whose responsibility is to alter the baseline configuration. The identification of complementing configurations could be based on a simple naming convention scheme, e.g. if the base configuration is org/tomcat6//car then all the configurations matching the pattern org/tomcat6-transform-DiscriminatorName//car are identified as complementing configurations. If there are complementing configurations, then the baseline ConfigurationData could be passed to them for arbitrary transformation, e.g. add, update or remove dependencies. An updated ConfigurationData is passed back and actually loaded by the kernel. The main drawback of this approach is the added configuration complexity. The main benefits is that it provides application server configuration traceability and a mean to perform very simple changes to a baseline configuration w/o having to redefine in its entirety the configuration to be slightly changed. In another thread about scripting language integration, I suggested an even simpler approach whereby a script is executed to perform ConfigurationData transformations. If any of these two options are plausible solutions, then I am happy to move forward with an implementation. Thanks, Gianny thanks david jencks
Re: An idea for defining custom valves in config.xml
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 import element to the dependencies in g-p.xml. I guess we'd expect a more or less empty environment element in the plan and fill in the dependencies from the g-p.xml when deploying. I guess another possibility might be to include the info from g-p.xml in the environment element of the plan. I've been thinking about this on and off for a long time and don't have any solution I'm entirely happy with so discussion and more ideas are more than welcome :-) Hi, Another possible solution would be to allow the extension of a given configuration by other configurations. This could work like the web.xml fragment mechanism of the upcoming servlet specs which allows framework libraries to transparently install Web components to the baseline components defined by the web.xml DD. When a configuration starts it looks for complementing configurations whose responsibility is to alter the baseline configuration. The identification of complementing configurations could be based on a simple naming convention scheme, e.g. if the base configuration is org/tomcat6//car then all the configurations matching the pattern org/tomcat6-transform-DiscriminatorName//car are identified as complementing configurations. If there are complementing configurations, then the baseline ConfigurationData could be passed to them for arbitrary transformation, e.g. add, update or remove dependencies. An updated ConfigurationData is passed back and actually loaded by the kernel. The main drawback of this approach is the added configuration complexity. The main benefits is that it provides application server configuration traceability and a mean to perform very simple changes to a baseline configuration w/o having to redefine in its entirety the configuration to be slightly changed. In another thread about scripting language integration, I suggested an even simpler approach whereby a script is executed to perform ConfigurationData transformations. If any of these two options are plausible solutions, then I am happy to move forward with an implementation. Thanks, Gianny thanks david jencks -- ~Jason Warner
Re: An idea for defining custom valves in config.xml
While David is more interested in the philosophy, I'd prefer to know a little bit more about your thoughts on implementation. Specifically what do you imagine would be involved in defining this configuration? Would it be as simple as a definition in config.xml? On Thu, Oct 16, 2008 at 4:08 AM, Gianny Damour [EMAIL PROTECTED] wrote: Hi David, You are correct: the underpinning philosophy of these approaches is to make it easier to modify pre-canned plugins through extension points. This may be a good approach to improve further the packaging model of dependencies and services. Let's say that an end-user wants to add a connector to the tomcat6 plugin. Instead of using the admin console or updating his config.xml, he can simply deploy a cumulative plan. This notion of cumulative plan is the key differentiator as users can share their cumulative plans as-is - i.e. w/o knowing what the plugin to be modified looks like. To some extent, providing a plan ready to be deployed instead of deployment instructions is better for novices. I will work on the Groovy builder approach and post back more details as I go. Thanks, Gianny On 16/10/2008, at 10:59 AM, David Jencks wrote: Hi Gianny, First, I'd like to make sure I understand the philosophy behind your proposals. IIUC they both involve the idea of making it easy to modify an existing plugin rather than making it easy to replace an existing plugin with a similar one. Why is this a good idea? My idea has been that we should make it easier to replace a plugin with a similar one than modify an existing one, and then we will have the best of all worlds. All this being said, I think your ideas are both quite interesting. I'm especially interested in the groovy builder approach. I'll be fairly unavailable until next week but might keep thinking about this anyway. thanks! david jencks On Oct 15, 2008, at 3:46 AM, Gianny Damour wrote: On 15/10/2008, at 4:16 AM, David Jencks wrote: That's one of the main missing bits of functionality. Right now the only way to get the g-p.xml is to use c-m-p or to export the plugin from a server it's been deployed into, or to do something by hand with jar packing and unpacking. The biggest problem here, in my mind, is that jsr88 only wants you to have one plan: to deploy something you get to specify the artifact and one plan. Our deployment system is built around jsr88 so we either have to condense the g-p.xml and plan into one plan or abandon jsr88. At the moment I'm thinking that one satisfactory solution might be to more or less embed the plan into g-p.xml. Perhaps we could avoid duplicating most of the dependency info by adding the import element to the dependencies in g-p.xml. I guess we'd expect a more or less empty environment element in the plan and fill in the dependencies from the g-p.xml when deploying. I guess another possibility might be to include the info from g-p.xml in the environment element of the plan. I've been thinking about this on and off for a long time and don't have any solution I'm entirely happy with so discussion and more ideas are more than welcome :-) Hi, Another possible solution would be to allow the extension of a given configuration by other configurations. This could work like the web.xml fragment mechanism of the upcoming servlet specs which allows framework libraries to transparently install Web components to the baseline components defined by the web.xml DD. When a configuration starts it looks for complementing configurations whose responsibility is to alter the baseline configuration. The identification of complementing configurations could be based on a simple naming convention scheme, e.g. if the base configuration is org/tomcat6//car then all the configurations matching the pattern org/tomcat6-transform-DiscriminatorName//car are identified as complementing configurations. If there are complementing configurations, then the baseline ConfigurationData could be passed to them for arbitrary transformation, e.g. add, update or remove dependencies. An updated ConfigurationData is passed back and actually loaded by the kernel. The main drawback of this approach is the added configuration complexity. The main benefits is that it provides application server configuration traceability and a mean to perform very simple changes to a baseline configuration w/o having to redefine in its entirety the configuration to be slightly changed. In another thread about scripting language integration, I suggested an even simpler approach whereby a script is executed to perform ConfigurationData transformations. If any of these two options are plausible solutions, then I am happy to move forward with an implementation. Thanks, Gianny thanks david jencks -- ~Jason Warner
Re: An idea for defining custom valves in config.xml
On 15/10/2008, at 4:16 AM, David Jencks wrote: That's one of the main missing bits of functionality. Right now the only way to get the g-p.xml is to use c-m-p or to export the plugin from a server it's been deployed into, or to do something by hand with jar packing and unpacking. The biggest problem here, in my mind, is that jsr88 only wants you to have one plan: to deploy something you get to specify the artifact and one plan. Our deployment system is built around jsr88 so we either have to condense the g-p.xml and plan into one plan or abandon jsr88. At the moment I'm thinking that one satisfactory solution might be to more or less embed the plan into g-p.xml. Perhaps we could avoid duplicating most of the dependency info by adding the import element to the dependencies in g-p.xml. I guess we'd expect a more or less empty environment element in the plan and fill in the dependencies from the g-p.xml when deploying. I guess another possibility might be to include the info from g- p.xml in the environment element of the plan. I've been thinking about this on and off for a long time and don't have any solution I'm entirely happy with so discussion and more ideas are more than welcome :-) Hi, Another possible solution would be to allow the extension of a given configuration by other configurations. This could work like the web.xml fragment mechanism of the upcoming servlet specs which allows framework libraries to transparently install Web components to the baseline components defined by the web.xml DD. When a configuration starts it looks for complementing configurations whose responsibility is to alter the baseline configuration. The identification of complementing configurations could be based on a simple naming convention scheme, e.g. if the base configuration is org/tomcat6//car then all the configurations matching the pattern org/ tomcat6-transform-DiscriminatorName//car are identified as complementing configurations. If there are complementing configurations, then the baseline ConfigurationData could be passed to them for arbitrary transformation, e.g. add, update or remove dependencies. An updated ConfigurationData is passed back and actually loaded by the kernel. The main drawback of this approach is the added configuration complexity. The main benefits is that it provides application server configuration traceability and a mean to perform very simple changes to a baseline configuration w/o having to redefine in its entirety the configuration to be slightly changed. In another thread about scripting language integration, I suggested an even simpler approach whereby a script is executed to perform ConfigurationData transformations. If any of these two options are plausible solutions, then I am happy to move forward with an implementation. Thanks, Gianny thanks david jencks
Re: An idea for defining custom valves in config.xml
Hi Gianny, First, I'd like to make sure I understand the philosophy behind your proposals. IIUC they both involve the idea of making it easy to modify an existing plugin rather than making it easy to replace an existing plugin with a similar one. Why is this a good idea? My idea has been that we should make it easier to replace a plugin with a similar one than modify an existing one, and then we will have the best of all worlds. All this being said, I think your ideas are both quite interesting. I'm especially interested in the groovy builder approach. I'll be fairly unavailable until next week but might keep thinking about this anyway. thanks! david jencks On Oct 15, 2008, at 3:46 AM, Gianny Damour wrote: On 15/10/2008, at 4:16 AM, David Jencks wrote: That's one of the main missing bits of functionality. Right now the only way to get the g-p.xml is to use c-m-p or to export the plugin from a server it's been deployed into, or to do something by hand with jar packing and unpacking. The biggest problem here, in my mind, is that jsr88 only wants you to have one plan: to deploy something you get to specify the artifact and one plan. Our deployment system is built around jsr88 so we either have to condense the g-p.xml and plan into one plan or abandon jsr88. At the moment I'm thinking that one satisfactory solution might be to more or less embed the plan into g-p.xml. Perhaps we could avoid duplicating most of the dependency info by adding the import element to the dependencies in g-p.xml. I guess we'd expect a more or less empty environment element in the plan and fill in the dependencies from the g-p.xml when deploying. I guess another possibility might be to include the info from g- p.xml in the environment element of the plan. I've been thinking about this on and off for a long time and don't have any solution I'm entirely happy with so discussion and more ideas are more than welcome :-) Hi, Another possible solution would be to allow the extension of a given configuration by other configurations. This could work like the web.xml fragment mechanism of the upcoming servlet specs which allows framework libraries to transparently install Web components to the baseline components defined by the web.xml DD. When a configuration starts it looks for complementing configurations whose responsibility is to alter the baseline configuration. The identification of complementing configurations could be based on a simple naming convention scheme, e.g. if the base configuration is org/tomcat6//car then all the configurations matching the pattern org/tomcat6-transform-DiscriminatorName//car are identified as complementing configurations. If there are complementing configurations, then the baseline ConfigurationData could be passed to them for arbitrary transformation, e.g. add, update or remove dependencies. An updated ConfigurationData is passed back and actually loaded by the kernel. The main drawback of this approach is the added configuration complexity. The main benefits is that it provides application server configuration traceability and a mean to perform very simple changes to a baseline configuration w/o having to redefine in its entirety the configuration to be slightly changed. In another thread about scripting language integration, I suggested an even simpler approach whereby a script is executed to perform ConfigurationData transformations. If any of these two options are plausible solutions, then I am happy to move forward with an implementation. Thanks, Gianny thanks david jencks
Re: An idea for defining custom valves in config.xml
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]mailto: [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
Re: An idea for defining custom valves in config.xml
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]mailto: [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
Re: An idea for defining custom valves in config.xml
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 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
Re: An idea for defining custom valves in config.xml
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 rather
Re: An idea for defining custom valves in config.xml
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 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
Re: An idea for defining custom valves in config.xml
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 deploy things that depend on tomcat6 as that will result in the tomcat6 plugin starting and having port conflicts with your
Re: An idea for defining custom valves in config.xml
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] mailto:[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] mailto:[EMAIL PROTECTED] wrote: On
Re: An idea for defining custom valves in config.xml
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
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
Jason Warner wrote: On Fri, Oct 3, 2008 at 6:55 PM, David Jencks [EMAIL PROTECTED] mailto:[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
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
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. Should I leave it as a change aimed solely at tomcat valves or should it be expanded to encompass any configuration? I
Re: An idea for defining custom valves in config.xml
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
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 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?
Re: An idea for defining custom valves in config.xml
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
