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