The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....

[Siegfried Goeschl]

Hi Aaron, 1) Original Motivation for YAAFI 1.1) A few months ago I worked on a JSP/Struts web application for a customer and they needed to integrate a few external services over the time. I decided to go with Avalon components but I got frustrated with the various containers (Excalibur, Merlin), my inability to get them running and the amount of additional dependencies. The problem was not my frustration as external consultant (I get paid for that) but my customer would have plainly recjected the Avalon approach if adds too much complexity (they devil you don't know). To cover my a**  I coded a minimal Avalon container over night. 1.2) In my own company we have a Turbine application and a few services which could have been contributed years ago but the Turbine Service Framework is convoluted due to the monolithic approach of Turbine. We found out that the only stuff we used from Turbine were a few services and our own stuff. And we are sort of stuck to an old version of Turbine - well, not a big deal but we would have to migrate our own services. Or we take the Fulcrum approach which would fit nicely .... 1.3) After another failure with Merlin I decided to go with Avalon services and my minimal Avalon container. I contacted Eric Pugh if my quick-and-dirty implementation would be of interest. And I was plainly astonished that he said "yes"?!! 2) The Role of an Avalon Container In my opinion the various Avalon projects were mainly focused on the container implementation. We all love the toys were are implementing but for the rest of the world an Avalon container is a commodity. Nothing else - a tool to get a job done. An added value are the available services with test cases, documentation and automatic build. An Avalon container with a bunch of good services is a much better tool to get a job done ... :-) There is no "container to rule them all" - therefore YAAFI is per definition a plain and simple AvalonContainer. Writing YAAFI initially was a sort of personal requirement (to put it politely) but extending YAAFI to compete with Fortress or Phoenix is a no-brainer. This will not happen. 3) The Current State of YAAFI I will finish the contract context thingie tommorrow - then it should be possible to run any Avalon component with YAAFI. And yes, YAAFI is used in production environment at least in our company. I think Eric Pugh tinkered with Scarab - anyone else out there?! And after proper integration with Turbine there will be more production environments. 4) The Future of Jakarta Avalon Containers I see YAAFI as an approiate choice for command-line applications, small server applications and embedded Avalon container for Turbine and if you need more bells and whistle you still have other choices - you name them. And I would appreciate some sort of cross-project cooperation to achieve the following long-term goals +) ensure that the available Avalon services (Excalibur, Fulcrum, Xingu) run with Fortress and YAAFI +) promote Fulcrum as an Avalon Service project out of obscurity +) convince the Excalibur community that YAAFI is not an odd project of a lone hacker (which it is) to be ignored but as starting point to migrate over to Fortress 5) The Usual Disclaimer This is strictly my personal opinion since I have no idea what the rest of the community is thinking ( "They smoked and did inhale", "Avalon is dead", "Lets get rid of IOC Type 1 containers", "That was good book", ...) and I'm only a small committer. Maybe the Turbine/Fulcrum PMCs can shed some light on plans for the future .... hint, hint. Cheers, Siegfried Goeschl J Aaron Farr wrote: On Wed, 16 Feb 2005 09:44:18 +0100, Siegfried Goeschl <[EMAIL PROTECTED]> wrote: The usage szenario would be : you find a few funky Fulcrum services but they depend on a Merlin Avalon contract regarding the Context. If I understand it correctly you can't use the components directly since the blow up during contextialize() trying to access "urn:avalon:home" and "urn:avalon:temp". First off, we (Excalibur) need to fix up the context contracts. It should be much easier now that Avalon has disolved. If nothing else, we could look at having Fortress handle all previous context "standards". We have the same requirement for Turbine - if the Turbine service framework does not find a service it should ask all its children implementing ServiceManager. In this case it is not a big deal since this is the only sensible solution to provide container-transparent access to components. But in Excalibur land it has a rather akward semantic. Sounds like it would involve a change to the default ServiceManager or a new ServiceManager implementation. Siegfried, what was the original motivation for YAAFI? Was it the existance of multiple Avalon containers? Was it the number of jar dependencies? Is YAAFI intended to be used in a production environment? I'd like to see Fortress evolve to be simple enough that there wouldn't be a need for Yet Another Avalon Framework Implementation. Maybe Turbine's needs can help drive that.