Raj Saini wrote:
Stephen McConnell wrote:Raj Saini wrote:Hi,
Merlin2 provides pluggable lifestyle extensions. Components can declare a dependency on a lifecycle extension provide. Components can also be provider of lifecycle extension service.Correct.
The Eclipse IDE (www.eclipse.org) provides the same kind of mechanism where the plugs can declare hook to extension points of other plugs or they can also declare their own extensions. The Merlin2 extension architecture seems similar to the Eclipse extension architecture. In Eclipse IDE it is possible to extend the IDE functionality by writing the plugins.
What is the purpose of the extension architecture in Merlin2?
There ate two ways of interpriting the question - and two distinct answers.
1. What is the purpose of the *component* Extension
architecture in Merlin 2
The purpose is to provide a higher level of flexibility
to component users by eliminating the restriction to
Avalon only lifecycle stages. In effect, different component
models can be handled by the Merlin system - although it is
safe to say that the Avalon model is the core and central
model supported.
2. What is the purpose of the *extendable* architecture of
Merlin 2
Merlin 2 design was initiated on the principal that diffenent
functional elements should be replaceble by components. This
requires at least a bootstrap component deployment framework
so that extensions logic to establish Merlin can be loader
without compromising the support for the core Avalon
component model. This is why a extension facility in Merlin
can have things like depedencies and so on - because the
bootstrap assemably, lifecycle and lifestyle facilities
enable the establishment of extensions that may end up
replacing themselves.
Thank you very much for clarifying this to me.Is it possible to write a core application and extend the functionality by writing pluggable blocks? I am impressed by the Eclipse plugin architecture. Eclipse allows tool venders to write tools and plug them to the base IDE. Does Merlin2 extension architecture server the same purpose for server application
Its a quaestion of granularity.
The "Lifecycle Extension" model only serves to suppliment the deployment and access stages that a component passes through. This is more a concern of the lifecycle model adn less to do blocks.
Componet service management (ability to declare dependecies) and system assembly is much closer to the notion of server extension that I think your getting at.
Yes, You are right. This is what in mind.Finally, the approach and policies applied to component management within Merlin are largely diriven my replaceable components. In that resspect the configuration of merlin containers allows a very high degree of freedom in terms of the component management and containment logic. For example, I can have a container hierachy in which different containters in the hierachy are using different approaches to componet deployment and service access. However, you won't find much document on this area as it is still not quitre settled. There is a little more seperation to be done on the service access policy and handling of custom service access handlers.
Extending the server application by writing self-contained plugs (or components) would be a nice feature. Though Phoenix offers this facility but it is on server level. In my opinion a server developer need deployable components (or plugs) for the server instead of many deployable servers application in a single kernel.
Agreed - I've been thinking recently about a block architecture which is basically a container hierachy packaged into a deploiyment unit. There blocks could be referenced by a container relative to the services exported by the block. Much of the structure for this is already in place within Merlin 2, but more thinking is still required on some aspects concerning the semantics of interaction between container and block.
I would like to contribute in this area. Is there any docs or pointer from where I can start? I would appreciate your help to enable me to make start.
That would be really terrific.
Documentation on Merlin (excalibur/assembly)
--------------------------------------------
http://jakarta.apache.org/avalon/excalibur/merlin
Documentation of the underlying meta model (escalibur/meta)
-----------------------------------------------------------
http://jakarta.apache.org/avalon/excalibur/meta
Documentation of the component lifecycle extensions (excalibur/container)
-------------------------------------------------------------------------
http://jakarta.apache.org/avalon/excalibur/container
Other Resources
---------------
You may also want to check out some of the posts from Gary Shea who is busy asking all sorts of questions in this area.
http://marc.theaimsgroup.com/?t=103714009400001&r=1&w=2
Markus Crafter is working on a package called XFC which is related to Merlin in that it aims to handle/automate the creation of meta data from legacy ECM component models (excalibur/xfc package). Leo Simons has also done some experimentation with Merlin running inside Oracle and I've working more on things like a Tomcat component, a set of PKI components, components supporting people, place and things (user centric view of a distributed service environment), components supporting process management, community management, and policy driven collaboration systems.
Cheers, Steve.
Hope that helps and gives you an idea where thinking is on this at this time.
Thank you ver much for infomation. It indeed helped me to understand things better.
Cheers, Steve.
Thanks,
Raj Saini
--
To unsubscribe, e-mail: <mailto:avalon-users-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-users-help@;jakarta.apache.org>
--
To unsubscribe, e-mail: <mailto:avalon-users-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-users-help@;jakarta.apache.org>
-- Stephen J. McConnell OSM SARL digital products for a global economy mailto:mcconnell@;osm.net http://www.osm.net -- To unsubscribe, e-mail: <mailto:avalon-users-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-users-help@;jakarta.apache.org>
