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

Thu Jan 7 04:28:33 EST 2016

Hi Lin,

On 01/07/2016 08:57 AM, Lin Gao wrote:
> 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. :-)
I thought so.
>
>> 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!~
You are welcome Lin.
>
> 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
>>
>>

-- 
Richard Opalka
Principal Software Engineer
JBoss by Red Hat
Mobile: +420 731 186 942