We could make the classpath a trait, but would probably need to make the trait column longer than it is currently

            String name = null;
            for (int i = 1; i < process.getCommandLine().length; i++) {
                String arg = process.getCommandLine()[i];

                if (!arg.startsWith("-")) {
                    name = arg;
                    break;
                }
            }

            name += " (" + port + ")";

Tries to take the first argument that doesn't start with -
Which is why: "java -jar helloworld.jar" always produces a name of "helloworld.jar".
If you start your VM like this: "java -cp long-classpath ...and the rest..." this bug will happen.

We need to make auto-detecting the name better.

see also 237962

svn rev 2037

the code falls back to "JMX Server" if it can't find a suitable, short name.  We automatically skip the classpath argument (-cp or -classpath).

need to test this

this is the code now:

            String name = "JMX Server";
            for (int i = 1; i < process.getCommandLine().length; i++) {
                String arg = process.getCommandLine()[i];

                if (!arg.startsWith("-")) {
                    if (arg.length() < 200) { // don't use it if its really long, that's an ugly resource name
                        name = arg;
                        break;
                    }
                } else if (arg.equals("-cp") || arg.equals("-classpath")) {
                    i++; // skip the next arg, its the classpath, we don't want that as the name
                }
            }

            name += " (" + port + ")";

to workaround this problem (if running an older version that does not yet have this fix), set the classpath via an environment variable so you don't have to pass it on the command line:

export CLASSPATH=/really/long:/class/path:/here
java -jar -Dmy-options=here myjar.jar

svn ren 2267 in the 1.1.2.CP branch

Fixed, 2.1.2GA_CP1 

<jweiss> this was my command: java -Dcom.sun.management.jmxremote.port=1500 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -cp .:/tmp:/usr/local/pgsql/include/server/access/:/usr/lib/acroread/Reader/Legal/en_US/::/tmp:/usr/local/pgsql/include/server/access/:/usr/lib/acroread/Reader/Legal/en_US/::/tmp:/usr/local/pgsql/include/server/access/:/usr/lib/acroread/Reader/Legal/en_US/::/tmp:/usr/local/pgsql/include/s
 erver/access/:/usr/lib/acroread/Reader/Legal/en_US/::/tmp:/usr/local/pgsql/include/server/access/:/usr/lib/acroread/Reader/Legal/en_US/::/tmp:/usr/local/pgsql/include/server/access/:/usr/lib/acroread/Reader/Legal/en_US/::/tmp:/usr/local/pgsql/include/server/access/:/usr/lib/acroread/Reader/Legal/en_US/::/tmp:/usr/local/pgsql/include/server/access/:/usr/lib/acroread/Reader/Legal/en_US/::/tmp:/usr/local/pgsql/include/server/access/:/usr/lib/acro
 read/Reader/Legal/en_US/: DummyJVM
<ccrouch> jweiss if that actually launches a JVM then it should be a good test
<jweiss> ccrouch: yeah, it did and it was discovered.  mazz now what am i looking for to make sure everything is fixed
 i don't see any traits for the jvm
<ccrouch> jweiss: the name of the resource not being 100's of characters long
<mazz> I think the fact it made it into inventory is a good sign :)
<ccrouch> +1
<jweiss> mazz: is the fix that it used the name of my class "DummyJVM" as the resource name?
<mazz> yes. 
 the name of the resource would have been that long classpath before
 which was obviously not what we wanted :)
<jweiss> ok, so when i restart with --classpath, it's going to stay the same resource right?
<mazz> if your resource name is valid now, then this is verified fixed
 correct

This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1036
This bug is related to RHQ-1104