geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Kurjanowicz" <>
Subject Re: Eclipse Plug-in, rough first cut
Date Sat, 22 Nov 2003 23:59:07 GMT
You're too fast for me :).  It looks good, I'll work on trying to figure out
how to get it to talk to Geronimo - does anyone out there know the state of
JSR-77 and geronimo?
-Matt K
----- Original Message ----- 
From: "Mariano Kamp" <>
To: <>; "Matt Kurjanowicz"
Sent: Saturday, November 22, 2003 6:16 PM
Subject: Eclipse Plug-in, rough first cut

> 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
> 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
> 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
> 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
> management console and if there will be a common base for the different ui
> types.
>  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.
> 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
> 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
>   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
> 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
> directory. This is usually located below the eclipse installation
> On debian you would unzip it to /usr/share/eclipse/plugins.
> To activate the views you go to Window/Show View/Other/JSR-77
> Objects View and Window/Show View/Other/Basic/Properies. The Properties
> will show the properties of a selected managed object in the Managed
> 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
> 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,
> 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
> the hierarchy.
> If that is the case it will be added, but a traversal of its "children"
> not be allowed.
>   As a consequence the order of apperarnce of ObjectNames is important. If
> 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
> 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
> children and therefore traversed.
> For j2eeTypes specific to a J2EEServer not supported (yet) that wouldn't
> 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
> 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
> (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
> lazy initialization, just be found after a couple of clicks on the
> tree, thus the already visible tree was showing wrong information and will
> changed afterwards.
> pros:
> - - depends on the likelyhood of the heuristic
> cons:
> - - missing correctnes, if any, will just be reached after traversing the
> 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
> Version: GnuPG v1.2.3 (GNU/Linux)
> StOm72DAQqSBYYrZAauPHoo=
> =7rbZ

View raw message