Hi Eric,
I'm currently not convinced about the POJO approach but I did not do any work with Pico/Nano, Hivemind or Spring ... :-)
The trouble with all of those discussions is
+) that choosing a IOC container is a matter of personal taste
+) the complexity does not disappear - it is either within the application code or the configuration file
+) that it adds no value to existing services and for the caller of the service, e.g. for a new and moderate complex J2EE project I would use Spring not because it uses a cool IOC framework with POJOs but for having a bunch of functionality solving a lot of my problems. And if I need a couple of Fulcrum services I would just write a YAAFI component for Spring.
Having said that I'm leaning towards embedding IOC containers within IOC containers as long as it is transparent to the caller of the service - which is unfortunately not the case for Turbine. It should be no problem to embed YAAFI into Hivemind or Spring ....
Cheers,
Siegfried Goeschl
Eric Pugh wrote:
I would like to see a migration to Fortess occur at some time as well. However, I think the lesson that the Turbine/Fulcrum land can take is that
depending on any one container is bad. Containers seem to come and go with
amazing regularity, and we shouldn't depend on any of them.
I am leaning towards any real code should be a POJO, with the appropriate interface layer for a specific container.
I like YAAFI because it works. I don't know that I would write an application
on it (although Siegfried would!), but I like that it fires up, runs the unit
tests, and then quits.
I wish we did have a unit testing strategy where we could test against ECM, YAAFI, and Fortress.
I think it boils down to someone stepping up and doing the work. It doesn't sound like anyone has any real objection to supporting Fortress. And moving from ECM + Yaafi to Fortress + Yaafi sounds like a good approach. Especially with Fortress actually having a 1.1 release available.
Eric
On Tue, 17 May 2005 10:22:05 +0200, Siegfried Goeschl wrote
Hi Peter,
my comments are below
Peter Courcoux wrote:
Siegfried,
I had a quick look at YAAFI and perused the excalibur lists over the weekend.
It looks like Fortress is still being actively developed, is used quite extensively and fits the style of component management required by turbine ( ie not wiring comoponents together but making them available in a similar manner to ECM).
Same for YAAFI ...
I also note that Fortress has cyclic dependency checking, the lack of which in ECM, was a worry to me in a recent project where I had a number of junior developers writing and using ECM managed components.This is a design problem and not a container problem ... :-) .... and YAAFI is actually unable to run services with cyclic dependencies.
It doesn't look to me like YAAFI has cyclic dependency checking and I think it might be worth looking at how we could use Fortress and what it would take to convert the fulcrum services to be usable in Fortress. It is more work but I'm thinking that biting the bullet now would have many advantages in the future.We already took a few bullets - the Turbine services were converted to ECM and then to Merlin thereby effectively stalling the Fulcrum project. I don't have a problem migrating the existing codebase to use Fortress but this involves the following steps
1) changing the access to the Avalon context for all services - not a big deal and YAAFI supports setting up the correct Avalon context based on the "componentFlavour" 2) writing role configuration files but I found nowhere a spec saying how to write such a file for Fortress - and I need to write a parser for it 3) sorting out the dependencies and adding them to Fulcrum/Turbine - Fortress requires around 20 JARs whereas YAAFI is happy with just two of them.
What do you think?+) making Fulcrum components compatible to Fortress is a good idea
+) using Fortress as default Avalon container is currently not on my list - but again this is my strictly personal opinion.
Cheers,
Siegfried Goeschl
---------------------------------------------------------------------Regards,
Peter
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-- OpenSource Connections (http://www.opensourceconnections.com)
