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.
+1
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
AxisConfigurator.
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!
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
