geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Kurjanowicz" <mkurj...@cc.gatech.edu>
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" <mkamp@gmx.de>
To: <geronimo-dev@incubator.apache.org>; "Matt Kurjanowicz"
<mkurjano@cc.gatech.edu>
Sent: Saturday, November 22, 2003 6:16 PM
Subject: Eclipse Plug-in, rough first cut


> -----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-----
>
>
>


Mime
View raw message