cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Disappointed about avalon usage
Date Wed, 01 Oct 2003 11:10:23 GMT

On Wednesday, Oct 1, 2003, at 09:49 Europe/Rome, Michael Lipp wrote:

> Hi,
>
> having studied the avalon concepts some time ago, I just came upon a 
> point where I wanted to take advantage of them and failed. Let me tell 
> you why.
>
> I have a problem with filenames of Java files generated from XSPs 
> becoming too long. So I tracked processing down and found that if I 
> modified ProgramGeneratorImpl.getNormalizedName a bit, I could fix 
> this. In old times, I would have had to patch ProgramGeneratorImpl and 
> put in in the classpath before cocoon.jar or replace it in cocoon.jar.
>
> But we have Avalon. And ProgramGeneratorImpl is a component. So I 
> thought instead of that nasty patching, I simply write a new component 
> and change the configuration. GetNormalizedName is private, so I could 
> not derive and override in the new class, but of course, this is 
> perfectly legal, and I basically copied the code in my new class.
>
> But when I tried to compile my new class, I found that it needs access 
> to GeneratorSelector.addGenerator (from the same package) and that 
> this method is protected! :-(
>
> And GeneratorSelector is itself a component, so you cannot say that it 
> is an intimate helper of ProgramGeneratorImpl. What now? Of course, I 
> could have copied GeneratorSelector in my new package as well, but 
> where  may this end...
>
> So I went (half) back to the old times: I have a new class, but I had 
> to put this class in package 
> org.apache.cocoon.components.language.generator kind of "spoiling" the 
> original distribution after all.
>
> I admit, I have no great experience with Avalon. But to me it seems 
> that the moral of this is that anything designed as an Avalon 
> component should not use package visible methods of other classes 
> unless those classes are only very private helpers. Otherwise you do 
> not really get configurable components.

You are completely right.

Cocoon suffers from what I call "overcomponentization", or "use of 
avalon where a regular class would have made more sense". I think you 
found one spot and I also agree with your result at the end.

If you want to submit patches to improve the situations, they will be 
welcome.

--
Stefano.


Mime
View raw message