Leo Simons wrote:
Stephen McConnell wrote:
Current blocker issue is excalibur-instrument, which ECM and fortress require, but which kinda depends on altrmi, which is unreleased. Also, we need some docs on instrument, and Steve is unhappy with some of the code IIUC. We might get to more showstopper issues in the cornerstone dependency tree, can't tell until we're done :D
As far as the cornerstone-scheduler package is concerned there are no "blocker" issues. The dependency relative to the insrumentable suite only concerns the excalibur-instrument package which is independent of instrument manager and instrument client. The issues I have raised concern the need to separate out the transport in the instrument-manager package into a separate build - and the need to either make the instrument client transport independent or repackage it as a altRMI specific instrument client. Non of these issues impact the excalibur-instrument package.
IMV it makes absolutely no sense to release excalibur-instrument and not release excalibur-instrument-client and excalibur-instrument-manager, so the distinction doesn't matter. Right?
The Client Contract -------------------
The excalibur-instrument package contains the Instrumentable interface and a couple of Instrument classes, the InstrumentManager interface plus a few other client side things). This package does not dictate how an Instrumentable object handler is established - it simply declares the contract through which instruments can be exposed. The subject of instrument and its relationship to framework came up presumably because of the fact that ECM and Fortress include Instrumentable as a potential lifecycle stage. I mentioned that this could be abstracted out by dealing with the instrumentable stage as a lifecycle extension. In such a scenario, a component declares that it has a requirement for instrumentation handling (using meta info in Merlin or roles files in Fortress). The container is then responsible for establishing the handler to service the lifecycle stage.
As such I don't see any obsticle concerning a release of this package.
The Implementation ------------------
The excalibur-instrument-manager package contains an implementation of an instrument manager. It can be broken down into two things:
a) the instrument manager itself b) a remote monitoring service
The instrument manager has been implemented such that the remote monitor can be handled independnetly of the manager. A moritor has been implemented based on the AltRMI package. This monitor is made of two classes in the excalibur-instrument-manager package, and all of the content in the current excalibur-instrument-client package.
The instrument manager IMO is at candidate status once the remote monitoring functions are seperated out. The ideal scenario would be the delivery of a local monitor as part of the default package solution (i.e. a monitor that is colocated with the manager).
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
