On Mon, Oct 6, 2008 at 11:56 AM, David Jencks <[EMAIL PROTECTED]>wrote:
>
> On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:
>
>
>
> On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <[EMAIL PROTECTED]>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.
>
> 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?
>
> 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
