Raymond Feng wrote:
From: "Graham Charters" <[EMAIL PROTECTED]>
...
I see from the design (and also the module name :-) ) that this work
is Equinox-specific and will not work in other OSGi runtimes. I think
it would be a shame to make this the only way to use an OSGi
implementation and I know Rajini worked very hard to ensure the osgi
runtime work she did also supported Apache Felix. Is the intention to
deprecate support for other OSGi implementations?
We use Equinox to get the idea working. It doesn't really prevent other
OSGi runtime from supporting the same design.
For Apache Felix, we can just slightly change the way how we create the
virtual bundle for 3rd party jars (it might be a
bit more expensive as Felix doesn't support "external" classpaths for
the "Bundle-ClassPath" entry and we can create a folder-based
bundle that include the 3rd party jars).
BTW, it might be worth trying to propose the Hook ideas to Felix to
support various Bundle formats, Bundle wrapping and ClassLoading :-).
Right, I was not thinking about making this 'the only way' or
deprecating the osgi modules either. I see this a bit like what we've
done for server runtime integrations, where several runtime integrations
can co-exist (e.g. Tomcat, Jetty, Geronimo), we try to use common code
when convenient, and maybe we can also have a more generic integration
story like what we've done or Webapps for example.
Also, I like Raymond's idea to propose/ask the Felix team for hooks that
will help us integrate Felix with Tuscany.
One aspect I'm really interested in at the moment is to try to get all
(or almost all) of Tuscany working smoothly in an OSGi environment, but
I must say I'm a little stuck on how to try that without making many
changes to the whole code base (like some surgery in all the modules
that do not behave correctly classloading-wise, and revisit all samples
and test cases which are not designed to work in OSGi). Any thoughts are
welcome.
Regarding Class.forName and TCCL, you might find the following blog
posts from BJ Hargrave interesting. I'm not sure whether these
circumstances are likely to arise in Tuscany, but it's something to be
aware of:
http://blog.bjhargrave.com/2007/09/classforname-caches-defined-class-in.html
http://blog.bjhargrave.com/2007/07/contextfinder-in-eclipse-is-broken.html
Have read these two entries several times after each ClassNotFound
exception the last few days :)
Regarding META-INF/services, is there any reason why we couldn't use
the OSGi service registry to register and discover these services?
The more we use of standard OSGi capabilities, the more we can perhaps
leverage standard or third-party tools for things like configuration,
administration, analysis, etc...
One reason is that we want to keep the support to run Tuscany in an
environment without OSGi.
Here too I think we can be flexible and use implementations of
ServiceDiscoverer that leverage the facilities provided by J2SE, OSGi in
general and/or specific OSGi implementations. The OSGi service registry
is an option if people want to try that, as well as the Eclipse plugin
registry for example.
--
Jean-Sebastien
