geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "n. alex rupp" <rupp0...@umn.edu>
Subject Re: [newbie] JMX Console - where to start?
Date Wed, 03 Sep 2003 16:38:42 GMT
Comments inline, bottom trimmed. : )

----- Original Message -----


> N. (or Alex?),

Please call me Alex : )

> The only thing that worries me is that it sounds like you're
> building a fairly generic console that can show any type of JMX resources
> (Geronimo, Tomcat, whatever).  When I've seen that sort of thing before,
> it's been a big list of fairly obscure entries:

I understand and agree with you.  That isn't my goal.  There will be generic
display components which will *hopefully* be added to MX4J as the default
JMX console, but on top of these will lie a set of display components
customized for Geronimo.

>
geronimo.j2ee.management:j2eeType=JDBCResource,name=Oracle,J2EEServer=server
>
geronimo.j2ee.management:j2eeType=JMSResource,name=OpenJMS,J2EEServer=server
> ...

> I don't think this ideal for the Geronimo console, but you also go
> out of your way to say you won't be contructing anything that looks like a
> vendor console.

I think perhaps you misunderstood my point.  The web console will look as
good as (if not better than) any other vendor console and offer better
functionality (go team go).  What I meant was that I won't be reverse
engineering the UI components from BEA or IBM's proprietary software because
I believe we can do better and because I'm uncertain about their patents in
the area.  It's a matter of good sense and principle that I've avoided
studying their software and I'd feel more comfortable if developers could do
the same, but I'm not going to lie awake at night worrying about it or go
into hysterics on the lists ;-)

Note this one for example:
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=/netahtm
l/search-adv.htm&r=3&p=1&f=G&l=50&d=ptxt&S1=Weblogic.PPDB.&OS=SPEC/Weblogic&
RS=SPEC/Weblogic

I know most people don't bother looking for patents before they start
writing code, but I've written a few stories on the sort of trouble we can
get into when big companies decide not to play nice.  I'd just prefer to
play it safe (out of respect for the competition and because I know we can
do better anyway).

That doesn't mean ours will not be a professional looking (and functioning)
console.  You guys have a ton of good ideas which I'd love to implement,
such as the stuff below.  : )

> Can you give an idea of what the user interface would be
> like?  I'm thinking of something like this:
>
> Geronimo
>  + Server
>   + Applications
>     + SomeApplication
>      ...

That all makes sense to me.  I know we'll be able to read the deployment
descriptors to find the managed resources and arrange them in such a way if
we decide to.  We're also going to show dependencies and relationships, so
the users can tell which pieces depend on what.  For my part, I plan to
present a set of different views.  One will be a "debug view" that shows the
alphabetized MBean stack (work in progress), another an "applications view".
Another a "configuration view".  There might be value in building a complete
client-side tree view of the entire system, but I'd like to keep the
presentation simple for the moment.

> I suspect we'd need to customize the UI a bit for Geronimo to make
> this happen.  For example, I'd like to present JDBC pools as "Databases"
> even if they're implemented with JCA under the covers and so on.  And it's
> fairly traditional to have a tree on the left and screens to operate on
> the individual items on the right, but this is sounding a lot like a
> vendor console.  Is this compatible with your vision for the web console?

Not sure about tree view on the left at this time, but I'll consider it.  If
we want to present JDBC pools as "Databases" (as an example) and operate at
a higher level, we can certainly do that.  We can also build a detailed help
menu so that people can click on "what's this?" and get details and
documentation on the different components--if the users and the developers
agree that those features are necessary.

> Finally, will your console operate on the JSR-77 objects through
> the MEJB, or will you be sticking to "pure JMX"?  If the latter, will the
> same JSR-77 components be available?

I'd rather stick to the JMX interface until I know more about the
requirements, but as things are situated now, delegating the JSR-77
components to a different formatter would be very simple.  The components
are already available through the MBeanServer interface.  The trick at this
point is just presenting them in a more readable fashion.

Great questions : )  I've got a lot more to say on the matter, so let's
continue the discussion.

--
N. Alex Rupp (n_alex_rupp@users.sf.net)



Mime
View raw message