geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: [newbie] JMX Console - where to start?
Date Wed, 03 Sep 2003 13:21:38 GMT
N. (or 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:

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.  Can you give an idea of what the user interface would be
like?  I'm thinking of something like this:

Geronimo
 + Server
  + Applications
    + SomeApplication
      + EJB JAR
        + Session Beans
        + Entity Beans
          ...
      + WAR
        + Servlets
          ...
  + Resources
    + Messaging (JMS)
    + Databases (JDBC)
      + Oracle JDBC Pool
      + PostgreSQL JDBC Pool
    + Mail
    + J2EE Connectors
      ...
 + Advanced (Server Components)
   + Boot
   + Deployment
     ...

	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?

	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?

Aaron

On Wed, 3 Sep 2003, n. alex rupp wrote:
> Hey, guys.
> 
> There isn't any documentation on this console yet, save for that which is
> provided within the code and a few correspondences in the MX4J archives and
> now below.  I only spent a few days working on it, but I've been thinking
> about the JMX console and management interface for several months.
> 
> Sorry I haven't been posting much lately.  I have a friend from Moscow whose
> grandparents just won permanent US resident status through a lottery.  Since
> they've been subsistence farming in Tashkent for 20 years they leapt at the
> chance to retire here in the States with their grandson.  But unfortunately
> my friend was about to leave for a two year graduate program in Toronto.  I
> promised him I'd look after them and convinced my roommates to let them live
> here at our house.  They don't speak any English yet but holy cow that lady
> can cook!
> 
> Also, the network at my house has been mysteriously dropping packets and was
> due for a complete overhaul.  That's taken up quite a bit of my time in the
> last few days, so I apologize for not answering this thread earlier.
> 
> <nar:wikiable>
> 
> The JMX web console exists to simplify the operation of the Geronimo server
> by providing the end user with an intuitive, flexible, lightweight interface
> to the JMX manageable resources inside Geronimo.  It also must be
> maintainable, so that future generations of developers can keep it alive.
> The user interface must be intuitive or it fails its first objective.  If it
> is flexible users will be able to customize its basic appearance to suit
> their needs--and we'll be able to change the look if we ever want to. CSS is
> heavily relied upon for this.  The UI must remain lightweight (thin client)
> in order to rapidly evolve to the changing needs of the users.  Therefore,
> all logical formatting mechanisms will be encapsulated in a custom JSP tag
> library.  Custom JSP tag libraries and CSS separate the concerns of
> developers and designers so they can each focus on their tasks.
> 
> In the beginning, the interface will assist with basic JMX debugging.  It
> will present the contents of the JMX server in a clear and straightforward
> manner for the Geronimo developers.
> 
> Later, the interface will be able to configure Geronimo's local manageable
> resources and provide a means to monitor active resources.  Eventually, it
> will assist with the configuration and management of remote resources and
> server clusters.
> 
> I've figured out a pretty clever way to instantiate and configure manageable
> resources and store them on the client for use in the web console (so that
> one can test JMX invocations through the web UI directly without relying on
> a persistence framework) but this will be an optional feature, as will some
> of the advanced UI components for monitoring resources.  For now, the
> primary functionality of the console is to help Geronimo's developers.
> 
> Finally, the JMX web console adheres to the JMX spec but is much more than a
> "JMX Client"  There will be many parts of the application which are not
> specified in any JSR and will be unique to the needs of the Geronimo
> project, such as aesthetic requirements which cannot be automated.  It is
> not my intent to copy the UI features and innovations of other products on
> the market.  If we focus on identifying and addressing the needs of the
> users we shouldn't need to steal anyone's UI ideas.  I'm sure they're great
> ideas but I'm also sure we can do better.  If end users of the console
> suggest important features, though, I'll always consider them.
> 
> That said, if anyone has suggestions or specific questions about the
> console, I'd love to hear them--developers and users alike.  If anyone is
> interested in adding any UI components, they can post some comps (of their
> own design) to the list here and we'll go over them together.  New UI
> features should be presented from the perspective of the end user.
> 
> </nar:wikiable>
> 
> I'll be rolling out another release of the code in the next couple of days,
> which will allow developers to introspect MBeans.  At that point I believe
> the console will perform enough of its first objective to warrant inclusion
> in the codebase, but I'll leave that decision to the committers : )
> 
> I hope you're all doing well and I'm glad to be back online.
> 
> Cheers,
> --
> N. Alex Rupp (n_alex_rupp@users.sf.net)
> 
> 
> 
> 
> ----- Original Message -----
> From: "Dain Sundstrom" <dain@coredevelopers.net>
> To: <geronimo-dev@incubator.apache.org>
> Sent: Monday, September 01, 2003 6:29 PM
> Subject: Re: [newbie] JMX Console - where to start?
> 
> 
> > I don't know.  I'm sure Norm will jump on this thread tomorrow when he
> > is back online.
> >
> > -dain
> >
> > On Monday, September 1, 2003, at 06:27 PM, Matt Kurjanowicz wrote:
> >
> > > Is there any documentation on this console (what it is mean to do,
> > > architecture, etc)?
> > > -Matt
> > > mkurjano at cc.gatech.edu
> > >
> > > -----Original Message-----
> > > From: Dain Sundstrom [mailto:dain@coredevelopers.net]
> > > Sent: Monday, September 01, 2003 7:09 PM
> > > To: geronimo-dev@incubator.apache.org
> > > Subject: Re: [newbie] JMX Console - where to start?
> > >
> > > N. Alex Rupp is working on a web based jmx console for Geronimo (and
> > > mx4j).  The code is on sf right now
> > > http://sourceforge.net/projects/service-cache
> > >
> > > -dain
> > >
> > > On Monday, September 1, 2003, at 05:49 PM, Nick Faiz wrote:
> > >
> > >> Putting it on a wiki page would be very useful.
> > >>
> > >> Also, how are server instances represented in Geronimo?
> > >>
> > >> Just to throw some obvious needs at the screen for the JMX console. We
> > >
> > >> could
> > >> also consider sections for
> > >>
> > >> - datasources, jdbc connection pools and the usual list of things
> > >> you'll see
> > >> in a J2EE console.
> > >> - users / groups. Are we using the typical ACL model?
> > >> - the adjustment of logging levels (it would be terrific if we could
> > >> view a
> > >> stat.s graph of server usage).
> > >> - possibly, a list of active sessions.
> > >>
> > >> Let me know if I can help out in this area. It's hard to know where to
> > >
> > >> jump
> > >> in.
> > >>
> > >> Nick
> > >>
> > >> -----Original Message-----
> > >> From: Matt Kurjanowicz [mailto:mkurjano@cc.gatech.edu]
> > >> Sent: Tuesday, 2 September 2003 7:55 AM
> > >> To: geronimo-dev@incubator.apache.org
> > >> Subject: RE: [newbie] JMX Console - where to start?
> > >>
> > >> Stepping back makes sense...
> > >> At the most basic level, I think we would need:
> > >> * start/stop/restart/kill server
> > >> * start/stop individual components (?)
> > >> * add/remove components (?)
> > >> * check status of server/individual components
> > >> * list/start/stop services
> > >>
> > >> From there, I think we would need to build some more advanced
> > >> functionality:
> > >> * Change configuration of server on the fly
> > >> * List configuration (? - basic?)
> > >> * Manage (in more depth than start/stop/list)/Configure Services
> > >> (necessary?)
> > >>
> > >> I think this is a really restricted list, and just takes into account
> > >> the most basic items.  As far as how to implement this functionality,
> > > a
> > >> command line interface would be nice and simple for the simpler tasks,
> > >> but it would be a little more difficult to say, configure the server
> > >> using a command line versus using a web/swing type framework.
> > >>
> > >> -Matt
> > >> mkurjano at cc.gatech.edu
> > >>
> > >> P.S> Where in the Wiki would a page about this go?
> > >>
> > >> -----Original Message-----
> > >> From: Aaron Mulder [mailto:ammulder@alumni.princeton.edu]
> > >> Sent: Monday, September 01, 2003 4:54 PM
> > >> To: geronimo-dev@incubator.apache.org
> > >> Subject: RE: [newbie] JMX Console - where to start?
> > >>
> > >> Twiddle is the command line framework I'm referring to.  If you
> > >> look at o.a.g.command.StartCommand (in the core module), you'll see
> > > how
> > >> to
> > >> construct a command to tke advantage of it.
> > >>
> > >> But perhaps it would be best to step back a sec and start at the
> > >>
> > >> top.  Shall we start a Wiki page on the topic, and assemble a list of
> > >> what
> > >> functions we think the JMX console should have?  It might help to talk
> > >> through the functionality we're going for, and then see what that
> > >> suggests
> > >> when it comes to the implementation.
> > >>
> > >> Aaron
> > >>
> > >> On Mon, 1 Sep 2003, Matt Kurjanowicz wrote:
> > >>> As far as which angle (command line, web, etc.), I'm interested in
> > > any
> > >>> of those.  Is Twiddle what you are talking about on the command line?
> > >>>
> > >>> Expanding the Tomcat code sounds like a really interesting idea, but
> > >> I'm
> > >>> not familiar with the code behind it.
> > >>>
> > >>> I am not completely familiar with JMX and JSR -77 and -88, but I am
> > >>> definitely willing to learn.  To be completely honest, I'm really new
> > >> at
> > >>> J2EE stuff, but have lots of time and willingness to learn, so I've
> > >> been
> > >>> playing around with different J2EE components, but nothing
> > > spectacular
> > >>> so far.
> > >>>
> > >
> > > /*************************
> > >   * Dain Sundstrom
> > >   * Partner
> > >   * Core Developers Network
> > >   *************************/
> > >
> > >
> >
> > /*************************
> >   * Dain Sundstrom
> >   * Partner
> >   * Core Developers Network
> >   *************************/
> >
> >
> 
> 


Mime
View raw message