geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Warner" <>
Subject Re: An idea for defining custom valves in config.xml
Date Mon, 13 Oct 2008 19:45:03 GMT
On Wed, Oct 8, 2008 at 6:55 PM, David Jencks <> wrote:

> On Oct 8, 2008, at 1:55 PM, Joe Bohn wrote:
>  Jason Warner wrote:
>>> Thanks for the explanation, David.  I don't disagree with anything you've
>>> explained, but I'm not sure you've addressed my concern about the disparity
>>> in the effort required to deploy a custom valve on tomcat and on geronimo.
>>>  Even with the a streamlined process involving a tomcat server portlet and
>>> using the tomcat6 plugin as a base, the user still has to become a plugin
>>> developer to deploy their valve on geronimo.  If that's how it has to be,
>>> then I suppose that's how it has to be.  I'm just concerned that it could
>>> turn off users that might have otherwise lived happily with geronimo.  I'm
>>> not really sure how widespread the use of custom valves are, though, so
>>> maybe it's just a small minority this would even effect.  I'd be curious to
>>> get some feedback from some other developers and see if they have any
>>> thoughts on the matter.  Anyone else out there keeping an eye on this
>>> thread?
>> I've been keeping an eye on it and I agree with you Jason that there is a
>> disparity in the work required to add a valve to tomcat versus that required
>> to add a valve to tomcat embedded in Geronimo.  I also agree with David that
>> the current Tomcat process does not lend itself to a reproducible
>> configuration.
>> In cases like this I tend to think like a politician and advocate a
>> both/and rather than an either/or.  I suspect that some users will want
>> things in Geronimo to be as similar to Tomcat as possible ... and so will
>> want a simple configuration solution.  Doing so might convince them to move
>> over to Geronimo and over time they may gain a greater appreciation for a
>> more Geronimo like solution.  Others might be coming in with more knowledge
>> of Geronimo and expect something that is more consistent with Geronimo and
>> can be reproduced.  Can we give them both what they want?
>> It seems like we could help the Tomcat centric folks with a simple
>> configuration attribute that we can use to extend the classpath.  For the
>> more sophisticated Geronimo user we can direct them to rebuild/redeploy the
>> Tomcat module with the additional dependency on the valve jar ... perhaps
>> using c-m-p and then their own custom assembly. Even while providing the
>> first approach we can highly recommend the second approach.
>> It seems to me that the attribute/classpath extension is a simple thing to
>> implement and will provide a high level of value to users that are
>> accustomed to Tomcat.  The Tomcat module rebuild/redeploy is just a matter
>> of documentation ... correct?
> I guess I'm trying to argue that we should be making doing the "right
> thing" as easy as modifying tomcat to have a custom valve.
> I'm not convinced we're all that far off:
> tomcat -stop server
> geronimo - server restart may be needed later.
> tomcat - add jar to server/lib (?)
> geronimo - add jar to repository
> tomcat - edit server.xml
> geronmo -edit tomcat6 plam.xml
> geronimo - add artifact-alias (this could probably be automated into part
> of the next step).  Basically this should be editing the
> geronimo-plugin.xml.
> geronimo - deploy modified tomcat6 plan.xml, resulting in a new plugin.

I seem to be having issues with this step.  It's probably something I'm
doing, though.  Is there a good example of the artifact-alias element in
action?  My issue seems to be that I can't disable the tomcat6 plugin
because modules that are dependent upon it restart it automatically when the
server is started.  At least, this is what I believe is happening.  This
results in port conflicts and such when my custom tomcat6 module is
started.  Shouldn't the artifact-alias be pointing the dependent modules to
the  custom module instead of the default tomcat6 plugin?  If not, perhaps
that's functionality we should add.  It's possible I'm specifying the
artifact-alias incorrectly or in the wrong place, which is why I'm asking
for an example where this is done.  I see it mentioned a few times in the
documentation, but it's usually either out of context or not detailed


> tomcat - restart
> geronimo - restart tomcat-dependent plugins/apps
> There's basically only one more step in geronimo.  I'm not sure how well
> the "obsoletes" functionality works at the moment but ideally we could have
> the new plugin obsolete the original and so installing it would shut down
> the old one, shut down the plugins depending on it, and restart the
> dependencies after install.  This is the same number of steps.
> One missing bit here is that there is no good way to deploy an app with an
> external geronimo-plugin.xml to end up immediately with a plugin.
> thanks
> david jencks
>> Joe
>>  On Wed, Oct 8, 2008 at 2:25 PM, David Jencks <<mailto:
>>>>> wrote:
>>>   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
>>>>   < <>> 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
>>>>>       < <>> wrote:
>>>>>           On Mon, Oct 6, 2008 at 1:59 PM, David Jencks
>>>>>           < <>>
>>>>>           wrote:
>>>>>               On Oct 6, 2008, at 10:35 AM, Jason Warner wrote:
>>>>>>               On Mon, Oct 6, 2008 at 11:56 AM, David Jencks
>>>>>>               <
>>>>>>               <>> wrote:
>>>>>>                   On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:
>>>>>>>                   On Fri, Oct 3, 2008 at 6:55 PM, David Jencks
>>>>>>>                   <
>>>>>>>                   <>> 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
>>>>>>>>                       config.xml.  Currently this isn't possible
>>>>>>>>                       since the tomcat classloader would
>>>>>>>>                       contain the custom classes for the
>>>>>>>>                     I've create a jira for tracking this
>>>>>>>>                       [1] and it contains a few links to
>>>>>>>>                       workarounds.  IMHO, The solution we
>>>>>>>>                       be looking for is a way to add classes
>>>>>>>>                       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
>>>>>>>                       Why is changing the classloader contents
>>>>>>>                       config.xml a good idea?  What is so hard
>>>>>>>                       about redeploying the app if you want to
>>>>>>>                       change its classloader significantly? 
>>>>>>>                       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,
>>>>>>>                   it's probably not necessary or desirable to
>>>>>>>                   expand it further.  I believe this situation
>>>>>>>                   different because the structure of geronimo
>>>>>>>                   causing a disconnect between the functionality
>>>>>>>                   of tomcat and the functionality of tomcat as
>>>>>>>                   is embedded in geronimo.  As Don just said
>>>>>>>                   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
>>>>>>>>                       how our classloader works, but I've
>>>>>>>>                       a look through the code and I think
>>>>>>>>                       ability to add to the classloader can
>>>>>>>>                       implemented without too much difficulty.
>>>>>>>>                   I'm not quite sure what type of scope to
>>>>>>>>                       give this change, though.  Should I
>>>>>>>>                       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
>>>>>>>>                       to do, but I'm still working out the
>>>>>>>>                       details of how to proceed.  I'm hoping
>>>>>>>>                       some feedback on what I intend to do
>>>>>>>>                       possibly some alternate ideas if anyone
>>>>>>>>                       has some.< br>
>>>>>>>>                       Thanks!
>>>>>>>>                       [1]
>>>>>>>>                       --                         ~Jason Warner
>>>>>>>                   --                     ~Jason Warner
>>>>>>               --                 ~Jason Warner
>>>>>           --             ~Jason Warner
>>>>>       --         ~Jason Warner
>>>>   --     ~Jason Warner
>>> --
>>> ~Jason Warner

~Jason Warner

View raw message