avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: roadmap info needed
Date Wed, 26 Feb 2003 23:23:31 GMT

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

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message