geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: An idea for defining custom valves in config.xml
Date Mon, 06 Oct 2008 14:56:13 GMT
Jason Warner wrote:
> 
> 
> On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <david_jencks@yahoo.com 
> <mailto: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. 

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


Mime
View raw message