Leif Mortenson wrote:
Berin Loritsch wrote:
The only concern I have is that the Client and the Manager (i.e.
the client and server) portions using the AltRMI transport will
be largely duplicated code between RMI implementations, SOAP
implementations, SNMP implementations, etc.
My thoughts originally had been to create various connectors within the IM project and then have them all be conditionally built the same way we do with optional classes in the Logkit project. Keeping them all in the IM project is really the only home for them that makes any sense in my opinion.
I agree with the "home" principal - I just disagree with the logic of bundling adapters with the manager (refer earlier email on reason why).
This should not affect the dependency list of projects that require the IM any more than the optional dependencies of LogKit do
Problem is that sooner or later logkit will need to sorted out as well. The practice is not something to consider as a "best-practice" - in fact is simply the easiest approach but complicates things when your actually managing jar dependency computationally and is error prone as we have witnessed in the past.
I think there has been confusion because the ECM and Fortress have both been including Altrmi as if they were required.
The important thing -- if you want to abstract out the transport is to seprate out the AltRMI specific portions:
On Manager, it is two classes--all in their own package.
On Client, I would have to check, but I estimate that it is
very similar.
Actually only 1 class. The other is deprecated and has been for quite
a while. Most likely it could be deleted.
InstrumentManagerAltrmiConnector.java is the only one that is needed.
Ouch - one class makes my case look superficial! The case concerning jar dependency management does not change - but the question has to be asked ... is it work the trouble?
Leif did a good job of separating out the transport--at least
on the server side/manager side.
The client side is not quite so clean. I was not too worried about it as it is
a stand alone application. But as it sounds like there is a desire to make
it work with other platforms, I am going to need to go in and clean that part
of it up. Most of the "sloppy" code is in the Menu code. And that is actually
not being used at the moment. Free time has unfortunately been a rarity
the last few months. (Apologies for the lack of progress documentation
wise etc.) So I don't want to promise to get it done right away. It is on my
list though...
The client side is where I ran into problems - could not figure out how I would go about connecting a IIOP transport in as the AltRMI stuff appear to be spinkled around and in some cases I couldn't locate what was happening where (e.g. the Menu class). The above comments help - given a little restructuring and cleanup I thingk it would be worthwhile revisiting the IIOP scenario.
Cheers, Steve.
Cheers, Leif
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
