I'm not sticking to Avalon. All I can say is that I've successfully used
Avalon to build a flexible server for document processing using the ECM
container (same that Cocoon is currently using). I loved to work with it,
especially after I was able to rewire the whole application at a
customer's site by only changing the XML configuration files. I didn't
have to change one line of Java to adapt the application to the
unsupected requirements found there.

I'm open to investigate other possibilities, even to simply try to work
without any outside help. What I find important is to have a way to
configure FOP using XML in a flexible manner, to have something that
helps us split up FOP into the right set of components, to have
exchangable components, to have FOP easily integrate with other packages
such as Cocoon.

I'm still thinking that we can do without a sophisticated container such
as Merlin, even ECM. The basic Avalon patterns established my Avalon
Framework already provide an interesting environment. I'm sure that even
Stefano and Pier would agree to that. They simply see different
requirements specifically targeted at Cocoon. FOP is surely something
different. But if we find something better, I will fully support it.

Well, let's have an eye on what's going on in Cocoon-land, but let's
also not blindly follow what they're doing.

On 28.03.2004 18:07:15 Glen Mazza wrote:
> Jeremias, I reached your conclusion yesterday in doing the logging 
> conversion (I'm only 2/3rds there right now):  namely, to keep Avalon 
> for the time being for the non-logging components, but just to replace 
> its logging component with Commons-Logging.  It was just in doing the 
> conversion yesterday that I first noticed that we were using Avalon for 
> other things (even after switching to C-L, it will still be in about 
> 10-15 classes over a few packages), namely the configuration that you 
> mention.  I also agree in not switching away from the Avalon 
> configuration unless there is something better in Commons--*** or 
> something better we can do ourselves.  I haven't studied configuration 
> (hence am not very knowledgeable about it), and it is not among my 
> priorities--other team members have thankfully been taking the lead on 
> configuration.
> Also, if there's another feature you like from Avalon, we can always use 
> it.  To me, Avalon is now just another library, like the Commons--*** 
> libraries.  It's just that FOP won't be living and breathing Avalon 24/7 
> anymore--we'll use certain parts of it where it's better than 
> Commons--*** libraries, but not just blindly using it "because it's 
> Avalon".  The entire 30-40 email Cocoon thread on "building on stone" 
> was not much of a confidence builder in adopting the latter 
> philosophy--email after email, the team had little good to say about 
> Avalon as an application framework, and is now considering painful 
> contortions [1] to liberate themselves from it.
> Thanks,
> Glen
> [1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108016162526312&w=2

Jeremias Maerki

Reply via email to