Jason Warner wrote:
On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <[EMAIL PROTECTED]
<mailto:[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.
Assuming that you can add a new valve to Tomcat with a simple
configuration change then I agree that we should be able to do the same
thing within Geronimo without requiring a user to redeploy the Tomcat
plugin.
I also agree that it seems this would be a tomcat module specific change
and not a general purpose thing (at least for now).
I know that David Jencks will cringe .... but it seems like we should be
able to do this in a similar fashion to how we extend the classloader in
SharedLib.java. We can just add an attribute or two on the Tomcat
GBean so the user can specify the location(s) of their valve jars and
then extend the classpath when the bean is constructed.
Joe
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
