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...
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. 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 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
