axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Sauthier <Guillaume.Sauth...@objectweb.org>
Subject Re: Extensions to Axis2/Java deployment engine
Date Mon, 16 Jun 2008 13:47:44 GMT
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 
> <deepalk@gmail.com> 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: axis-dev-unsubscribe@ws.apache.org
> |> For additional commands, e-mail: axis-dev-help@ws.apache.org
> |>
> |>
> |
> |
> |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Cygwin)
>
> iD8DBQFIVloagNg6eWEDv1kRAk4LAJ9L46jJOZb/53Fp1Y6ZVpxL3CXdJQCgpPJE
> gkMLLkWQRzPvjKtRM+KbE+4=
> =z4aB
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
>


Mime
View raw message