axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Saminda Abeyruwan" <samin...@gmail.com>
Subject Re: Extensions to Axis2/Java deployment engine
Date Mon, 16 Jun 2008 13:57:38 GMT
+1

Saminda

On Mon, Jun 16, 2008 at 7:17 PM, Guillaume Sauthier <
Guillaume.Sauthier@objectweb.org> 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 <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
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>



-- 
Saminda Abeyruwan

Senior Software Engineer
WSO2 Inc. - www.wso2.org

Mime
View raw message