On Oct 6, 2008, at 10:35 AM, Jason Warner wrote:
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.
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.
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
