excalibur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <lsim...@jicarilla.org>
Subject Re: Instrument Manager package.
Date Thu, 17 Jun 2004 18:12:42 GMT
Leif Mortenson wrote:
> Hi all,

Hi Leif!

> 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.

This was part of a big effort by Niclas to get excalibur to build with a 
single command, and to have all of it built by gump. In absence of 
people like you (who know the package internals well) he did a good job 
of sorting out the dependencies. Which was a mess.

> 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 don't know.

I would like to wait with changing any of this back until we have 
excalibur building using gump again (right now gump is building the 
version in cvs). I really don't want to go back to a complex build that 
continuously breaks.

Excalibur used to be a really big mess dependency-wise, and this is now 
less of an issue. I'd like to keep it that way.

> 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 thought that there were just a few classes in pool with 
instrumentation, and those were moved out for dependency management reasons.

[lsimons@giraffe instrumented]$ pwd
/home/lsimons/svn/asf/excalibur/trunk/pool/instrumented
[lsimons@giraffe instrumented]$ find . -name '*.java'
./src/java/org/apache/avalon/excalibur/pool/ValidatedResourceLimitingPool.java
./src/java/org/apache/avalon/excalibur/pool/InstrumentedResourceLimitingPool.java
[lsimons@giraffe instrumented]$ cd ../impl/
[lsimons@giraffe impl]$ find . -name '*.java' ! -path '*test*'
./src/java/org/apache/avalon/excalibur/pool/HardResourceLimitingPool.java
./src/java/org/apache/avalon/excalibur/pool/SingleThreadedPool.java
./src/java/org/apache/avalon/excalibur/pool/DefaultObjectFactory.java
./src/java/org/apache/avalon/excalibur/pool/DefaultPoolController.java
./src/java/org/apache/avalon/excalibur/pool/ResourceLimitingPool.java
./src/java/org/apache/avalon/excalibur/pool/DefaultPool.java
./src/java/org/apache/avalon/excalibur/pool/SoftResourceLimitingPool.java
./src/java/org/apache/avalon/excalibur/pool/AbstractPool.java

as you can see, no duplicated classes between the two. Same should be 
true for the thread package.

In summary: Niclas broke things out for a good reason (in order to 
figure out the dependency chain), I'm okay with changing things again, 
but only if the dependency graph stays clean and we use gump to verify that.

cheers,

- LSD

---------------------------------------------------------------------
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/


Mime
View raw message