avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject [RT] Attempt to simplify Fortress (long)
Date Tue, 07 Oct 2003 16:14:58 GMT
For the uninitiated, [RT] means "Random Thought".  There is no current
commitment to anything in this email other than trying to start a conversation
to provide a good direction.  That means, for all you users out there, this
is the perfect time to chime in.

The bottom line is that I want to make Fortress the perfect transition tool
from ECM to Merlin.  As a result there are some steps that I need to take.
The first step I attempted was to get some agreement on a description language
for meta data in the source code (i.e. the @avalon.component type tags).
Unfortunately, as discussions somewhat broke down and things weren't adequately
specified by the time Fortress was originally released, all the tags that
Fortress used have some changes to them.

Rather than dwell on the past (esp. since my recollection of the order of
events very well may not be correct), I want to see about moving forward.
Let me start with where we are, and how we got here.

The Present
-----------
We have several containers that represent different concepts at the time.
First, there is the now antiquated ECM.  It works, kindof, but to tell the
truth, it has some issues.  For instance, the ECM relies on a combination of
a "roles" file and marker interfaces to manage component instances.  Not
to mention that the ECM is one component manager shared with all the components,
which means that the synchronization overhead in that beast can slow down
operations.

Fortress was originally written to address two issues: the reliance on marker
interfaces, and the heavy synchronization in the ECM.  As a result, the
Excalibur Event package was born with new asynchronously managed pools for
components, and the roles file format was changed to list the "component
handler" that would be used for a particular component.  Now, whent that
information was not present, it would fall back to the ECM approach of marker
interfaces for compatibility's sake.  Also it introduced some semantics to
help wean people from the Selector based code.  We can now access components
by an interface name with an appended component name.  It works quite well,
but Fortress is transparently compatible with ECM code that follows the
convention of appending the word "Selector" to the interface name.  That way
your existing components would still work (compatibility again), but your
new components would be able to take advantage of the new feature.

At the same time, work was being done on both Phoenix and Merlin.  Both of
those containers provide a more robust meta-information layer that allows you
to embed your component meta-information directly in the source code.  This
has proven to really improve code maintainability and portability.  It is a
win/win situation.  After a while Fortress adopted a crippled version of the
meta-info layer, but there are some issues with it.

Currently, we are working on porting all the important features of Phoenix
over to Merlin, so that we can still run the existing code all on one container.
We will also be (eventually) providing a compatibility layer for Fortress, and
hense ECM based code.  As an interim step, I want to make it easier to migrate
up from Fortress.

Where We Go from Here
---------------------

I want to integrate the new Avalon Meta package with Fortress.  That means that
there will be some changes to your source code if you were using Fortress meta
information, and a change in the tool that you would use to collect that meta
information.  However, with the new Meta package, there is no need for the old
Roles file or RoleManager interfaces as well as no need for the MetaInfoManager
and associated interfaces.  They would have to be removed.

I don't believe anyone has created any implementations for those items other
than what is already part of Fortress.  Please correct me if I'm wrong.  That
said, I would like to remove them from the picture.

There are some differences in the way that the Avalon Meta Info package pulls
the component meta info from JAR files, which begs the question of whether
Fortress needs to directly control the classpath or not.  I wanted to have
Fortress operate without having to scan the JARs.  For that to work I had a
special "services.list" file which listed all the services, and the associated
entries in the META-INF/services/ directory with a list of the implementing
components.  It worked pretty well for Fortress as it would also recognize
components higher up on the classloader food chain.

We can make the simple ANT tool that specifically does this much, which is what
the Fortress tool started out as.  Alternatively, we can create a special
FortressClassloader that you would be required to load all your components with.
The question is what is best for our users?  Again if there are other
alternatives which I am not aware of, please bring them to the table.  Again,
this is a question of what is easiest to deal with for our users.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message