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
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
On Mon, Oct 6, 2008 at 1:59 PM, David Jencks
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
wrote:
On Oct 6, 2008, at 10:35 AM, Jason Warner wrote:
On Mon, Oct 6, 2008 at 11:56 AM, David Jencks
<[EMAIL PROTECTED]
<mailto:[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]
<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.
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.< br>
Thanks!
[1]
https://issues.apache.org/jira/browse/GERONIMO-4335
--
~Jason Warner
--
~Jason Warner
--
~Jason Warner
--
~Jason Warner
--
~Jason Warner