You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@excalibur.apache.org by Leif Mortenson <le...@tanukisoftware.com> on 2004/06/17 03:12:05 UTC
Instrument Manager package.
Hi all,
Still trying to come up to speed with SVN, but thanks for all the work
getting things moved over.
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.
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?
Cheers,
Leif
---------------------------------------------------------------------
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/
Re: Instrument Manager package.
Posted by Leif Mortenson <le...@tanukisoftware.com>.
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
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: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: Instrument Manager package.
Posted by Mauro Talevi <ma...@aquilonia.org>.
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
> 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.
Cheers
---------------------------------------------------------------------
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/
Re: Instrument Manager package.
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 18 June 2004 11:52, Leif Mortenson wrote:
> The circular dependencies are actually only present in the tests.
> The actual jar
> dependency tree is completely linear.
> Instrument->ECM,Fortress
> Instrument->Pool->ECM,Fortress
> Instrument->InstrumentManager->ECM,Fortress
Sorry, tests was only part of the picture.
I broke out the UnitTest parts of ECM into its own subproject, as that created
cyclic dependencies in just about all parts. But it wasn't this, it was
indeed a compile time problem.
I can't recall the exact details (other than it was 4 or 5 degree away), but
looking at the picture above, it could have something like
Instrument->IM->Fortress->Pool->Instrument
(Although I have a vague memory that AltRMI was part of the loop as well).
I would need to go back and check out the commit logs and some other stuff to
refresh my memory.
Anyway, I think it is fairly irrelevant to hypothesize about, I did what was
required and what my abilities allowed for, so let's get on with the future.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
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/
Re: Instrument Manager package.
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Niclas,
All the work you put into cleaning up the circular dependencies is
appreciated.
I know how much of a pain that can be having done so a couple times in
the past.
The circular dependencies are actually only present in the tests.
The actual jar
dependency tree is completely linear.
Instrument->ECM,Fortress
Instrument->Pool->ECM,Fortress
Instrument->InstrumentManager->ECM,Fortress
The problem is that the testcase project requires ECM, and it is used by
Pool's tests.
To resolve this, I had set up the full ant build to run in two
passes. It would
first go through and build the jars for all of the sub projects, then it
would make
a second pass through running the tests. It does not sound like
something like
that is possible with Maven. (Not that it was ever a great thing to be
doing in
the first place) The solution is probably to do what you have started,
going
through and moving problematic tests into their own sub projects.
I just went back and checked. The instrument project is only
dependent on
Framework for all of its classes and tests. Even there, it is only a
single class,
the AbstractLogEnabledInstrumentable class. This ends up being the parent
class of most instrumented components.
As for Alt-RMI, I have agreed for a while that it should probably go.
Currently it is the only way for the Swing based Instrument Client to
connect
to the InstrumentManager. When the altrmi versions are identical both
on the
client and server then it actually works quite while. AltRMI was well
thought
out and quite easy to use. The problem is when the versions are even
slightly
different, the underlying protocol gets into a loop of sending errors
back and
forth about not understanding each others messages. This does not
affect the
server application, but the client is never able to complete its connect
cycle.
The first step in being able to remove AltrRMI was to create another way
of connecting. I had that done about a year ago by implementing an HTTP
based connector. It uses a very light weight sessionless HTTP server to
handle all requests, so this does not have any new dependencies.
The HTTP connector works great and is what I have been using to work
with instrumentation for quite some time. It is able to serve both
HTML and
XML content very efficiently. The HTML is for users connecting with a
browser, but the XML was implemented to be a replacement for AltRMI
as the protocol used to communicate with the Instrument Client. It is
just a
matter of getting the work done in the client.
Once that is completed, I see no reason why the AltRMI connector could
not be removed from the Instrument-Manager jars completely. I doubt that
it is being used for any other purpose.
It is important to note however, that even now, the Instrument-Manager's
dependency on AltRMI is only at compile time. The jars are not needed
at run time if the AltRMI connector is not specified in the IM's
configuration
file. None of my projects have included them for quite some time. So,
for example, there is absolutely no reason why pool or component need to
include altrmi jars in their lists of dependencies.
As to other suggested changes, I am open to discussion. There are
a few things
that I would do differently were I to completely redesign the API. Most
of the
changes are in the IM rather than the public Instrument API so they
should be
possible without requiring changes to components. A lot of thought went
into it
but almost no API ends up perfect the first time around. You always
learn once
it is put to use.
Cheers,
Leif
Niclas Hedhman wrote:
>On Thursday 17 June 2004 09:12, Leif Mortenson wrote:
>
>Mauro already answered the 'build concern'. Quick note, I was very concerned
>that avalon-excalibur didn't build in its entirety, and not from a single
>point of build invocation. Hence the big effort in a package that I
>personally have no investment in.
>"xml-util" remained a problem. The JVM crashes on my machine, and the closest
>I got to a conclusion was classloading (XML apis) in conjunction with
>testcase (IIRC). It is probably still in a non-fully-buildable state.
>
>
>
>>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?
>>
>>
>
>There were a lot of mess in Excalibur, prior to my and Stephen's fairly large
>clean-up somewhere around March IIRC...
>
>1. There was a few cyclic dependencies, and one rather 'long chain' involving
>the instrumented packages.
>
>2. instrument itself have (had?) a dependency on Alt-RMI, which sits in a
>semi-limbo/beta/half-dead state in the incubator. It was concluded that such
>dependency was not entirely healthy.
>
>
>
>>I fear that the two will quickly diverge and become a maintenance
>>nightmare.
>>
>>
>
>I agree with the sentiment of this conclusion. However, without the proper
>help to resolve the cyclic dependencies, as well as the 'un-healthy'
>dependency on Alt-RMI, I did what I could...
>
>
>
>>This is akin to creating
>>a version of the classes which do not do logging... Thoughts?
>>
>>
>
>I think better SoC principles can be applied and everything goes away.
>1. The components and parts are instrumented.
>2. The instrument package have a proper SPI/connection interface.
>3. Alt-RMI connectivity is a SPI implmentation.
>
>
>Cheers
>Niclas
>
>
---------------------------------------------------------------------
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/
Re: Instrument Manager package.
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 17 June 2004 09:12, Leif Mortenson wrote:
Mauro already answered the 'build concern'. Quick note, I was very concerned
that avalon-excalibur didn't build in its entirety, and not from a single
point of build invocation. Hence the big effort in a package that I
personally have no investment in.
"xml-util" remained a problem. The JVM crashes on my machine, and the closest
I got to a conclusion was classloading (XML apis) in conjunction with
testcase (IIRC). It is probably still in a non-fully-buildable state.
> 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?
There were a lot of mess in Excalibur, prior to my and Stephen's fairly large
clean-up somewhere around March IIRC...
1. There was a few cyclic dependencies, and one rather 'long chain' involving
the instrumented packages.
2. instrument itself have (had?) a dependency on Alt-RMI, which sits in a
semi-limbo/beta/half-dead state in the incubator. It was concluded that such
dependency was not entirely healthy.
> I fear that the two will quickly diverge and become a maintenance
> nightmare.
I agree with the sentiment of this conclusion. However, without the proper
help to resolve the cyclic dependencies, as well as the 'un-healthy'
dependency on Alt-RMI, I did what I could...
> This is akin to creating
> a version of the classes which do not do logging... Thoughts?
I think better SoC principles can be applied and everything goes away.
1. The components and parts are instrumented.
2. The instrument package have a proper SPI/connection interface.
3. Alt-RMI connectivity is a SPI implmentation.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
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/
Re: Instrument Manager package.
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 18 June 2004 13:03, Leif Mortenson wrote:
> Leo, Niclas,
> I have been going through the dependencies of the various projects and
> do not see
> where there would be any dependency problems created by merging the
> pool-instrumented into pool-impl, and thread-instrumented into
> thread-impl packages.
> It looks like the dependency loops were all cleaned up by breaking the
> component
> package up into component, testcase and component-tests.
:o)
I leave it to you guys. I am only here to shed any additional light, if
needed, to the changes made.
A lot of the motivation was referred to the AltRMI (compile time dependency is
bad enough), and if you take that out, and people are generally positive to
instrumentation, then I think you are in good position....
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
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/
Re: Instrument Manager package.
Posted by Leo Simons <ls...@jicarilla.org>.
Leif,
Leif Mortenson wrote:
> Leo, Niclas,
<snip/>
I think you're now more up to speed on the dependency issues than me or
niclas :-D
Please give me saturday to get us built by gump (or someone else could
do that ;), and then by all means, yes, please, finish the cleanup!
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/
Re: Instrument Manager package.
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Leo, Niclas,
I have been going through the dependencies of the various projects and
do not see
where there would be any dependency problems created by merging the
pool-instrumented into pool-impl, and thread-instrumented into
thread-impl packages.
It looks like the dependency loops were all cleaned up by breaking the
component
package up into component, testcase and component-tests.
There is nothing in the dependency trees that I can find that would
cause any loops by
merging the Instrumented versions back into their originals. I know
that there
used to be so this is a credit to all of your hard work breaking things up.
Here are the dependency paths that currently exist in the packages involved:
(They can be skipped if you want. More comments below.)
instrument
Direct: none
Indirect: none
External: framework-api, framework-impl
instrument-spi
Direct: instrument
Indirect: none
External: framework-api, xml-apis
instrument-impl
Direct: instrument, instrument-spi
Indirect: none
External: framework-api, framework-impl, xml-apis
pool-api
Direct: none
Indirect: none
External: framework-api
pool-impl
Direct: pool-api
Indirect: none
External: framework-api, framework-impl, commons-collections,
concurrent, junitperf
pool-instrumented
Direct: pool-api, pool-impl, instrument
Indirect: none
External: framework-api, framework-impl, commons-collections,
concurrent, junitperf
i18n
Direct: none
Indirect: none
External: none
logger
Direct: i18n
Indirect: none
External: logkit, framework-api, servletapi, log4j, javamail, jms, xml-apis
component
Direct: logger, instrument, instrument-spi, instrument-impl, pool-api,
pool-impl, pool-instrumented,
Indirect: i18n
External: logkit, framework-api, framework-impl, commons-collections,
concurrent, serletapi, junit
thread-api
Direct: none
Indirect: none
External: framework-api
thread-impl
Direct: thread-api, pool-api, pool-impl
Indirect: none
External: framework-api, framework-impl, commons-collections, concurrent
thread-instrumented
Direct: thread-api, thread-impl, pool-api, pool-impl, instrument,
pool-instrumented
Indirect:
External: framework-api, framework-impl, commons-collections, concurrent
By the way, what does the "spi" in instrument-spi stand for? I had
originally broken
the instrument-manager into two jars because a connecting altrmi client
did not need
to have access to the full api. If I am going to wipe out altrmi, then
a lot of this could
probably be further cleaned up and simplified.
Cheers,
Leif
Leif Mortenson wrote:
> Leo Simons wrote:
>
>> Leif Mortenson wrote:
>>
>>> 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.
>
>
> Agreed. If it is possible to clean up the dependency tree amongst the
> tests however
> then remerging the pool code would be desirable.
>
>>> 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 fear that the two will quickly diverge and become a
>>
>> I thought that there were just a few classes in pool with
>> instrumentation, and those were moved out for dependency management
>> reasons.
>
>
> There are only a few with instrumentation. The problem is that the class
> ResourceLimitingPool used to be instrumented. It is widely used in my
> code.
> That class was copied as InstrumentedResourceLimitingPool and the
> original
> had all of its instrumentation removed. This is the naming change
> that I was
> referring to. If possible, I would like to get this worked out
> before a release.
> Once that happens it gets more and more difficult to change back.
>
>> [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/
>
>
> <snip>
>
>> 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.
>
>
> Ok, I will look into how that can be done.
>
> Cheers,
> Leif
>
>
> ---------------------------------------------------------------------
> 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/
>
>
---------------------------------------------------------------------
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/
Re: Instrument Manager package.
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Leo Simons wrote:
> Leif Mortenson wrote:
>
>> 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.
Agreed. If it is possible to clean up the dependency tree amongst the
tests however
then remerging the pool code would be desirable.
>> 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 fear that the two will quickly diverge and become a
>
> I thought that there were just a few classes in pool with
> instrumentation, and those were moved out for dependency management
> reasons.
There are only a few with instrumentation. The problem is that the class
ResourceLimitingPool used to be instrumented. It is widely used in my code.
That class was copied as InstrumentedResourceLimitingPool and the original
had all of its instrumentation removed. This is the naming change that
I was
referring to. If possible, I would like to get this worked out before
a release.
Once that happens it gets more and more difficult to change back.
> [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/
<snip>
> 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.
Ok, I will look into how that can be done.
Cheers,
Leif
---------------------------------------------------------------------
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/
Re: Instrument Manager package.
Posted by Leo Simons <ls...@jicarilla.org>.
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/