[jboss-jira] [JBoss JIRA] (WFLY-3726) Filesystem deployment scanner deployment failure removes unrelated deployments

[Jess Holle (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-3726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12992069#comment-12992069 ] 

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)