-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi.
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
types.
You can have a look at a screenshot here:
http://mariano.homelinux.org/fullScreen.png
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:
http://mariano.homelinux.org/org.apache.geronimo.console.eclipse_1.0.0.zip
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.
pros:
- - straight forward to implement
- - generic
cons:
- - 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
j2eeType.
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.
pros:
- - will be 100% correct for standard j2eeTypes
cons:
- - 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.
pros:
- - depends on the likelyhood of the heuristic
cons:
- - missing correctnes, if any, will just be reached after traversing the whole
tree
- - 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.
Cheers,
Mariano
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/v+5CSraqt+SsFIMRAq+xAJsEWI4ETrvVciViD8HjfZZTlJDJQQCfQcnl
StOm72DAQqSBYYrZAauPHoo=
=7rbZ
-----END PGP SIGNATURE-----
