All, I've been following the latest threads, and just thought I'd jump in with two small comments.
= 4.2 vs. 5 = Some have said that "of course 4.2 is incompatible with 4.1, you don't expect to use nio in a Java 1.3 environment, or a 2.3 servlet in a 2.2 environment, do you?". Which is correct. If the minor version number increases, you can expect backwards compatibility for clients, but of course not for providers. But we're all in the business of developing providers. Which is why versioning in Avalon-land is perceived a bit different. A minor version change in framework is, for example, if you add a method to ExceptionUtils. The general opinion, as I remember it, is that a component-container contract change is a *major* version change. The fact that Serviceable/ServiceManager was a minor change should be written up as an exception. Above all, since contract changes impact container developers, they should be made in consensus with the most important container developers (Merlin team, Excalibur, Cocoon, etc.) Since there is no reasonable way of fixing the underspecification of the 4.x versions without altering the framework, I think Niclas, Stephen et al should switch to Avalon *5*, and just start cutting cruft left, right and center. You know you'll end up with a better result that way. *And* it will give you the room you need to experiment. = Constructor Injection = The null constructor/constructor with parameters issue is easily solvable, just thought I'd state the obvious in writing here: A component may use either constructor dependency injection, bean-style dependency injection, or ServiceManager lookup dependency resolution. Then define the requirements for each one separately. Then define how the container will react when a component has both a null constructor and one with parameters: The container will first see if there is a constructor that takes any parameters. If it finds one, it will shoot up the component according to <<reference to constructor injection lifecycle>>. If not, it will scan the methods for methods with signature setX (X x), where X *may* be a dependency (absence of meta makes this a bit of hit-and-miss). If ti finds any, it will <<blah blah blah>>... And so on... /LS --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
