geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: An idea for defining custom valves in config.xml
Date Mon, 06 Oct 2008 17:59:35 GMT

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.


>
>
> 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


Mime
View raw message