On 01/05/2010 12:38 PM, Mark Thomas wrote:
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.
agree with Mark, just make the common/shared/server class loaders
configurable/injectable
Filip
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
