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 Wed, 08 Oct 2008 14:45:24 GMT
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 <jaw981@gmail.com> wrote:

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



-- 
~Jason Warner

Mime
View raw message