On Oct 8, 2008, at 11:04 AM, Jason Warner wrote:
I'm not sure if these steps are reasonable from a purely user
perspective. When using plain old tomcat, you can download a
binary, add your custom valve jar, make a config change and then use
your server with its custom valve. To accomplish the same task in
geronimo, we are asking the user to download and install maven as
well as grab source code for the tomcat plugin. I'd really like to
have a way we can accomplish the same goal while allowing the users
to maintain a user level of interaction with geronimo.
I think (1) is really a more realistic approach philosophically so
I'll only discuss it more.
Lets consider the results of the modifications on tomcat and geronimo.
In tomcat, the user has modified their server installation and has no
built-in record of what they did. If they install another server
somewhere else they have to look in their notes or try to remember
what they did or ??? to get the same result.
In geronimo + maven they have a reproducible and automated way to
generate the customization that is suitable for storing in scm,
auditing, running through qa, etc etc.
Its also possible to fish the plan out of the tomcat6 plugin, modify
it a bit, and deploy it using gshell or (if you didn't start it) using
the console. I think you could add the geronimo-plugin.xml using the
admin console and add the artifact-aias. This on export would result
in a reusable plugin. I'm not sure if you could turn around and
install the plugin on the server it was generated on to install the
artifact alias so on the next startup you'd get the new tomcat plugin.
My philosophical objection to adding valves to the existing tomcat
config is that you've changed it in a fundamental way so you should
have a new, replacement, plugin instead. By this point you can add
the extra jar(s) anyway as dependencies.
Maybe we could have a tomcat server portlet that would help with
generating tomcat server plans with custom valves and connectors and
such stuff. I think that right now that is still the hardest part.
thanks
david jencks
On Wed, Oct 8, 2008 at 1:22 PM, David Jencks
<[EMAIL PROTECTED]> wrote:
On Oct 8, 2008, at 7:45 AM, Jason Warner wrote:
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.
app-per-port is complicated by the additional features there of:
- only one artifact (an ear) instead of 2 or 3 plugins
- starting the connectors after the web app has started
If neither of these features is needed you can just build a plugin
with the tomcat server + custom valve. There are two strategies:
1. replace the tomcat6 plugin
2. use the (stopped) tomcat6 plugin as a parent for the new plugin.
In either case I'd build the new plugin with maven and start by
copying the tomcat6 plugin and renaming it appropriately. Then
modify the plan to include the custom valve.
for (1), you'd just add the jar with the custom valve as a pom
dependency. Use an artifact-alias so your tomcat plugin will
replace the usual tomcat6 plugin.
for (2), you'd replace the pom dependencies with a dependency on the
tomcat6 plugin, and add the custom valve jar dependency. In the c-m-
p configuration you'll want to specify the import on the tomcat^
plugin as "classes" so it wont get started. An artifact alias won't
work here so don't deploy things that depend on tomcat6 as that will
result in the tomcat6 plugin starting and having port conflicts with
your plugin.
Building a custom server including your plugin or installing it on a
framework server via gshell is likely to work better than trying to
replace the tomcat6 plugin while it's running through the admin
console.
hope this helps
david jencks
Thanks,
On Mon, Oct 6, 2008 at 3:08 PM, Jason Warner <[EMAIL PROTECTED]>
wrote:
On Mon, Oct 6, 2008 at 1:59 PM, David Jencks
<[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]
> 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.
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
--
~Jason Warner