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

[Siegfried Goeschl <si...@it20one.at>]

Might be of interest ....

-------- Original Message --------
Subject: 	The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Date: 	Thu, 17 Feb 2005 11:33:12 +0100
From: 	Siegfried Goeschl <si...@it20one.at>
Reply-To: 	siegfried.goeschl@it20one.at
Organization: 	IT20one GmbH
To: 	Turbine Developers List <tu...@jakarta.apache.org>, Excalibur 
Developers List <de...@excalibur.apache.org>
References: 	<00...@sagunto> 
<42...@it20one.at> 
<C1...@apache.org> 
<42...@it20one.at> <7a...@mail.gmail.com>



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
><si...@it20one.at> 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.
>
>  
>