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]> 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. >>>> >>>> Thanks! >>>> >>>> >>>> [1] https://issues.apache.org/jira/browse/GERONIMO-4335 >>>> >>>> -- >>>> ~Jason Warner >>>> >>>> >>>> >>> >>> >>> -- >>> ~Jason Warner >>> >>> >>> >> >> >> -- >> ~Jason Warner >> >> >> > > > -- > ~Jason Warner > -- ~Jason Warner
