excalibur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leif Mortenson <leifli...@tanukisoftware.com>
Subject Re: Instrument Manager package.
Date Thu, 17 Jun 2004 16:48:24 GMT
Mauro Talevi wrote:

>Hi Leif,
>Leif Mortenson wrote:
>>I was doing to start digging in and working on the Instrument packages.
>>But it looks like the Instrument Manager directory has been reworked.
>>This was done in the Avalon repository but I was wondering what the
>>thinking here is. Currently the maven build does not work as it appears
>>to still expect the source files to all be in the same directory. I can
>>fix it
>>but I want to make sure I am on the same page.
>why do you say the maven build does not work?
>in the latest svn repo, the following works fine for me:
>cd excalibur/instrument-manager
>maven multiproject:install
You mean I have to use the correct command!?!    Sorry I was doing
"maven jar:install".   Still coming up to speed with maven...  All my other
builds are still using ant.

>>Also it looks like the pool and thread packages have been broken up into
>>instrumented and uninstrumented copies of the components. Is this really
>>necessary? I fear that the two will quickly diverge and become a
>>maintenance nightmare. If a user does not wish to use instrumentation
>>then all they need to do is include the instrument jar, which is extremely
>>small. I think it would be wise to get rid of the uninstrumented versions
>>and go back to only having one copy of the source. This is akin to creating
>>a version of the classes which do not do logging... Thoughts?
>I agree on the need to not make the implementations diverge.
>alternatively to having to include the instrument jar when one does
>require instrumentation, one could have the instrumentable components be
>made to reuse the non-instrumentable ones in some way (eg extending) and
>add the instrument specific functionality.
>in this way the component functionality will be in one place only.
The problem is that the instrumentation is deep in the guts of the 
classes so that
they can instrument things like pool size gets, puts, blocks etc.  All 
things that you
would not want to expose.

Currently, the instrument jar is already required by ECM, Fortress, and 
So having it required by the pool classes as well does not require you 
to use any
extra jars.   Having renamed the classes which do implement 
instrumentation also
requires going back and modifying all of the code which uses the pools 
if I want
to continue making use of the instrumentation.   The non instrumented 
versions, if
anything are the new code.  If there is a naming conflict, they are what 
should be
given new names to maintain backwards compatibility.

The instrumentation code needs to get documented, something I am going 
to get
working on.   Hopefully once people understand it, they will be more 
using it.

Removing the instruments from code in the future is not out of the 
question, I
am just not clear on what is behind doing so now.


To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/

View raw message