hi,
cross-post to eemgmt and jboss-dev.
see at the end...
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Juha-P Lindfors
|Sent: Thursday, December 28, 2000 5:56 AM
|To: jBoss Developer
|Subject: Re: [jBoss-Dev] JMS Topics for monitoring
|
|
|
|
|On Thu, 28 Dec 2000, Bordet, Simone wrote:
|> For a client is easier to subscribe to a specific topic, instead of
|> searching somewhere for the right selector, isn't it ?
|
|That depends on whether the client/users model is exactly the same as
|ours, that is, if the separation of topics we create is exactly
|what he is looking for.
|
|With several topics we "hard code" the information channels from the
|server, with one topic channel we leave it to the client to modify the
|information channel to their specific needs. For me the latter approach
|seems more flexible, as it is easier to combine the information from
|several parts of the server based on a single selector instead of creating
|several selectors for several topics. For an example, think of a situation
|where you want to monitor the server usage based on a login ID.
|
|> I have in mind a JBossJMSMonitoring interface with only public
|final static
|> in it, so that the client can know which properties we set in
|messages, what
|> do you think ? (lots of constants, anyway, and difficult to mantain...)
|
|Yes that's a good idea. Although I think the name of the interface could
|be simpler :) Maybe just org.jboss.monitor.MonitorConstants or
|MonitorProperties.
|
|> Better yet, collect in the admin GUI all properties of all
|messages and give
|> clients a GUI way to select only specific properties, and so filter
|> messages; but from API point of view ?
|
|Yes, selecting the messages based on properties is a feature that advanced
|admin tools should provide. Also being able to query these properties from
|the server is required for a generic J2EE server admin tool --> which
|means we would need an API (not just model) --> JSR77's domain.
|
|-- Juha
|
bad ju-ju, I went to bat with jsr77 on the topic of a generic "J2EE" server
admin tool and it seems it is outside the scope.
The group 77 scope is just at the model layer only.
You are right in saying that a discovery mechanism, in your case through the
properties discovering and filtering on the JMS topics, is necessary for
portable tools. You have one schema based on JMS, andy and myself are
looking at a simple EJB one (home lookup and findbypk), today we already
provide one with JMX.
Each tool will need to know the underlying propagation mechanism, which is
fine for now it seems. The API and naming standardization is not here yet,
only a model. You are on your own when it comes to the naming discovery of
these. JSR77 will not cover this.
marc
|
|
|
