On Mon, 2003-02-24 at 04:29, Leo Sutic wrote: > > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Leo Simons > > > > Finally, this is our "last chance" to move the instrument > > package into > > org.apache.avalon.framework space, if we want to do that. > > Last time we > > talked about it we didn't want to IIRC. Anything changed? From the > > perspective of the instrument package, it makes sense. > > OK, let's run a quick vote for this in order to gauge consensus. > > Proposal: > > 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. Are you trying to formalize instrumentation usage? What's to stop things Management and who knows what else from going into the core. 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. I'm just thinking of using the same container for micro devices being able to run at a level like phoenix by layering functionality over a small core and the core seems to be getting bigger as instrumentation and management seem to be getting close reaching the core level. 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. > 2. The instrument package may be release separately or bundled > with the framework jar. We don't decide on this now. My non-binding +1 > Regarding exactly which interfaces in (1), let's postpone that as > well - I just want to know if there's any consensus to put > instrument in framework. We can decide on the exact way of putting > it there later. > > /LS > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
