directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [eve] merlin wrappers
Date Fri, 02 Jul 2004 18:46:00 GMT
Alex Karasulu wrote:
> Steve,
> 
> Quick question for ya.  I just finished the consolidation of the Eve
> interfaces and pojo services into a single maven project.  This has the
> SPI interfaces for all the components and the default service
> implementation as a POJO only (non-Avalon specific component).  I moved
> all the merlin wrapper projects into their own area.  Do you think its
> worth it to keep the Merlin wrappers for each component separate? 

No benefit.  I would consolidate the this down to a single Merlin 
adapter for the front-end and another for the backend.

> The reason why I ask this is because of thoughts that came my way while
> consolidating.  First Merlin probably will have the ability at some
> point to hot swap blocks because of the attention to detail with respect
> to class loading schemes.  

It's already possible.

:-)

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

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

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

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

WDYT?

Cheers, Steve.


> Alex
> 
> 
> 
> 


-- 

|---------------------------------------|
| Magic by Merlin                       |
| Production by Avalon                  |
|                                       |
| http://avalon.apache.org              |
|---------------------------------------|

Mime
View raw message