Bug 991244 - An exploded war inside an archived ear returns 404 in EAP 6
Summary: An exploded war inside an archived ear returns 404 in EAP 6
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Microcontainer and Deployers
Version: 6.1.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ER4
: EAP 6.2.0
Assignee: Emmanuel Hugonnet (ehsavoie)
QA Contact:
Russell Dickenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-01 23:52 UTC by Masafumi Miura
Modified: 2018-12-02 16:04 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-15 16:16:30 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker WFLY-2028 0 Major Resolved An exploded war inside an archived ear returns 404 2016-08-17 08:42:53 UTC

Description Masafumi Miura 2013-08-01 23:52:53 UTC
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 13:20:53 UTC
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 15:47:04 UTC
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 13:21:05 UTC
Emmanuel Hugonnet <ehugonne> updated the status of jira WFLY-2028 to Coding In Progress

Comment 4 Emmanuel Hugonnet (ehsavoie) 2013-09-10 14:55:48 UTC
PR: https://github.com/jbossas/jboss-eap/pull/388

Comment 5 JBoss JIRA Server 2013-09-17 21:50:01 UTC
Thomas Frühbeck <fruehbeck> 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 12:41:36 UTC
Verified in 6.2.0.CR3.


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