[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
10 years, 1 month
[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
10 years, 1 month
[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
10 years, 1 month
[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
10 years, 1 month
[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
10 years, 1 month
[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
10 years, 1 month
[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
10 years, 1 month
[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
10 years, 1 month
[JBoss JIRA] (JBWEB-290) Optimize string literals inside jsp expressions
by John O'Hara (JIRA)
[ https://issues.jboss.org/browse/JBWEB-290?page=com.atlassian.jira.plugin.... ]
John O'Hara commented on JBWEB-290:
-----------------------------------
Thinking about this in more generalized terms, it occurs when the string concat operator + is used within expressions. When parsing the jsp page, if we can remove string literals from inside expressions and treat them as standard TemplateText nodes in the parser, we can eliminate string concatenation within expressions and corresponding pressure placed on the heap by StringBuilder
> Optimize string literals inside jsp expressions
> ------------------------------------------------
>
> Key: JBWEB-290
> URL: https://issues.jboss.org/browse/JBWEB-290
> Project: JBoss Web
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Tomcat
> Affects Versions: JBossWeb-3.0.0.Final
> Reporter: John O'Hara
> Assignee: Remy Maucherat
>
> After setting genStringAsCharArray=true, we continue to see StringBuilder concatenating string literals for each jsp request for some of our jsp pages; instead of creating a static char[].
> This occurs when a string literal is included in a jsp expression, e.g.;
> <%="<INPUT type=\"hidden\" name=\"name\" value=\"" + obj.getName() + "\">"%>
> Is it possible to identify string literals inside expressions during the tokenization phase of parsing jsp pages in apache jasper and treat them as text nodes so that the apache jasper generator can apply the same optimizations as string literals outside the jsp expression?
--
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, 1 month
[JBoss JIRA] (WFLY-3046) Not possible change the object store type from hornetq to jdbc via cli commands
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3046?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-3046:
-----------------------------------
Fix Version/s: 8.0.1.Final
> Not possible change the object store type from hornetq to jdbc via cli commands
> -------------------------------------------------------------------------------
>
> Key: WFLY-3046
> URL: https://issues.jboss.org/browse/WFLY-3046
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transactions
> Affects Versions: 8.0.0.Final
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
> Fix For: 8.0.1.Final
>
>
> When you have set the object store to be type of hornetq and then you change your mind to set it for jdbc object store the jboss-cli permits this operation but no change is propagated to model and XML file.
> How to reproduce:
> # ./bin/standalone.xml (start eap 6.2.0.GA)
> # ./bin/jboss-cli.sh -c (connect to running eap)
> # /subsystem=transactions:write-attribute(name=use-hornetq-store, value=true)
> # :reload# /subsystem=transactions/log-store=log-store:read-attribute(name=type)# /subsystem=transactions:write-attribute(name=use-jdbc-store, value=true)# :reload
> # /subsystem=transactions/log-store=log-store:read-attribute(name=type)
> The object store stays to be set to hornetq and no change happens in the standalone.xml file.
--
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, 1 month