[JBoss JIRA] (JBEE-151) Missing doPrivileged block(s) around getContextClassLoader
by Shelly McGowan (JIRA)
[ https://issues.jboss.org/browse/JBEE-151?page=com.atlassian.jira.plugin.s... ]
Shelly McGowan resolved JBEE-151.
---------------------------------
Resolution: Done
> Missing doPrivileged block(s) around getContextClassLoader
> -----------------------------------------------------------
>
> Key: JBEE-151
> URL: https://issues.jboss.org/browse/JBEE-151
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: jboss-el-api
> Reporter: Carlo de Wolf
> Assignee: Shelly McGowan
> Fix For: jboss-el-api_2.2_spec-1.0.4.Final, jboss-el-api_3.0_spec-1.0.1.Final
>
>
> jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1
> {code}
> 12:56:34,897 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/read-props].[jsp]] (http-/127.0.0.1:8080-4) JBWEB000236: Servlet.service() for servlet jsp threw exception: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")
> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372) [rt.jar:1.7.0_45]
> at java.security.AccessController.checkPermission(AccessController.java:559) [rt.jar:1.7.0_45]
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) [rt.jar:1.7.0_45]
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1561) [rt.jar:1.7.0_45]
> at java.lang.Thread.getContextClassLoader(Thread.java:1472) [rt.jar:1.7.0_45]
> at javax.el.FactoryFinder.find(FactoryFinder.java:130) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:185) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:156) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at org.apache.jasper.runtime.JspApplicationContextImpl.<init>(JspApplicationContextImpl.java:48) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (JBEE-151) Missing doPrivileged block(s) around getContextClassLoader
by Shelly McGowan (JIRA)
[ https://issues.jboss.org/browse/JBEE-151?page=com.atlassian.jira.plugin.s... ]
Shelly McGowan edited comment on JBEE-151 at 3/13/14 11:21 AM:
---------------------------------------------------------------
Fix also committed to master branch for jboss-el-api_3.0:
https://github.com/jboss/jboss-el-api_spec/commit/c82e83c9c78d25abd839f64...
EL 3.0 API v1.0.1.Final has been released:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/j...
was (Author: shelly.mcgowan):
Fix also committed to master branch for jboss-el-api_3.0:
https://github.com/jboss/jboss-el-api_spec/commit/c82e83c9c78d25abd839f64...
> Missing doPrivileged block(s) around getContextClassLoader
> -----------------------------------------------------------
>
> Key: JBEE-151
> URL: https://issues.jboss.org/browse/JBEE-151
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: jboss-el-api
> Reporter: Carlo de Wolf
> Assignee: Shelly McGowan
> Fix For: jboss-el-api_2.2_spec-1.0.4.Final, jboss-el-api_3.0_spec-1.0.1.Final
>
>
> jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1
> {code}
> 12:56:34,897 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/read-props].[jsp]] (http-/127.0.0.1:8080-4) JBWEB000236: Servlet.service() for servlet jsp threw exception: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")
> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372) [rt.jar:1.7.0_45]
> at java.security.AccessController.checkPermission(AccessController.java:559) [rt.jar:1.7.0_45]
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) [rt.jar:1.7.0_45]
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1561) [rt.jar:1.7.0_45]
> at java.lang.Thread.getContextClassLoader(Thread.java:1472) [rt.jar:1.7.0_45]
> at javax.el.FactoryFinder.find(FactoryFinder.java:130) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:185) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:156) [jboss-el-api_2.2_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at org.apache.jasper.runtime.JspApplicationContextImpl.<init>(JspApplicationContextImpl.java:48) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-3110) Don't copy the contents to all hosts when assigning a deployment to a server-group
by Emanuel Muckenhuber (JIRA)
[ https://issues.jboss.org/browse/WFLY-3110?page=com.atlassian.jira.plugin.... ]
Emanuel Muckenhuber updated WFLY-3110:
--------------------------------------
Summary: Don't copy the contents to all hosts when assigning a deployment to a server-group (was: Don't copy deployment contents to all hosts when updating an existing deployment)
Description: When assigning a deployment to a server-group it also copies the actual deployment contents to all hosts regardless of the whether the deployment is used locally or not. This should be changed that the contents are only retrieved if they are actually needed on a local server. (was: In case a deployment gets updated, the full-replace deployment handler on the host-controller retrieves the deployment regardless a local server uses this deployment or not.
This does not seem to be affecting the deployment add operation, which will only get the deployment contents when an actual server requires the contents.)
> Don't copy the contents to all hosts when assigning a deployment to a server-group
> ----------------------------------------------------------------------------------
>
> Key: WFLY-3110
> URL: https://issues.jboss.org/browse/WFLY-3110
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Reporter: Emanuel Muckenhuber
> Assignee: Emanuel Muckenhuber
> Fix For: 8.0.1.Final
>
>
> When assigning a deployment to a server-group it also copies the actual deployment contents to all hosts regardless of the whether the deployment is used locally or not. This should be changed that the contents are only retrieved if they are actually needed on a local server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-3044) Mojarra's @ViewScoped implementation is not cluster-aware resulting in NotSerializableException
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3044?page=com.atlassian.jira.plugin.... ]
Farah Juma edited comment on WFLY-3044 at 3/13/14 10:32 AM:
------------------------------------------------------------
There isn't too much about ViewScoped in the actual spec file (see Section 7.8.1.1 in the spec file [here | http://download.oracle.com/otndocs/jcp/jsf-2_2-fr-eval-spec/index.html ]). However, the [javadocs | http://docs.oracle.com/javaee/7/api/javax/faces/view/ViewScoped.html] for ViewScoped does have just the @NormalScope annotation though (passivating defaults to false).
We'll need to wait for [JAVASERVERFACES_SPEC_PUBLIC-1268| https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1268] to be resolved.
was (Author: fjuma):
There isn't too much about ViewScoped in the actual spec (see Section 7.8.1.1 in the spec file [here | http://download.oracle.com/otndocs/jcp/jsf-2_2-fr-eval-spec/index.html ]).
We'll need to wait for [JAVASERVERFACES_SPEC_PUBLIC-1268| https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1268] to be resolved.
> Mojarra's @ViewScoped implementation is not cluster-aware resulting in NotSerializableException
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-3044
> URL: https://issues.jboss.org/browse/WFLY-3044
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF
> Affects Versions: 8.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 8.0.1.Final
>
>
> The problem is in ViewScopeContextManager, namely
> {code}
> getContextMap(facesContext).put(contextual, new ViewScopeContextObject(contextual, creational, name));
> {code}
> probably it needs an artificial ID generated to serve as a key.
> Also the ViewScopeContextObject needs to be serializable as well among other things
> {code}
> class ViewScopeContextObject {
> {code}
> Issue manifests as
> {noformat}[Server:server-one] 19:22:41,564 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-15) ISPN000136: Execution error: org.infinispan.commons.CacheException: java.lang.RuntimeException: Failure to marshal argument(s)
> [Server:server-one] at org.infinispan.commons.util.Util.rewrapAsCacheException(Util.java:581)
> ...
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263)
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312)
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69)
> [Server:server-one] at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80)
> [Server:server-one] at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101)
> [Server:server-one] at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83)
> [Server:server-one] at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64)
> [Server:server-one] at org.infinispan.CacheImpl.endBatch(CacheImpl.java:777)
> [Server:server-one] at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53)
> [Server:server-one] at org.wildfly.clustering.web.infinispan.InfinispanBatcher$1.end(InfinispanBatcher.java:56)
> [Server:server-one] at org.wildfly.clustering.web.infinispan.InfinispanBatcher$1.close(InfinispanBatcher.java:46)
> [Server:server-one] at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:72)
> [Server:server-one] at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:704) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:522) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:287) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> [Server:server-one] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> [Server:server-one] Caused by: java.lang.RuntimeException: Failure to marshal argument(s)
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.marshallCall(CommandAwareRpcDispatcher.java:333)
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:352)
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)
> [Server:server-one] ... 76 more
> [Server:server-one] Caused by: org.infinispan.commons.marshall.NotSerializableException: org.jboss.weld.bean.ManagedBean
> [Server:server-one] Caused by: an exception which occurred:
> [Server:server-one] in object java.util.HashMap@b37422bb
> [Server:server-one] in object org.jboss.as.clustering.marshalling.SimpleMarshalledValue@b37422bb
> [Server:server-one] in object org.infinispan.commands.write.PutKeyValueCommand@db517a36
> [Server:server-one] in object org.infinispan.commands.tx.PrepareCommand@6fa34718
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-3044) Mojarra's @ViewScoped implementation is not cluster-aware resulting in NotSerializableException
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3044?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFLY-3044:
----------------------------------
There isn't too much about ViewScoped in the actual spec (see Section 7.8.1.1 in the spec file [here | http://download.oracle.com/otndocs/jcp/jsf-2_2-fr-eval-spec/index.html ]).
We'll need to wait for [JAVASERVERFACES_SPEC_PUBLIC-1268| https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1268] to be resolved.
> Mojarra's @ViewScoped implementation is not cluster-aware resulting in NotSerializableException
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-3044
> URL: https://issues.jboss.org/browse/WFLY-3044
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF
> Affects Versions: 8.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 8.0.1.Final
>
>
> The problem is in ViewScopeContextManager, namely
> {code}
> getContextMap(facesContext).put(contextual, new ViewScopeContextObject(contextual, creational, name));
> {code}
> probably it needs an artificial ID generated to serve as a key.
> Also the ViewScopeContextObject needs to be serializable as well among other things
> {code}
> class ViewScopeContextObject {
> {code}
> Issue manifests as
> {noformat}[Server:server-one] 19:22:41,564 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-15) ISPN000136: Execution error: org.infinispan.commons.CacheException: java.lang.RuntimeException: Failure to marshal argument(s)
> [Server:server-one] at org.infinispan.commons.util.Util.rewrapAsCacheException(Util.java:581)
> ...
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263)
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312)
> [Server:server-one] at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69)
> [Server:server-one] at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80)
> [Server:server-one] at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101)
> [Server:server-one] at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83)
> [Server:server-one] at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64)
> [Server:server-one] at org.infinispan.CacheImpl.endBatch(CacheImpl.java:777)
> [Server:server-one] at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53)
> [Server:server-one] at org.wildfly.clustering.web.infinispan.InfinispanBatcher$1.end(InfinispanBatcher.java:56)
> [Server:server-one] at org.wildfly.clustering.web.infinispan.InfinispanBatcher$1.close(InfinispanBatcher.java:46)
> [Server:server-one] at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:72)
> [Server:server-one] at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:704) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:522) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:287) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> [Server:server-one] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> [Server:server-one] Caused by: java.lang.RuntimeException: Failure to marshal argument(s)
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.marshallCall(CommandAwareRpcDispatcher.java:333)
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:352)
> [Server:server-one] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)
> [Server:server-one] ... 76 more
> [Server:server-one] Caused by: org.infinispan.commons.marshall.NotSerializableException: org.jboss.weld.bean.ManagedBean
> [Server:server-one] Caused by: an exception which occurred:
> [Server:server-one] in object java.util.HashMap@b37422bb
> [Server:server-one] in object org.jboss.as.clustering.marshalling.SimpleMarshalledValue@b37422bb
> [Server:server-one] in object org.infinispan.commands.write.PutKeyValueCommand@db517a36
> [Server:server-one] in object org.infinispan.commands.tx.PrepareCommand@6fa34718
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-3108) Can't promote --backup slave HC to master and reload without moving domain.cached-remote.xml
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3108?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3108:
-----------------------------------------------
Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1076066|https://bugzilla.redhat.com/show_bug.cgi?id=1076066] from NEW to ASSIGNED
> Can't promote --backup slave HC to master and reload without moving domain.cached-remote.xml
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-3108
> URL: https://issues.jboss.org/browse/WFLY-3108
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 8.0.1.Final
>
>
> The prescribed mechanism for converting a slave HC to master is to:
> 1) Start the slave with --backup so a local copy of the domain config is maintained (in file domain.cached-remote.xml).
> 2) Stop the existing master.
> 3) Use the cli to connect to the slave and
> /host=<slavename>:write-local-domain-controller
> 4) Then, in the CLI
> reload --host=<slavename>
> Problem is this fails because the HC expects to have a domain config file "domain.xml".
> 2014-03-13 09:54:04,829 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010932: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:514) [wildfly-host-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.FileNotFoundException: /Users/bstansberry/tmp/WF801/slave/domain/configuration/domain.xml (No such file or directory)
> at java.io.FileInputStream.open(Native Method) [rt.jar:1.7.0_45]
> at java.io.FileInputStream.<init>(FileInputStream.java:146) [rt.jar:1.7.0_45]
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> ... 3 more
> Or, MUCH WORSE, there happens to be a random domain.xml in the filesystem, which has content that is out of sync with the correct domain config. This domain.xml config will be used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-3108) Can't promote --backup slave HC to master and reload without moving domain.cached-remote.xml
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3108?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-3108:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1076066
> Can't promote --backup slave HC to master and reload without moving domain.cached-remote.xml
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-3108
> URL: https://issues.jboss.org/browse/WFLY-3108
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 8.0.1.Final
>
>
> The prescribed mechanism for converting a slave HC to master is to:
> 1) Start the slave with --backup so a local copy of the domain config is maintained (in file domain.cached-remote.xml).
> 2) Stop the existing master.
> 3) Use the cli to connect to the slave and
> /host=<slavename>:write-local-domain-controller
> 4) Then, in the CLI
> reload --host=<slavename>
> Problem is this fails because the HC expects to have a domain config file "domain.xml".
> 2014-03-13 09:54:04,829 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010932: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:514) [wildfly-host-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.FileNotFoundException: /Users/bstansberry/tmp/WF801/slave/domain/configuration/domain.xml (No such file or directory)
> at java.io.FileInputStream.open(Native Method) [rt.jar:1.7.0_45]
> at java.io.FileInputStream.<init>(FileInputStream.java:146) [rt.jar:1.7.0_45]
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> ... 3 more
> Or, MUCH WORSE, there happens to be a random domain.xml in the filesystem, which has content that is out of sync with the correct domain config. This domain.xml config will be used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (JGRP-1802) OverlappingUnicastMergeTest fails to receive all messages
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1802?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1802:
-------------------------------------------
Provided synchronized access to results array for channel receiver. PR is attached.
> OverlappingUnicastMergeTest fails to receive all messages
> ---------------------------------------------------------
>
> Key: JGRP-1802
> URL: https://issues.jboss.org/browse/JGRP-1802
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: Solaris, RHEL
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> OverlappingUnicastMergeTest does the following:
> - set up three channels a,b,c with the layers MERGE2, VERIFY_SUSPECT and FC removed
> - the receiver of each channel will look at all incoming messages: if mcast, ignore it; if unicast, add to the list of messages received
> - inject some new view into the channels which represents a view configuration which should be recovered from
> - send messages to the channels and check that the messages are received, despite the injected view
> OverlappingUnicastMergeTest this test is failing in a number of ways (i.e. many of the test methods are failing within the test class on multiple platforms.
> What we expect to see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=15
> receiver C: ucasts=15
> {noformat}
> What we instead see is:
> {noformat}
> receiver A: ucasts=15
> receiver B: ucasts=11
> ucasts for B:
> B: unicast msg #1 from B B: unicast msg #2 from B B: unicast msg #3 from B B: unicast msg #4 from B B: unicast msg #5 from B A: unicast msg #1 from A C: unicast msg #2 from C C: unicast msg #3 from C A: unicast msg #4 from A C: unicast msg #4 from C C: unicast msg #5 from C
> {noformat}
> The order here is the order in which the unicasts were received from all three senders by the single receiver. For example, in the above, in testWithViewBC, channel A should receive messages #1 through #5 from channels A, B and C, but it does not receive #1 from channel C.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months