directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [eve] merlin wrappers
Date Fri, 02 Jul 2004 21:33:35 GMT
Vince, Steve,


> > We can still benefit from this to allow hot
> > swaping if the Avalon wrapper components are in separate jars.  Is this
> > a correct assumption?
> The avalon components "could" be in separate jars but they will be 
> sharing the jars containing the apis and pojos.  This means that the 
> only thing you gain is the ability to swap out the adapter (and I really 
> can;t see why that would be useful).
Not exactly.  Your adapter component, which from now on I'll just for
simplicity refer to as the adapter, may or may not use the default POJO
implementation.  The "adapter" may not be an adapter at all or may be an
adapter to a component implementation that is not the default POJO
implementation in the frontend.jar.  So the frontend.jar falls back to
being the api jar in situations where the default POJO is not being

So the potential to swap out adapter components is still there.  One
version of the adapter may implement interface Foo, and it may wrap the
POJO Bar which implements Foo as well.  Another version of the adapter
may wrap another object of class Xyz which implements Foo.  So we can
swap out one component for the other and be ok hot swapping this way.

Effectively everything in the frontend.jar by containing POJO
implementations with their service interfaces is an API.  Because at the
end of the day the component developer chooses whether or not some
default implementation is worth using for them or not.  This API can be
used by anyone including us while writing wrappers for various
containers.  We may opt to use the default POJO provided if we want to
as a part of the API.  It is completely up to the framework specific
component developer.

> The main interest in hot-swapping is the ability to bring in a different 
> implementation and once established, re-sync a service to point to the 
> the new implementation (without taking down dependent services).  Merlin 

Not a problem at all.

> 3.3.1-DEV provides support for the loading and unload of containers 
> dynamically, add, the ability to modify and remove component models 
> without a restart (there still of another layer needed to handle service 
> availability).

That's great and should be very exciting. 
> What this means is that we want to be able to swap out eve version X.Y 
> with eve X.Z - and that means demounting an implementation classloader 
> containing the pojo classes while maintaining the api classes in the 
> classloader (because these are referenced by consumers).
We can still have this by keeping a single frontend.jar with the service
interfaces, and their POJO implementations in the same jar.

> > The second thought was what the heck am I going to do with the different
> > conf/ directories I have for integration tests on the Merlin wrappers
> > using Merlin-Unit.  Right now having each component in its own project
> > makes it easy to have its separate conf/ directory to test the component
> > with.  The top level compoent for the frontend called the 'frontend
> > component' will have the final block.xml for the server's
> > configuration.  What are your opinions and thoughts here?  
> My current thinking is that we should structure thing as follows:
>     /frontend
>        /api <------ * absolutely minimal external dependencies
>                     * interface, exceptions
>                     * immutable data objects
>        /impl <----- * pojos, implementation classes, resources
>        /merlin <--- * definition of a container that exports
>                       services exposed by the api and handles
>                       deployment based on internal component
>                       definitions
>  From the point of view of a classloader what this means is:
>      |-------------------------|
>      | eve api                 |
>      |-------------------------|
>      | merlin adapter          |
>      |-------------------------|
>      | eve impl                |
>      |-------------------------|

This does look rather nice.  I especially like the part about the api
jar having minimal dependencies.  However I don't think this outwieghs
at least in my mind the points I've made above.

Although this does not look as well structured I'm leaning more towards
the following:


This makes me feel like I'm bouncing between extremes.

If you guys (Vince, Steve, and others) really feel more aligned towards
going the way of the api, impl, adapter separation then I may reconsider
but lets discuss this a little more please.  No matter how we decide to
go, this time I really want to know we're doing the right thing.  


View raw message