Jean-Sebastien Delfino wrote:
Jean-Sebastien Delfino wrote:
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.
Yesterday evening I made one more minor change to node-launcher-equinox
and simplified it a bit as it didn't really need a BundleActivator to
initialize itself (since it's main function is to be actively 'launched'
anyway). I just committed that small change this morning.
I've started to look at how to change samples and test cases to work in
OSGi with the OSGi based launchers, tried the helloworld WS and store
samples and ran into errors (ClassLoading issues again in the Tuscany
code and Axis2).
I also tried the calculator-rcp app that Raymond has started to work on
and realized that for it to work all other modules should be seen as PDE
plugin projects in my IDE. I tried to convert the sca-api module to a
plugin and that made calculator-rcp compile at least.
Obviously I'm not going to commit any of these changes right now as they
would be pretty disruptive, but I just wanted to give an update.
I think that getting the whole all Tuscany working in OSGi is going to
require a serious effort of several weeks and changes in many different
places in the code.
I've made some progress since yesterday:
- changed the build as suggested by Raymond in [1];
- started to change calls to getContextClassLoader(), about 70 places
across the Tuscany code;
- ported some of the samples and itests to use the Equinox launcher;
- and started to debug issues with Tomcat and Axis2 in this environment.
I'll create a branch to make progress on this Equinox porting effort
without breaking everybody else. As I said before it'll probably take a
few weeks to get most Tuscany samples and itests up and running, but I'd
like to try to have a few core itests and maybe a Web Service or two
working in the next few days.
I hope others can jump in if they are interested and help debug some of
these classloading issues: ClassNotFoundException, NoClassDefFoundError,
IncompatibleClassChangeError... pick your exception :)
[1] http://marc.info/?l=tuscany-dev&m=122107319814317
--
Jean-Sebastien
