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

>> 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.

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

>> 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 :(

> > 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.

> [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