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

Wed Jan 6 17:21:39 EST 2016

Hi Lin,

On 01/06/2016 07:19 AM, Lin Gao wrote:
> Hi Richard,
>
>    Thank you for the reply. :-)
>
>> 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 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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo.ear
Type: application/octet-stream
Size: 5410 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160106/afe8cc47/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mixed1-foo.ear
Type: application/octet-stream
Size: 6674 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160106/afe8cc47/attachment-0003.obj 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160106/afe8cc47/attachment-0002.html 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160106/afe8cc47/attachment-0003.html 