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
