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
