[
https://issues.jboss.org/browse/WFLY-3726?page=com.atlassian.jira.plugin....
]
Jess Holle commented on WFLY-3726:
----------------------------------
One possible workaround would be avoid the explicit deployment of the war directory and
deploy it via a deployment scanner as well.
Unfortunately, the .web app parent directory contains numerous files and sub-directories
which must remain at their current relative locations to the web app directory, so I
can't just move the .war directory directly under a deployment scanner.
I originally thought to simply place this war directory's parent directory in a
deployment scanner directory, call it MyApp.ear, and treat MyApp.ear as a ear directory.
This web app is coming from Tomcat (where we simply used an app-xxxx.xml file to deploy
the web app), so it doesn't actually have a logical enterprise app, but there seemed
little harm in this from my reading of the spec.
Unfortunately this failed. From my reading of the EE specs, it seems like only .war,
.rar, .jar, etc, files in the top-level of the ear and the lib directory should be
scanned, yet it appears Wildfly scans much, much more than this -- causing a deployment
failure due to jars in sub-directories that are not to its liking. Do I misunderstand the
spec here? Is there a way to tell Wildfly not to scan so much? If so and I could get
Wildfly to auto-deploy this as an ear, then I could avoid the explicit deployment
entirely.
Filesystem deployment scanner deployment failure removes unrelated
deployments
------------------------------------------------------------------------------
Key: WFLY-3726
URL:
https://issues.jboss.org/browse/WFLY-3726
Project: WildFly
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Domain Management
Affects Versions: 8.0.0.Final
Environment: WIndows and Linux platforms both exhibit the issue
Reporter: Jess Holle
Assignee: Emmanuel Hugonnet
If one's standalone-full.xml configuration contains something like:
<deployments>
<deployment name="MyWebApp.war" runtime-name="MyWebApp.war"
enabled="true">
<fs-exploded path="../../SomeDir/MyWebApp.war"
relative-to="jboss.home.dir"/>
</deployment>
</deployments>
whether manually inserted (while the server is not running) or installed via the CLI via
/deployment=ServiceCenter.war/:add(runtime-name=ServiceCenter.war,content=[{archive=false,path="../../Windchill/ServiceCenter.war",relative-to="jboss.home.dir"}])
and a deployment scanner like:
<subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">
<deployment-scanner name="1" path="../../../Applications"
relative-to="jboss.server.base.dir" scan-interval="5000"
auto-deploy-exploded="true"/>
</subsystem>
a failure by a deployment-scanner to deploy an application (exploded in my case, though
I'm not sure this makes a difference) will cause the explicitly listed
<deployments> to be removed from the configuration!
This occurs irrespective of the value used for auto-deploy-exploded and to
<deployment> elements that had already successfully been deployed and started.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)