rev 2749] Jopr-55 Filter out standalone Tomcat processes from the JMX plugin discovery
by John Mazzitelli
IMO, we should not do this kind of thing.
We basically are hardcoding knowledge about a Jopr plugin into a core
RHQ plugin. This is bad practice. An RHQ plugin should not care about or
know anything about a Jopr plugin. In fact, the general practice is one
plugin should not know anything about another plugin.
Pretty soon, we could potentially have bunches of these little "nuggets"
all over the place and then we get into how the old JON 1.x plugin
system worked - dependencies all over the place without any
compartmentalization.
Let's think this through and come up with another solution that doesn't
dirty up the RHQ JMX plugin with Jopr-plugin-specific knowledge.
-------- Original Message --------
Subject: [Rhq-commits] [rhq-project.org rhq] [2749] Jopr-55 Filter out
standalone Tomcat processes from the JMX plugin discovery.
Date: 26 Jan 2009 17:45:00 -0000
From: jshaughn(a)rhq-project.org
To: rhq-commits(a)lists.sourceforge.net
Revision
2749
Author
jshaughn
Date
2009-01-26 11:45:00 -0600 (Mon, 26 Jan 2009)
Log Message
Jopr-55 Filter out standalone Tomcat processes from the JMX plugin discovery. To manage standalone Tomcat the Jopr Tomcat plugin should be installed.
Modified Paths
* rhq/trunk/modules/plugins/jmx/src/main/java/org/rhq/plugins/jmx/JMXDiscoveryComponent.java
<#rhqtrunkmodulespluginsjmxsrcmainjavaorgrhqpluginsjmxJMXDiscoveryComponentjava>
Diff
Modified:
rhq/trunk/modules/plugins/jmx/src/main/java/org/rhq/plugins/jmx/JMXDiscoveryComponent.java
(2748 => 2749)
--- rhq/trunk/modules/plugins/jmx/src/main/java/org/rhq/plugins/jmx/JMXDiscoveryComponent.java 2009-01-26 15:31:31 UTC (rev 2748)
+++ rhq/trunk/modules/plugins/jmx/src/main/java/org/rhq/plugins/jmx/JMXDiscoveryComponent.java 2009-01-26 17:45:00 UTC (rev 2749)
@@ -59,11 +59,16 @@
public static final String ADDITIONAL_CLASSPATH_ENTRIES = "additionalClassPathEntries";
+ /* Ignore certain processes that are managed by their own plugin. For example The Tomcat plugin will
+ * handle tomcat processes configured for JMX management.
+ */
+ private static final String[] PROCESS_FILTERS = { "catalina.startup.Bootstrap" };
+
public Set<DiscoveredResourceDetails> discoverResources(ResourceDiscoveryContext context) {
Set<DiscoveredResourceDetails> found = new HashSet<DiscoveredResourceDetails>();
- // This model of discovery is of questionable usefullness since if you restart your process you'll get a new resource
+ // This model of discovery is of questionable usefulness since if you restart your process you'll get a new resource
// Works only on JDK6 and maybe some 64 bit JDK5 See JBNADM-3332.
//
// Map<Integer, LocalVirtualMachine> vms;
@@ -114,7 +119,16 @@
for (ProcessInfo process : processes) {
DiscoveredResourceDetails details = discoverProcess(context, process);
if (details != null) {
- found.add(details);
+ boolean isFiltered = false;
+ for (String filter : PROCESS_FILTERS) {
+ if (details.getResourceName().contains(filter)) {
+ isFiltered = true;
+ break;
+ }
+ }
+ if (!isFiltered) {
+ found.add(details);
+ }
}
}
} catch (Exception e) {
@@ -128,8 +142,7 @@
String resourceKey = c.getSimpleValue(CONNECTOR_ADDRESS_CONFIG_PROPERTY, null);
String connectionType = c.getSimpleValue(CONNECTION_TYPE, null);
- DiscoveredResourceDetails s = new DiscoveredResourceDetails(context.getResourceType(), resourceKey,
- "Java VM", "?", connectionType + " [" + resourceKey + "]", null, null);
+ DiscoveredResourceDetails s = new DiscoveredResourceDetails(context.getResourceType(), resourceKey, "Java VM", "?", connectionType + " [" + resourceKey + "]", null, null);
s.setPluginConfiguration(c);
@@ -175,14 +188,11 @@
name += " (" + port + ")";
Configuration config = context.getDefaultPluginConfiguration();
- config.put(new PropertySimple(CONNECTION_TYPE,
- "org.mc4j.ems.connection.support.metadata.J2SE5ConnectionTypeDescriptor"));
- config.put(new PropertySimple(CONNECTOR_ADDRESS_CONFIG_PROPERTY, "service:jmx:rmi:///jndi/rmi://localhost:"
- + port + "/jmxrmi"));
+ config.put(new PropertySimple(CONNECTION_TYPE, "org.mc4j.ems.connection.support.metadata.J2SE5ConnectionTypeDescriptor"));
+ config.put(new PropertySimple(CONNECTOR_ADDRESS_CONFIG_PROPERTY, "service:jmx:rmi:///jndi/rmi://localhost:" + port + "/jmxrmi"));
// config.put(new PropertySimple(INSTALL_URI, process.getCurrentWorkingDirectory()));
- details = new DiscoveredResourceDetails(context.getResourceType(), port, name, null,
- "Standalone JVM Process", config, null);
+ details = new DiscoveredResourceDetails(context.getResourceType(), port, name, null, "Standalone JVM Process", config, null);
}
return details;
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Rhq-commits mailing list
Rhq-commits(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rhq-commits
15 years, 2 months
jps
by John Mazzitelli
Found a nice nugget today....
Java has a "jps" utility. run it and it dumps the PIDs of all JVMs
running, along with the MainClass. Helps find the agent really quick:
C:\mazz\source>jps
6112 org.eclipse.equinox.launcher_1.0.100.v20080509-1800.jar
3988 WrapperSimpleApp
1720 Jps
2684 AgentMain
6112 is my eclipse. 3988 is my server. 1720 is obviously the jps utility
command I just ran. And 2684 is my agent.
15 years, 2 months
jsf navigation rule question
by John Mazzitelli
If you go to:
http://localhost:7080/rhq/resource/content/create.xhtml?id=500551
(where 500551 represents a JBossAS resource in my inventory)
and you click cancel, the browser is redirected to this URL:
http://localhost:7080/rhq/resource/content/create.xhtml
and the page that gets rendered is a generic JSF error page.
Here's the thing I don't get. The navigation rules say that upon cancel,
this should go to the deploy.xhtml (with an id param), NOT create.xhtml:
<navigation-rule>
<from-view-id>/rhq/resource/content/create.xhtml</from-view-id>
<navigation-case>
<from-action>#{CreateNewPackageUIBean.createPackage}</from-action>
<from-outcome>success</from-outcome>
<to-view-id>/rhq/resource/content/confirm-create.xhtml</to-view-id>
</navigation-case>
<navigation-case>
<from-outcome>cancel</from-outcome>
<to-view-id>/rhq/resource/content/deploy.xhtml?id=#{param.id}</to-view-id>
<redirect/>
</navigation-case> </navigation-rule>
Why is it going to create.xhtml???? Notice it goes there WITHOUT an "id"
parameter, and hence why I think this error is happening. Something
isn't right with our navigation rules now - but obviously, this USED to
work. I'm wondering if Seam created a problem here??
15 years, 2 months
regd jopr console
by Sadat Khan
Hi there,
I am using rhq server and agent on my windows machine. I have
jboss service running on my machine which is detected by the server and
shown in the dashboard. However when I click on a managed resource like a
machine or a server or a service to see it's health I get an exception
thrown in the logs. The stack trace is attached.
I am running win xp SP2 , and jopr server and agent 2.1.0... jdk
and jre 1.5...
What am I missing here ?
thanks and regards
Sadat Ali Khan
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
15 years, 2 months
review my proposal for the AI queue UI page
by John Mazzitelli
Please read my latest comment in:
http://jira.rhq-project.org/browse/RHQ-1236
and tell me what you think (Charles, you wrote this up, so you'll want
to review at least).
This deals with the Auto Inventory Queue page (not the AD portlet, its
the "view all" page).
I checked in some code for this issue (now that the RichFaces bug is
fixed, I was able to take out a bunch of hack code).
It still doesn't work like how the issue wants, and I admit it doesn't
work how you would think it would. But (a) right now I don't know of a
way to get it to do what we want it to do, (b) in order to do what we
want it to do would require additional time to think up and code a fix
and (c) fixing it would cause another "problem" similar to the problem
the issue was written up for - see my jira comment for what this is.
So, I'm inclined to say leave it as-is (at least for this release, if
not for good) - its better than the way it was for sure, so it is
progress at least. Would like additional comments/suggestions - feel
free to add comments to that JIRA with your thoughts.
15 years, 2 months
Re: [jopr-dev] review my proposal for the AI queue UI page
by Charles Crouch
So how does the AI page function now when compared to the AI portlet? In terms of what gets selected when I check a platform I think they should be the same, otherwise we're going to cause more confusion.
My 2c, the use case for people wanting to import just their platforms is not a very common one, mostly people want to easily import all the stuff they have discovered, or everything except for certain types of items.
We may not want to bite this off now, but I'd be fine with thinking outside of the tree-with-check-boxes rendering view, e.g.
instead have something like the browse resources page where you can filter on resource category (platform/server) and resource type (linux/jbas/apache), have "negative filters" (show me everything except the result of this filter), a recursive check box (if you want to filter on platforms and bring everything in), then just a big Import/Ignore button that works on the entire filtered results. This sounds more like a feature request :-)
Cheers
Charles
----- "John Mazzitelli" <mazz(a)redhat.com> wrote:
> Please read my latest comment in:
>
> http://jira.rhq-project.org/browse/RHQ-1236
>
> and tell me what you think (Charles, you wrote this up, so you'll want
>
> to review at least).
>
> This deals with the Auto Inventory Queue page (not the AD portlet, its
>
> the "view all" page).
>
> I checked in some code for this issue (now that the RichFaces bug is
> fixed, I was able to take out a bunch of hack code).
>
> It still doesn't work like how the issue wants, and I admit it doesn't
>
> work how you would think it would. But (a) right now I don't know of a
>
> way to get it to do what we want it to do, (b) in order to do what we
>
> want it to do would require additional time to think up and code a fix
>
> and (c) fixing it would cause another "problem" similar to the problem
>
> the issue was written up for - see my jira comment for what this is.
>
> So, I'm inclined to say leave it as-is (at least for this release, if
>
> not for good) - its better than the way it was for sure, so it is
> progress at least. Would like additional comments/suggestions - feel
> free to add comments to that JIRA with your thoughts.
> _______________________________________________
> jopr-dev mailing list
> jopr-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jopr-dev
15 years, 2 months
eclipse-tools > download sources
by Joseph Marques
note: rev163 adds a convenience for eclipse users whereby you can easily
downloaded maven dependencies. i noticed this today when the tomcat
plugin added new dependencies to its pom. since the dev-profile passes
the "-o" switch, the launcher will fail because it can not go out and
get the needed dependencies in offline mode. if that happens in the
future, simply execute the "Download Dependencies" external tool once,
watch 'em be pulled down, then execute the dev-profile again. enjoy.
-joseph
15 years, 2 months
autoboxing
by John Mazzitelli
What's the thought on auto-boxing? I saw some checkins related:
- timeout = timeoutProperty.getIntegerValue().intValue();
+ timeout = timeoutProperty.getIntegerValue();
I hate autoboxing. If I see an explicit "intValue()", it tells me right
away this is an Integer and not an int (and I need to therefore worry
about nulls and NPEs).So it helps code-readability to explicitly not
rely on autoboxing, and can avoid coding errors.
If I do not see the explicit "intValue" (or similar things), I either
think its an "int" or I have to hunt around to find the declaration to
find out for sure what it is.
I always thought autoboxing was a mistake and leads to more problems
than it solves.
15 years, 2 months
