Bug 972233 - Jboss Modules behaviour changed between EAP6.0/EAP6.1 Alpha and EAP6.1GA
Jboss Modules behaviour changed between EAP6.0/EAP6.1 Alpha and EAP6.1GA
Status: CLOSED CURRENTRELEASE
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Microcontainer and Deployers (Show other bugs)
6.1.0
Unspecified Unspecified
urgent Severity urgent
: ER4
: EAP 6.1.1
Assigned To: Chao Wang
:
Depends On: 975143 978896
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-07 17:31 EDT by Charles Crouch
Modified: 2015-02-01 18:28 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-16 16:23:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
msimka: needinfo-


Attachments (Terms of Use)
tar with the module that shows the problem (30.00 KB, application/x-tar)
2013-06-07 17:44 EDT, John Mazzitelli
no flags Details
source tarball for the code of the test module that shows the bug (30.00 KB, application/x-tar)
2013-06-07 17:45 EDT, John Mazzitelli
no flags Details

  None (edit)
Description Charles Crouch 2013-06-07 17:31:25 EDT
(3:47:57 PM) mazz: folks - does anyone know of behavioral differents between EAP 6.1 alpha and EAP 6.1. GA related to JBoss Modules and the module.xml <resource-root> stuff?
(3:48:05 PM) mazz: what used to work in alpha no longer works in GA
(3:48:24 PM) mazz: we have this in module.xml:    <resources>  <resource-root path="deployments"/>  </resources>
(3:48:41 PM) mazz:                 URL url = module.getExportedResource("rhq.ear");
(3:49:03 PM) mazz: used to return the URL to the exploded rhq.ear found under our main/deployments (there is an actual ear here)
(3:49:14 PM) mazz: but when we moved to EAP 6.1.GA, that API is returning null
(3:49:35 PM) mazz: completely breaks JON when running on top of EAP 6.1.GA
(3:49:45 PM) mazz: but again, this works fine on EAP 6.1.alpha
Comment 1 John Mazzitelli 2013-06-07 17:44:05 EDT
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.
Comment 2 John Mazzitelli 2013-06-07 17:45:48 EDT
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
Comment 3 John Mazzitelli 2013-06-07 18:07:40 EDT
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.
Comment 4 David M. Lloyd 2013-06-10 09:36:33 EDT
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.
Comment 5 John Mazzitelli 2013-06-18 13:22:18 EDT
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
Comment 6 Chao Wang 2013-06-27 05:13:18 EDT
jboss-module 1.2.2.Final contains the bug fix. we might need an upgrade for next EAP 6.1.1 release.
Comment 7 Chao Wang 2013-07-02 22:15:35 EDT
#975143 is on "MODIFIED" which has already updated version to 1.2.2.Final on EAP 6.1.x branch
Comment 9 Martin Simka 2013-08-07 04:37:49 EDT
verified on EAP 6.1.1.ER4
Comment 10 Ondrej Chaloupka 2013-08-29 09:03:56 EDT
Verified on EAP 6.1.1.ER7

Note You need to log in before you can comment on or make changes to this bug.