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