geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: An idea for defining custom valves in config.xml
Date Tue, 14 Oct 2008 17:16:49 GMT
Jason,

I think you've picked up that I'm mixing talking about what we can  
easliy do now and what I wish we could do now more easily :-)

On Oct 14, 2008, at 8:11 AM, Jason Warner wrote:

> David,
>
> I've been trying to follow your steps and seem to be having issues  
> accomplishing the goal.  Please see questions inline.
>
> On Wed, Oct 8, 2008 at 6:55 PM, David Jencks  
> <david_jencks@yahoo.com> 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.
>
> Which geronimo-plugin.xml am I editing here?  I tried  editing the   
> original tomcat6 plugin  but that didn't seem to work.

This would be the geronimo-plugin.xml for the new plugin you are  
constructing.  IIRC there are at least two missing bits of  
functionality:
- there's no editor for artifact-aliases and obsoletes in geronimo- 
plugin.xml
- there's no way except the c-m-p to deploy a plan and include a  
geronimo-plugin.xml in the resulting car file.
- even if we did have a way to include the geronimo-plugin.xml we  
currently don't do the extra installation steps of unpacking files and  
modifying the configuration files (config.xml, config- 
substitutions.properties, artifact-aliases.properties)

>
>
> geronimo - deploy modified tomcat6 plan.xml, resulting in a new  
> plugin.
>
> tomcat - restart
> geronimo - restart tomcat-dependent plugins/apps
>
> Was your intention to have this new plugin run in parallel with the  
> original tomcat6 plugin?  I'm not sure it would be necessary to have  
> them both run.

It should replace it.  It should have an artifact-alias so anything  
referring to the old plugin gets the new one instead and it should  
have an obsoletes element to uninstall the old tomcat plugin.
>
>
>
> 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.
>
> I'm confused.  One of your steps said to deploy the plan.xml and  
> that would result in a new plugin.  Here you are saying that there's  
> good way to do this.  When I deployed the plan.xml, the resultant  
> directory in the repository was missing a geronimo-plugin.xml.

That's one of the main missing bits of functionality.  Right now the  
only way to get the g-p.xml is to use c-m-p or to export the plugin  
from a server it's been deployed into, or to do something by hand with  
jar packing and unpacking.

The biggest problem here, in my mind, is that jsr88 only wants you to  
have one "plan": to deploy something you get to specify the artifact  
and one "plan".  Our deployment system is built around jsr88 so we  
either have to condense the g-p.xml and plan into one "plan" or  
abandon jsr88.

At the moment I'm thinking that one satisfactory solution might be to  
more or less embed the plan into g-p.xml.  Perhaps we could avoid  
duplicating most of the dependency info by adding the <import> element  
to the dependencies in g-p.xml.  I guess we'd expect a more or less  
empty <environment> element in the plan and fill in the dependencies  
from the g-p.xml when deploying.

I guess another possibility might be to include the info from g-p.xml  
in the environment element of the plan.

I've been thinking about this on and off for a long time and don't  
have any solution I'm entirely happy with so discussion and more ideas  
are more than welcome :-)

thanks
david jencks

>
>
> thanks
> david jencks
>
>
>
>
>
>
> Joe
>
> On Wed, Oct 8, 2008 at 2:25 PM, David Jencks <david_jencks@yahoo.com  
> <mailto:david_jencks@yahoo.com>> 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
>   <david_jencks@yahoo.com <mailto:david_jencks@yahoo.com>> 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
>       <jaw981@gmail.com <mailto:jaw981@gmail.com>> wrote:
>
>
>
>           On Mon, Oct 6, 2008 at 1:59 PM, David Jencks
>           <david_jencks@yahoo.com <mailto:david_jencks@yahoo.com>>
>           wrote:
>
>
>               On Oct 6, 2008, at 10:35 AM, Jason Warner wrote:
>
>
>
>               On Mon, Oct 6, 2008 at 11:56 AM, David Jencks
>               <david_jencks@yahoo.com
>               <mailto:david_jencks@yahoo.com>> wrote:
>
>
>                   On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:
>
>
>
>                   On Fri, Oct 3, 2008 at 6:55 PM, David Jencks
>                   <david_jencks@yahoo.com
>                   <mailto:david_jencks@yahoo.com>> 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
> -- 
> ~Jason Warner
>
>
>
>
>
> -- 
> ~Jason Warner


Mime
View raw message