[JBoss JIRA] (LOGMGR-99) Infinite recursion when exception stack frame class lookup fails
by James Livingston (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-99?page=com.atlassian.jira.plugin.... ]
James Livingston updated LOGMGR-99:
-----------------------------------
Workaround Description: Use %e in the formatter rather than %E
> Infinite recursion when exception stack frame class lookup fails
> ----------------------------------------------------------------
>
> Key: LOGMGR-99
> URL: https://issues.jboss.org/browse/LOGMGR-99
> Project: JBoss Log Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.5.1.Final
> Reporter: James Livingston
> Assignee: David Lloyd
> Priority: Critical
>
> To print out the jar information in exception stack traces, the log manager needs to resolve the class name from StackTraceElement to the Class object. Since the log manager cannot know which classloader was used, guessClass() tries the TCCL, the logmanager's classloader and finally the system classloader.
> It is possible that the TCCL contains a class of the same name as the one in the stack frame, but it not the same class. This can easily happen if the application packages a jar that is also used by the container. In this situation, the class may not be able to be loaded, such as if the application-packages class is missing it's dependencies.
> If Class.forName() would throw a NoClassDefFoundError or similar, JBoss Modules (or other classloader implementation) may attempt to log this using java.util.logging API. This can result in infinite recursion, for example
> ...
> at org.jboss.logmanager.Logger.log(Logger.java:367)
> at org.jboss.modules.log.JDKModuleLogger.doLog(JDKModuleLogger.java:109)
> at org.jboss.modules.log.JDKModuleLogger.classDefineFailed(JDKModuleLogger.java:194)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:401)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:243)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:73)
> at org.jboss.modules.Module.loadModuleClass(Module.java:527)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:266)
> at org.jboss.logmanager.formatters.Formatters$12.guessClass(Formatters.java:578)
> at org.jboss.logmanager.formatters.Formatters$12.renderExtended(Formatters.java:421)
> at org.jboss.logmanager.formatters.Formatters$12.renderRaw(Formatters.java:388)
> at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:150)
> at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86)
> at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35)
> at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49)
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:290)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:721)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:731)
> at org.jboss.logmanager.Logger.log(Logger.java:367)
> ...
--
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
11 years, 7 months
[JBoss JIRA] (WFLY-3033) Better SSO configuration
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3033?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-3033:
------------------------------------
Assignee: Tomaz Cerar (was: Stuart Douglas)
> Better SSO configuration
> ------------------------
>
> Key: WFLY-3033
> URL: https://issues.jboss.org/browse/WFLY-3033
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Reporter: Tin Tvrtkovic
> Assignee: Tomaz Cerar
> Priority: Critical
> Labels: single-sign-on, undertow
> Fix For: 8.0.1.Final
>
>
> When enabling Undertow SSO in standalone.xml, the only option to tweak is the cookie domain.
> My life would be made easier by two changes:
> 1) If the domain is not specified, the SSO cookie should have no domain set. This will make the browser apply the domain from the URL being requested. Currently the cookie domain gets populated with a value from the enclosing XML element.
> 2) There's no way of setting the cookie path, which makes this less useful for services on different URLs. I propose adding a path attribute to the SSO XML element, which would set the cookie path. For example:
> <single-sign-on path="/" />
> Right now my workaround is to use my reverse proxy (Apache) to edit response headers and modify the cookie, removing the domain and adding the path. If anyone else needs the workaround:
> Header edit Set-Cookie "^JSESSIONIDSSO=([^; ]+).+" "JSESSIONIDSSO=$1; path=/"
--
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
11 years, 7 months
[JBoss JIRA] (WFLY-3050) '=' character removed from request cookie
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3050?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-3050:
--------------------------------------
This related to UNDERTOW-49, it looks like we missed adding a configuration option for this to Wildfly.
> '=' character removed from request cookie
> ------------------------------------------
>
> Key: WFLY-3050
> URL: https://issues.jboss.org/browse/WFLY-3050
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Environment: windows 7
> Reporter: roy mizrachi
> Assignee: Stuart Douglas
>
> I'm saving encrypted user token in session cookie:
> Cookie: JCORESESSIONID=aes256$/tew4VVsfdJ32iUX1AOqBGRb717TJC9KkejjAPl6BIAG6kCP4beSraL51eQG2iu5bV9uT3OsubXUcjO+sG2lYNWbu5NliQd361oUz2Yl4LQ=
> The problem is that in the server i see that the '=' character is removed hence i cannot decrypt it.
>
--
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
11 years, 7 months
[JBoss JIRA] (DROOLS-446) Literals may be ambiguously resolved as classes on case insensitive filesystems
by Davide Sottara (JIRA)
Davide Sottara created DROOLS-446:
-------------------------------------
Summary: Literals may be ambiguously resolved as classes on case insensitive filesystems
Key: DROOLS-446
URL: https://issues.jboss.org/browse/DROOLS-446
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.0.1.Final, 6.0.0.Final, 5.6.0.Final, 5.5.0.Final
Reporter: Davide Sottara
Assignee: Mark Proctor
Fix For: 6.1.0.CR1
When a candidate class literal is analyzed, e.g. :
{code}
declare Foo
f1 : Bar = new Bar()
f2 : boolean = false
end
{code}
"Bar" is tentatively resolved (twice) and its f.q.n. is substituted as needed.
However, even "false" is tentatively resolved as well.
On a case insensitive filesytems, the presence of a class named False will cause the literal to be resolved erroneously.
The same will happen to "true" and "null"
--
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
11 years, 7 months
[JBoss JIRA] (WFLY-3050) '=' character removed from request cookie
by roy mizrachi (JIRA)
roy mizrachi created WFLY-3050:
----------------------------------
Summary: '=' character removed from request cookie
Key: WFLY-3050
URL: https://issues.jboss.org/browse/WFLY-3050
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Undertow)
Affects Versions: 8.0.0.Final
Environment: windows 7
Reporter: roy mizrachi
Assignee: Stuart Douglas
I'm saving encrypted user token in session cookie:
Cookie: JCORESESSIONID=aes256$/tew4VVsfdJ32iUX1AOqBGRb717TJC9KkejjAPl6BIAG6kCP4beSraL51eQG2iu5bV9uT3OsubXUcjO+sG2lYNWbu5NliQd361oUz2Yl4LQ=
The problem is that in the server i see that the '=' character is removed hence i cannot decrypt it.
--
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
11 years, 7 months
[JBoss JIRA] (WFLY-3001) JSF WindowId: NPE in Weld HTTP BeanStore inhibits application access
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3001?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-3001.
-------------------------------
Fix Version/s: 8.0.0.Final
Resolution: Done
> JSF WindowId: NPE in Weld HTTP BeanStore inhibits application access
> ---------------------------------------------------------------------
>
> Key: WFLY-3001
> URL: https://issues.jboss.org/browse/WFLY-3001
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, JSF
> Affects Versions: 8.0.0.CR1
> Reporter: Thomas Frühbeck
> Assignee: Stuart Douglas
> Labels: cdi, npe, session, weld
> Fix For: 8.0.0.Final
>
>
> Web session has been established, after _very_ long time (>> session timeout) browser refresh, URL refresh leads to NPE in weld beanstore on access to SessionScoped deltaspike DefaultClientWindowConfig bean.
> From that point on the _only_ possibility to access the application is clean of session cookies.
> Stacktrace:
> 2014-02-23 16:59:13,319 ERROR [io.undertow.request] (default task-36) Servlet request failed HttpServerExchange{ GET /mssms2/faces/csms/groupManagement.xhtml}: java.lang.NullPoi
> nterException
> at org.jboss.weld.context.beanstore.http.AbstractSessionBeanStore.getLockStore(AbstractSessionBeanStore.java:113) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
> at org.jboss.weld.context.beanstore.AttributeBeanStore.lock(AttributeBeanStore.java:210) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
> at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:88) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
> at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:
> 53]
> at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
> at org.apache.deltaspike.jsf.spi.scope.window.DefaultClientWindowConfig$Proxy$_$$_WeldClientProxy.getClientWindowRenderMode(Unknown Source) [deltaspike-jsf-module-api-0.
> 6-SNAPSHOT.jar:0.6-SNAPSHOT]
> at org.apache.deltaspike.jsf.impl.scope.window.DefaultClientWindow.getWindowId(DefaultClientWindow.java:119) [deltaspike-jsf-module-impl-0.6-SNAPSHOT.jar:0.6-SNAPSHOT]
> at org.apache.deltaspike.jsf.impl.scope.window.DefaultClientWindow$Proxy$_$$_WeldClientProxy.getWindowId(Unknown Source) [deltaspike-jsf-module-impl-0.6-SNAPSHOT.jar:0.6
> -SNAPSHOT]
> at org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.execute(DeltaSpikeLifecycleWrapper.java:78) [deltaspike-jsf-module-impl-0.6-SNAPSHOT.jar:0.
> 6-SNAPSHOT]
--
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
11 years, 7 months
[JBoss JIRA] (WFLY-3001) JSF WindowId: NPE in Weld HTTP BeanStore inhibits application access
by Thomas Frühbeck (JIRA)
[ https://issues.jboss.org/browse/WFLY-3001?page=com.atlassian.jira.plugin.... ]
Thomas Frühbeck commented on WFLY-3001:
---------------------------------------
could not reproduce it in Wildfly 8.0.0.Final, please close issue.
Regards,
Thomas
> JSF WindowId: NPE in Weld HTTP BeanStore inhibits application access
> ---------------------------------------------------------------------
>
> Key: WFLY-3001
> URL: https://issues.jboss.org/browse/WFLY-3001
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, JSF
> Affects Versions: 8.0.0.CR1
> Reporter: Thomas Frühbeck
> Assignee: Stuart Douglas
> Labels: cdi, npe, session, weld
>
> Web session has been established, after _very_ long time (>> session timeout) browser refresh, URL refresh leads to NPE in weld beanstore on access to SessionScoped deltaspike DefaultClientWindowConfig bean.
> From that point on the _only_ possibility to access the application is clean of session cookies.
> Stacktrace:
> 2014-02-23 16:59:13,319 ERROR [io.undertow.request] (default task-36) Servlet request failed HttpServerExchange{ GET /mssms2/faces/csms/groupManagement.xhtml}: java.lang.NullPoi
> nterException
> at org.jboss.weld.context.beanstore.http.AbstractSessionBeanStore.getLockStore(AbstractSessionBeanStore.java:113) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
> at org.jboss.weld.context.beanstore.AttributeBeanStore.lock(AttributeBeanStore.java:210) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
> at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:88) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
> at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:
> 53]
> at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
> at org.apache.deltaspike.jsf.spi.scope.window.DefaultClientWindowConfig$Proxy$_$$_WeldClientProxy.getClientWindowRenderMode(Unknown Source) [deltaspike-jsf-module-api-0.
> 6-SNAPSHOT.jar:0.6-SNAPSHOT]
> at org.apache.deltaspike.jsf.impl.scope.window.DefaultClientWindow.getWindowId(DefaultClientWindow.java:119) [deltaspike-jsf-module-impl-0.6-SNAPSHOT.jar:0.6-SNAPSHOT]
> at org.apache.deltaspike.jsf.impl.scope.window.DefaultClientWindow$Proxy$_$$_WeldClientProxy.getWindowId(Unknown Source) [deltaspike-jsf-module-impl-0.6-SNAPSHOT.jar:0.6
> -SNAPSHOT]
> at org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.execute(DeltaSpikeLifecycleWrapper.java:78) [deltaspike-jsf-module-impl-0.6-SNAPSHOT.jar:0.
> 6-SNAPSHOT]
--
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
11 years, 7 months
[JBoss JIRA] (WFLY-1568) Cannot reliably reinstall service with same name
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-1568?page=com.atlassian.jira.plugin.... ]
David Lloyd resolved WFLY-1568.
-------------------------------
Fix Version/s: (was: 9.0.0.CR1)
Resolution: Rejected
Actually it is theoretically possible for the CPU to schedule all actions for a REMOVE before the install runs. But in the real world, yes, this code construct will probably never work. A service can presently only be replaced by employing a service listener, unfortunately. A simpler service replacement API is something we can look into for MSC 2 though.
> Cannot reliably reinstall service with same name
> ------------------------------------------------
>
> Key: WFLY-1568
> URL: https://issues.jboss.org/browse/WFLY-1568
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: MSC
> Reporter: Thomas Diesler
> Assignee: David Lloyd
>
> There seems to be an undefined "cleanup period" needed, before a service with the same name can be installed successfully. If you do the below in the same thread it will always fail (I believe).
> {code}
> controller.setMode(Mode.REMOVE)
> serviceTarget.addService(controller.getName(), service).install()
> {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
11 years, 7 months
[JBoss JIRA] (WFLY-3044) Mojarra's @ViewScoped implementation is not cluster-aware resulting in NotSerializableException
by Stan Silvert (JIRA)
[ https://issues.jboss.org/browse/WFLY-3044?page=com.atlassian.jira.plugin.... ]
Stan Silvert reassigned WFLY-3044:
----------------------------------
Assignee: Farah Juma (was: Stan Silvert)
> 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: Farah Juma
> 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
11 years, 7 months
[JBoss JIRA] (WFLY-1271) Infinispan remote-store requires remote-servers but not marked as required in mgmt model
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1271?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1271:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 956904|https://bugzilla.redhat.com/show_bug.cgi?id=956904] from POST to MODIFIED
> Infinispan remote-store requires remote-servers but not marked as required in mgmt model
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-1271
> URL: https://issues.jboss.org/browse/WFLY-1271
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Alpha4
> Reporter: Takayoshi Kimura
> Assignee: Richard Achmatowicz
> Fix For: 8.0.0.CR1
>
>
> Affect version is actually 8.0.0.Alpha1-SNAPSHOT (before 8.0.0.Alpha1, we don't have such selection).
> Command remote-store=REMOTE_STORE:add fails with this exception:
> {quote}
> 15:58:05,112 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014607: Failed to persist configuration change: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014675: Failed to marshal configuration
> at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.<init>(AbstractFilePersistenceResource.java:50) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.<init>(ConfigurationFilePersistenceResource.java:45) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.persistence.BackupXmlConfigurationPersister.store(BackupXmlConfigurationPersister.java:80) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:522) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:178) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:359) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:228) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:513) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:499) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:321) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:228) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:223) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:235) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:124) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:148) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:97) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:114) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [jboss-as-protocol-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [jboss-as-protocol-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014680: Failed to write configuration
> at org.jboss.as.controller.persistence.AbstractConfigurationPersister.marshallAsXml(AbstractConfigurationPersister.java:123) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.<init>(AbstractFilePersistenceResource.java:43) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> ... 22 more
> Caused by: java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.asList(ModelValue.java:128) [jboss-dmr-1.1.6.Final.jar:1.1.6.Final]
> at org.jboss.dmr.ModelNode.asList(ModelNode.java:1205) [jboss-dmr-1.1.6.Final.jar:1.1.6.Final]
> at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLWriter.processCommonCacheAttributesElements(InfinispanSubsystemXMLWriter.java:282)
> at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLWriter.writeContent(InfinispanSubsystemXMLWriter.java:124)
> at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLWriter.writeContent(InfinispanSubsystemXMLWriter.java:42)
> at org.jboss.as.server.parsing.StandaloneXml.writeServerProfile(StandaloneXml.java:1191) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.server.parsing.StandaloneXml.writeContent(StandaloneXml.java:1108) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.server.parsing.StandaloneXml.writeContent(StandaloneXml.java:103) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.staxmapper.XMLMapperImpl.doDeparse(XMLMapperImpl.java:88) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.staxmapper.XMLMapperImpl.deparseDocument(XMLMapperImpl.java:83) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.controller.persistence.AbstractConfigurationPersister.marshallAsXml(AbstractConfigurationPersister.java:117) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> ... 23 more
> {quote}
> Reproduce steps:
> {quote}
> [standalone@localhost:9999 /] /subsystem=infinispan/cache-container=web/replicated-cache=repl/file-store=FILE_STORE:remove
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> [standalone@localhost:9999 /] /subsystem=infinispan/cache-container=web/replicated-cache=repl/remote-store=REMOTE_STORE:add
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014677: Failed to persist configuration change: JBAS014675: Failed to marshal configuration",
> "rolled-back" => true,
> "response-headers" => {"process-state" => "reload-required"}
> }
> [standalone@localhost:9999 /] /subsystem=infinispan/cache-container=web/replicated-cache=repl/remote-store=REMOTE_STORE:add(remote-servers=[])
> {
> "outcome" => "success",
> "response-headers" => {"process-state" => "reload-required"}
> }
> {quote}
> In $JBOSS_HOME/docs/schema/jboss-as-infinispan_1_3.xsd, it looks like the remote-server is required as it's defined as minOccurs="1":
> {quote}
> <xs:element name="remote-server" type="tns:remote-server" minOccurs="1" maxOccurs="unbounded"/>
> {quote}
--
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
11 years, 7 months