cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Disappointed about avalon usage
Date Wed, 01 Oct 2003 08:56:44 GMT

Michael:

A couple of comments - the issue of the Component interface was 
addressed 12-18 months ago with the introduction of the service 
sub-package in the framework.  The Component interface along with the 
entire component sub-package is now depricated.  The replacement 
org.apache.avalon.framework.service makes things *much* easier and 
eliminates many restrictions that exited in the past.  On the other 
hand, you comment concerning selectors reflect on something that 
continues to bug me.  I don't like selector sementics, and I think they 
should be removed from the framework (in their current form), but I 
don't have a migration stategy in mind.  Buttom line - in my personal 
opinion - selectors are a weak link in the framework container/component 
contract.

Stephen.

(Avalon developer).


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.
>
>  - Michael
>
>
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org




Mime
View raw message