[JBoss JIRA] (ELY-42) Vault
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-42:
-----------------------------------
Summary: Vault
Key: ELY-42
URL: https://issues.jboss.org/browse/ELY-42
Project: WildFly Elytron
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: API / SPI
Reporter: Darran Lofthouse
Fix For: 1.0.0.Beta1
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (WFLY-3727) Clustering service race condition causing NPE on channel startup
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3727?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-3727:
-------------------------------
Description:
{noformat}
ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 30) MSC000001: Failed to start service jboss.infinispan.ejb.global-component-registry: org.jboss.msc.service.StartException in service jboss.infinispan.ejb.global-component-registry: org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type ChannelTransport
at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:91)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
Caused by: org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type ChannelTransport
at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:241)
at org.jboss.as.clustering.infinispan.subsystem.GlobalComponentRegistryService.start(GlobalComponentRegistryService.java:33)
at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:86)
... 4 more
Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type ChannelTransport
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:219)
... 6 more
Caused by: org.infinispan.commons.CacheException: Unable to start JGroups Channel
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:198)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:187)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51]
at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
... 11 more
Caused by: java.lang.NullPointerException
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1010)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:245)
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:391)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147)
at org.jgroups.protocols.FD.up(FD.java:255)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301)
at org.jgroups.protocols.MERGE2.up(MERGE2.java:209)
at org.jgroups.protocols.Discovery.up(Discovery.java:522)
at org.jgroups.protocols.MPING.up(MPING.java:181)
at org.jgroups.protocols.TP.fetchLocalAddresses(TP.java:2001)
at org.jgroups.protocols.TP.start(TP.java:1131)
at org.jgroups.protocols.TCP.start(TCP.java:82)
at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:938)
at org.jgroups.JChannel.startStack(JChannel.java:864)
at org.jgroups.JChannel._preConnect(JChannel.java:527)
at org.jgroups.JChannel.connect(JChannel.java:284)
at org.jgroups.JChannel.connect(JChannel.java:275)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:196)
... 17 more
{noformat}
> Clustering service race condition causing NPE on channel startup
> ----------------------------------------------------------------
>
> Key: WFLY-3727
> URL: https://issues.jboss.org/browse/WFLY-3727
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.1.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 9.0.0.Beta1
>
>
> {noformat}
> ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 30) MSC000001: Failed to start service jboss.infinispan.ejb.global-component-registry: org.jboss.msc.service.StartException in service jboss.infinispan.ejb.global-component-registry: org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type ChannelTransport
> at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:91)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type ChannelTransport
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:241)
> at org.jboss.as.clustering.infinispan.subsystem.GlobalComponentRegistryService.start(GlobalComponentRegistryService.java:33)
> at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:86)
> ... 4 more
> Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type ChannelTransport
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:219)
> ... 6 more
> Caused by: org.infinispan.commons.CacheException: Unable to start JGroups Channel
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:198)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:187)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51]
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
> ... 11 more
> Caused by: java.lang.NullPointerException
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1010)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:245)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:391)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147)
> at org.jgroups.protocols.FD.up(FD.java:255)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301)
> at org.jgroups.protocols.MERGE2.up(MERGE2.java:209)
> at org.jgroups.protocols.Discovery.up(Discovery.java:522)
> at org.jgroups.protocols.MPING.up(MPING.java:181)
> at org.jgroups.protocols.TP.fetchLocalAddresses(TP.java:2001)
> at org.jgroups.protocols.TP.start(TP.java:1131)
> at org.jgroups.protocols.TCP.start(TCP.java:82)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:938)
> at org.jgroups.JChannel.startStack(JChannel.java:864)
> at org.jgroups.JChannel._preConnect(JChannel.java:527)
> at org.jgroups.JChannel.connect(JChannel.java:284)
> at org.jgroups.JChannel.connect(JChannel.java:275)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:196)
> ... 17 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (WFLY-3705) read-resource recursive-depth has no effect when recursive=true
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-3705?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov commented on WFLY-3705:
--------------------------------------
Latest pull has only 11 tests failing.
Is it worth pursuing trying to implement the logic as stated in the docs?
11 test changes are, potentially, fixable and errata may allow to take care of the client code.
> read-resource recursive-depth has no effect when recursive=true
> ---------------------------------------------------------------
>
> Key: WFLY-3705
> URL: https://issues.jboss.org/browse/WFLY-3705
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Documentation, Domain Management
> Affects Versions: 8.1.0.Final
> Environment: Linux aimobile-sm.servicemesh.com 3.15.7-200.fc20.x86_64 #1 SMP Mon Jul 28 18:50:26 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Arcadiy Ivanov
> Assignee: Brian Stansberry
>
> The code inside ReadResourceHandler.doExecuteInternal(OperationContext context, ModelNode operation) goes as follows:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = recursiveDepth > 0 || operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false);
> {noformat}
> The [documentation|https://docs.jboss.org/author/display/WFLY8/Global+operations] states:
> recursive-depth – (int) – The depth to which information about child resources should be included *if recursive is {{true}*. If not set, the depth will be unlimited; i.e. all descendant resources will be included.
> The logic, however, as implemented goes - either recursive-depth is greater than zero OR recursive is true.
> The proper implementation should be:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false) &&
> (!operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).isDefined() || recursiveDepth > 0);
> {noformat}
> The above snippet works as follows: recurs IF recursive is set AND (either recursive-depth is not defined OR recursive-depth is greater than 0).
>
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (WFCORE-49) Limit deployment scanner to a list of deployments
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-49:
--------------------------------------
Summary: Limit deployment scanner to a list of deployments
Key: WFCORE-49
URL: https://issues.jboss.org/browse/WFCORE-49
Project: WildFly Core
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Domain Management
Reporter: Brian Stansberry
Priority: Minor
The basic scenario here is there's a file /some/path/to/foo.war that users want deployed via a scanner, but /some/path/to includes other files that can't be moved and that should not be scanned. There's no way to limit the scanner to foo.war and related marker files.
Allowing configuration of an explicit whitel list of (non-marker) files to consider, or a black list of ones to ignore, would allow this use case.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (WFCORE-49) Limit deployment scanner to a list of deployments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-49?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFCORE-49:
-----------------------------------
Description:
The basic scenario here is there's a file /some/path/to/foo.war that users want deployed via a scanner, but /some/path/to includes other files that can't be moved and that should not be scanned. There's no way to limit the scanner to foo.war and related marker files.
Allowing configuration of an explicit white list of (non-marker) files to consider, and/or a black list of ones to ignore, would allow this use case.
was:
The basic scenario here is there's a file /some/path/to/foo.war that users want deployed via a scanner, but /some/path/to includes other files that can't be moved and that should not be scanned. There's no way to limit the scanner to foo.war and related marker files.
Allowing configuration of an explicit whitel list of (non-marker) files to consider, or a black list of ones to ignore, would allow this use case.
> Limit deployment scanner to a list of deployments
> -------------------------------------------------
>
> Key: WFCORE-49
> URL: https://issues.jboss.org/browse/WFCORE-49
> Project: WildFly Core
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Brian Stansberry
> Priority: Minor
>
> The basic scenario here is there's a file /some/path/to/foo.war that users want deployed via a scanner, but /some/path/to includes other files that can't be moved and that should not be scanned. There's no way to limit the scanner to foo.war and related marker files.
> Allowing configuration of an explicit white list of (non-marker) files to consider, and/or a black list of ones to ignore, would allow this use case.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (WFLY-3726) Filesystem deployment scanner deployment failure removes unrelated deployments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3726?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-3726:
----------------------------------------
The scanner has no idea what the contents on the filesystem represent. If you put a directory named MyApp.ear on the filesystem in a scanned dir, it's going to tell the server there's content there named MyApp.ear. The server then is going to assume that content represents a valid ear.
If you think the deployers are paying attention to parts of that content that they should just ignore, that's a separate issue from this. I recommend you start on the forums to try to validate your thoughts on that.
> 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)
11 years, 8 months
[JBoss JIRA] (WFLY-3726) Filesystem deployment scanner deployment failure removes unrelated deployments
by Jess Holle (JIRA)
[ https://issues.jboss.org/browse/WFLY-3726?page=com.atlassian.jira.plugin.... ]
Jess Holle commented on WFLY-3726:
----------------------------------
I think I'm not being precise enough here. There are lots of different ways to produce the problem, but one can do things like:
* Configure deployment scanner and explicit web app deployment in standalone-full.xml prior to ever starting the given Wildfly installation.
* Start Wildfly
* Watch the auto-deployed app fail and watch Wildfly undeploy the explicitly deployed application and remove it from standalone-full.xml.
I've tried numerous different orderings of events here. Any which way I've tried, a failure in the scan-deployed application's deployment removes the explicitly deployed application.
> 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)
11 years, 8 months
[JBoss JIRA] (WFLY-3726) Filesystem deployment scanner deployment failure removes unrelated deployments
by Jess Holle (JIRA)
[ 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)
11 years, 8 months
[JBoss JIRA] (WFLY-3726) Filesystem deployment scanner deployment failure removes unrelated deployments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3726?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-3726:
----------------------------------------
OK, so not during boot. You changed the contents of the scanned dir *after* boot, and you saw this happen.
I ask because it's an important distinction for narrowing down the possible problem.
> 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)
11 years, 8 months