axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deepal jayasinghe <>
Subject Re: Extensions to Axis2/Java deployment engine
Date Fri, 13 Jun 2008 05:40:19 GMT

> Hi Devs,
> Dims has started the work on providing the OSGi extension to Axis2.  
> This extension is a single bundle which consist of all the jars needed 
> to run axis2. It uses OSGi Bundle events to update AxisConfiguration.  
So does that mean Dims has written a OSGi based Axis configurator ?
> Main  aspect of  OSGi  is version and modularity. 
Well in Axis2 module has version support by default , so we do not need 
to worry of getting module version support. No body ask for better 
module version support than what we have, so no need to worry.
> In order to get the full power of OSGi, we need to consider the following,
Just for curiosity does any user ask for OSGi support in Axis2. Or we 
just did that thinking ha!! there is something called OSGi out there , 
how about using that. The reason I am telling this is there a number of 
critical issues in Axis2 then having OSGi support.
> 1. Modules and Service loading
> 2. Using OSGi services
> I would consider the first section. Second section has a broad scope 
> and lets discuss that in a separate thread.
> With the OSGi, one could be able to write aar & mar as OSGi bundles. 
Yes , but we MUST support what we have now out of the BOX . if you want 
to deploy them as OSGi bundle then do that using a separate Deployer. Do 
not try to change any of the kernel code to do this.
> Thus, when Axis2 start, one can give a repository where services & 
> modules available and one could use  bundles to  mimic this behaviour
You are talking about a new AxisConfigurator , if that is the case I 
have no objection. Go ahead and do what ever you want.
> . When it's come to bundles, they could either exist or remove from 
> the system any-time. This is dynamism of OSGi and this behaviour is 
> currently not possible with current module & service loading mechanism.
I am sorry one of the architectural decision we took when we deploy 
Axis2 was , that we are not going to have hot -deployment support for 
modules. So we do not need to worry about dynamic nature of module ,right ?
> Current architecture requires, modules to be available first before 
> services are loaded, if modules are referenced by theses services. 
> Thus, services have a direct dependency to modules. Even if the 
> service is not faulty, 
Well if the module is not there , then thats simply mean something is 
missing for service to up and running . So if the module is not there 
then that simply mean the service is faulty.
> if the referenced module is not available, that service become faulty. 
> This behaviour contradicts the nature of dynamic behaviour.
Nope, thats what Axis2 architecture enforce , and that is one of the 
architectural decision we have taken few years back.
> Thus, what would really need is modules to be loaded and initialize 
> orthogonal of service load and initialization. 
Well in the OSGi world that may be true but not in Axis2. So if you 
write your own AxisConfigurator then you can code your code to work 
exactly what you have mention. But not in Axis2 default behavior ;-) .
> If loaded service reference to a module that is not available yet, 
> marked that service as "unresolved" until the module is available. 
> Once the module is available it would be easily go thorough the 
> "unresolved" services and marked the relevant services as "resolved". 
> Everything will be handle using OSGi events, which is very powerful 
> and flexible. There  could be other events that make the service 
> "unresolved", but the major one is module.
yes all those with your custom OSGi dependent code , not in Axis2 core.
> Where there are 100s of bundles available in the system, its not 
> practical to assume a start level to  bundles. These bundles may mimic 
> Axis2 services/module or other 3rd party bundle.
> I am totally fine with current deployment mechanism, but in order to 
> obtain a tighter integration we would have to revisit the current 
> deployment semantics.
No way , I am -1 for that. But I am +1 for writing a OSGi based 
> In addition to this standardizing this on Axis2 provide unique user 
> experience among the Axis2 community.
What do you mean by standardizing ? what do you want to standarde ?

Thank you!

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

View raw message