1. The interfaces from the instrument package should move into the org.apache.avalon.framework namespace.
Why would you make instrumentation part of the core of Avalon? That seems very wrong to me. I would rather see some flexible extension mechanism where things like instrumentation and management can be added easily. But wiring the notion of instrumentation in at the framework level doesn't seem right.
Why do you have interfaces for instrumentation anyway? I've never understood this myself. I have either used bytecode instrumentation, or now I can actually load a 30 line aspect dynamically if I want to profile apps in production. But I think you can effectively do the same with something like cglib.
yup. In many ways, avalon can be viewed as a "poor man's AspectJ" (though not really a fair comparison, as you get a level of control and transparency difficult to ensure in large aspect-based systems). Instead of the dynamic approach, avalon basically picks out a few common aspects and uses the more "normal/conventional" setup with interfaces.
The question is when your interfaces are becoming so uncommon they're either not worth the trouble or don't justify the 3 or 4k they add to the jarfile.
Are you trying to formalize instrumentation usage? What's to stop things Management and who knows what else from going into the core.
good point.
I think the core is great, if the default implmentatations were removed it would be even better. No down side to splitting them up as you can package your distributions in any fashion you like to provide convenience yet let more savvy users package as they please.
we talked about doing it for 4.1.4; not happening now but probably for 4.1.5. Of course it is trivial to downsize the jar if you're a "savvy user":
<exclude name="**/*Default*.java"/> <exclude name="**/Util.java"/> <exclude name="**/*SAX*.java"/> <exclude name="**/Wrapper.java"/> <exclude name="**/thread/**"/>
(and don't put the optional deps like logkit on the classpath)
I just think it becomes harder and harder to use the same base container when behaviour like async component management, instrumentation and component management are present at the core levels. Things get complex, no doubt, but the complexity should be optional.
yep. One way of looking at this is what you need is a way to modify/extend the lifecycle aspect of the code. Which is where the lifecycle extension work comes into play. Alternative setups include interceptors, chaining/buses, event-controlled IoC, big-ball-of-dynamic-mud or something like AspectJ. Most of those result in looser coupling (ie more of the "optional"), but also in more of the "complex".
cheers,
- Leo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
