Eric Pugh wrote:
Stephen,
I am going to dig into this over the weekend. One question I have is why seperate the API from the Impl... I understand from the standpoint that if you plan on having multiple implementations, then this is simpler. But what if you only expect to have a single implementation? Doesn't that mean you are making life more complex? Maybe this is more of a general design question versus usage with merlin question...
The separation of api and impl enables the sharing of services across classloaders. The classes containing the API need to be available in a classloader that is common to all "consumers" components and the "provider". Without separation, you are forced to push implementation classes up in a container hierarchy. That's not so terrible in and of itself, but then you now have the problem that any dependent service classes need to up there as well, and all of the dependent implementations need to be up there. End result - you loose potential isolation, and your deployment information looses any sense of modularity. Or more simply - you force yourself into a single big container.
As far as Merlin is concerned - the separation is not required. Its just that Merlin will provide facilities that leverage the isolation and modularity. For example, we may want to be able to declare different security policies on different containers. Keep in mind that in Merlin a container is basically the implementation strategy of a logical block and that implementation can be achieved through the active composition of existing blocks. As such, active seperation basically paves the way for more value from the container and greater potential for component reuse.
Also, can you provide a pointer to an example of merlin running inside of something else? I know Peter Courcoux has been developing a Merlin container for Turbine.. It would be nice to see some other implementations.
Take a look at the AbstractMerlinTestCase (written specifically to eliminate the dependency on the Turbine Test Container). The source file is in the package merlin/kernel/unit. The important stuff is done in the constructor and the sequence is basically:
* create the Merlin kernel context * use the context to create the Merlin Kernel * get the containment meta model from the Kernel * do what you want to the model (e.g. adding sub-containers) * the start the kernel
There are a couple of things not demonstrated in the current test case. These include resolution of an existing merlin installation and application of a custom configuration. I should have the configuration stuff completed in a couple of days.
Stephen.
Eric Pugh
-----Original Message----- From: Stephen McConnell [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 08, 2003 1:16 AM To: Avalon framework users Subject: Re: [RT] Attempt to simplify Fortress (long)
Eric:
I took a quick look at the fulcum components and decided to take a shot at migrating crypo to Merlin. First thing I did was to take out the Component interface and ComponentException referenes, dropped a few unused lifecycle interfaces (Contextualizable, and Startable).
I broke the package into two seperate Maven projects - api and impl (makes life a lot easier when sharing services across different classloaders). I added a few @avalon meta tags and a pre-goal to trigger meta-info generation using the avalon-meta plugin for Maven.
This left me with a broken test case because it was using the Excalibur Component abstract testcase. So I wrote an equivalent Merlin version (suficient to get things working). I created a container descriptor that gets auto loaded by the abstract merlin test case and updated your test case to use the Merlin variant.
Here are the results ...
[INFO ] (testcase.testUnixCrypt): ok [INFO ] (testcase.testClearCrypt): ok [INFO ] (testcase.testOldJavaCryptMd5): ok [INFO ] (testcase.testOldJavaCryptSha1): ok [INFO ] (testcase.testJavaCryptMd5): ok [INFO ] (testcase.testJavaCryptSha1): ok
The abstract testcase is a preliminary version and for the moment does not provide support for configuration of the components in the container. I used the lazy option of bundling a static configuration under a <classname>.xconfig resource with the component type.
Running the component under Merlin with debug enabled for the crypto package (including container sub-channels) generates the following:
$ merlinx target\classes -execute -config conf\config.xml
[INFO ] (kernel): installing: file:/${user.dir}/target/classes/ [DEBUG ] (crypto.crypto.appliance): assembly phase [DEBUG ] (crypto.crypto.appliance): deployment (singleton) [true] [DEBUG ] (crypto.crypto.appliance): new instance: 26779524 [DEBUG ] (crypto.crypto.appliance): applying logger to: 26779524 [DEBUG ] (crypto.crypto.appliance): applying configuration to: 26779524 [DEBUG ] (crypto.crypto.appliance): stage count: 0 [DEBUG ] (crypto.crypto.appliance): applying initialization to: 26779524 [DEBUG ] (crypto.crypto): initialize() [DEBUG ] (crypto.crypto.appliance): established: 26779524 [DEBUG ] (crypto.crypto.appliance): activated instance: 26779524 [DEBUG ] (crypto.crypto.appliance): decommissioning phase [DEBUG ] (crypto.crypto.appliance): component disposal: 26779524 [DEBUG ] (crypto.crypto.appliance): stage count: 0 [DEBUG ] (crypto.crypto.appliance): destroyed instance: 26779524 [INFO ] (kernel): dissassembly phase [DEBUG ] (crypto.crypto.appliance): dissassembly phase [INFO ] (kernel): disposal phase [DEBUG ] (crypto.crypto.appliance): disposal
I've posted a copy of the package on the following url for anyone interested. http://www.apache.org/~mcconnell/temp/turbine/crypto.zip
Don't hesitate to post any questions!
Cheers, Steve.
Eric Pugh wrote:
A very well written email! I have spent a fair amount oftime converting
old Turbine services into new Fulcrum componentscontainer. And at
(http://jakarta.apache.org/turbine/fulcrum) using the ECM
this point they all do work okay, but not great. There is a bit ofpoint I am
confusion about the roles versus config files etc. At this
trying to figure out "what next". What I would like to seeis a clear
document that says what my components should look like. Iunderstand that
ECM is old, I don't know where to go next.. Merlin? Fortress?compatibility... I think
To me, one of the banes of software is backwards
it leads to layers upon layers, each causing more cruft inthe code and
obfuscating bugs. In the open source world people find maintainingspecifically drawing a
backwards compatibility such a pain, that instead of
line and saying "This Won't Be Supported", they insteadstart a new project
with a new name so that they don't require backwardscompatibility. So, as
far as attempting to make old ECM components run well in more modernrather see a
containers, I feel that the effort is not worth it. I would
document that says "Merlin is where it's at" and "Here arethe steps to
update an ECM component to Merlin". And forget about the rest.so many people
As far as the class loader versus the file.. It seems like
have issues with custom class loaders interfering with otherclass loaders
that I would prefer to just have an avalon.xml file in theclasspath that
specified all the services.no current
Eric Pugh
-----Original Message----- From: Berin Loritsch [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 6:15 PM To: Avalon Developers List; Avalon framework users Subject: [RT] Attempt to simplify Fortress (long)
For the uninitiated, [RT] means "Random Thought". There is
are othercommitment 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
---------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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Stephen J. McConnell mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
