geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: An idea for defining custom valves in config.xml
Date Wed, 08 Oct 2008 17:22:32 GMT

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  

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 <> wrote:
> On Mon, Oct 6, 2008 at 1:59 PM, David Jencks  
> <> wrote:
> On Oct 6, 2008, at 10:35 AM, Jason Warner wrote:
>> On Mon, Oct 6, 2008 at 11:56 AM, David Jencks  
>> <> wrote:
>> On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:
>>> On Fri, Oct 3, 2008 at 6:55 PM, 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
>>> 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]
>>>> -- 
>>>> ~Jason Warner
>>> -- 
>>> ~Jason Warner
>> -- 
>> ~Jason Warner
> -- 
> ~Jason Warner
> -- 
> ~Jason Warner

View raw message