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): disposalI'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 of time converting old Turbine services into new Fulcrum components (http://jakarta.apache.org/turbine/fulcrum) using the ECM container. And at this point they all do work okay, but not great. There is a bit of confusion about the roles versus config files etc. At this point I am trying to figure out "what next". What I would like to see is a clear document that says what my components should look like. I understand that ECM is old, I don't know where to go next.. Merlin? Fortress?
To me, one of the banes of software is backwards compatibility... I think it leads to layers upon layers, each causing more cruft in the code and obfuscating bugs. In the open source world people find maintaining backwards compatibility such a pain, that instead of specifically drawing a line and saying "This Won't Be Supported", they instead start a new project with a new name so that they don't require backwards compatibility. So, as far as attempting to make old ECM components run well in more modern containers, I feel that the effort is not worth it. I would rather see a document that says "Merlin is where it's at" and "Here are the steps to update an ECM component to Merlin". And forget about the rest.
As far as the class loader versus the file.. It seems like so many people have issues with custom class loaders interfering with other class loaders that I would prefer to just have an avalon.xml file in the classpath that specified all the services.
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 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: [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]
