-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 +1 Go for it!
- -- dims David Illsley wrote: | Sounds good. +1 | David | | On Thu, Jun 12, 2008 at 5:27 PM, Saminda Abeyruwan <[EMAIL PROTECTED]> wrote: |> 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 |> |> |> |> | | --------------------------------------------------------------------- | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) iD8DBQFIUciJgNg6eWEDv1kRAscLAKCZ+UUnx2ItP3phrJ4by6+pLR+SUwCg6jQC 8nF6JcA72LZRhAyk5gpQ7NM= =fEJ4 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
