axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Saminda Abeyruwan" <>
Subject Re: Extensions to Axis2/Java deployment engine
Date Sun, 15 Jun 2008 17:36:41 GMT
Hi All,

w.r.t OSGi, at the end of the day prior points will boil down to version,
modularity and life-cycle support. OSGi has established its ways to  be  a
good modular system for  Java.

This extension wouldn't break any backward compatibility. But in order to
embed this extension properly, few aspects of deployment semantics has to be
changed (ex: tight dependency between services and modules to lazy
dependency).  One could always use this jars in its environment, if they
don't need OSGi. Being OSGi, this jar contains additional headers in

JSR 291 is the dynamic module for Java (R4.1), which we wanted to use. JSR
294 is the proposed language extension for modules in Java (native). All I
know is, JSR 294 is very far from being a reality, not even in Java 1.7.

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.

Axis2 kernel  doesn't have to be depend on any transport. One usecase will
be one version of kernel be listen by (http/https) only and other version
only be listen by (jms), and both reside in the same JVM. There are other
usecase to have multiple instances of Axis2 running inside same JVM.

>  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

Reason is same as step 2.

>  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?

This phase will eliminate what we call "jar hell".  This life-cycle support
is not the same this that axis service support. This is the phase where one
could physically alter the bundle and include the changes without shutting
down the system. This phase has a association with #1.

>  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".

Axis2 service doesn't have to an "aar". "aar" is one extension that is being
used to create the axis service with "ServiceDeployer". One could write n
number of deployers, with different formats. What bundle provide is a unique
way to share resources, packages, version etc. One ex: will be the POJO
deployer. pojos are lookup by ".jar" extension and 3rd party libraries are
located in either the "pojo/lib" folder or root lib. Do you think this is

1.  What if two pojo need two different hibernated versions.
2. What if these pojo need  to  be hosted and  downloaded.

w.r.t OSGi, now POJO can have two different hibernate versions, and they can
be downloaded from a bundle repository and dependency is resolved at

You have mentioned "rampart" as a famous example. "rampart.mar" contains
only the module.xml. All other 3rd party jars has to be put into root lib.
Rampart folks has done this, in order to prevent class delegation problems.
With OSGi, one would need only to copy the relevant bundles into bundle
repository and start them. Thus, this will eliminate of copying jars and
mars all over the place. In order to  include rampart into the system, one
has to shut down the entire instance and start again. No offence rampart
folks. This is true for most of the modules. So this is the problem we are
trying to address and sort out with proper modularizing and version.

The other 5 cases as strong as the prior 5 cases.

Thank you!



Saminda Abeyruwan

Senior Software Engineer
WSO2 Inc. -

View raw message