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. Main aspect of OSGi is version and modularity. In order to get the full power of OSGi, we need to consider the following,
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. Thus, when Axis2 start, one can give a repository where services & modules available and one could use bundles to mimic this behaviour. 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. 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, if the referenced module is not available, that service become faulty. This behaviour contradicts the nature of dynamic behaviour. Thus, what would really need is modules to be loaded and initialize orthogonal of service load and initialization. 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. 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. In addition to this standardizing this on Axis2 provide unique user experience among the Axis2 community. I am really appreciate if Axis2 folks comment on prior. Thank you! Saminda
