+1 Saminda
On Mon, Jun 16, 2008 at 7:17 PM, Guillaume Sauthier < [EMAIL PROTECTED]> wrote: > 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] >> >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Saminda Abeyruwan Senior Software Engineer WSO2 Inc. - www.wso2.org
