You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2002/12/10 19:39:31 UTC
[INSTRUMENTATION] integration question
Berin Loritsch wrote:
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>Based on the build file there appear to be the following dependencies.
>>
>>
<snip>
>> excalibur-instrument 0.3 UNRELEASED
>> excalibur-instrument-manager 0.3 UNRELEASED
>> excalibur-instrument-manager-interfaces 0.3 UNRELEASED
>>
>>
>
>Yep, we need to release these. I think only the implementation
>stuff has really changed, the interface is fairly constant.
>
A question for Pete and Berin - is is possible/reasonable to isolate
instrumentation depedencies into a lifecycle extension handler? Just
looking at the instrumentation doc pages it would appear so on an
initial read - however the doc is more focussed on the client usage
point of view as distict from the container perspective.
Any thoughts ?
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [INSTRUMENTATION] integration question
Posted by Leif Mortenson <le...@tanukisoftware.com>.
> A question for Pete and Berin - is is possible/reasonable to isolate
> instrumentation depedencies into a lifecycle extension handler? Just
> looking at the instrumentation doc pages it would appear so on an
> initial read - however the doc is more focussed on the client usage
> point of view as distict from the container perspective.
Should be absolutely no problem. Components which implement
Instrumentable are designed to function correctly even if the container
is not Instrument aware.
The only drawback with doing this is that several components of Fortress
itself are currently instrumentable. It currently will instrument the
lookup and releasing of components even if those components are not
themselves instrumentable. In order for that to work, the instrument
jars must always be available. If they are always available, then there
is no reason to change Instrumentable to an extension lifecycle. Thoughts?
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [INSTRUMENTATION] integration question
Posted by Berin Loritsch <bl...@citi-us.com>.
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Sent: Tuesday, December 10, 2002 1:40 PM
> To: Avalon Developers List
> Subject: [INSTRUMENTATION] integration question
>
>
>
>
> Berin Loritsch wrote:
>
> >>From: Stephen McConnell [mailto:mcconnell@apache.org]
> >>
> >>Based on the build file there appear to be the following
> dependencies.
> >>
> >>
>
> <snip>
>
> >> excalibur-instrument 0.3 UNRELEASED
> >> excalibur-instrument-manager 0.3 UNRELEASED
> >> excalibur-instrument-manager-interfaces 0.3 UNRELEASED
> >>
> >>
> >
> >Yep, we need to release these. I think only the implementation
> >stuff has really changed, the interface is fairly constant.
> >
>
> A question for Pete and Berin - is is possible/reasonable to isolate
> instrumentation dependencies into a lifecycle extension handler? Just
> looking at the instrumentation doc pages it would appear so on an
> initial read - however the doc is more focused on the client usage
> point of view as distinct from the container perspective.
>
> Any thoughts ?
Definitely doable.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>