axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Asankha C. Perera" <>
Subject Re: Extensions to Axis2/Java deployment engine
Date Sat, 14 Jun 2008 11:05:22 GMT

Thanks for the detailed reply.. Please see my comments below, I will 
only take the top 5 points for each list I asked for to keep this 
discussion short, as I believe these are in the order of importance/use
> 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.
I see this as a good use for the "end users"!
> 2. We will be able to have multiple version of Axis2 instancres 
> running inside same JVM.
>    This require the need of minimizing System properties.
But you really will need to change ports/queues etc to really run two 
axis2 versions. (i.e. there is no way two instances can share the same 
http/s port, or the JMS queue or check for email on the same account 
etc..). So the probability of this use and the value would be less. So 
this is not a good candidate for position # 2.
> 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.
See comment above.. again this is not something and "end user" will see 
much value in.. its like being able to deploy the same transport twice - 
at the same time. Also transports would be tied to axis2 versions, and 
if you have a newer version, its probably much better than a previous 
one anyway.. so again I don't see this as a good candidate for position # 3
> 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.
What most end users would do is write services.. and I believe they 
already can do some amount of life cycle management.. can you tell me 
what "new" improvements this will give?
> 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.
Typically a "user" written aar file is not really shared AFAIK.. but 
this is possible even as they are already.. as for the mar's - the most 
famous ones are rampart, sandesha/mercury etc.. which are "released".

> =================================================
> In Synapse point of view.
> 1. Mediators can be written as OSGi bundles. When you start the 
> bundle, the proper factory is called and build the relevant object model.
This is irrelevant, you will not just "add a mediator" at runtime.. but 
you can configure or update your sequence etc at runtime, and you can do 
it now itself (e.g. WSO2 ESB)
> 2. Different version of same mediator is highly possible. i.e two 
> mediator can live in two different class spaces.
Again, this is highly unlikely, since a newer version is better improved 
or fixes a bug of an older version, also you will not be able to 
configure two mediators as they register a unique QName in the 
> 3. You will be able to remove Sun service providers facility of 
> loading extension to bundles, which will be support in all Java 
> implementations.
This maybe good, but does not itself show much advantage, as we can do 
the Sun service provider with a bit of custom code in any JDK anyway..
> 4. Synapse guys like embedded devices ?
Not me.. but Synapse is being embedded.. but I don't see how this has 


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

View raw message