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

Thu Jan 7 02:57:18 EST 2016

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 at localhost:9990 /] deploy
> /manual-overlay-tests/original-archives/mixed1-foo.ear
> [standalone at 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 at localhost:9990 /] deployment-overlay remove
> --name=staticContentOverlay --redeploy-affected
> [standalone at localhost:9990 /] undeploy mixed1-foo.ear
> 
> And second one, not working example:
> 
> # deploying foo.ear plus overlays
> [standalone at localhost:9990 /] deploy
> /manual-overlay-tests/original-archives/foo.ear
> [standalone at 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 at localhost:9990 /] deployment-overlay remove
> --name=staticContentOverlay --redeploy-affected
> [standalone at 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/as/ee/structure/EarStructureProcessor.java#L271
> > [2]
> > https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/org/jboss/as/server/deployment/DeploymentOverlayDeploymentUnitProcessor.java#L111-L112
> > [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/org/jboss/as/server/deployment/DeploymentOverlayDeploymentUnitProcessor.java
> >> [2]
> >> https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/org/jboss/as/server/deployment/DeferredDeploymentOverlayDeploymentUnitProcessor.java
> >>
> >> Best Regards
> >> --
> >> Lin Gao
> >> JBoss Software Engineer
> >>
> >>
> >>
> >> _______________________________________________
> >> wildfly-dev mailing list wildfly-dev at 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 at 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
> 
> 