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.
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.
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. :-)
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. :-)
Since the PR to remove VFS is up, I think my PRs[3] won't get merged any way.
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!~ :-)
[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