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.
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>
