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 Fri, 18 Jun 2004 03:52:52 GMT
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/


Mime
View raw message