axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <>
Subject Re: Extensions to Axis2/Java deployment engine
Date Mon, 16 Jun 2008 12:18:34 GMT
Hash: SHA1


That's exactly that's being done so far on the osgi module in various stages of completion
:) [Except for the last item]


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 <> 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
|>> (
|> 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:
|> For additional commands, e-mail:
Version: GnuPG v1.4.5 (Cygwin)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message