You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2003/02/28 19:31:12 UTC
[PROPOSAL] restructuring of the instrument suite
This is a proposal for the restructuring of the instrumentation suite:
Current structure:
instrument
instrument-manager
instrument-client
Proposed structure:
instrument <-- no change
instrument-manger <-- move AltRMI classes to
instrument-monitor/altrmi/server
instrument-monitor
- altrmi/server <-- two classes from instrument manageer
- altrmi/client <-- content of instrument-client
Any objections?
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] restructuring of the instrument suite
Posted by Stephen McConnell <mc...@apache.org>.
Leif Mortenson wrote:
> Stephen McConnell wrote:
>
>>
>> This is a proposal for the restructuring of the instrumentation suite:
>>
>> Current structure:
>>
>> instrument
>> instrument-manager
>> instrument-client
>>
>> Proposed structure:
>>
>> instrument <-- no change
>> instrument-manger <-- move AltRMI classes to
>> instrument-monitor/altrmi/server
>> instrument-monitor
>> - altrmi/server <-- two classes from instrument manageer
>> - altrmi/client <-- content of instrument-client
>
>
> Is there any reason not to just make the instrument-manager build skip
> the altrmi
> classes if they are not present. This is what logkit and other
> projects do.
Hi Leif:
There are two good reasons. The instrument manager has dependencies on
avalon-framework the instrument package. These dependencies can be
correctly expressed both in a build and in terms of manifest
dependencies. The AltRMI adapters have a very different dependency
model - they are dependent on the instrument manager and on AltRMI. By
separating out the adapters into separate builds we ensure that we can
introduce consistent jar dependency declarations. Furthermore, it
separates the release status of the manager from whatever adapters are
developed in the future (whereas the current approach forces re-release
of the manager with the introduction of a new adapter).
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] restructuring of the instrument suite
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Stephen McConnell wrote:
>
> This is a proposal for the restructuring of the instrumentation suite:
>
> Current structure:
>
> instrument
> instrument-manager
> instrument-client
>
> Proposed structure:
>
> instrument <-- no change
> instrument-manger <-- move AltRMI classes to
> instrument-monitor/altrmi/server
> instrument-monitor
> - altrmi/server <-- two classes from instrument manageer
> - altrmi/client <-- content of instrument-client
Is there any reason not to just make the instrument-manager build skip
the altrmi
classes if they are not present. This is what logkit and other projects do.
However, as things are now, there is no run time dependency on the
altrmi jars.
If the altrmi connector is not specified in the instrument configuration
file, then
those classes are never loaded. This is the same as other jars like logkit
which are built in an environment which contains all available jars. But at
runtime, it is not required that all of those jars be in the classpath
if the
relevant features are not being used.
Cheers,
Leif
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] restructuring of the instrument suite
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> so, what's the resolution on this proposal? To me it sounds like a
> "not accepted, we keep things as-is with good reason"....
>
> Steve, are you objecting to releasing instrument-manager (currently at
> RC2) when it contains the two altrmi-referencing classes?
Leo:
I'm not objecting.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] restructuring of the instrument suite
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
> so, what's the resolution on this proposal? To me it sounds like a "not
> accepted, we keep things as-is with good reason"....
>
> Steve, are you objecting to releasing instrument-manager (currently at
> RC2) when it contains the two altrmi-referencing classes?
>
> I think it is doable to provide support for these classes. They've been
> tested to work with altrmi 0.9.2 (available from
> http://cvs.apache.org/viewcvs.cgi/avalon-excalibur/lib/ only atm I
> think); I think they can be upgraded later to work with altrmi 1.0 with
> minimal work).
They work with AltRMI 0.9.3 (the package renamed version of 0.9.2 that
is in Incubator).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] restructuring of the instrument suite
Posted by Leo Simons <le...@apache.org>.
so, what's the resolution on this proposal? To me it sounds like a "not
accepted, we keep things as-is with good reason"....
Steve, are you objecting to releasing instrument-manager (currently at
RC2) when it contains the two altrmi-referencing classes?
I think it is doable to provide support for these classes. They've been
tested to work with altrmi 0.9.2 (available from
http://cvs.apache.org/viewcvs.cgi/avalon-excalibur/lib/ only atm I
think); I think they can be upgraded later to work with altrmi 1.0 with
minimal work).
- LSD
Stephen McConnell wrote:
> Leif Mortenson wrote:
>> Berin Loritsch wrote:
<stuff/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] restructuring of the instrument suite
Posted by Stephen McConnell <mc...@apache.org>.
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: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] restructuring of the instrument suite
Posted by Peter Donald <pe...@realityforge.org>.
On Sat, 1 Mar 2003 06:19, Leif Mortenson wrote:
> 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.
+1
--
Cheers,
Peter Donald
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] restructuring of the instrument suite
Posted by Berin Loritsch <bl...@apache.org>.
Leif Mortenson wrote:
>
> 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...
CLient side is not as critical as Manager and Instrument. You can
take your time on that. The docs are a bit more critical. I can
only do so much and it is crunch time at the office.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] restructuring of the instrument suite
Posted by Leif Mortenson <le...@tanukisoftware.com>.
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.
This should not affect the dependency list of projects that require the
IM any more than the optional dependencies of LogKit do
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.
> 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...
Cheers,
Leif
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] restructuring of the instrument suite
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>> This is a proposal for the restructuring of the instrumentation suite:
>>
>> Current structure:
>>
>> instrument
>> instrument-manager
>> instrument-client
>>
>> Proposed structure:
>>
>> instrument <-- no change
>> instrument-manger <-- move AltRMI classes to
>> instrument-monitor/altrmi/server
>> instrument-monitor
>> - altrmi/server <-- two classes from instrument manageer
>> - altrmi/client <-- content of instrument-client
>>
>> Any objections?
>
>
> 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.
As things stand - yes - at least on the client side. As you stated, the
instrument manager has a nice seperation but things are not so elegant
on the client - that's why I suggested the expidient route of repackaging
the client as the AltRMI client monitor. This would give us (Leif?) some
more time to refactor the transport indepednent aspects into a real
instrument client package.
>
> 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.
The minimum approach is to simply explude the alt rmi classes from the
instruemnt manager jar and build a seperate jar container the two
classes. This at lteast would enable seperation of jar depedencies.
>
> On Client, I would have to check, but I estimate that it is
> very similar.
I've browsed around with the idea of putting in place a IIOP solution
however what I saw on the client was not seperated (as per the server).
Leif's recent message is clarifying some things that suggest the
sitution if better than my initial assesment (classes not used etc.).
>
> Leif did a good job of separating out the transport--at least
> on the server side/manager side.
I agree.
Cheers, Steve.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL] restructuring of the instrument suite
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
> This is a proposal for the restructuring of the instrumentation suite:
>
> Current structure:
>
> instrument
> instrument-manager
> instrument-client
>
> Proposed structure:
>
> instrument <-- no change
> instrument-manger <-- move AltRMI classes to
> instrument-monitor/altrmi/server
> instrument-monitor
> - altrmi/server <-- two classes from instrument manageer
> - altrmi/client <-- content of instrument-client
>
> Any objections?
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.
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.
Leif did a good job of separating out the transport--at least
on the server side/manager side.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org