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.
The problem is that the instrumentation is deep in the guts of the classes so thatAlso 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.
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 Phoenix.
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 comfortable
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.
Cheers, Leif
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Apache Excalibur Project -- URL: http://excalibur.apache.org/
