> Does it really matter that much that it is not in commons? I agree, the Avalon lifecycles are perfectly fine where they are now. A project does not have to be in commons for it to suddenly become available for other projects to use.
Nicola's comment about turbine-commons was also right on the point. Commons-logging does not have any lifecycle support. The Turbine community wants to move towards lifecycles as there seems to be the general consensus that it makes life much easier. The Avalon LogEnabled interfaces give us logging via a lifecycle _regardless_ on the backend implementation of the logging, which can very well be commons-logging/log4j, as I understand it. Also note that I'm operating under the assumption that I suspect not every has realized, but that in the current T2/Torque/Fulcrum, commons-logging/log4j is the way to go. (So in reference to your changed logging code, Henning, I think we'd all agree to go ahead and commit it as it'll be an improvement over the existing approach). Avalon/LogEnabled/etc. only comes into play when we start talking about the potential re-write with T3/T4/Summit, which will, as proposed, be completely Avalon-based. And I'd think that along with the T3/T4/Summit release in it's LogEnabled/Avalon-ized form, we'd have a Fulcrum do a corresponding major release where even though the current version used in T2/Torque it is not at all coupled to Avalon (e.g. it uses commons-logging/log4j), the next mature release would be in the form of Avalon components (and so use the lifecycles which is the whole point to this Avalon/T4/Summit thing) that inherently use LogEnabled. (Note that if the next version of Fulcrum gets merged into the Avalon component repository or perhaps better yet becomes wrappers in the Avalon component repository for commons-xxx projects that are not Avalon-coupled, I think it'd be for all the better). - Stephen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
