Hi Peter,
Thoughts below :-)
Peter Courcoux wrote:
Hi Siegfried,
Thoughts below :-
Siegfried Goeschl wrote:
Hi Peter,
regarding the decision of choosing an Avalon container
+) ECM is dead
Agreed.
+) Merlin/Metro was never intended as embeddable Avalon container hence the problem with embedding it
Agreed.
+) Fortress is a valid choice but requires some work
OK
+) YAAFI is used for Fulcrum builds the last 6 months
I apologise for not having looked at YAAFI. In my ignorance I have some questions :-
Can we embed YAAFI as a service in turbine to replace ECM?
Is this the right way to do it?
How do you use YAAFI with turbine?
In the YAAFI source tree there is a "contrib" directory which contains code for setting up YAAFI within Turbine. I need to check if it works with Turbine 2.4 CVS HEAD. And I use YAAFI in a Turbine 2.2 application for nearly a year. Technically it is a copy-cat of the existing TurbineAvalonComponentService.
Having said that
+) there is no need to deprecate ECM based services since they all run with YAAFI
+) we use YAAFI and Fulcrum in production for serveral products now
Fine.
One last thought. Should we really be writing our own service framework or using one written for us. If we use our own, it adds a burden of maintaining it in the future. If Fortress is being actively developed, should we try to use that instead so we gain the benefit of not having to maintain our own. Can you summarise the advantages of using YAAFI over Fortress. Hivemind seems to have a following as well, but I haven't looked into that either. Do you know anything about it?
For background information about writing YAAFI checkout http://www.mail-archive.com/[email protected]/msg01251.html and all the other messages in the thread.
Comparing YAAFI with Fortress:
+) it is a light-weight Avalon container only depending on the two Avalon Framework libraries and nothing else.
+) it is able to run Avalon services written for any Avalon container - many Avalon services are not portable across Avalon containers
+) it supports reconfiguration of individual or all services either by monitoring the configuration files or triggering it through the application
+) it comes with an automated build, documentation, tutorial, regression tests and a test coverage of 75% - I hate to say it but YAAFI might be in a better shape than Fortress
Regarding HiveMind - it is a different approach of an IOC container using "Constructor Dependcy Injection" or "Setter Dependcy Injection" whereas Avalon relies on using interfaces. Choosing an IOC container is a matter of personal taste but a sticky decision. Changing over to HiveMind requires rewriting all Fulcrum services therefore it is not an option. If you have some hours to spare/waste you can read the dev mailing list of the JAMES community - just check out POJO - they invest a huge amount of time and energy to replace the Avalon Phoenix container with something else using POJOs (Plain Old Java Objects).
Conclusion:
+) Fulcrum and Turbine in their current incarnation require an Avalon container
+) There are a few Avalon container out there - ECM, ECM+ being used in Cocoon, Fortress, Phoenix, Loom, Plexus, Metro andYAAFI
+) I agree that maintaining an Avalon container within Fulcrum is not a brilliant idea but there is no free lunch or "there is no container to rule them all"
Regards,
Peter
Cheers,
Siegfried Goeschl
Peter Courcoux wrote:
Siegfried,
I think Eric Pugh and myself were the last people to work on the 2.4 codebase. As far as I am concerned one major issue remains which is that we are still using ECM as the container for Avalon style components. I think that we need to make a decision on which container to use and then embed it, deprecating the ECM based service. I know lots of work has been done on YAAFI but have not looked at it myself. Is this a reasonable option? I have lost track of Fortress but this was the option we were favouring when we last had time to look.
As an aside, have you seen this :- http://www.theserverside.com/articles/article.tss?l=IOCandEJB
There is some work to be done in continuing the refactoring of the RunData interface and implementation. I would like to effectively replace RunData with PipelineData but keep a deprecated RunData option for backwards compatibility. I'm not sure how long this would take but I don't think it is too much work.
That said, I have 2.4 in use in production, and it seems stable.
I agree with you it would be nice to work towards a release.
I'm at home at the moment so I'm not always at my desk, but I am periodically on #turbine irc channel if you want to chat.
Eric, do you have anything to add?
Regards,
Peter
Siegfried Goeschl wrote:
Hi folks,
are there any plans for a Turbine 2.4 M2 release?! Personally I would like to use the Fulcrum components instead of Turbine components ... :-)
Cheers,
Siegfried Goeschl
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
