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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Apache Excalibur Project -- URL: http://excalibur.apache.org/
