geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Warner" <jaw...@gmail.com>
Subject Re: An idea for defining custom valves in config.xml
Date Mon, 06 Oct 2008 19:08:19 GMT
On Mon, Oct 6, 2008 at 1:59 PM, David Jencks <david_jencks@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.
>>>
>>> Thanks!
>>>
>>>
>>> [1]  https://issues.apache.org/jira/browse/GERONIMO-4335
>>>
>>> --
>>> ~Jason Warner
>>>
>>>
>>>
>>
>>
>> --
>> ~Jason Warner
>>
>>
>>
>
>
> --
> ~Jason Warner
>
>
>


-- 
~Jason Warner

Mime
View raw message