Created attachment 686339 [details]
Proposed fix for both JBoss AS 4 and AS 5 plug-ins to handle absolute paths without a drive letter.

To fix this issue, my proposed patch is simply adding a check to see if the runJar file exists or not before attempting to resolve an absolute path:

                if (!runJar.isAbsolute()) {...

Becomes:
                if (!runJar.isAbsolute() && !runJar.exists()) {...

git commit to master: d2523a0

this BZ's description provides replication procedures

As this is MODIFIED or ON_QA, setting milestone to ER1.

Discovery is fixed but the AS 5 resource is unavailable after import. This is caused by 
Caused by: org.rhq.core.pluginapi.inventory.InvalidPluginConfigurationException: Configuration path 'e:\opt\jboss\jboss-eap-5.2\jboss-as\opt\jboss\jboss-eap-5.2\jboss-as\server\default' does not exist.

Configuration path is concatenation of 'JBoss Home Directory' and 'Server Home Dir'. See attached screen shot.

Scenario:
1- follow steps 1 to 9 from previous description.
2- import AS 5 resource from discovery queue

Result:
The AS 5 resource is not available and rhq agent is throwing following warning:
2013-11-05 01:43:59,330 DEBUG [InventoryManager.availability-1] (rhq.core.pc.inventory.InventoryManager)- Resource has a bad config, waiting for this to go away: Resource[id=10124, uuid=3d451234-7e96-4150-84ec-a4a3c666f56c, type={JBossAS5}JBossAS Server, key=E:\opt\jboss\jboss-eap-5.2\jboss-as\opt\jboss\jboss-eap-5.2\jboss-as\server\default, name=EAP 127.0.0.1:1199 default, parent=10.16.23.233, version=EAP 5.2.0]
2013-11-05 01:43:59,331 WARN  [InventoryManager.availability-1] (rhq.core.pc.inventory.AvailabilityExecutor)- Availability collection failed with exception on Resource[id=10124, uuid=3d451234-7e96-4150-84ec-a4a3c666f56c, type={JBossAS5}JBossAS Server, key=E:\opt\jboss\jboss-eap-5.2\jboss-as\opt\jboss\jboss-eap-5.2\jboss-as\server\default, name=EAP 127.0.0.1:1199 default, parent=10.16.23.233, version=EAP 5.2.0], availability will be reported as DOWN
org.rhq.core.pluginapi.inventory.InvalidPluginConfigurationException: Failed to start component for resource Resource[id=10124, uuid=3d451234-7e96-4150-84ec-a4a3c666f56c, type={JBossAS5}JBossAS Server, key=E:\opt\jboss\jboss-eap-5.2\jboss-as\opt\jboss\jboss-eap-5.2\jboss-as\server\default, name=EAP 127.0.0.1:1199 default, parent=10.16.23.233, version=EAP 5.2.0].
        at org.rhq.core.pc.inventory.InventoryManager.activateResource(InventoryManager.java:1937)
        at org.rhq.core.pc.inventory.AvailabilityExecutor.checkInventory(AvailabilityExecutor.java:343)
        at org.rhq.core.pc.inventory.AvailabilityExecutor.startScan(AvailabilityExecutor.java:197)
        at org.rhq.core.pc.inventory.CustomScanRootAvailabilityExecutor.startScan(CustomScanRootAvailabilityExecutor.java:71)
        at org.rhq.core.pc.inventory.AvailabilityExecutor.call(AvailabilityExecutor.java:152)
        at org.rhq.core.pc.inventory.AvailabilityExecutor.call(AvailabilityExecutor.java:62)
        at java.util.concurrent.FutureTask.run(FutureTask.java:262)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:744)
Caused by: org.rhq.core.pluginapi.inventory.InvalidPluginConfigurationException: Configuration path 'e:\opt\jboss\jboss-eap-5.2\jboss-as\opt\jboss\jboss-eap-5.2\jboss-as\server\default' does not exist.
        at org.rhq.plugins.jbossas5.ApplicationServerComponent.getConfigurationPath(ApplicationServerComponent.java:590)
        at org.rhq.plugins.jbossas5.ApplicationServerComponent.start(ApplicationServerComponent.java:195)
        at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocation.call(ResourceContainer.java:654)
        at java.util.concurrent.FutureTask.run(FutureTask.java:262)

Created attachment 819814 [details]
eap5 connection settings

customer issue, and rejected by QE.  i am tentatively adding the JON 3.2 blocker .... to flag this.  this should be re-triaged at the 11/11/2013 BZ Triage meeting ...with input from GSS on the impact of this.

I think the problem is in the method "resolvePathRelativeToHomeDir".

Crazy thing is - there's more than one of these in more than one plugin! So I have a feeling this latest problem potentially exists for JBossAS 4, JBossAS 5, Tomcat, and Apache servers running on windows and configured without a drive letter!

See these:

===== JBOSS AS 4 PLUGIN:

org.rhq.plugins.jbossas.JBossASServerComponent.resolvePathRelativeToHomeDir(Configuration, String)

===== JBOSS AS 5 PLUGIN:

org.rhq.plugins.jbossas5.ApplicationServerComponent.resolvePathRelativeToHomeDir(String)

org.rhq.plugins.jbossas5.ApplicationServerDiscoveryComponent.resolvePathRelativeToHomeDir(Configuration, String)

org.rhq.plugins.jbossas5.ApplicationServerOperationsDelegate.resolvePathRelativeToHomeDir(Configuration, String)

===== TOMCAT PLUGIN:

org.jboss.on.plugins.tomcat.TomcatServerComponent.resolvePathRelativeToHomeDir(Configuration, String)

===== APACHE PLUGIN:

org.rhq.plugins.apache.ApacheServerComponent.resolvePathRelativeToServerRoot(Configuration, String)

I think the same kind of solution can be applied here as in the original patch. 

        if (!configDir.isAbsolute()) {

can be changed to

        if (!configDir.isAbsolute() && !configDir.isDirectory()) {

since, on Windows, if the only thing missing is the drive letter, that isDirectory should return true in this case (assuming the JVM current working directory's drive letter is the same - which we want to ensure anyway).

Yes. However, the only reason I didn't use isDirectory in my original suggested fix was because it was not clear what isDirectory would do with symbolic links or shortcuts on some platforms. But perhaps that was just paranoia.

(In reply to Larry O'Leary from comment #9)
> Yes. However, the only reason I didn't use isDirectory in my original
> suggested fix was because it was not clear what isDirectory would do with
> symbolic links or shortcuts on some platforms. But perhaps that was just
> paranoia.

Ran the following test - in short, isDirectory returns true even for relative path symlinks:

$ cat Tmp.java
import java.io.*;
public class Tmp {
   public static void main(String[] args) {
      File file = new File("mazzwashere");
      System.out.println("file: " + file);
      System.out.println("abs-path: " + file.getAbsolutePath());
      System.out.println("is-absolute: " + file.isAbsolute());
      System.out.println("exists: " + file.exists());
      System.out.println("is-dir: " + file.isDirectory());
   }
}

$ ls -ld mazzwashere
lrwxrwxrwx 1 mazz mazz 3 Nov 11 11:10 mazzwashere -> foo

$ java Tmp
file: mazzwashere
abs-path: /home/mazz/tmp/mazzwashere
is-absolute: false
exists: true
is-dir: true

of course, this change would have to assume all paths being processed ARE directories that actually exist. If the path being used isn't created yet or isn't a directory, this doesn't do what I want.

Similarily, if we just use .exists() - we assume the path already exists, or, again, it won't do what we want.

This was OK in the original patch because the run.jar should always exist.

I'll have to look more deeply at the callers of these methods to see if we can assume things like "it always exists" or "its always an existing directory".

git commit to master: aab2317

want to do more testing before pushing to release/jon3.2.x branch

I ran tests on a Windows 2008 machine and all looks to be working now. I will commit to the release/3.2.x branch shortly

(In reply to John Mazzitelli from comment #13)
> I ran tests on a Windows 2008 machine and all looks to be working now. I
> will commit to the release/3.2.x branch shortly

git commit to release/3.2.x: 50324de

Moving to ON_QA as available for testing with new brew build.

Mass moving all of these from ER6 to target milestone ER07 since the ER6 build was bad and QE was halted for the same reason.

Verified with JON 3.2.0.ER7 and EAP 5.2.0