left nav color
by John Mazzitelli
I think I know what I don't like about that left-hand nav.
Take a look at the colors of the lines that connect all the icons. You
can barely see it - so it looks like all the tree nodes are "floating".
Make the colors of those lines more bright - like white - and I think it
will make a different.
15 years, 2 months
[Fwd: preview of new propertySet component]
by John Mazzitelli
[sending to jopr-dev mailing list]
To check out the new propertySet component (to be used for drilling down
on a particular property in a group config), svn up to 2855 or later,
then go to http://localhost:7080/rhq/test/config/props.xhtml. You can
submit the form and the values will be saved in session scope.
Validation and the unset controls also work. Note, there's an early
version of the control for setting all member properties to the same
value; it's a text box now, but it will eventually be an input control
of the appropriate type for the property type (radio buttons for
boolean, etc.). Comments are welcome.
15 years, 2 months
agent plugin file upload to the server works!
by John Mazzitelli
Hey, I just confirmed the new RichFaces we have fixes the agent plugin
file-upload problem!
So, we now have the ability to file upload an agent plugin to the server
using the UI ("manage plugins" admin page - see the richfaces
file-upload component at the bottom). No more manually copying jars to
the rhq-downloads/rhq-plugins directory! :)
Upload a new agent plugin (or update an existing one) and notice that it
will update the database with the new code. If an agent then tries to
update its plugins, it'll get the new one (if its a brand new plugin,
this works in an HA server cloud - doesn't matter which server the agent
asked for the plugin! neat trick)
If you update an existing plugin in an HA server cloud, you need to wait
5 minutes (30 seconds if its a dev build) for all the servers in the
cloud to update themselves before the agents can update its plugins -
or, if you do not want to wait, go to that same "manage plugins" UI
admin page in all your servers and click "SCAN FOR UPDATES".
Pretty cool, I should blog about this :)
15 years, 3 months
Event constructor question
by John Mazzitelli
I have a question about the Event domain object API. It has these two
constructors:
public Event(String type, String sourceLocation, long timestamp,
EventSeverity severity, String detail)
public Event(String type, String sourceLocation, long timestamp,
EventSeverity severity, String detail, *EventSource source*)
I'm questioning that second one. If we accept an EventSource as the
last argument, can't we then infer the values of "type" and
"sourceLocation" and thus shouldn't that constructor be:
public Event(long timestamp, EventSeverity severity, String detail,
EventSource source) {
this.type = source.getEventDefinition().getName;
this.sourceLocation = source.getLocation();
...
}
Otherwise, what prohibits type and sourceLocation parameter values from
(accidentally) being DIFFERENT than that which is found in the given
event source (and if that happens, I assume that would semantically be
wrong).
???
15 years, 3 months
classloaders, jar files and open file descriptors, oh my!
by John Mazzitelli
I wrote up a blog that discusses what I found in the agent regarding its
classloading and why we were getting errors during hot-deployment:
http://management-platform.blogspot.com/2009/01/classloaders-keeping-jar-...
Thanks to Jay - he pointed me to the place in the code where it was
failing. From there, it was just a matter of stepping through some JRE
code and googling and, well, the blog explains the problem.
In the end, we don't really need to do that hack that I show in the blog
(as I mention in the last paragraph). It turns out, in two places in
the code we were creating temporary classloaders just so we could get a
stream of the plugin descriptor from the jar file - and that was opening
the plugin jar files (and on Windows, locking them too). I replaced the
temporary classloaders with code that simply gets the stream using the
JarFile API. This fixed the problem.
This should put to bed those nasty "the JMX plugin is not in the
dependency graph" errors we sometimes got in the agent (at least, I hope
it does).
That said, we still have one problem which manifests itself in the agent
being unable to delete the virt plugin's data/tmp directory at shutdown.
See the comment in RHQ-1399 for the stack that shows the libvirt code
asking the classloader to load the jna jar file - I do not know why this
is still locked. Here's the link to that RHQ issue:
http://jira.rhq-project.org/browse/RHQ-1399?focusedCommentId=13893#action...
15 years, 3 months
NPE in snmptrapd plugin
by John Mazzitelli
http://jira.rhq-project.org/browse/RHQ-1398
Who is familiar with this snmptrapd plugin that can look at this?
Getting an NPE when registering the event poller... I didn't look at
this at all, I assume its easy to fix but I'm not familiar with the
snmptrapd plugin.
I'm running on windows and I have no snmp stuff running - this is just
deployed as part of the RHQ build.
15 years, 3 months