Bug 991244 - An exploded war inside an archived ear returns 404 in EAP 6
An exploded war inside an archived ear returns 404 in EAP 6
Status: CLOSED CURRENTRELEASE
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Microcontainer and Deployers (Show other bugs)
6.1.0
Unspecified Unspecified
unspecified Severity unspecified
: ER4
: EAP 6.2.0
Assigned To: Emmanuel Hugonnet (ehsavoie)
Russell Dickenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-01 19:52 EDT by Masafumi Miura
Modified: 2013-12-15 11:16 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-15 11:16:30 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker WFLY-2028 Major Resolved An exploded war inside an archived ear returns 404 2016-08-17 04:42 EDT

  None (edit)
Description Masafumi Miura 2013-08-01 19:52:53 EDT
Created attachment 781787 [details]
reproducer

Description of problem:

When an archived ear which includes an exploded war is deployed in EAP 6, the application seems to be deployed successfully but it returns status code 404. 


How reproducible:

Everytime.


Steps to Reproduce:

1. Start EAP 6 standalone mode
2. Put the attached test.ear to $JBOSS_HOME/standalone/deployments
3. Access the web application
    curl -v http://localhost:8080/test/index.jsp 


Actual results:

JBoss returns status code 404.


Expected results:

JBoss returns actual response of web application's content.


Additional info:

Same application works in EAP 5. When an application is an exploded ear which includes an exploded war, it works in EAP 6.
Comment 1 Bjarke Skjernaa 2013-08-09 09:20:53 EDT
The problem also exists in 6.0.1.

We have an ear file with a war directory inside (the ear is a zip, the war is just a directory in the ear). From a servlet in the war we try to get a resource from the war but we just get null.

If either the ear file is deployed as a directory instead of zipped or the war archive is zipped instead of just a directory it works. The resource is retrieved by

ServletContext context = config.getServletContext();
context.getResourceAsStream(name)
Comment 2 Emmanuel Hugonnet (ehsavoie) 2013-09-09 11:47:04 EDT
https://github.com/ehsavoie/wildfly/compare/WFLY-2028 for a view on the current fix for Wildfly
Comment 3 JBoss JIRA Server 2013-09-10 09:21:05 EDT
Emmanuel Hugonnet <ehugonne@redhat.com> updated the status of jira WFLY-2028 to Coding In Progress
Comment 4 Emmanuel Hugonnet (ehsavoie) 2013-09-10 10:55:48 EDT
PR: https://github.com/jbossas/jboss-eap/pull/388
Comment 5 JBoss JIRA Server 2013-09-17 17:50:01 EDT
Thomas Frühbeck <fruehbeck@aon.at> made a comment on jira WFLY-2028

this change completely nukes exploded deployments (e.g. as in JBossTools) 

 private Closeable exportExplodedWar(final boolean war, final VirtualFile file) throws IOException {
        if (war && !file.isFile()) {
            File warContent = file.getPhysicalFile();
            VFSUtils.recursiveCopy(file, warContent.getParentFile());
 
seems to completly overwrite the files with itself.
If write protecting files in deployment, below exception is thrown:

23:09:29,392 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."mssms-ear.ear".STRUCTURE: org.jboss.msc.service.Sta
rtException in service jboss.deployment.unit."mssms-ear.ear".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "mssms-ear.ear"
        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
        at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011060: Failed to process children for EAR ["/work/java/wildfly-8.0.0.Beta1-SNAPSHOT/standalone/deplo
yments/mssms-ear.ear"]
        at org.jboss.as.ee.structure.EarStructureProcessor.deploy(EarStructureProcessor.java:237)
        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
        ... 5 more
Caused by: java.io.FileNotFoundException: /work/java/wildfly-8.0.0.Beta1-SNAPSHOT/standalone/deployments/mssms-ear.ear/mssms.war/css/test.css (Keine Berechtigung)
        at java.io.FileOutputStream.open(Native Method) [rt.jar:1.7.0_40]
        at java.io.FileOutputStream.<init>(FileOutputStream.java:221) [rt.jar:1.7.0_40]
        at java.io.FileOutputStream.<init>(FileOutputStream.java:171) [rt.jar:1.7.0_40]
        at org.jboss.vfs.VFSUtils.recursiveCopy(VFSUtils.java:725)
        at org.jboss.vfs.VFSUtils.recursiveCopy(VFSUtils.java:722)
        at org.jboss.vfs.VFSUtils.recursiveCopy(VFSUtils.java:722)
        at org.jboss.as.ee.structure.EarStructureProcessor.exportExplodedWar(EarStructureProcessor.java:277)
        at org.jboss.as.ee.structure.EarStructureProcessor.createResourceRoot(EarStructureProcessor.java:261)
        at org.jboss.as.ee.structure.EarStructureProcessor.deploy(EarStructureProcessor.java:192)
        ... 6 more
Comment 9 Jan Martiska 2013-12-06 07:41:36 EST
Verified in 6.2.0.CR3.

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