Re: [wildfly-dev] Do we support overlay for files in jar of war of ear?

Hi Richard, >>> our current 'Overlay feature" implementation is quite limited to be >>> honest. >>> It is not possible to introduce new files inside jar inside war that is in >>> ear. >>> The only exception is if war is exploded inside ear. >> I don't think there is any difference on exploded or not of war from >> structure >> POV(in case of war inside ear), EarStructureProcessor[1] will explode the >> war if >> the war is a file inside ear, and will copy it to temporary directory if it >> is a >> directory inside ear. > There is a difference if war is packaged or exploded in ear from > overlays implementation point of view. > And I was talking about current overlay implementation. What it does and > what it doesn't. Ah, yes, I see your point now. :-) I tested overlay static files for packaged war inside ear, it worked because I used the one with the hot fix applied. :-)

> Attached is a simple example you can use to reproduce the problem on > Wildfly master: > > * foo.ear //contains packaged app.war inside > * mixed1-foo.ear //contains exploded app.war inside > * index.html // overlayed index.html > * overlay.jsp // overlay for non existing JSP file > > Execute the following commands in jboss-cli.sh: > > Let's do working example first: > > # deploying mixed1-foo.ear plus overlays > [standalone@localhost:9990 /] deploy > /manual-overlay-tests/original-archives/mixed1-foo.ear > [standalone@localhost:9990 /] deployment-overlay add > --name=staticContentOverlay > --content=/app.war/overlay.jsp=/manual-overlay-tests/overlays/overlay.jsp,/app.war/index.html=/manual-overlay-tests/overlays/index.html > --deployments=*ear --redeploy-affected > > and open new browser window for URL http://localhost:8080/app > You will see overlayed index.html. Further more overlay.jsp link will work. > > # remove overlay and mixed1-foo.ear deployment > [standalone@localhost:9990 /] deployment-overlay remove > --name=staticContentOverlay --redeploy-affected > [standalone@localhost:9990 /] undeploy mixed1-foo.ear > > And second one, not working example: > > # deploying foo.ear plus overlays > [standalone@localhost:9990 /] deploy > /manual-overlay-tests/original-archives/foo.ear > [standalone@localhost:9990 /] deployment-overlay add > --name=staticContentOverlay > --content=/app.war/overlay.jsp=/manual-overlay-tests/overlays/overlay.jsp,/app.war/index.html=/manual-overlay-tests/overlays/index.html > --deployments=*ear --redeploy-affected > > and open new browser window for url http://localhost:8080/app (be aware > of browser caches). > You will see original index.html. And overlay.jsp link is will be > unfunctional. > > # remove overlay and foo.ear deployment > [standalone@localhost:9990 /] deployment-overlay remove > --name=staticContentOverlay --redeploy-affected > [standalone@localhost:9990 /] undeploy foo.ear I can reproduce the issue using your example on wildfly master, and with my hot fix applied, it works well. :-) >>> Further more it is not possible to overlay static content inside wars >>> (although Wildfly documentation for overlays feature promises that). >>> The reason is every war is exploded to temporary location during >>> the deploy process and >>> >>> org.wildfly.extension.undertow.deployment.ServletResourceManager >>> >>> obtains physical location of that exploded archive and passes it to >>> FileResourceManager / PathResourceManager in its constructor. >>> >>> This at first sight innocent hack bypasses all VFS modifications. >>> So although you would mount war static files properly via overlays, >>> those overlays will be completely ignored. >>> The only exception are deployment descriptors, >>> which are processed during the deployment phase. >>> >>> Note: Don't get confused with overlays in ServletResourceManager. >>> Those are Undertow specific and have nothing to do with WildfFly >>> deployment >>> overlays. >> Actually it can overlay static content within WAR, the >> DeploymentOverlayDeploymentUnitProcessor[2] >> will replace the file in the exploded temporary directory with the content >> user wants to overlay. > Yes, but it will work only for exploded wars in ears, see example above. > Not for packaged wars. > >>> In order to fix your concrete problem (i.e. adding new file inside >>> jar in war in ear) I'd guess fixing just DeploymentOverlay processors will >>> be >>> insufficient. >>> With high probability you'll need to revisit also >>> WarDeploymentStructureProcessor. >> Yeah, I thought it too, but it will require >> WarStructureDeploymentProcessor to access its parent >> DeploymentUnit's attachment for deferred overlays, even deferred after >> DeferredDeploymentOverlayDeploymentUnitProcessor for the top level EAR >> deployment, I don't >> know whether it is correct way to do this. :-) > This wouldn't be proper way to fix it because > DeferredDeploymentOverlayDeploymentUnitProcessor > must be the last STRUCTURE processor in the chain. > There's > deploymentUnit.getAttachment(Attachments.DEPLOYMENT_OVERLAY_LOCATIONS) > available > for your convenience. You can use it in EAR or WAR structure processors. >>> Good news is 'Wildfly Deployment Overlays' should work without any >>> limitations in >>> upcomming Wildfly 11. There's a PR eliminating Wildfly dependency on JBoss >>> VFS: >>> >>> https://github.com/wildfly/wildfly-core/pull/1261 >>> >>> The PR incorporates 'Deployment Overlay' complete rewrite with no >>> limitations >>> current implementation has. >> Hope it can resolve all overlay related issues. :-) > Definitely, because of new simplified overlays rewrite. >> Since the PR to remove VFS is up, I think my PRs[3] won't get merged any >> way. > I reviewed both PRs. The one providing test cases should be merged to > Wildfly master > because of the enhanced test coverage. The second introducing the wars > hot fix > looks good to me as well. Anyway there are many other overlay issues > still remaining :( Thank you for the review. :-) I sent another PRs to downstream product repos. >> But 2 downstream product issues[4] depend on this, so I will keep the my >> PRs open, >> if we can leave the overlay for files in jar of war inside ear, could you >> please >> review the PRs in [3] to see whether it is OK? Thanks!~ :-) > PRs reviewed, I'm fine with them. Thanks again!~

Best Regards -- Lin Gao Software Engineer JBoss by Red Hat >> [1] >> https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss... >> [2] >> https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... >> [3] https://github.com/wildfly/wildfly-core/pull/1332 and >> https://github.com/wildfly/wildfly/pull/8528 >> [4] https://bugzilla.redhat.com/show_bug.cgi?id=1147352 and >> https://issues.jboss.org/browse/JBEAP-2491 >> >> Best Regards >> -- >> Lin Gao >> JBoss Software Engineer >> >> >>> On 12/23/2015 05:17 PM, Lin Gao wrote: >>> >>> >>> >>> Hi, >>> >>> I am working on https://issues.jboss.org/browse/WFCORE-761 for a while, >>> and I >>> am stuck in the case of overlaying files in jar of war of ear. >>> >>> I want to know that do we support overlay for files in jar of war of ear? >>> like: xx.ear/yy.war/zz.jar/META-INF/config.properties >>> >>> DeploymentOverlayDeploymentUnitProcessor.java[1] and >>> DeferredDeploymentOverlayDeploymentUnitProcessor.java[2] are classes to >>> handle the deployment overlay, but in this case, the jar of war of ear >>> does >>> not get mounted yet, which leads to >>> DeferredDeploymentOverlayDeploymentUnitProcessor.handleEntryWithFileParent() >>> method is called, which just prints the error message. >>> >>> The way to fix it maybe mount the jar(VFS.mountZip) beforehand, but it is >>> specific to the case of ear/war/jar, and these 2 classes are more >>> generic(they are in wildfly-core, no ee nor undertow extension), so where >>> this can be fixed? >>> >>> [1] >>> https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... >>> [2] >>> https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... >>> >>> Best Regards >>> -- >>> Lin Gao >>> JBoss Software Engineer >>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> -- >>> Richard Opalka >>> Principal Software Engineer >>> JBoss by Red Hat >>> Mobile: +420 731 186 942 >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- > Richard Opalka > Principal Software Engineer > JBoss by Red Hat > Mobile: +420 731 186 942 > >