On 05/01/2010 17:41, David Jencks wrote: > > On Jan 4, 2010, at 2:56 AM, Mark Thomas wrote: >> One thing that isn't clear to me is whether the requirement is for an >> extension point for web application related instances (ie things that in >> a J2EE environment would be bundled in the WAR) or for container related >> instances such as LifecycleListeners. The current patch in bug 48414 >> seems to focussed on Tomcat internals and I don't understand how the >> line was drawn between what to access via the InstanceManager and what >> not to. > > Thanks for taking another look at this subject. I've been thinking of > the InstanceManager as the extension point for creating objects by > reflection rather than as the annotation handler, perhaps because of how > the Geronimo InstanceManager happens to be implemented. So, it seems to > me that adding a newSystemInstance method to it for creating objects > that are expected to come from the system rather than application > classes is reasonable. I'll try to come up with a patch using this > additional method in the next day or two.
The new patches make it clear that these are what I called container related instances. In this case the InstanceManager feels like the wrong place to do this. InstanceManagers are per web application and not really intended for container level objects. It is also still not clear why some container objects were selected for this new instantiation method and some not. This seems like something you would want for all container objects, rather than a sub-set. Since these are container objects and the default implementation is to call containerClassLoader.loadClass(className) I started to wonder if the container class loader might not be a better point to implement this integration. Something along the lines of a modified ClassLoaderFactory that returned a ClassLoader instance that new how to look things up via OSGI services and/or other OSGI bundles. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
