You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jason Warner <ja...@gmail.com> on 2008/10/03 21:51:30 UTC
An idea for defining custom valves in config.xml
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. 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
Posted by Donald Woods <dw...@apache.org>.
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
Posted by Jason Warner <ja...@gmail.com>.
On Wed, Oct 15, 2008 at 7:59 PM, David Jencks <da...@yahoo.com>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
Posted by Gianny Damour <gi...@optusnet.com.au>.
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
> <gi...@optusnet.com.au> 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
> <gi...@optusnet.com.au> 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
> <gi...@optusnet.com.au> wrote:
> Hi David,
>
> You are correct: the underpinning philosophy of these approaches is
> to make it easier to modify pre-canned plugins through extension
> points.
>
> This may be a good approach to improve further the packaging model
> of dependencies and services. Let's say that an end-user wants to
> add a connector to the tomcat6 plugin. Instead of using the admin
> console or updating his config.xml, he can simply deploy a
> cumulative plan. This notion of cumulative plan is the key
> differentiator as users can share their cumulative plans "as-is" -
> i.e. w/o knowing what the plugin to be modified looks like. To
> some extent, providing a plan ready to be deployed instead of
> deployment instructions is better for novices.
>
> I will work on the Groovy builder approach and post back more
> details as I go.
>
> Thanks,
> Gianny
>
>
> On 16/10/2008, at 10:59 AM, David Jencks wrote:
>
> Hi Gianny,
>
> First, I'd like to make sure I understand the philosophy behind
> your proposals. IIUC they both involve the idea of making it easy
> to modify an existing plugin rather than making it easy to replace
> an existing plugin with a similar one.
>
> Why is this a good idea? My idea has been that we should make it
> easier to replace a plugin with a similar one than modify an
> existing one, and then we will have the best of all worlds.
>
> All this being said, I think your ideas are both quite
> interesting. I'm especially interested in the groovy builder
> approach.
>
> I'll be fairly unavailable until next week but might keep thinking
> about this anyway.
>
> thanks!
> david jencks
> On Oct 15, 2008, at 3:46 AM, Gianny Damour wrote:
>
> On 15/10/2008, at 4:16 AM, David Jencks wrote:
>
> That's one of the main missing bits of functionality. Right now
> the only way to get the g-p.xml is to use c-m-p or to export the
> plugin from a server it's been deployed into, or to do something by
> hand with jar packing and unpacking.
>
> The biggest problem here, in my mind, is that jsr88 only wants you
> to have one "plan": to deploy something you get to specify the
> artifact and one "plan". Our deployment system is built around
> jsr88 so we either have to condense the g-p.xml and plan into one
> "plan" or abandon jsr88.
>
> At the moment I'm thinking that one satisfactory solution might be
> to more or less embed the plan into g-p.xml. Perhaps we could
> avoid duplicating most of the dependency info by adding the
> <import> element to the dependencies in g-p.xml. I guess we'd
> expect a more or less empty <environment> element in the plan and
> fill in the dependencies from the g-p.xml when deploying.
>
> I guess another possibility might be to include the info from g-
> p.xml in the environment element of the plan.
>
> I've been thinking about this on and off for a long time and don't
> have any solution I'm entirely happy with so discussion and more
> ideas are more than welcome :-)
>
> Hi,
>
> Another possible solution would be to allow the extension of a
> given configuration by other configurations. This could work like
> the web.xml fragment mechanism of the upcoming servlet specs which
> allows framework libraries to transparently install Web components
> to the baseline components defined by the web.xml DD.
>
> When a configuration starts it looks for complementing
> configurations whose responsibility is to alter the baseline
> configuration. The identification of complementing configurations
> could be based on a simple naming convention scheme, e.g. if the
> base configuration is org/tomcat6//car then all the configurations
> matching the pattern org/tomcat6-transform-DiscriminatorName//car
> are identified as complementing configurations.
>
> If there are complementing configurations, then the baseline
> ConfigurationData could be passed to them for arbitrary
> transformation, e.g. add, update or remove dependencies. An updated
> ConfigurationData is passed back and actually loaded by the kernel.
>
> The main drawback of this approach is the added configuration
> complexity. The main benefits is that it provides application
> server configuration traceability and a mean to perform very simple
> changes to a baseline configuration w/o having to redefine in its
> entirety the configuration to be slightly changed.
>
> In another thread about scripting language integration, I suggested
> an even simpler approach whereby a script is executed to perform
> ConfigurationData transformations.
>
> If any of these two options are plausible solutions, then I am
> happy to move forward with an implementation.
>
> Thanks,
> Gianny
>
>
> thanks
> david jencks
>
>
>
>
>
>
> --
> ~Jason Warner
>
>
>
>
> --
> ~Jason Warner
>
>
>
>
> --
> ~Jason Warner
Re: An idea for defining custom valves in config.xml
Posted by Jason Warner <ja...@gmail.com>.
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 <
gianny.damour@optusnet.com.au> 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 <
>> gianny.damour@optusnet.com.au> 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 <
>> gianny.damour@optusnet.com.au> wrote:
>> Hi David,
>>
>> You are correct: the underpinning philosophy of these approaches is to
>> make it easier to modify pre-canned plugins through extension points.
>>
>> This may be a good approach to improve further the packaging model of
>> dependencies and services. Let's say that an end-user wants to add a
>> connector to the tomcat6 plugin. Instead of using the admin console or
>> updating his config.xml, he can simply deploy a cumulative plan. This notion
>> of cumulative plan is the key differentiator as users can share their
>> cumulative plans "as-is" - i.e. w/o knowing what the plugin to be modified
>> looks like. To some extent, providing a plan ready to be deployed instead
>> of deployment instructions is better for novices.
>>
>> I will work on the Groovy builder approach and post back more details as I
>> go.
>>
>> Thanks,
>> Gianny
>>
>>
>> On 16/10/2008, at 10:59 AM, David Jencks wrote:
>>
>> Hi Gianny,
>>
>> First, I'd like to make sure I understand the philosophy behind your
>> proposals. IIUC they both involve the idea of making it easy to modify an
>> existing plugin rather than making it easy to replace an existing plugin
>> with a similar one.
>>
>> Why is this a good idea? My idea has been that we should make it easier
>> to replace a plugin with a similar one than modify an existing one, and then
>> we will have the best of all worlds.
>>
>> All this being said, I think your ideas are both quite interesting. I'm
>> especially interested in the groovy builder approach.
>>
>> I'll be fairly unavailable until next week but might keep thinking about
>> this anyway.
>>
>> thanks!
>> david jencks
>> On Oct 15, 2008, at 3:46 AM, Gianny Damour wrote:
>>
>> On 15/10/2008, at 4:16 AM, David Jencks wrote:
>>
>> That's one of the main missing bits of functionality. Right now the only
>> way to get the g-p.xml is to use c-m-p or to export the plugin from a server
>> it's been deployed into, or to do something by hand with jar packing and
>> unpacking.
>>
>> The biggest problem here, in my mind, is that jsr88 only wants you to have
>> one "plan": to deploy something you get to specify the artifact and one
>> "plan". Our deployment system is built around jsr88 so we either have to
>> condense the g-p.xml and plan into one "plan" or abandon jsr88.
>>
>> At the moment I'm thinking that one satisfactory solution might be to more
>> or less embed the plan into g-p.xml. Perhaps we could avoid duplicating
>> most of the dependency info by adding the <import> element to the
>> dependencies in g-p.xml. I guess we'd expect a more or less empty
>> <environment> element in the plan and fill in the dependencies from the
>> g-p.xml when deploying.
>>
>> I guess another possibility might be to include the info from g-p.xml in
>> the environment element of the plan.
>>
>> I've been thinking about this on and off for a long time and don't have
>> any solution I'm entirely happy with so discussion and more ideas are more
>> than welcome :-)
>>
>> Hi,
>>
>> Another possible solution would be to allow the extension of a given
>> configuration by other configurations. This could work like the web.xml
>> fragment mechanism of the upcoming servlet specs which allows framework
>> libraries to transparently install Web components to the baseline components
>> defined by the web.xml DD.
>>
>> When a configuration starts it looks for complementing configurations
>> whose responsibility is to alter the baseline configuration. The
>> identification of complementing configurations could be based on a simple
>> naming convention scheme, e.g. if the base configuration is org/tomcat6//car
>> then all the configurations matching the pattern
>> org/tomcat6-transform-DiscriminatorName//car are identified as complementing
>> configurations.
>>
>> If there are complementing configurations, then the baseline
>> ConfigurationData could be passed to them for arbitrary transformation, e.g.
>> add, update or remove dependencies. An updated ConfigurationData is passed
>> back and actually loaded by the kernel.
>>
>> The main drawback of this approach is the added configuration complexity.
>> The main benefits is that it provides application server configuration
>> traceability and a mean to perform very simple changes to a baseline
>> configuration w/o having to redefine in its entirety the configuration to be
>> slightly changed.
>>
>> In another thread about scripting language integration, I suggested an
>> even simpler approach whereby a script is executed to perform
>> ConfigurationData transformations.
>>
>> If any of these two options are plausible solutions, then I am happy to
>> move forward with an implementation.
>>
>> Thanks,
>> Gianny
>>
>>
>> thanks
>> david jencks
>>
>>
>>
>>
>>
>>
>> --
>> ~Jason Warner
>>
>>
>>
>>
>> --
>> ~Jason Warner
>>
>
>
--
~Jason Warner
Re: An idea for defining custom valves in config.xml
Posted by Gianny Damour <gi...@optusnet.com.au>.
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
> <gi...@optusnet.com.au> 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
> <gi...@optusnet.com.au> wrote:
> Hi David,
>
> You are correct: the underpinning philosophy of these approaches is
> to make it easier to modify pre-canned plugins through extension
> points.
>
> This may be a good approach to improve further the packaging model
> of dependencies and services. Let's say that an end-user wants to
> add a connector to the tomcat6 plugin. Instead of using the admin
> console or updating his config.xml, he can simply deploy a
> cumulative plan. This notion of cumulative plan is the key
> differentiator as users can share their cumulative plans "as-is" -
> i.e. w/o knowing what the plugin to be modified looks like. To
> some extent, providing a plan ready to be deployed instead of
> deployment instructions is better for novices.
>
> I will work on the Groovy builder approach and post back more
> details as I go.
>
> Thanks,
> Gianny
>
>
> On 16/10/2008, at 10:59 AM, David Jencks wrote:
>
> Hi Gianny,
>
> First, I'd like to make sure I understand the philosophy behind
> your proposals. IIUC they both involve the idea of making it easy
> to modify an existing plugin rather than making it easy to replace
> an existing plugin with a similar one.
>
> Why is this a good idea? My idea has been that we should make it
> easier to replace a plugin with a similar one than modify an
> existing one, and then we will have the best of all worlds.
>
> All this being said, I think your ideas are both quite
> interesting. I'm especially interested in the groovy builder
> approach.
>
> I'll be fairly unavailable until next week but might keep thinking
> about this anyway.
>
> thanks!
> david jencks
> On Oct 15, 2008, at 3:46 AM, Gianny Damour wrote:
>
> On 15/10/2008, at 4:16 AM, David Jencks wrote:
>
> That's one of the main missing bits of functionality. Right now
> the only way to get the g-p.xml is to use c-m-p or to export the
> plugin from a server it's been deployed into, or to do something by
> hand with jar packing and unpacking.
>
> The biggest problem here, in my mind, is that jsr88 only wants you
> to have one "plan": to deploy something you get to specify the
> artifact and one "plan". Our deployment system is built around
> jsr88 so we either have to condense the g-p.xml and plan into one
> "plan" or abandon jsr88.
>
> At the moment I'm thinking that one satisfactory solution might be
> to more or less embed the plan into g-p.xml. Perhaps we could
> avoid duplicating most of the dependency info by adding the
> <import> element to the dependencies in g-p.xml. I guess we'd
> expect a more or less empty <environment> element in the plan and
> fill in the dependencies from the g-p.xml when deploying.
>
> I guess another possibility might be to include the info from g-
> p.xml in the environment element of the plan.
>
> I've been thinking about this on and off for a long time and don't
> have any solution I'm entirely happy with so discussion and more
> ideas are more than welcome :-)
>
> Hi,
>
> Another possible solution would be to allow the extension of a
> given configuration by other configurations. This could work like
> the web.xml fragment mechanism of the upcoming servlet specs which
> allows framework libraries to transparently install Web components
> to the baseline components defined by the web.xml DD.
>
> When a configuration starts it looks for complementing
> configurations whose responsibility is to alter the baseline
> configuration. The identification of complementing configurations
> could be based on a simple naming convention scheme, e.g. if the
> base configuration is org/tomcat6//car then all the configurations
> matching the pattern org/tomcat6-transform-DiscriminatorName//car
> are identified as complementing configurations.
>
> If there are complementing configurations, then the baseline
> ConfigurationData could be passed to them for arbitrary
> transformation, e.g. add, update or remove dependencies. An updated
> ConfigurationData is passed back and actually loaded by the kernel.
>
> The main drawback of this approach is the added configuration
> complexity. The main benefits is that it provides application
> server configuration traceability and a mean to perform very simple
> changes to a baseline configuration w/o having to redefine in its
> entirety the configuration to be slightly changed.
>
> In another thread about scripting language integration, I suggested
> an even simpler approach whereby a script is executed to perform
> ConfigurationData transformations.
>
> If any of these two options are plausible solutions, then I am
> happy to move forward with an implementation.
>
> Thanks,
> Gianny
>
>
> thanks
> david jencks
>
>
>
>
>
>
> --
> ~Jason Warner
>
>
>
>
> --
> ~Jason Warner
Re: An idea for defining custom valves in config.xml
Posted by Jason Warner <ja...@gmail.com>.
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 <
gianny.damour@optusnet.com.au> 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 <
>> gianny.damour@optusnet.com.au> wrote:
>> Hi David,
>>
>> You are correct: the underpinning philosophy of these approaches is to
>> make it easier to modify pre-canned plugins through extension points.
>>
>> This may be a good approach to improve further the packaging model of
>> dependencies and services. Let's say that an end-user wants to add a
>> connector to the tomcat6 plugin. Instead of using the admin console or
>> updating his config.xml, he can simply deploy a cumulative plan. This notion
>> of cumulative plan is the key differentiator as users can share their
>> cumulative plans "as-is" - i.e. w/o knowing what the plugin to be modified
>> looks like. To some extent, providing a plan ready to be deployed instead
>> of deployment instructions is better for novices.
>>
>> I will work on the Groovy builder approach and post back more details as I
>> go.
>>
>> Thanks,
>> Gianny
>>
>>
>> On 16/10/2008, at 10:59 AM, David Jencks wrote:
>>
>> Hi Gianny,
>>
>> First, I'd like to make sure I understand the philosophy behind your
>> proposals. IIUC they both involve the idea of making it easy to modify an
>> existing plugin rather than making it easy to replace an existing plugin
>> with a similar one.
>>
>> Why is this a good idea? My idea has been that we should make it easier
>> to replace a plugin with a similar one than modify an existing one, and then
>> we will have the best of all worlds.
>>
>> All this being said, I think your ideas are both quite interesting. I'm
>> especially interested in the groovy builder approach.
>>
>> I'll be fairly unavailable until next week but might keep thinking about
>> this anyway.
>>
>> thanks!
>> david jencks
>> On Oct 15, 2008, at 3:46 AM, Gianny Damour wrote:
>>
>> On 15/10/2008, at 4:16 AM, David Jencks wrote:
>>
>> That's one of the main missing bits of functionality. Right now the only
>> way to get the g-p.xml is to use c-m-p or to export the plugin from a server
>> it's been deployed into, or to do something by hand with jar packing and
>> unpacking.
>>
>> The biggest problem here, in my mind, is that jsr88 only wants you to have
>> one "plan": to deploy something you get to specify the artifact and one
>> "plan". Our deployment system is built around jsr88 so we either have to
>> condense the g-p.xml and plan into one "plan" or abandon jsr88.
>>
>> At the moment I'm thinking that one satisfactory solution might be to more
>> or less embed the plan into g-p.xml. Perhaps we could avoid duplicating
>> most of the dependency info by adding the <import> element to the
>> dependencies in g-p.xml. I guess we'd expect a more or less empty
>> <environment> element in the plan and fill in the dependencies from the
>> g-p.xml when deploying.
>>
>> I guess another possibility might be to include the info from g-p.xml in
>> the environment element of the plan.
>>
>> I've been thinking about this on and off for a long time and don't have
>> any solution I'm entirely happy with so discussion and more ideas are more
>> than welcome :-)
>>
>> Hi,
>>
>> Another possible solution would be to allow the extension of a given
>> configuration by other configurations. This could work like the web.xml
>> fragment mechanism of the upcoming servlet specs which allows framework
>> libraries to transparently install Web components to the baseline components
>> defined by the web.xml DD.
>>
>> When a configuration starts it looks for complementing configurations
>> whose responsibility is to alter the baseline configuration. The
>> identification of complementing configurations could be based on a simple
>> naming convention scheme, e.g. if the base configuration is org/tomcat6//car
>> then all the configurations matching the pattern
>> org/tomcat6-transform-DiscriminatorName//car are identified as complementing
>> configurations.
>>
>> If there are complementing configurations, then the baseline
>> ConfigurationData could be passed to them for arbitrary transformation, e.g.
>> add, update or remove dependencies. An updated ConfigurationData is passed
>> back and actually loaded by the kernel.
>>
>> The main drawback of this approach is the added configuration complexity.
>> The main benefits is that it provides application server configuration
>> traceability and a mean to perform very simple changes to a baseline
>> configuration w/o having to redefine in its entirety the configuration to be
>> slightly changed.
>>
>> In another thread about scripting language integration, I suggested an
>> even simpler approach whereby a script is executed to perform
>> ConfigurationData transformations.
>>
>> If any of these two options are plausible solutions, then I am happy to
>> move forward with an implementation.
>>
>> Thanks,
>> Gianny
>>
>>
>> thanks
>> david jencks
>>
>>
>>
>>
>>
>>
>> --
>> ~Jason Warner
>>
>
>
--
~Jason Warner
Re: An idea for defining custom valves in config.xml
Posted by Gianny Damour <gi...@optusnet.com.au>.
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
> <gi...@optusnet.com.au> wrote:
> Hi David,
>
> You are correct: the underpinning philosophy of these approaches is
> to make it easier to modify pre-canned plugins through extension
> points.
>
> This may be a good approach to improve further the packaging model
> of dependencies and services. Let's say that an end-user wants to
> add a connector to the tomcat6 plugin. Instead of using the admin
> console or updating his config.xml, he can simply deploy a
> cumulative plan. This notion of cumulative plan is the key
> differentiator as users can share their cumulative plans "as-is" -
> i.e. w/o knowing what the plugin to be modified looks like. To
> some extent, providing a plan ready to be deployed instead of
> deployment instructions is better for novices.
>
> I will work on the Groovy builder approach and post back more
> details as I go.
>
> Thanks,
> Gianny
>
>
> On 16/10/2008, at 10:59 AM, David Jencks wrote:
>
> Hi Gianny,
>
> First, I'd like to make sure I understand the philosophy behind
> your proposals. IIUC they both involve the idea of making it easy
> to modify an existing plugin rather than making it easy to replace
> an existing plugin with a similar one.
>
> Why is this a good idea? My idea has been that we should make it
> easier to replace a plugin with a similar one than modify an
> existing one, and then we will have the best of all worlds.
>
> All this being said, I think your ideas are both quite
> interesting. I'm especially interested in the groovy builder
> approach.
>
> I'll be fairly unavailable until next week but might keep thinking
> about this anyway.
>
> thanks!
> david jencks
> On Oct 15, 2008, at 3:46 AM, Gianny Damour wrote:
>
> On 15/10/2008, at 4:16 AM, David Jencks wrote:
>
> That's one of the main missing bits of functionality. Right now
> the only way to get the g-p.xml is to use c-m-p or to export the
> plugin from a server it's been deployed into, or to do something by
> hand with jar packing and unpacking.
>
> The biggest problem here, in my mind, is that jsr88 only wants you
> to have one "plan": to deploy something you get to specify the
> artifact and one "plan". Our deployment system is built around
> jsr88 so we either have to condense the g-p.xml and plan into one
> "plan" or abandon jsr88.
>
> At the moment I'm thinking that one satisfactory solution might be
> to more or less embed the plan into g-p.xml. Perhaps we could
> avoid duplicating most of the dependency info by adding the
> <import> element to the dependencies in g-p.xml. I guess we'd
> expect a more or less empty <environment> element in the plan and
> fill in the dependencies from the g-p.xml when deploying.
>
> I guess another possibility might be to include the info from g-
> p.xml in the environment element of the plan.
>
> I've been thinking about this on and off for a long time and don't
> have any solution I'm entirely happy with so discussion and more
> ideas are more than welcome :-)
>
> Hi,
>
> Another possible solution would be to allow the extension of a
> given configuration by other configurations. This could work like
> the web.xml fragment mechanism of the upcoming servlet specs which
> allows framework libraries to transparently install Web components
> to the baseline components defined by the web.xml DD.
>
> When a configuration starts it looks for complementing
> configurations whose responsibility is to alter the baseline
> configuration. The identification of complementing configurations
> could be based on a simple naming convention scheme, e.g. if the
> base configuration is org/tomcat6//car then all the configurations
> matching the pattern org/tomcat6-transform-DiscriminatorName//car
> are identified as complementing configurations.
>
> If there are complementing configurations, then the baseline
> ConfigurationData could be passed to them for arbitrary
> transformation, e.g. add, update or remove dependencies. An updated
> ConfigurationData is passed back and actually loaded by the kernel.
>
> The main drawback of this approach is the added configuration
> complexity. The main benefits is that it provides application
> server configuration traceability and a mean to perform very simple
> changes to a baseline configuration w/o having to redefine in its
> entirety the configuration to be slightly changed.
>
> In another thread about scripting language integration, I suggested
> an even simpler approach whereby a script is executed to perform
> ConfigurationData transformations.
>
> If any of these two options are plausible solutions, then I am
> happy to move forward with an implementation.
>
> Thanks,
> Gianny
>
>
> thanks
> david jencks
>
>
>
>
>
>
> --
> ~Jason Warner
Re: An idea for defining custom valves in config.xml
Posted by Jason Warner <ja...@gmail.com>.
While David is more interested in the philosophy, I'd prefer to know a
little bit more about your thoughts on implementation. Specifically what do
you imagine would be involved in defining this configuration? Would it be
as simple as a definition in config.xml?
On Thu, Oct 16, 2008 at 4:08 AM, Gianny Damour <
gianny.damour@optusnet.com.au> wrote:
> Hi David,
>
> You are correct: the underpinning philosophy of these approaches is to make
> it easier to modify pre-canned plugins through extension points.
>
> This may be a good approach to improve further the packaging model of
> dependencies and services. Let's say that an end-user wants to add a
> connector to the tomcat6 plugin. Instead of using the admin console or
> updating his config.xml, he can simply deploy a cumulative plan. This notion
> of cumulative plan is the key differentiator as users can share their
> cumulative plans "as-is" - i.e. w/o knowing what the plugin to be modified
> looks like. To some extent, providing a plan ready to be deployed instead
> of deployment instructions is better for novices.
>
> I will work on the Groovy builder approach and post back more details as I
> go.
>
> Thanks,
> Gianny
>
>
> On 16/10/2008, at 10:59 AM, David Jencks wrote:
>
> Hi Gianny,
>>
>> First, I'd like to make sure I understand the philosophy behind your
>> proposals. IIUC they both involve the idea of making it easy to modify an
>> existing plugin rather than making it easy to replace an existing plugin
>> with a similar one.
>>
>> Why is this a good idea? My idea has been that we should make it easier
>> to replace a plugin with a similar one than modify an existing one, and then
>> we will have the best of all worlds.
>>
>> All this being said, I think your ideas are both quite interesting. I'm
>> especially interested in the groovy builder approach.
>>
>> I'll be fairly unavailable until next week but might keep thinking about
>> this anyway.
>>
>> thanks!
>> david jencks
>> On Oct 15, 2008, at 3:46 AM, Gianny Damour wrote:
>>
>> On 15/10/2008, at 4:16 AM, David Jencks wrote:
>>>
>>> That's one of the main missing bits of functionality. Right now the
>>>> only way to get the g-p.xml is to use c-m-p or to export the plugin from a
>>>> server it's been deployed into, or to do something by hand with jar packing
>>>> and unpacking.
>>>>
>>>> The biggest problem here, in my mind, is that jsr88 only wants you to
>>>> have one "plan": to deploy something you get to specify the artifact and one
>>>> "plan". Our deployment system is built around jsr88 so we either have to
>>>> condense the g-p.xml and plan into one "plan" or abandon jsr88.
>>>>
>>>> At the moment I'm thinking that one satisfactory solution might be to
>>>> more or less embed the plan into g-p.xml. Perhaps we could avoid
>>>> duplicating most of the dependency info by adding the <import> element to
>>>> the dependencies in g-p.xml. I guess we'd expect a more or less empty
>>>> <environment> element in the plan and fill in the dependencies from the
>>>> g-p.xml when deploying.
>>>>
>>>> I guess another possibility might be to include the info from g-p.xml in
>>>> the environment element of the plan.
>>>>
>>>> I've been thinking about this on and off for a long time and don't have
>>>> any solution I'm entirely happy with so discussion and more ideas are more
>>>> than welcome :-)
>>>>
>>>
>>> Hi,
>>>
>>> Another possible solution would be to allow the extension of a given
>>> configuration by other configurations. This could work like the web.xml
>>> fragment mechanism of the upcoming servlet specs which allows framework
>>> libraries to transparently install Web components to the baseline components
>>> defined by the web.xml DD.
>>>
>>> When a configuration starts it looks for complementing configurations
>>> whose responsibility is to alter the baseline configuration. The
>>> identification of complementing configurations could be based on a simple
>>> naming convention scheme, e.g. if the base configuration is org/tomcat6//car
>>> then all the configurations matching the pattern
>>> org/tomcat6-transform-DiscriminatorName//car are identified as complementing
>>> configurations.
>>>
>>> If there are complementing configurations, then the baseline
>>> ConfigurationData could be passed to them for arbitrary transformation, e.g.
>>> add, update or remove dependencies. An updated ConfigurationData is passed
>>> back and actually loaded by the kernel.
>>>
>>> The main drawback of this approach is the added configuration complexity.
>>> The main benefits is that it provides application server configuration
>>> traceability and a mean to perform very simple changes to a baseline
>>> configuration w/o having to redefine in its entirety the configuration to be
>>> slightly changed.
>>>
>>> In another thread about scripting language integration, I suggested an
>>> even simpler approach whereby a script is executed to perform
>>> ConfigurationData transformations.
>>>
>>> If any of these two options are plausible solutions, then I am happy to
>>> move forward with an implementation.
>>>
>>> Thanks,
>>> Gianny
>>>
>>>
>>>> thanks
>>>> david jencks
>>>>
>>>>
>>
>
--
~Jason Warner
Re: An idea for defining custom valves in config.xml
Posted by Gianny Damour <gi...@optusnet.com.au>.
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
Posted by David Jencks <da...@yahoo.com>.
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
Posted by Gianny Damour <gi...@optusnet.com.au>.
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
Posted by David Jencks <da...@yahoo.com>.
Jason,
I think you've picked up that I'm mixing talking about what we can
easliy do now and what I wish we could do now more easily :-)
On Oct 14, 2008, at 8:11 AM, Jason Warner wrote:
> 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
> <da...@yahoo.com> 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.
This would be the geronimo-plugin.xml for the new plugin you are
constructing. IIRC there are at least two missing bits of
functionality:
- there's no editor for artifact-aliases and obsoletes in geronimo-
plugin.xml
- there's no way except the c-m-p to deploy a plan and include a
geronimo-plugin.xml in the resulting car file.
- even if we did have a way to include the geronimo-plugin.xml we
currently don't do the extra installation steps of unpacking files and
modifying the configuration files (config.xml, config-
substitutions.properties, artifact-aliases.properties)
>
>
> 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.
It should replace it. It should have an artifact-alias so anything
referring to the old plugin gets the new one instead and it should
have an obsoletes element to uninstall the old tomcat plugin.
>
>
>
> 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.
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 :-)
thanks
david jencks
>
>
> thanks
> david jencks
>
>
>
>
>
>
> Joe
>
> On Wed, Oct 8, 2008 at 2:25 PM, David Jencks <david_jencks@yahoo.com
> <ma...@yahoo.com>> 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
> <david_jencks@yahoo.com <ma...@yahoo.com>> 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
> <jaw981@gmail.com <ma...@gmail.com>> wrote:
>
>
>
> On Mon, Oct 6, 2008 at 1:59 PM, David Jencks
> <david_jencks@yahoo.com <ma...@yahoo.com>>
> wrote:
>
>
> On Oct 6, 2008, at 10:35 AM, Jason Warner wrote:
>
>
>
> On Mon, Oct 6, 2008 at 11:56 AM, David Jencks
> <david_jencks@yahoo.com
> <ma...@yahoo.com>> wrote:
>
>
> On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:
>
>
>
> On Fri, Oct 3, 2008 at 6:55 PM, David Jencks
> <david_jencks@yahoo.com
> <ma...@yahoo.com>> 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? 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?
>
>
>
> If anyone knows how osgi deals with situations like
> this I'd find it really helpful in considering
> alternative directions.
> thanks
> david jencks
>
>
> 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.< br>
> Thanks!
>
> [1] https://issues.apache.org/jira/browse/GERONIMO-4335
>
> -- ~Jason Warner
>
>
>
>
> -- ~Jason Warner
>
>
>
>
> -- ~Jason Warner
>
>
>
>
> -- ~Jason Warner
>
>
>
>
> -- ~Jason Warner
>
>
>
>
> -- ~Jason Warner
> --
> ~Jason Warner
>
>
>
>
>
> --
> ~Jason Warner
Re: An idea for defining custom valves in config.xml
Posted by Jason Warner <ja...@gmail.com>.
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 <da...@yahoo.com> 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 <david_jencks@yahoo.com<mailto:
>>> david_jencks@yahoo.com>> 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
>>>> <david_jencks@yahoo.com <ma...@yahoo.com>> 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
>>>>> <jaw981@gmail.com <ma...@gmail.com>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Oct 6, 2008 at 1:59 PM, David Jencks
>>>>> <david_jencks@yahoo.com <ma...@yahoo.com>>
>>>>> wrote:
>>>>>
>>>>>
>>>>> On Oct 6, 2008, at 10:35 AM, Jason Warner wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> On Mon, Oct 6, 2008 at 11:56 AM, David Jencks
>>>>>> <david_jencks@yahoo.com
>>>>>> <ma...@yahoo.com>> wrote:
>>>>>>
>>>>>>
>>>>>> On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Fri, Oct 3, 2008 at 6:55 PM, David Jencks
>>>>>>> <david_jencks@yahoo.com
>>>>>>> <ma...@yahoo.com>> 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?
>>>>>> 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?
>>>>>>
>>>>>>
>>>>>>
>>>>> If anyone knows how osgi deals with situations like
>>>>> this I'd find it really helpful in considering
>>>>> alternative directions.
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>>
>>>>> 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.< br>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://issues.apache.org/jira/browse/GERONIMO-4335
>>>>>>>>
>>>>>>>> -- ~Jason Warner
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -- ~Jason Warner
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- ~Jason Warner
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- ~Jason Warner
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- ~Jason Warner
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -- ~Jason Warner
>>>>
>>> --
>>> ~Jason Warner
>>>
>>
>>
>
--
~Jason Warner
Re: An idea for defining custom valves in config.xml
Posted by Jason Warner <ja...@gmail.com>.
On Wed, Oct 8, 2008 at 6:55 PM, David Jencks <da...@yahoo.com> 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 <david_jencks@yahoo.com<mailto:
>>> david_jencks@yahoo.com>> 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
>>>> <david_jencks@yahoo.com <ma...@yahoo.com>> 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
>>>>> <jaw981@gmail.com <ma...@gmail.com>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Oct 6, 2008 at 1:59 PM, David Jencks
>>>>> <david_jencks@yahoo.com <ma...@yahoo.com>>
>>>>> wrote:
>>>>>
>>>>>
>>>>> On Oct 6, 2008, at 10:35 AM, Jason Warner wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> On Mon, Oct 6, 2008 at 11:56 AM, David Jencks
>>>>>> <david_jencks@yahoo.com
>>>>>> <ma...@yahoo.com>> wrote:
>>>>>>
>>>>>>
>>>>>> On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Fri, Oct 3, 2008 at 6:55 PM, David Jencks
>>>>>>> <david_jencks@yahoo.com
>>>>>>> <ma...@yahoo.com>> 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?
>>>>>> 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?
>>>>>>
>>>>>>
>>>>>>
>>>>> If anyone knows how osgi deals with situations like
>>>>> this I'd find it really helpful in considering
>>>>> alternative directions.
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>>
>>>>> 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.< br>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://issues.apache.org/jira/browse/GERONIMO-4335
>>>>>>>>
>>>>>>>> -- ~Jason Warner
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -- ~Jason Warner
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- ~Jason Warner
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- ~Jason Warner
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- ~Jason Warner
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -- ~Jason Warner
>>>>
>>> --
>>> ~Jason Warner
>>>
>>
>>
>
--
~Jason Warner
Re: An idea for defining custom valves in config.xml
Posted by David Jencks <da...@yahoo.com>.
On Oct 8, 2008, at 1:55 PM, Joe Bohn wrote:
> Jason Warner wrote:
>> Thanks for the explanation, David. I don't disagree with anything
>> you've explained, but I'm not sure you've addressed my concern
>> about the disparity in the effort required to deploy a custom valve
>> on tomcat and on geronimo. Even with the a streamlined process
>> involving a tomcat server portlet and using the tomcat6 plugin as a
>> base, the user still has to become a plugin developer to deploy
>> their valve on geronimo. If that's how it has to be, then I
>> suppose that's how it has to be. I'm just concerned that it could
>> turn off users that might have otherwise lived happily with
>> geronimo. I'm not really sure how widespread the use of custom
>> valves are, though, so maybe it's just a small minority this would
>> even effect. I'd be curious to get some feedback from some other
>> developers and see if they have any thoughts on the matter. Anyone
>> else out there keeping an eye on this thread?
>
> I've been keeping an eye on it and I agree with you Jason that there
> is a disparity in the work required to add a valve to tomcat versus
> that required to add a valve to tomcat embedded in Geronimo. I also
> agree with David that the current Tomcat process does not lend
> itself to a reproducible configuration.
>
> In cases like this I tend to think like a politician and advocate a
> both/and rather than an either/or. I suspect that some users will
> want things in Geronimo to be as similar to Tomcat as possible ...
> and so will want a simple configuration solution. Doing so might
> convince them to move over to Geronimo and over time they may gain a
> greater appreciation for a more Geronimo like solution. Others
> might be coming in with more knowledge of Geronimo and expect
> something that is more consistent with Geronimo and can be
> reproduced. Can we give them both what they want?
>
> It seems like we could help the Tomcat centric folks with a simple
> configuration attribute that we can use to extend the classpath.
> For the more sophisticated Geronimo user we can direct them to
> rebuild/redeploy the Tomcat module with the additional dependency on
> the valve jar ... perhaps using c-m-p and then their own custom
> assembly. Even while providing the first approach we can highly
> recommend the second approach.
>
> It seems to me that the attribute/classpath extension is a simple
> thing to implement and will provide a high level of value to users
> that are accustomed to Tomcat. The Tomcat module rebuild/redeploy
> is just a matter of documentation ... correct?
I guess I'm trying to argue that we should be making doing the "right
thing" as easy as modifying tomcat to have a custom valve.
I'm not convinced we're all that far off:
tomcat -stop server
geronimo - server restart may be needed later.
tomcat - add jar to server/lib (?)
geronimo - add jar to repository
tomcat - edit server.xml
geronmo -edit tomcat6 plam.xml
geronimo - add artifact-alias (this could probably be automated into
part of the next step). Basically this should be editing the geronimo-
plugin.xml.
geronimo - deploy modified tomcat6 plan.xml, resulting in a new plugin.
tomcat - restart
geronimo - restart tomcat-dependent plugins/apps
There's basically only one more step in geronimo. I'm not sure how
well the "obsoletes" functionality works at the moment but ideally we
could have the new plugin obsolete the original and so installing it
would shut down the old one, shut down the plugins depending on it,
and restart the dependencies after install. This is the same number
of steps.
One missing bit here is that there is no good way to deploy an app
with an external geronimo-plugin.xml to end up immediately with a
plugin.
thanks
david jencks
>
>
> Joe
>
>> On Wed, Oct 8, 2008 at 2:25 PM, David Jencks
>> <david_jencks@yahoo.com <ma...@yahoo.com>> 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
>>> <david_jencks@yahoo.com <ma...@yahoo.com>> 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
>>>> <jaw981@gmail.com <ma...@gmail.com>> wrote:
>>>>
>>>>
>>>>
>>>> On Mon, Oct 6, 2008 at 1:59 PM, David Jencks
>>>> <david_jencks@yahoo.com <ma...@yahoo.com>>
>>>> wrote:
>>>>
>>>>
>>>> On Oct 6, 2008, at 10:35 AM, Jason Warner wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Oct 6, 2008 at 11:56 AM, David Jencks
>>>>> <david_jencks@yahoo.com
>>>>> <ma...@yahoo.com>> wrote:
>>>>>
>>>>>
>>>>> On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Oct 3, 2008 at 6:55 PM, David Jencks
>>>>>> <david_jencks@yahoo.com
>>>>>> <ma...@yahoo.com>> 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? 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?
>>>>>
>>>>>
>>>>
>>>> If anyone knows how osgi deals with situations like
>>>> this I'd find it really helpful in considering
>>>> alternative directions.
>>>> thanks
>>>> david jencks
>>>>
>>>>
>>>>> 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.< br>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> [1] https://issues.apache.org/jira/browse/GERONIMO-4335
>>>>>>>
>>>>>>> -- ~Jason Warner
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- ~Jason Warner
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- ~Jason Warner
>>>>
>>>>
>>>>
>>>>
>>>> -- ~Jason Warner
>>>>
>>>>
>>>>
>>>>
>>>> -- ~Jason Warner
>>>
>>>
>>>
>>>
>>> -- ~Jason Warner
>> --
>> ~Jason Warner
>
Re: An idea for defining custom valves in config.xml
Posted by Joe Bohn <jo...@earthlink.net>.
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 <david_jencks@yahoo.com
> <ma...@yahoo.com>> 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
>> <david_jencks@yahoo.com <ma...@yahoo.com>> 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
>>> <jaw981@gmail.com <ma...@gmail.com>> wrote:
>>>
>>>
>>>
>>> On Mon, Oct 6, 2008 at 1:59 PM, David Jencks
>>> <david_jencks@yahoo.com <ma...@yahoo.com>>
>>> wrote:
>>>
>>>
>>> On Oct 6, 2008, at 10:35 AM, Jason Warner wrote:
>>>
>>>>
>>>>
>>>> On Mon, Oct 6, 2008 at 11:56 AM, David Jencks
>>>> <david_jencks@yahoo.com
>>>> <ma...@yahoo.com>> wrote:
>>>>
>>>>
>>>> On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Oct 3, 2008 at 6:55 PM, David Jencks
>>>>> <david_jencks@yahoo.com
>>>>> <ma...@yahoo.com>> 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?
>>>> 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?
>>>>
>>>>
>>>
>>> If anyone knows how osgi deals with situations like
>>> this I'd find it really helpful in considering
>>> alternative directions.
>>> thanks
>>> david jencks
>>>
>>>
>>>> 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.< br>
>>>>>> Thanks!
>>>>>>
>>>>>>
>>>>>> [1]
>>>>>> https://issues.apache.org/jira/browse/GERONIMO-4335
>>>>>>
>>>>>> --
>>>>>> ~Jason Warner
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ~Jason Warner
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> ~Jason Warner
>>>
>>>
>>>
>>>
>>> --
>>> ~Jason Warner
>>>
>>>
>>>
>>>
>>> --
>>> ~Jason Warner
>>
>>
>>
>>
>> --
>> ~Jason Warner
>
>
>
>
> --
> ~Jason Warner
Re: An idea for defining custom valves in config.xml
Posted by Jason Warner <ja...@gmail.com>.
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 <da...@yahoo.com> 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 <da...@yahoo.com>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 <ja...@gmail.com> wrote:
>>
>>>
>>>
>>> On Mon, Oct 6, 2008 at 1:59 PM, David Jencks <da...@yahoo.com>wrote:
>>>
>>>>
>>>> On Oct 6, 2008, at 10:35 AM, Jason Warner wrote:
>>>>
>>>>
>>>>
>>>> On Mon, Oct 6, 2008 at 11:56 AM, David Jencks <da...@yahoo.com>wrote:
>>>>
>>>>>
>>>>> On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <da...@yahoo.com>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? 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?
>>>>>
>>>>
>>>>>
>>>> If anyone knows how osgi deals with situations like this I'd find it
>>>> really helpful in considering alternative directions.
>>>> thanks
>>>> david jencks
>>>>
>>>>
>>>> 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.< br>
>>>>>> Thanks!
>>>>>>
>>>>>>
>>>>>> [1] https://issues.apache.org/jira/browse/GERONIMO-4335
>>>>>>
>>>>>> --
>>>>>> ~Jason Warner
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ~Jason Warner
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> ~Jason Warner
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> ~Jason Warner
>>>
>>
>>
>>
>> --
>> ~Jason Warner
>>
>>
>>
>
>
> --
> ~Jason Warner
>
>
>
--
~Jason Warner
Re: An idea for defining custom valves in config.xml
Posted by David Jencks <da...@yahoo.com>.
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
> <da...@yahoo.com> 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 <ja...@gmail.com>
>> wrote:
>>
>>
>> On Mon, Oct 6, 2008 at 1:59 PM, David Jencks
>> <da...@yahoo.com> wrote:
>>
>> On Oct 6, 2008, at 10:35 AM, Jason Warner wrote:
>>
>>>
>>>
>>> On Mon, Oct 6, 2008 at 11:56 AM, David Jencks <david_jencks@yahoo.com
>>> > wrote:
>>>
>>> On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:
>>>
>>>>
>>>>
>>>> On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <david_jencks@yahoo.com
>>>> > 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? 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?
>>>
>>
>> If anyone knows how osgi deals with situations like this I'd find
>> it really helpful in considering alternative directions.
>> thanks
>> david jencks
>>
>>
>>> 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.< br>
>>>>> Thanks!
>>>>>
>>>>>
>>>>> [1] https://issues.apache.org/jira/browse/GERONIMO-4335
>>>>>
>>>>> --
>>>>> ~Jason Warner
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> ~Jason Warner
>>>
>>>
>>>
>>>
>>> --
>>> ~Jason Warner
>>
>>
>>
>>
>> --
>> ~Jason Warner
>>
>>
>>
>> --
>> ~Jason Warner
>
>
>
>
> --
> ~Jason Warner
Re: An idea for defining custom valves in config.xml
Posted by Jason Warner <ja...@gmail.com>.
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 <da...@yahoo.com> 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 <ja...@gmail.com> wrote:
>
>>
>>
>> On Mon, Oct 6, 2008 at 1:59 PM, David Jencks <da...@yahoo.com>wrote:
>>
>>>
>>> On Oct 6, 2008, at 10:35 AM, Jason Warner wrote:
>>>
>>>
>>>
>>> On Mon, Oct 6, 2008 at 11:56 AM, David Jencks <da...@yahoo.com>wrote:
>>>
>>>>
>>>> On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:
>>>>
>>>>
>>>>
>>>> On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <da...@yahoo.com>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? 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?
>>>>
>>>
>>>>
>>> If anyone knows how osgi deals with situations like this I'd find it
>>> really helpful in considering alternative directions.
>>> thanks
>>> david jencks
>>>
>>>
>>> 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.< br>
>>>>> Thanks!
>>>>>
>>>>>
>>>>> [1] https://issues.apache.org/jira/browse/GERONIMO-4335
>>>>>
>>>>> --
>>>>> ~Jason Warner
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> ~Jason Warner
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> ~Jason Warner
>>>
>>>
>>>
>>
>>
>> --
>> ~Jason Warner
>>
>
>
>
> --
> ~Jason Warner
>
>
>
--
~Jason Warner
Re: An idea for defining custom valves in config.xml
Posted by David Jencks <da...@yahoo.com>.
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 <ja...@gmail.com> wrote:
>
>
> On Mon, Oct 6, 2008 at 1:59 PM, David Jencks
> <da...@yahoo.com> wrote:
>
> On Oct 6, 2008, at 10:35 AM, Jason Warner wrote:
>
>>
>>
>> On Mon, Oct 6, 2008 at 11:56 AM, David Jencks
>> <da...@yahoo.com> wrote:
>>
>> On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:
>>
>>>
>>>
>>> On Fri, Oct 3, 2008 at 6:55 PM, David Jencks
>>> <da...@yahoo.com> 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? 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?
>>
>
> If anyone knows how osgi deals with situations like this I'd find it
> really helpful in considering alternative directions.
> thanks
> david jencks
>
>
>> 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.< br>
>>>> Thanks!
>>>>
>>>>
>>>> [1] https://issues.apache.org/jira/browse/GERONIMO-4335
>>>>
>>>> --
>>>> ~Jason Warner
>>>
>>>
>>>
>>>
>>> --
>>> ~Jason Warner
>>
>>
>>
>>
>> --
>> ~Jason Warner
>
>
>
>
> --
> ~Jason Warner
>
>
>
> --
> ~Jason Warner
Re: An idea for defining custom valves in config.xml
Posted by Jason Warner <ja...@gmail.com>.
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 <ja...@gmail.com> wrote:
>
>
> On Mon, Oct 6, 2008 at 1:59 PM, David Jencks <da...@yahoo.com>wrote:
>
>>
>> On Oct 6, 2008, at 10:35 AM, Jason Warner wrote:
>>
>>
>>
>> On Mon, Oct 6, 2008 at 11:56 AM, David Jencks <da...@yahoo.com>wrote:
>>
>>>
>>> On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:
>>>
>>>
>>>
>>> On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <da...@yahoo.com>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? 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?
>>>
>>
>>>
>> If anyone knows how osgi deals with situations like this I'd find it
>> really helpful in considering alternative directions.
>> thanks
>> david jencks
>>
>>
>> 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
>>>
>>>
>>>
>>
>>
>> --
>> ~Jason Warner
>>
>>
>>
>
>
> --
> ~Jason Warner
>
--
~Jason Warner
Re: An idea for defining custom valves in config.xml
Posted by Jason Warner <ja...@gmail.com>.
On Mon, Oct 6, 2008 at 1:59 PM, David Jencks <da...@yahoo.com> wrote:
>
> On Oct 6, 2008, at 10:35 AM, Jason Warner wrote:
>
>
>
> On Mon, Oct 6, 2008 at 11:56 AM, David Jencks <da...@yahoo.com>wrote:
>
>>
>> On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:
>>
>>
>>
>> On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <da...@yahoo.com>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? 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?
>>
>
>>
> If anyone knows how osgi deals with situations like this I'd find it really
> helpful in considering alternative directions.
> thanks
> david jencks
>
>
> 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
>>
>>
>>
>
>
> --
> ~Jason Warner
>
>
>
--
~Jason Warner
Re: An idea for defining custom valves in config.xml
Posted by David Jencks <da...@yahoo.com>.
On Oct 6, 2008, at 10:35 AM, Jason Warner wrote:
>
>
> On Mon, Oct 6, 2008 at 11:56 AM, David Jencks
> <da...@yahoo.com> wrote:
>
> On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:
>
>>
>>
>> On Fri, Oct 3, 2008 at 6:55 PM, David Jencks
>> <da...@yahoo.com> 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 can come up with
> something better.
>
> How would you deal with this in an osgi or spring environment?
>
If anyone knows how osgi deals with situations like this I'd find it
really helpful in considering alternative directions.
thanks
david jencks
> 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
>
>
>
>
> --
> ~Jason Warner
Re: An idea for defining custom valves in config.xml
Posted by Jason Warner <ja...@gmail.com>.
On Mon, Oct 6, 2008 at 11:56 AM, David Jencks <da...@yahoo.com>wrote:
>
> On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:
>
>
>
> On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <da...@yahoo.com>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 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
>
>
>
--
~Jason Warner
Re: An idea for defining custom valves in config.xml
Posted by David Jencks <da...@yahoo.com>.
On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:
>
>
> On Fri, Oct 3, 2008 at 6:55 PM, David Jencks
> <da...@yahoo.com> 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
Posted by Joe Bohn <jo...@earthlink.net>.
Jason Warner wrote:
>
>
> On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <david_jencks@yahoo.com
> <ma...@yahoo.com>> 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
Posted by Jason Warner <ja...@gmail.com>.
On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <da...@yahoo.com> 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
Posted by David Jencks <da...@yahoo.com>.
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