geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mariano Kamp <>
Subject Eclipse Plug-in, rough first cut
Date Sat, 22 Nov 2003 23:16:18 GMT
Hash: SHA1


  I never had a look at JMX/JSR-77 before and didn't use the eclipse api for a 
couple of months. So I'd used this code to get some basic experience of 
JSR-77 and get reacquainted with the eclipse api. As a consequence of this I 
am willing to throw away all the code I did and will be very open to 
comments. This also includes changing directions and work on panoptesmgmt. 
This is true as long as the result is directed to be included into geronimo 
some day and will integrated into eclipse.  

  Even without comments I would change the existing code to reduce 
dependencies and move functionality around to make responsibilities clearer. 
I will also eliminate all the shortcuts I implemented to get something 
working fast. 

  I'll wait for the discussion to start/end about the minimum features for a 
management console and if there will be a common base for the different ui 
 You can have a look at a screenshot here:

  Please be aware that I didn't even try to make it look nice and shiny. Thus 
there are no icons etc. That was outside of the learning-scope. 
The code is not a too nice sight too, as I did lot's of shortcuts and learned 
on the way. Due to the discussion about panoptesmgmt I am not bothering to 
cleanup the code properly. We'll see what the discussion will come up with.

  You can download the plugin (source included) here:

  If you want to run it, a JBoss-3.2.2 with JSR-77 enabled need to run 
already. I haven't been able to get it running with geronimo, but this is 
likely due me not trying hard enough. My respective questions haven't been 
answered and I walked the easiest way, but have it on my agenda to find out 
how to connect to geronimo and get access to the mejb. 
To deploy the plugin into eclipse you need to unzip the file to your plugins 
directory. This is usually located below the eclipse installation directory. 
On debian you would unzip it to /usr/share/eclipse/plugins.
To activate the views you go to Window/Show View/Other/JSR-77 Console/Managed 
Objects View and Window/Show View/Other/Basic/Properies. The Properties view 
will show the properties of a selected managed object in the Managed Objects 
View. On some platforms you need to click in the upper-left corner of the 
plus-sign to expand the properties. This is an Eclipse issue.

  I stumbled over lots of questions during my learing phase. I guess the post 
is already to lenghty, but at least I'd like to ask one of them:

Recursions in J2EE Managed Object (jmo) Hierarchy

Some of the jmos reference not only children, but also jmos which are not 
descendants of it. The original idea of jmo traversal was to resolve all 
attributes of type ObjectName or ObjectName[] as children. This obviously 
will lead to infinite hierarchies as some of the jmos reference a jmo, which 
is not a descendant and probably references back.
I haven't found anything about it in the specs.

Possible Solutions:

a) N-th Apperance Marked As Recursion
The easiest approach, hence the implemented one, is to check if a new 
ObjectName which should be added to the hierarchy does already exist within 
the hierarchy.
If that is the case it will be added, but a traversal of its "children" will 
not be allowed.

  As a consequence the order of apperarnce of ObjectNames is important. If the 
first apperance is *just* a reference and the second appearance happens 
during to the actual parent/child discovery, the first appearance wins and 
the actual child will be marked as recursion.

- - straight forward to implement
- - generic

- - probably wrong

b) Using Metadata
Either way I will put some xml-based meta-data model in place. This will hold 
for example references to the images to be associated with a particular 
The metadata could also be used to mark what references should be treated as 
children and therefore traversed. 
For j2eeTypes specific to a J2EEServer not supported (yet) that wouldn't work 
as there is no metadata available.

- - will be 100% correct for standard j2eeTypes

- - wouldn't work for unknown j2eeTypes, read vendor specific extensions
- - need also to implement a) or c) as a fallback

c) Taking Hierarchy-Depth Into Account
What about the following heuristic: The first ObjectName on the level with the 
least depth wins.
As a consequence an ObjectName qualified as child after one is in place 
already needs to take the place of the former one in the ObjectName listing 
(used to check if this ObjectName has been added already) and the former 
one's children needs to be removed. This would also affect the GUI.
Another consequence is that the second, and better, match will likely due to 
lazy initialization, just be found after a couple of clicks on the displayed 
tree, thus the already visible tree was showing wrong information and will be 
changed afterwards.

- - depends on the likelyhood of the heuristic

- - missing correctnes, if any, will just be reached after traversing the whole 
- - unpredictable
- - bit harder to implement

Well, if I revist the code I would likely go for b) with a) as fallback to 
handle the generic part of vendor specific extensions, but am very open to 
better aproachs.

Version: GnuPG v1.2.3 (GNU/Linux)


View raw message