Created attachment 758347 [details]
tar with the module that shows the problem

Here's how to replicate this. I tried this on AS7.1.1.Final to show it works find (and we know it works on EAP 6.1.alpha because this is what RHQ is running on).

This only begins to FAIL on "EAP 6.1.0.GA (AS 7.2.0.Final-redhat-8)"

Here's the steps, assuming you have a out-of-box EAP 6.1.GA unzipped on your machine under some <eap-install> directory:

1) Take the attached tar and untar it in the AS modules/ location (this means on EAP6.1.GA, you untar it while in the "<eap-install>/modules/system/layers/base/" directory). You will end up with a "org/rhq/rhq-enterprise-server-startup-subsystem" module.

2) edit <eap-install>/standalone/configuration/standalone-full.xml and add two lines - one an extension and one a subsystem:

2a) Before the </extensions> end tag, insert a new extension:

     <extension module="org.rhq.rhq-enterprise-server-startup-subsystem"/> <!-- add this-->
 </extensions>
 
2b) Before the </profile> end tag, add a new subsystem:

     <subsystem xmlns="urn:org.rhq:startup:1.0"/> <!-- add this! -->
 </profile>

3) now start the server, this stub code requires a system property to be set to your EAP install directory (<eap-install>); you only need this for the code to run (it is a vestige of the production code I snipped for this test module, it is unrelated to this bug being reported)

<eap-install>/bin/standalone.sh -c standalone-full.xml -Drhq.server.home=<eap-install>

Now look at the server output. In AS 7.1.1.Final and EAP 6.1.alpha, you'll see this:

17:25:21,744 INFO  [stdout] ~~~~~~~~~~~~~URL: file:/home/mazz/bin/jbossas/jboss-as-7.1.1.Final/modules/org/rhq/rhq-enterprise-server-startup-subsystem/main/deployments/rhq.ear/
17:25:21,747 INFO  [stdout] ~~~~~~~~~~~~~paths has ear: true

That's good - it got a non-null URL pointing to our module's resource-root of deployments/ where the rhq.ear can be found.

HOWEVER, now run this in EAP 6.1.GA and you get this:

17:29:03,689 INFO  [stdout] (ServerService Thread Pool -- 30) ~~~~~~~~~~~~~URL: null
17:29:03,695 INFO  [stdout] (ServerService Thread Pool -- 30) ~~~~~~~~~~~~~paths has ear: true

Note the oddity here - now the URL was null - JBossModules failed to find our deployments resource-root. BUT!!! It still says it can find our rhq.ear under there.

The APIs in question is this:

            Module module = Module.forClass(getClass());
            URL url = module.getExportedResource("rhq.ear");
            System.out.println("~~~~~~~~~~~~~URL: " + url);
            Set<String> paths = module.getExportedPaths();
            System.out.println("~~~~~~~~~~~~~paths has ear: " + paths.contains("rhq.ear"));

Now, why does JBoss Modules tell us the rhq.ear path exists in the returned set of getExportedPaths, but yet it can't return the URL to that path it says exists via the getExportedResource() method? There seems to be an incongruence here.

I will attach a zip with the source code for the attached module's jar so you can see the exact code. This code I show above is in the StartupSubsystemAdd class.

Created attachment 758348 [details]
source tarball for the code of the test module that shows the bug

source.tar is the tarball that contains the source code for the module that I attached previously

BTW: this extension-being-used-to-deploy-an-ear was the "Mixed Approach" recommended by Brian S as explained on his Extending AS7 wiki page here: https://community.jboss.org/wiki/ExtendingAS7

And this did work on earlier EAP versions - it worked fine on AS7.1.1.Final and EAP6.1.alpha. It only stopped working once on EAP6.1.GA.

I've created (and resolved): https://issues.jboss.org/browse/MODULES-167

Loading resources for directories is non-spec behavior, but it seems to be commonly desired, so I don't object to adding it where it makes sense to do so.  That said - I'm not certain that JBoss Modules itself is the culprit here.  If you're talking about a module corresponding to a deployment, then VFSResourceLoader is where the pertinent logic is located, in the EAP code base.

The patch found in bug #975242 seems to have fixed the problem. When I run the same replication procedures (using a JON 3.2 build), I now see this in the output:

13:20:41,284 INFO  [stdout] (ServerService Thread Pool -- 30) ~~~~~~~~~~~~~URL: file:/home/mazz/Downloads/jon-server-3.2.0.ALPHA_QA/modules/org/rhq/rhq-enterprise-server-startup-subsystem/main/deployments/rhq.ear/
13:20:41,286 INFO  [stdout] (ServerService Thread Pool -- 30) ~~~~~~~~~~~~~paths has ear: true

So it looks like its able to find the directory again.

The patch I tried is attached in this comment: https://bugzilla.redhat.com/show_bug.cgi?id=975242#c3

jboss-module 1.2.2.Final contains the bug fix. we might need an upgrade for next EAP 6.1.1 release.

#975143 is on "MODIFIED" which has already updated version to 1.2.2.Final on EAP 6.1.x branch

verified on EAP 6.1.1.ER4

Verified on EAP 6.1.1.ER7