You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Michael Lipp <mi...@danet.de> on 2003/10/01 09:49:26 UTC
Disappointed about avalon usage
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
Re: Disappointed about avalon usage
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
> 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).
Keep in mind that Fortress provides a way around the whole Selector
concept, and makes things sooo much easier to manage. We also hope to
add some compatibility layer of Fortress with Merlin so that you can
move forward.
The selector concept will eventually become obsolete like the component
package--but we are still looking at the different use cases surrounding
their use.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: Disappointed about avalon usage
Posted by Stephen McConnell <mc...@apache.org>.
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
Re: Server-side XForms (was Re: Disappointed about avalon usage)
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 01.Oct.2003 -- 02:07 PM, Michael Lipp wrote:
> And here is where XForms fits 100%. We simply use the (X)HTML with
> XForms UI-elements for the form as one of the parameters in the tool
> definition (i.e. you define a tool by combining the one generic
> implementation class with a specific HTML fragment). Into the HTML, the
> tool - when called - inserts the actual data and OUT parameters as a
> XForms model and then hands this to the XForms processor (at least
> that's the targeted scenario). Currently, we have a very, very small
> subset of the functionallity by simply applying a stylesheet with
> non-standard dynamic evaluations (to resolve the references to the model
> elements) to the mixture of HTML, XForms UI elements and XForms model,
> thus producing a displayable HTML form.
>
> So, I do not favour XForms in particular. But it is the only starting
> point that I have found that supports this scenario with runtime form
> definition. Maybe I have simply not understood XMLForms in Cocoon, but I
> have tried. And I am sure to have understood that you need JavaBeans
> corresponding to your forms and this rules out XMLForms for our
> scenario, because we must be able to create the form completely at run
> time (from the workflow description). And though maybe possible, I do
> not want to do something with dynamic code generation (for the
> JavaBeans), I need a fully interpreted solution for form creation.
>
> OK, this was a fast walkthrough and I hope I have made the problem
> clear. If you know of another approach to this, I would, of course, like
> to know about it.
Well, couldn't resist to mention the "simple" forms solution in Cocoon:
FormValidatorAction, SimpleFormTransformer, and
SimpleFormInstanceTransformer which allow for basic syntax validation
of submitted values, display of validation results, repeating form
elements depending on available data, form filling (e.g. with request
parameters), extraction of instance data.
The last two features allow to have instance data separate from the
form controls. All those components work on XML files (or input
modules, which, through XMLFileModule allows to access XML files
again...) And those are the features I like most about XForms.
But then, this is nowhere near the cool features of Woody and only
meant as a teaser or migration path for plain HTML forms. However, I
believe it works well for completely dynamic forms.
Have a look at the simple form processing example in 2.1.2 (better: CVS)
Sorry. Couldn't resist the temptation ;-)
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: Server-side XForms (was Re: Disappointed about avalon usage)
Posted by Michael Lipp <mi...@danet.de>.
> But this wasn't the real question: why XForms at all? Why use a
> client-side spec to constrain it in a server where it doesn't fit?
>
OK, here's the motivation. We have built a workflow engine
(http://wfmopen.sourceforge.net) that uses an XML based workflow
description language (XPDL).
Part of the definiton of a workflow is (better: may be) that a specific
activity is to be executed by a human. And there again it may be that
the action consists of providing some data, maybe based on the display
of other data. So the activity is implemented as a call to a tool that
displays some data in a form, lets the user edit or input some more data
and returns the result to the workflow engine.
Of course, we do not want to build a tool for every form. Rather we want
to have one generic tool that can take the form description as a
parameter. And we want to embed the form description in the workflow
description as part of the tool definition.
And here is where XForms fits 100%. We simply use the (X)HTML with
XForms UI-elements for the form as one of the parameters in the tool
definition (i.e. you define a tool by combining the one generic
implementation class with a specific HTML fragment). Into the HTML, the
tool - when called - inserts the actual data and OUT parameters as a
XForms model and then hands this to the XForms processor (at least
that's the targeted scenario). Currently, we have a very, very small
subset of the functionallity by simply applying a stylesheet with
non-standard dynamic evaluations (to resolve the references to the model
elements) to the mixture of HTML, XForms UI elements and XForms model,
thus producing a displayable HTML form.
So, I do not favour XForms in particular. But it is the only starting
point that I have found that supports this scenario with runtime form
definition. Maybe I have simply not understood XMLForms in Cocoon, but I
have tried. And I am sure to have understood that you need JavaBeans
corresponding to your forms and this rules out XMLForms for our
scenario, because we must be able to create the form completely at run
time (from the workflow description). And though maybe possible, I do
not want to do something with dynamic code generation (for the
JavaBeans), I need a fully interpreted solution for form creation.
OK, this was a fast walkthrough and I hope I have made the problem
clear. If you know of another approach to this, I would, of course, like
to know about it.
- Michael
Server-side XForms (was Re: Disappointed about avalon usage)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Dr. Michael N. Lipp wrote:
<snip/>
> My project aac-xforms (another approach to Coocon XForms) grew out of
> the desire to have the "standard" XForms in Cocoon. I'm still working
> on this project, but have currently very little time and so it is
> making little progress. Sometimes I look at chiba/chicoon and wonder
> if I should stop aac-xforms, but I still like my approach ;-).
>
> Concerning the server/client question of XForms, I think there will
> always be demand for a pure server side solution (or at least
> approximation, as you can obviously not fully implement UI event
> behaviour) until XForms is integrated in browser (which will not
> shortly - if ever - happen). Believe it or not, especially the large
> costumers of the company I'm working for are still hesitant about
> allowing JavaScript (bad) or user driven download of plugins (very
> bad) and "please do not propose a solution that requires our IT
> department to do installation of software on the clients".
I perfectly understand this and had similar experiences: convincing a
large customer to deploy a plugin on thousands of PCs is not a simple
thing to do.
But this wasn't the real question: why XForms at all? Why use a
client-side spec to constrain it in a server where it doesn't fit?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Disappointed about avalon usage
Posted by "Dr. Michael N. Lipp" <Li...@Danet.de>.
> Typo: Where/how is poolable *not* used as it should be ?
>
Sorry, it is really quite some time ago. It was something with DOM/SAX
handling. When I just looked through the code (2.0.4), the only thing I
could find was XMLByteStreamCompiler being generally used with "new
XMLByteStreamCompiler" although it implements Recycable (which I mixed
up with pooled in my previous mail, I think). You should probably forget
about this detail - if I come across it again, I'll send a note.
My project aac-xforms (another approach to Coocon XForms) grew out of
the desire to have the "standard" XForms in Cocoon. I'm still working on
this project, but have currently very little time and so it is making
little progress. Sometimes I look at chiba/chicoon and wonder if I
should stop aac-xforms, but I still like my approach ;-).
Concerning the server/client question of XForms, I think there will
always be demand for a pure server side solution (or at least
approximation, as you can obviously not fully implement UI event
behaviour) until XForms is integrated in browser (which will not shortly
- if ever - happen). Believe it or not, especially the large costumers
of the company I'm working for are still hesitant about allowing
JavaScript (bad) or user driven download of plugins (very bad) and
"please do not propose a solution that requires our IT department to do
installation of software on the clients".
- Michael
Re: Disappointed about avalon usage
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Sylvain Wallez wrote:
> Sorry, I don't follow you there? Where/how is poolable used as it
> should be?
Typo: Where/how is poolable *not* used as it should be ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Disappointed about avalon usage
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Michael Lipp wrote:
>> Now an important point is that you aren't disappointed by Avalon (its
>> concepts and the implied benefits), but by usage mistakes in a
>> particular usage of it. Am I right ?
>
>
> Clearly, this is a misusage. As Avalon is concerned in general, I'm
> still considering. I'm responsible for development projects with 3+
> developers. We are doing a lot with J2EE etc., so you couldn't call us
> unexperienced. Still, I have remained hesitant about adding Avalon to
> our "tool-box" because I have the feeling that the implications of
> this kind of design are very complex (the "mistake" being a
> confirmation of this) and that we would end up with an example of bad
> Avalon usage that wouldn't stand a review.
>
> I had to learn Avalon concepts when I started my XForms processor for
> Cocoon (http://aac-xforms.sourceforge.net)
Wow, never heard of this project before! That's interesting. What's the
status of this? And have you looked at Woody (I'm still dubious about a
server-side XForms implementation).
> and failed at various places, especially when I really tried to re-use
> pooled components from Cocoon (2.0.4, btw). It is not easy to really
> implement proper cleanup and it takes a lot of testing and I found
> that Cocoon often does not take advantage of a component being a
> pooled component and so there was little implicit testing and so some
> Cocoon components are buggy in this respect (sorry I cannot give you
> specifics, when I encountered this kind of problem, I simply switch to
> plain old "new" because I had my development goal in mind).
Sorry, I don't follow you there? Where/how is poolable used as it should be?
> The only thing I find really annoying is that I have to pass a logger
> into every class that is not a component (instead of simply declaring
> the logger as a static member like I do with log4j). As a result, I
> often used System.out for debugging and then deleted the statements
> when everything worked which is, of course, the wrong thing to do. I'd
> have to think of something there if I had to do a larger project with
> Avalon.
<other-people-please-do-not-read>
Let me tell you a secret: I also have a lot of non-Avalonized code, and
I wrote a LoggerFactory that provides static methods to get a logger. I
uses the same logger hierarchy as Cocoon (initialized in the servlet's
init method), so can be configured with the usual logkit.xconf. Et voilà ;-)
</other-people-please-do-not-read>
> Anyway, this is just because you asked me "publicly" and so here is my
> "public" response. I assume this is not the right list to discuss
> Avalon and I don't want to be flamed ;-)
Flamed? Why so? Explaining problems is the first step towards solving them!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Disappointed about avalon usage
Posted by Michael Lipp <mi...@danet.de>.
> Now an important point is that you aren't disappointed by Avalon (its
> concepts and the implied benefits), but by usage mistakes in a
> particular usage of it. Am I right ?
Clearly, this is a misusage. As Avalon is concerned in general, I'm
still considering. I'm responsible for development projects with 3+
developers. We are doing a lot with J2EE etc., so you couldn't call us
unexperienced. Still, I have remained hesitant about adding Avalon to
our "tool-box" because I have the feeling that the implications of this
kind of design are very complex (the "mistake" being a confirmation of
this) and that we would end up with an example of bad Avalon usage that
wouldn't stand a review.
I had to learn Avalon concepts when I started my XForms processor for
Cocoon (http://aac-xforms.sourceforge.net) and failed at various places,
especially when I really tried to re-use pooled components from Cocoon
(2.0.4, btw). It is not easy to really implement proper cleanup and it
takes a lot of testing and I found that Cocoon often does not take
advantage of a component being a pooled component and so there was
little implicit testing and so some Cocoon components are buggy in this
respect (sorry I cannot give you specifics, when I encountered this kind
of problem, I simply switch to plain old "new" because I had my
development goal in mind).
The only thing I find really annoying is that I have to pass a logger
into every class that is not a component (instead of simply declaring
the logger as a static member like I do with log4j). As a result, I
often used System.out for debugging and then deleted the statements when
everything worked which is, of course, the wrong thing to do. I'd have
to think of something there if I had to do a larger project with Avalon.
Anyway, this is just because you asked me "publicly" and so here is my
"public" response. I assume this is not the right list to discuss Avalon
and I don't want to be flamed ;-)
- Michael
Re: Disappointed about avalon usage
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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.
<snip/>
> 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.
Your analysis is right, and I also faced the exact same problem some
time ago (was with 2.0.4) when writing a SourceLessProgramGenerator to
have an XSP engine using only precompiled XSPs. I also found a that time
that a bit of refactoring quickly leads the GeneratorSelector to
disappear and be replaced by a simple HashMap.
I should go back on this and cleanup this package... or maybe you want
to send a patch ?
Now an important point is that you aren't disappointed by Avalon (its
concepts and the implied benefits), but by usage mistakes in a
particular usage of it. Am I right ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: over-componentization scenario
Posted by Stefano Mazzocchi <st...@apache.org>.
On Wednesday, Oct 1, 2003, at 13:36 Europe/Rome, Stephen McConnell
wrote:
> As a matter of principal - I have to make a comment here.
> There are assertion onf the Cocoon web site that imply some evil
> associated with "over componentization". I would like to take you up
> on this. Now - to give fair warning - I have specific ideas about
> what is and what is not a component. And I'm thinking in my mind that
> over-componentization of good components is a null-event .. it does
> not exist. However, I am trying to rationalize this with you
> assertions . Can you help me out here? I can confirm that I am an
> avid non-component developer - when appropriate - however - in my mind
> there is a definative point where something is a component as distict
> from an implementation object. That difinative point concerns
> publication and containment (in my view of the world).
>
> What I would like to know is what (in you view of the world)
> constitues an over-componentization scenario?
when you use a component and a simple regular class would have been
exactly as functional, easier to understand, future compatible.
over-componentization is an instance of over-design.
I was a big fan of early-on interface creation. I'm not anymore. I now
believe in incremental programming, darwinistic, you could say: change
things only when a need for change emerges.
or, to use XP terminology, "do the simplest thing that can possibly
work".
An example of overcomponentization in cocoon: the cache as a SAX
compilation strategy, the strategy could be pluggable, therefore, let's
create a sax compiler component and an interface that describes it.
After years, nobody ever implemented another instance of that
component. Componentization was not created by a real-life need, but it
was created by design elegance. This is, IMO, bad practice.
Since real-life needs are measurable, while design elegance is not, I
think the first is a much healthier driver for innovation, and,
moreover, results in less code to write, more readable code and simpler
systems.
Note, however, that there are places, in cocoon, where components *DO*
make sense (sitemap components, for example, where polymorphic behavior
is required by clear real-life needs!), but many components might be
replaced with regular classes with no lack of functionality.
Now, at the same time, incremental thinking suggests to start patching
only when a problem emerges and 'de-componentize' something is, again,
an elegance-driven concept, if the real need doesn't emerge.
So, right now, we are all set.... but if somebody has a problem with
how the componentization is done in cocoon and has a better solution
and does the patch, I'll be glad to see it applied.
--
Stefano.
over-componentization scenario
Posted by Stephen McConnell <mc...@apache.org>.
Stefano Mazzocchi wrote:
>
> 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.
Stefano:
As a matter of principal - I have to make a comment here.
There are assertion onf the Cocoon web site that imply some evil
associated with "over componentization". I would like to take you up on
this. Now - to give fair warning - I have specific ideas about what is
and what is not a component. And I'm thinking in my mind that
over-componentization of good components is a null-event .. it does not
exist. However, I am trying to rationalize this with you assertions .
Can you help me out here? I can confirm that I am an avid non-component
developer - when appropriate - however - in my mind there is a
definative point where something is a component as distict from an
implementation object. That difinative point concerns publication and
containment (in my view of the world).
What I would like to know is what (in you view of the world) constitues
an over-componentization scenario?
Stephen.
>
>
> If you want to submit patches to improve the situations, they will be
> welcome.
>
> --
> Stefano.
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Re: Disappointed about avalon usage
Posted by Stefano Mazzocchi <st...@apache.org>.
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.