I've uploaded a couple patches to https://issues.apache.org/bugzilla/show_bug.cgi?id=48414
with a new newSystemInstance method. I'm not sure why this doesn't
need to be in a protected block like much of the code that creates
objects for the app, but the original code wasn't in such a block so
I'm assuming it's not really needed.
thanks
david jencks
On Jan 5, 2010, at 9:41 AM, David Jencks wrote:
On Jan 4, 2010, at 2:56 AM, Mark Thomas wrote:
On 04/01/2010 02:46, Tim Whittington wrote:
No need to re-post. A ping would have sufficed.
We've experienced similar issues integrating lots of third party
libraries (Tomcat being one of them) into our OSGi runtime.
Thanks for your input. I can't speak for the other Tomcat
committers but
I know very little about OSGI so it is useful to have input from
those
more experienced.
Essentially this boils down to OSGi liking extension functionality
to be provided by instantiation in the providing bundles, and
publication using OSGi services.
(i.e. pure OSGi services or declarative services etc.). Put
another way, the concepts of global application classloaders where
Class.forName works (ala Java EE etc.) break down in OSGi.
Libraries that use the TCCL in preference to Class.forName help,
but in cases like the one you describe where there's no direct
invocation from the bundle that has access to the classes it
doesn't help. Fragment bundles (and Eclipse specific buddy
classloaders) also help, and we've had to use them with tools like
Hibernate, but they're less than ideal.
I think the conclusion you've reached is correct - either fragment
bundles (which is a sub-optimal solution) or a pluggable extension
loading framework could be the solution.
OK. The consensus amongst those that know OSGI seems to be some
form for
pluggable extension point.
I believe we ran into issues like this when integrating Tomcat 5.5
into our OSGi runtime - we had to patch up the web app
ClassLoaders at runtime to make taglib loading work.
In that case we were able to wrap the ClassLoaders with the help
of some declarative metadata in bundles containing taglibs.
If you can tell which bundles can contain implementions of
whatever it is you're trying to instantiate, you can construct a
ClassLoader spanning those bundles yourself and use that (you'd
only want to use it for loading these extensions, as it defeats
the purpose/nature of OSGi to some extent to do this).
It might be that the web application bundles would be all you need
(and the upcoming OSGi Enterprise Spec will give you a standard
way of locating these), and that'd probably be a reasonable
limitation, or you could accomodate applications partitioned to a
finer degree by some additional marker to include other bundles.
The other, more OSGi approach would be for listeners to be
published as OSGi services with target properties, that are then
just looked up by name by the OSGi version of the extension loader
(as opposed to instantiating them).
i.e. an instance of the Listener interface is published by a
bundle as an OSGi service with a property
tomcatClassName=org.myproject.impl.MyListener. The extension
loader then looks up the service with a property filter on
'tomcatClassName' to find the available extension.
OSGi apps using Tomcat would simply publish these using
Declarative Services or similar, and this would be a very natural
approach for an OSGi app.
Using Services does seem more in the spirit of OSGI.
With this latter approach you have delightful lifecycle management
issues because of the dynamic nature of OSGi (extension bundles
starting after the Tomcat bundles for instance). We solve some of
these with a combination of declarative only metadata (using the
Eclipse Extension Registry) to advertise extension existence on
bundle resolution, and Declarative Services to instantiate and
publish the actual extension, and some by having the framework
accept dynamic injection of extensions (Listeners come and go).
Glad I don't have to worry about those issues :)
The main purpose of the InstanceManager is meet some of the
requirements
for annotations support. As such, it is only used for instances
that may
have annotations. There is one InstanceManager instance per web
application.
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.
thanks again!
david jencks
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
