Hi Dims & all
This discussion about OSGi is very interesting.
I agree that OSGi benefits are maybe not directly visible for the
end-user but maybe more for the deployer/assembler.
We did exactly what you want to do with Axis with our EJB3 container
(EasyBeans) a year ago:
* Having OSGi as an option: no dependencies on OSGi on the core so that
easybeans can still be used out of the box without OSGi, but when
easybeans is started in its OSGi mode, we take advantages of all the
OSGi features (versionned packages dependencies, some IoC, dynamism, ...).
http://wiki.easybeans.org/xwiki/bin/view/Main/OSGi
OSGi enforce some strong rules about packages visibility (the class
space) and moreover "force" us to use interfaces a lot (to limit
dependencies on implementations details). So using system properties is
discouraged (sys prop are JVM scoped, so maybe that's not the
configuration you want to share if you have multiple Axis instances).
We had to change things in the core to make this possible (like
providing extension interfaces), but without affecting the backward
compatibility.
What I want to say here is that some changes are probably necessary in
the core of Axis to ease that OSGi extension:
* All the places were there are some classloadings are probably to be
checked, OSGi prefers that the bundle that brings some new code creates
the instance, or at least load the class itself. A general idea is that
it's not safe, in OSGi, to rely on the TCCL to load class: who knows if
the TCCL contains the classloader you want ?
* Try to avoid sys properties, and prefer a configuration API
* Concerning the extensions, rely heavily on interfaces, not on
implementations, with clean packages separation
And last thing: that's better (almost mandatory) to have continuous
integration testing for OSGi, at least when there are developers that
don't know OSGi at all...
Oh, and that's better if the developers know a little about OSGi, so
that they can code something that will be easier to execute under OSGi
Cheers
--Guillaume
BTW, we will be very happy to see Axis2/OSGi running into JOnAS :)
Davanum Srinivas wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Paul,
That's exactly that's being done so far on the osgi module in various
stages of completion :) [Except for the last item]
thansk,
dims
Paul Fremantle wrote:
| I think the ideal outcome would be this:
|
| * Firstly we allow Axis2 to work cleanly in a OSGi environment.
| * We also allow Axis2 to work in a non-OSGi environment (full
| backwards compatibility).
| * We define an extension to Axis2 that is available as a separate JAR
| that enables OSGi
| * If the OSGi extension is available, then that enables OSGi
| deployment of services and modules
| * In other words, there is a well-defined way of creating a bundle
| that is a service and a bundle that is a module, and once the OSGi
| extension is enabled, the OSGi discovery mechanisms pick up the
| extensions.
| * Axis2 transports could also have OSGi metadata in the JAR so that
| these could use OSGi to be enabled if OSGi is enabled.
|
| I don't know if this is possible :)
|
| Paul
|
|
| On Mon, Jun 16, 2008 at 11:59 AM, Deepal jayasinghe
<[EMAIL PROTECTED]> wrote:
|> Saminda Abeyruwan wrote:
|>> =================================================
|>>
|>> 1. When aar/mar behavior is mimicked in an OSGi bundle, these
bundles be
|>> able to live in different class spaces.
|>> ex: If the bundles needed different hibernate versions they can be
|>> easily plug into different class spaces.
|> With the existing Axis2 class loaders you can easily do that , so
no new
|> thing is going to add :)
|>> 2. We will be able to have multiple version of Axis2 instancres
running
|>> inside same JVM.
|>> This require the need of minimizing System properties.
|> This is YAGNI.
|>> 3. Axis2 will be able to initiate same transport with different
versions.
|>> This will require proper integration of OSGi services. I haven't
touched
|>> this area yet, otherwise whole situation will be overwhelming.
|> What is the value of this , aren't we trying to build castles in
the sky
|> ;-)
|>> 4. OSGi life-cycle support. This will give the ability to
|>> start/stop/install/update/uninstall bundles.
|>> ex: I have myModule.jar which would mimic myModule.mar. We will
be able
|>> use the above actions to to manipulate the AxisModule as we need.
|> Yes , this a valid point that we can consider.
|>> 5. Once a user has written a bundle (which mimic
aar/mar/transport/etc),
|>> they just need to upload them into a "Axis2 bundle repository",
where the
|>> community can search them and install them into there system, without
|>> shutting down the running system.
|>>
|> So isnt this same as service hot deployment ?
|>> 6. OSGi event framework. When bundle is (aar/mar/transport/etc)
|>> install/started/updated/uninstall, using OSGi events other bundles
can
|>> change there behaviour.
|> We already have this in Axis2. I know places like WSO2 WSAS they
use this
|> feature a lot.
|>> 7. When bundle are properly designed, one will be able to deploy
these
|>> bundles in any OSGi environment. Most of the app servers are in
the path of
|>> supporting OSGi. All we have to do is to drop our bundles in their
|>> repositories and start them
|> I do not see a big value of this with respect to Web services
containers.
|>> 8. User can use resources (html/jsp/ etc) needed for aar/mar in
bundles.
|> You can already do with Axis2 services aar file , by adding "WWW"
directory
|> in the services aar file you can achieve almost all the power you have
|> mentioned.
|>>
|>> 8. Once the ConfigurationContext become an OSGi service, any
bundle can
|>> access it and use it.
|> Yes :)
|>> 9. People will be able to use OSGi registry to register POJOs as OSGi
|>> services and make them as web services
|>>
(http://www.knopflerfish.org/releases/current/doc/bundledoc/index.html)
|> But with Axis2 you can expose POJO as Web services in very
straightforward
|> manner.
|>> 10. People would need minimum effort to integrate into OSGi powered
|>> Spring etc.
|> Agreed.
|>
|> Thank you!
|> Deepal
|>
|> ---------------------------------------------------------------------
|> To unsubscribe, e-mail: [EMAIL PROTECTED]
|> For additional commands, e-mail: [EMAIL PROTECTED]
|>
|>
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
iD8DBQFIVloagNg6eWEDv1kRAk4LAJ9L46jJOZb/53Fp1Y6ZVpxL3CXdJQCgpPJE
gkMLLkWQRzPvjKtRM+KbE+4=
=z4aB
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
begin:vcard
fn:Guillaume Sauthier
n:Sauthier;Guillaume
org:<a href="http://www.ow2.org";><img title="OW2" alt="OW2 Consortium" border="0" src="http://www.ow2.org/xwiki/bin/skin/XWiki/DefaultSkin/logoOW2.png"; /></a>
adr:;;;;;;France
email;internet:[EMAIL PROTECTED]
title:<a href="http://jonas.ow2.org";>JOnAS Application Server</a>
x-mozilla-html:TRUE
url:http://jonas.ow2.org
version:2.1
end:vcard
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
![http://www.ow2.org/xwiki/bin/skin/XWiki/DefaultSkin/logoOW2.png"](http://www.ow2.org/xwiki/bin/skin/XWiki/DefaultSkin/logoOW2.png"){kind=link}