JBossDeveloper

Adrian,
Thank you for the changes and useful unit tests.
I'll start to change MLet getMBeansFromURL() with the getVersion() and the registerMBean() method of the new MBeanRegistry.

Juha,
Making a patch for checking mbean version doesn't seems difficult for me but It might take a couple of days for my first try. If you already have done it or you cannot wait my small contribution, please let me know.

Best regards,
Miki

I've just submitted the patch for version handling.
I'd make another one for the presentationString next week.

http://sourceforge.net/tracker/?func=detail&atid=376687&aid=548459&group_id=22866

Regards,
Miki

Juha,

Just started on the design for the presentationString part.

Since the ManagedMBeanRegistry is a RequiredModelMBean and the attached MBeanInfo
is static inherently, we need to have a trigger to set a presentationString for
dynamic data such as version or date of mbean metadata.

My idea is as follows:

1. Define a subclass of the RequiredModelMBean to override the getMBeanInfo().
This subclass is used for creating the ManagedMBeanRegistry.

2. The getMBeanInfo() invokes PresentationStringBuilder,
which is an object to create a presentatinString,
then updates the string in the descriptor.

3. The PresentationStringBuilder creates a xml string for all mbeans in the registry:

<registry>
 <domain>
 <name>DefaultDomain</name>
 <entry>
 <name>service=Configuration</name>
 <version>1.0</version>
 <date>2002/05/01 00:00:00 PST</date>
 </entry>
 ...
 </domain>
 ...
</registry>

public class PresentationStringBuilder
{
 StringBuffer buf = new StringBuffer();

 public PresentationStringBuilder()
 {
 }

 public String getPresentationString()
 {
 return buf.toString();
 }

 /*
 * MBean descriptor
 */
 public void createMBeanRegisty(ManagedMBeanRegistry registry)
 {
 buf.append("<registry>\n");
 // for every domain, call createDomain(registry, domain)
 buf.append("</registry>\n");
 }

 protected void createDomain(String domain, MBeanEntry[] entries)
 {
 buf.append("<domain>\n");
 // for every entry, call createMBeanEntry(entry)
 buf.append("</domain>\n");
 }

 protected void createMBeanEntry(MBeanEntry entry)
 {
 buf.append("<entry>\n");
 // call createValueMap(valueMap)
 buf.append("</entry>\n");
 }

 protected void createValueMap(HashMap valueMap)
 {
 Iterator it = valueMap.entrySet().iterator();
 while (it.hasNext())
 {
 Map.Entry entry = (Map.Entry) it.next();
 String key = (String) entry.getKey();
 String value = (String) entry.getValue();
 buf.append("<" + key + ">\n");
 buf.append(value);
 buf.append("</" + key + ">\n");
 }
 }
//...
}

I made a prototype for the PresentationStringBuilder.
This is how to use this:

PresentationStringBuilder builder = new PresentationStringBuilder(registry);
builder.buid();
System.out.println(builder.getMBeanString());

> Well, first of all the ManagedMBeanRegistry is going
> away, I've moved the MBeanifying as the responsibility of
> the agent (all registry implementations will always be
> exposed as MBeans).

Ok, I saw the MBeanServerImpl#getRegistryManagementInterface().

> This leaves the registry responsible of updating its presentation, iow
> lookup its MBean representation (JMImplementation:something=or=other),
> and setDescriptor() with updated presentation.

Then when can we update the descriptor?
I stll have a concern about the timing of the update.

> But I wouldn't want to impose all the presentation logic to the
> resource objects themselves. I need to think about it some more.

Well, you are right.
My prototype was supposed only for the registry and it apparently
can't apply to normal mbeans.

I should have thought about a generic framework for making presention
strings for every mbean. For simplicity, only mbeans those need the
presentation should have the logic to produce the presentation
strings.

Can I use an mbean intercepter for this?

> The best way would be to possibly embed somekind of query as part
> of the presentation string. But then I suppose some of the web
> frameworks already do this type of functionality.

I'm afraid I don't figure this out.
I need an example.

> Hmm, something like indexed attributes would be nice in this case
> (something Andreas proposed once, I think I might be able to
> implement them without breaking the existing API, Andreas you there?)

I'd like to have more information about this proposal.

Miki

> > Then when can we update the descriptor?
>
> well, what I was trying to say was that you don't
> expose the attribute values as part of the
> presentationString, rather you declare which
> attributes are displayed, how they're displayed etc.
> and then let the tool which is processing the
> presentation to call the appropriate methods in the
> JMX API. So you don't have to update the
> presentationString everytime the state of the MBean
> changes.

Before reading your reply I'd read the JMX spec again.
It says "the presentaionString provides hints to a console so that it can generate user interfaces".

I realized I quite misunderstood the concept of the presentationString. Now your response make me sure how I shoud use this string. Thanks.

>
> > My prototype was supposed only for the registry
> and
> > it apparently can't apply to normal mbeans.
>
> yes that is alright at this point.
>
>
> > I should have thought about a generic framework
> for
> > making presention
> > strings for every mbean. For simplicity, only
> mbeans
> > those need the
> > presentation should have the logic to produce the
> > presentation
> > strings.
>
> Right but I was talking about presentationString that
> contains the elements of the management interface (an
> attribute name or operation name) which is then
> replaced by the tool by invoking that particular item
> and replacing it with the return value rather than
> putting the values themselves into the
> presentationString (in which case it needs continuous
> updates).
>

This makes sense to me now.

>
> > Can I use an mbean intercepter for this?
>
> yes, for the approach you have taken, an interceptor
> would be perfect. good point.

I'm always looking for a chance to use it :-)

>
>
> > > The best way would be to possibly embed somekind
> of query as part
> > > of the presentation string. But then I suppose
> some of the web
> > > frameworks already do this type of
> functionality.
> >
> > I'm afraid I don't figure this out.
> > I need an example.
>
> Well for instance, in the registry expose attribute
> MBeanNames with the corresponding accessor
> ObjectName[] getMBeanNames() or List getMBeanNames()
> and in the presentationString use the attribute name
> MBeanNames to indicate the location where this
> attribute value should be placed in the
> presentation.
>
> So assuming the presentationString was HTML like:
>

> <b>Attribute Names</b>
> <attribute name="MBeanNames"/>
>

For the presentationString format, we may need a xml ui conmponent package and a template engine. It is cool if we can use XUL and Velocity (or Anakia) respectively.

There are some projects about XUL like Luxor:
http://luxor-xul.sourceforge.net/

Even if it looks interesting, I'm not familiar with them and need much time for investigation.

Now I should rather focus on the mbean intercepter.
I make a simple one for the evaluation although the sample client needs explicit xlst handling.

Miki

I did a quick hack to my local copy of JBossMX and got a feeling of how to make a intercepter for the presentationString.

Now I'm going to define the xml dtd of the presentationSting that is most difficult part of this work for me.

> We're definitely on the same page now. I was thinking
> about XUL as well, another possibility might be W3C
> XForms, and yet another we just roll our own if
> neither of the two can be adapted to our purposes.

I've looked over the spec.
XForms would be a perfect platform for us in future.
It supports device independecy, nice xml controls and constraints between form data. Every xml control is a placeholder for the actual representation like XHTML.

IMHO, however, it is a bit difficult to implement ui for every mbean developers because XForms requires XPath, XSLT, XML Schema. Probably they need good developing tools to build custom ui without knowledge of XForms itself. I don't think the tools are mature at this moment.

I was looking for a better way fo ui cosumization than XSLT. So I browsed the Jakarta Velocity manual.
With Velocity we could set the ModelMbean*Info to a variable as follows:

ModelMBeanAtrributeInfo roomNameInfo = ...;
VelocityContext context = new VelocityContext();
context.put("roomNameInfo", roomNameInfo);

Then we could access the every field and method by the variable $roomNameInfo in the presentaionString. For example, the type of the roomNameInfo could be accessed by $roomNameInfo.description:

<h1>Description:</h1>

$roomNameInfo.description


We also could pack the mbean attribute values to a Java object(map?) and access it by a variable. Then we could expand the variables to make options for menu items in HTML. As you see, it is easier and more intuitive to build mbean ui for the developers than XSLT.

I'd like to define the presentationString as simple as I could. The default ui should be as simple as the HTML adapter. We can change the basic redering parameters with CSS. But that's not enough.

If I need to elaborate my mbean ui for production, I try to replace some attribute ui components with charts, gauges or graphs by combining multiple mbean attribute values. It looks too difficult to achive this with XSLT.

Just my thougnt.

Miki