Wow - slow down - go read the instrument documetation.
I just went over all that this weekend :D
A lifecycle extension is two parts:
* an interface implemented by a component that represents a supplimentary stage (as distrinct from a work interface) * an implementation of a handler that is capable of supporting the stage using the contracts defined by the lifecycle package
its a case of terminology. I made the exact same seperation; the case I was making is that you can define a supplementary stage without the handler. The component requiring the supplementary stage doesn't care how it is handled, as long as it is handled. A container can implement support for that handling without a lifecycle extension package.
so it is impossible to define a generic way to handle lifecycle management from the container side, and also impossible to define a generic way to create plugins to assist in that management.
Correction.
It is possible - that was the objective of the project. That objective was reached. We have this working today.
agreed. Case of terminology again. It is "general" in that it can be used across multiple containers. Not in that it can be satisfactory successfully applied in every container.
Your assumption (example again) is that any container providing support for Instrumentable will do so by having an instrumentable "handler" or some kind. I can provide support for instrumentable in a container without having lifecycle.jar on my path. Just did so this weekend :D
MyContainerUtil extends ContainerUtil { setupInstrumentation( Object obj, InstrumentManager im ) { /* ... */ } }
cheers!
- Leo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
