Nicola Ken Barozzi wrote:
Anyone fancy advocating Avalon usage in Eclipse?
http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equinox-home/alternateRuntimes/index.html
Nicolas:
I don't think you can do a generic Avalon cut - they are looking at a plugin framework which really gets down into a service management model. Here is a view from the Merlin perspective.
How are libraries shared? -------------------------
Jar libraries are sharable using explicit import into a block, implicit association (via standard extensions mechanisms), or through composition by direct reference. Jar libraries provide the computational implementation of a block that in term may export services (enabling isolation of the implementation). Service exported by one block may be imported explicitly or resolved through assembly based on deployment and runtime dependency declarations.
Plugin private libraries supported?
-----------------------------------
Yes. A block represents a unit of isolation. The block implementation (jars and nested blocks) are private to the block.
Multiple versions of the same library?
--------------------------------------
Yes. Each block is managed in a separate classloader. The classloader hierarchy parallels a block structural hierarchy.
How are ClassCastExceptions prevented for shared objects?
---------------------------------------------------------
Meta-info is associated with all components, services and blocks enabling the declaration of the casting assumptions prior to system assembly. Client applications can safely cast shared services and runtime context information based on these prior declarations.
How are new/updated dynamic plugins discovered?
-----------------------------------------------
Components may be resolved in response to service access requests. A access request results in the assembly of a provider component (plugin) and subsequent deployment. Dependencies are resolved relative to a set of registries containing available services, types, deployment templates, and established deployment instances. Dynamic discovery is achievable by using a active as opposed to static registry.
What security model is provided?
--------------------------------
The default security model of the underlying JVM (i.e. J2SE). Platform extensions have been developed by users enabling principal establishment, authentication, authorization, and identity propagation as part of a service invocation context when invoking services across a distributed service management network.
What is the delivery model?
---------------------------
Multiple levels exist with the framework commencing with file system references at the lowest level. Higher level block services deal with repository based access to component implementations. Block level services also enable the introduction of distributed service access points using IIOP.
Tooling support
---------------
Support is in place for Ant based task that simplify/automate the meta-info generation activities. Corresponding functionality is provided for the Maven platform.
Lifecycle Primitives
--------------------
Full support for the Avalon component lifecycle stages (logging, configuration or parameterization, contextualization, initialization, startup, shutdown and disposal). Support also provided for lifecycle extensions enabling the introduction of non-standard phases into a component deployment process. The contextaulization phases handling is plug-replaceable. All phase handlers are themselves full components enabling complete customization of lifecycle management.
Persistent data management?
---------------------------
Temperature and permanent files based storage may be requested by a component. Components requiring more comprehensive persistence mechanisms may declare these requirements as dependencies. Existing persistence components are available support the PSS runtime persistence model based on PSDL specifications.
Any issues with 5000 plugins?
-----------------------------
The question implies a flat repository of plugins which is quite different to the Merlin system approach. Under Merlin repositories are hierarchical in nature and may be distributed. Typical applications scenarios call for 10-100 components within a particular JVM. Management of 1000s of component type declarations would be readily achievable is required through a set of registries that leverage the serialized meta-info descriptors, however, more information would be required on the underlying requirements on which question is raised.
(Remote) Management model? ---------------------------------- JMX planned.
Boot time issues?
--------------------
The framework separates boot time functions into a micro-kernel which is responsible for the establishment of the hierarchy root. The kernel may be embedded into other applications, invoked from the command line, accessed over JNDI, or deployed as an NT service.
Plugin-to-Plugin collaboration?
---------------------------
Blocks provide the framework for the isolation of component implementations from the services they provide. Service exposed by a block are exposed to other components in accordance with dependencies declared under component and block meta-info. The process of dependency resolution, ordering, assembly, deployment and decommissioning are completely automated.
Native code? (E.g. the SWT dll) ------------------------ Uses underlying JVM native code support.
Issues? ---------- Platform is under active development and subject to change.
Equinox Applicability? ------------------------ High.
Licensing? --------------- Apache 1.1
Implementations? ---------------------- Apache Merlin 2.1 OSM SMP
Links -------- http://avalon.apache.org/sandbox/merlin http://www.osm.net/products/merlin
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
