geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sonnek, Ryan" <>
Subject RE: Fw: console-web
Date Tue, 04 Nov 2003 19:30:32 GMT
It makes a lot more sense now that you explained why you did the things you
do.  I completely agree that the focus should be on improving the feature
list and not on making it look "pretty".  

I have an idea where you could start out.  I am interested in building a set
very simple DataSource objects that encapsulates all of the information
contained in MBeanInfo, MBeanAttributeInfo and MBeanOperationInfo objects so
that data can be easily be accessed and printed to the screen in a

I'll start here.  I'd like to get a little more information about your
thoughts on this.  I'm familiar with the Jboss JMX console, and I'm guessing
that you're thinking along the lines of the work they did to define
datasources in the simplified *-ds.xml instead of the verbose *-service.xml?
so, does this at all impact the JCA Geronimo project?


-----Original Message-----
From: n. alex rupp [] 
Sent: Monday, November 03, 2003 2:31 PM
Subject: Re: Fw: console-web

This is good.  I was hoping someone would bring this up, so I could explain
decision : )

----- Original Message ----- 
From: "Sonnek, Ryan" <>
To: <>
Sent: Monday, November 03, 2003 11:07 AM
Subject: RE: Fw: console-web

> Just trying to help out where I think I can.  I'm new to geronimo, and to
> try and understand what the hell is going on, I thought starting small
> be good.  UI does not impact the underlying system, but it DOES provide a
> great chance to learn what is going on under the covers.
> Removing html from the jsp custom tags is just one of my pet peeves.  It
> completely restricts someone that does not the system what is going on
> making improvements.  I hate to see any application ignore the role of the
> "designer" (which I am not claiming to be!  I know about as much "layout"
> a blind monkey)

Here lies a tricky paradox.  You're admittedly not a skilled designer, and
unless you're willing to put a significant investment into training yourself
that area, you won't be one anytime soon.  On the other hand, I *am* a
designer--that's where I cut my teeth in this industry.  I've been designing
nearly a decade now and I know the ropes, (but Jeremy and David's son have
taught me a few tricks in the last year, and I've always benefitted from
discerning eye).  But what's better, I'm also a developer.  I can develop
client-side components in ecma-script, interactive UI engines using flash,
director, whatever you like.  And I can write middleware components, web
ejbs, custom tag libraries in JSP, XSLT processors, servlet frameworks, all

Now, when most people think about "separation of concerns" between designers
developers, there is an implication that the developers are trying to shield
their code from the designer, so as not to confuse them with business logic.
But here, that is not the case.  I, the designer, have decided to use custom
tag libraries to hide the presentation logic from the developers, so as not
confuse them with HTML and other complex presentation logic.  Since this
application does not yet deal with any business logic, I've not yet needed
separate the concerns of the component architecture.  But I've plans to do
very soon as we move past the basic JMX client application into more complex
server and container management.

So, when the time comes to write a good web application, it makes sense for
to build pluggable design components using custom JSP tag libraries and a
reliance on CSS.  That way, I know that I can guarantee the visual outcome
the work.  And I enjoy working with presentation logic; enough to write
fine-tuned component tag libraries.  Dropping HTML into the tag libraries is
only practical route for me.  I *am* concerned with making the material more
approachable for newcomers, and I'm already beginning to notice flaws in the
structure and preparing to refactor.

I've made a distinction between separating the concerns of the archetectural
components and separating the concerns of the developers.  From my
developers of this console must have a solid understanding of both ends of
product (being the presentation logic and the JMX interfaces), or be willing
accept certain abstractions in order to ensure the quality of the

> But all I'm really trying to do is find a way to understand what's going
> and help out where I can.  I see this as a great learning experience for
> to be exposed to JMX and hopefully I can branch out from there and help
> other places.

Therefore, you rock : )

> If anyone has ideas on an area that could use work, like
> testcases, or someplace that would be a good introduction, I could start
> there.

I have an idea where you could start out.  I am interested in building a set
very simple DataSource objects that encapsulates all of the information
contained in MBeanInfo, MBeanAttributeInfo and MBeanOperationInfo objects so
that data can be easily be accessed and printed to the screen in a
format.  This involves string parsing and very little else.   I want to
the parsing logic out of the presentation tags for the console.  I also want
break up the MBeanAttributesTag object into three (or more) tags which nest
inside of an MBeanInfoContextTag object.  I want to the screen output to be
modular than it is. And I could always use more comparators : )

I also need to start incorporating a servlet framework into this process, as
getting to the point where it would be nice to be able to validate incoming
data, and it would also be nice to keep a repository of objects in the
context which have been summoned using invocations and can be used as the
parameters for other invocations--this will involve building wrappers for
presentation components as above, but will probably involve more use of
reflection, because we can't be guaranteed there's an MBean interface for
return types.  The code for matching objects by type and presenting them in
"MBean Operation Information" table, probably in some kind of drop-down
needs to be written.  Code governing the placement and behavior of the
buttons needs to be written--you shouldn't have an invoke button if you
have all of the parameters available to invoke a method, right?   There's
stuff, too, which we could get into.

I've got a ton of work I could use help with, and I'm happy to work closely
you, so you don't feel lost in the code.  And we *can* always shoot for more
abstraction if it makes it easier for you to contribute : )  If any of the
interests you, then by all means let's collaborate now and finish up some of
these features.

> I am just looking for a way into this project, and would be glad to look
> another area.

I think it's important we all remember that there is no portion of this
which isn't going to be challenging.  It doesn't matter where you get
involved--the entrance threshold is daunting wherever you look, because
set the bar really high.  But if you've got experience developing
logic, I'd be happy for the help.

: )
N. Alex Rupp (

View raw message