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?
I'd go with Merlin. That's where new stuff is going.
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.
Understandable. Also keep in mind projects like Cocoon who have hundreds of components to upgrade. If they could do it a little bit at a time, then they would be much more likely to upgrade to the new containers. It takes time to upgrade things--esp. frameworks.
The old ECM based components are still usable, they just need to declare their meta information differently. At least that is the first step. After that, components need to be weaned from the ServiceSelector/COmponent** concepts. Fortress is the layer that will facilitate that process. Although, FOrtress *can* be used in Merlin so that you can get that layer.
What I want to do though is to remove the old roles file and have Fortress use a compatible meta info format with Merlin. That way as you are done with the upgrade process, FOrtress can be moved out of the picture. Sort of a transitional thing.
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.
:)
What Fortress does right now is this:
It specifies a services.list file that is found as a classloader resource. That lists all the services in the META-INF/services folder that you can expect the implementation classes from.
I guess that the implementations is the most important thing. So as long as Fortress has a list of implementations that will be used in a system, that should be good enough. It wouldn't need to be an Avalon.xml file.
If you do have an Avalon.xml file, what types of things would you expect
to find there? I know Merlin has a kernel.xml file, so I want to see if
what you expect is somehow along those lines.
--
"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]
