On Wed, Oct 8, 2008 at 6:55 PM, David Jencks <[EMAIL PROTECTED]> 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 enough. Thanks! > > 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 <[EMAIL PROTECTED]<mailto: >>> [EMAIL PROTECTED]>> 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 >>>> <[EMAIL PROTECTED] <mailto:[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] <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 >>>>> >>>> >>>> >>>> >>>> >>>> -- ~Jason Warner >>>> >>> -- >>> ~Jason Warner >>> >> >> > -- ~Jason Warner
