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:[EMAIL PROTECTED]
