[JBoss JIRA] (WFLY-9817) JSON-P 1.1 is not loaded when ee8.preview.mode property is defined in standalone.xml file, seems that Elytron uses JSON-P stuff too early
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFLY-9817?page=com.atlassian.jira.plugin.... ]
Rostislav Svoboda updated WFLY-9817:
------------------------------------
Summary: JSON-P 1.1 is not loaded when ee8.preview.mode property is defined in standalone.xml file, seems that Elytron uses JSON-P stuff too early (was: JSON-P 1.1 is not loaded when ee8.preview.mode property is defined in configuration file, seems that Elytron uses JSON-P stuff too early)
> JSON-P 1.1 is not loaded when ee8.preview.mode property is defined in standalone.xml file, seems that Elytron uses JSON-P stuff too early
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9817
> URL: https://issues.jboss.org/browse/WFLY-9817
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Reporter: Rostislav Svoboda
> Assignee: Jason Greene
> Priority: Critical
>
> JSON-P 1.1 is not loaded when ee8.preview.mode property is defined in configuration file.
> Early investigation done by James and Stuart indicates that Elytron uses JSON-P stuff too early and it prevents JSON-P 1.1 activation when ee8.preview.mode property is defined in configuration file.
> CCing [~jamezp] [~swd847] [~jason.greene] [~kabirkhan] [~brian.stansberry]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9788) EJB over HTTP fails with Arrays in Request
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-9788?page=com.atlassian.jira.plugin.... ]
jaikiran pai commented on WFLY-9788:
------------------------------------
I have updated that PR to include an additional change. I _think_ this should fix your issue. You'll have to rebuild this afresh and give it a try to see how it goes.
> EJB over HTTP fails with Arrays in Request
> ------------------------------------------
>
> Key: WFLY-9788
> URL: https://issues.jboss.org/browse/WFLY-9788
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 11.0.0.Final
> Reporter: Heiko Lettmann
> Attachments: Test.zip
>
>
> I stumbled over the issue WFLY-9573. Then I updated to wildfly-http-client-1.0.9.Final which made a few invocations work. There I discovered another issue. I attached a modified Quickstart version to demonstrate it!
> Exception is on the client side:
> Exception in thread "main" javax.ejb.EJBException: java.io.IOException: java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.String
> at org.jboss.as.ejb3.remote.AssociationImpl.receiveInvocationRequest(AssociationImpl.java:128)
> at org.wildfly.httpclient.ejb.HttpInvocationHandler.lambda$handleInternal$0(HttpInvocationHandler.java:130)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.String
> at org.wildfly.httpclient.ejb.HttpInvocationHandler$1.getRequestContent(HttpInvocationHandler.java:204)
> at org.jboss.as.ejb3.remote.AssociationImpl.receiveInvocationRequest(AssociationImpl.java:126)
> ... 4 more
> Caused by: java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.String
> at org.wildfly.httpclient.ejb.HttpInvocationHandler$1.getRequestContent(HttpInvocationHandler.java:178)
> ... 5 more
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9798) Undertow filter rewrite configuration error
by 구용 이 (JIRA)
[ https://issues.jboss.org/browse/WFLY-9798?page=com.atlassian.jira.plugin.... ]
구용 이 commented on WFLY-9798:
----------------------------
Good~
Thank you very match
> Undertow filter rewrite configuration error
> -------------------------------------------
>
> Key: WFLY-9798
> URL: https://issues.jboss.org/browse/WFLY-9798
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Environment: h2. Test environment
> 1. CentOS Linux release 7.4.1708 (Core)
> 2. wildfly-11.0.0.Final
> 3. wildfly-12.0.0.Alpha1-SNAPSHOT
> Reporter: 구용 이
> Assignee: Stuart Douglas
>
> hi~
> A URL in the form of "http://localhost/test1" should be rewritten to "http://localhost/abc/test1"
> h2. Configuration
> Undertow Subsystem
> <host ...
> <filter-ref name="rewrite-test" predicate="regex('^/test(.*)$')"/>
> ...
> <filters>
> <rewrite name="rewrite-test" target="/abc/test${1}.jsp" redirect="false"/>
> h2. Problems:
> server.log
> WFLYUT0014: Creating file handler for path '/svc/eap71/was/wildfly-12.0.0.Alpha1-SNAPSHOT/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 2018-02-12 13:44:09,562 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 65) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "undertow"),
> ("configuration" => "filter"),
> ("rewrite" => "rewrite-test")
> ]) - failure description: "WFLYCTL0211: Cannot resolve expression '/abc/test${1}.jsp'"
> Thank you
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9817) JSON-P 1.1 is not loaded when ee8.preview.mode property is defined in configuration file, seems that Elytron uses JSON-P stuff too early
by Rostislav Svoboda (JIRA)
Rostislav Svoboda created WFLY-9817:
---------------------------------------
Summary: JSON-P 1.1 is not loaded when ee8.preview.mode property is defined in configuration file, seems that Elytron uses JSON-P stuff too early
Key: WFLY-9817
URL: https://issues.jboss.org/browse/WFLY-9817
Project: WildFly
Issue Type: Bug
Components: Server
Reporter: Rostislav Svoboda
Assignee: Jason Greene
Priority: Critical
JSON-P 1.1 is not loaded when ee8.preview.mode property is defined in configuration file.
Early investigation done by James and Stuart indicates that Elytron uses JSON-P stuff too early and it prevents JSON-P 1.1 activation when ee8.preview.mode property is defined in configuration file.
CCing [~jamezp] [~swd847] [~jason.greene] [~kabirkhan] [~brian.stansberry]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9816) There are in doubt transactions after communication DB to EAP is halted
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-9816?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka moved JBEAP-14219 to WFLY-9816:
-----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9816 (was: JBEAP-14219)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Transactions
(was: Transactions)
Affects Version/s: 11.0.0.Final
(was: 7.1.0.CR1)
Affects Testing: (was: Regression)
> There are in doubt transactions after communication DB to EAP is halted
> -----------------------------------------------------------------------
>
> Key: WFLY-9816
> URL: https://issues.jboss.org/browse/WFLY-9816
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 11.0.0.Final
> Reporter: Ondra Chaloupka
> Assignee: Ondra Chaloupka
> Priority: Critical
>
> Implementation: JTS
> Priority is set to critical due to regression (issue is not seen in 7.0) and the fact that some inconsistency might be expected (communication from DB to EAP is halted - resource is commited, but TM doesn't know it)
> Failing tests:
> org.jboss.as.test.jbossts.crashrec.test.JMSProxyMdbMessagingServerCrashRecoveryTestCase.haltConnectionAfterDbCommitsWithTestXA(org.jboss.as.test.jbossts.crashrec.test.JMSProxyMdbMessagingServerCrashRecoveryTestCase)
> Run 1: JMSProxyMdbMessagingServerCrashRecoveryTestCase.haltConnectionAfterDbCommitsWithTestXA:276->TestBaseOneServer.checkIfTxLogsAreEmpty:564->TestBaseOneServer.checkIfTransactionManagerLogStoreIsEmpy:619 Recovery failed, some Uids still left in the tx log - number of pending uids before test: 0, pending uids after test: 1. Pending Uids are: 0:ffff7f000001:-5d473c0b:59afe2ee:69[["0:ffff7f000001:-5d473c0b:59afe2ee:7c"]],
> Run 2: JMSProxyMdbMessagingServerCrashRecoveryTestCase.haltConnectionAfterDbCommitsWithTestXA JBoss log parsed file /home/istraka/repositories/jboss-other-repositories/tests-transactions/jbossts/target/jbossas-jbossts/standalone/log/JMSProxyMdbMessagingServerCrashRecoveryTestCase_haltConnectionAfterDbCommitsWithTestXA_jts_server.log contains not expected string XAException on line 11313 with text '2017-09-06 14:00:32,786 WARN [com.arjuna.ats.jtax] (Periodic Recovery) ARJUNA024023: XAResourceRecord.commit caused an XA error: XAException.XAER_NOTA from resource XAResourceWrapperImpl@46c7baf5[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)4d2dca8d pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:846be472-92f7-11e7-b284-340286a805f7] in transaction < 131072, 32, 36, 0000000000-1-1127001-94-72-61-1189-81-30-1800010597889871, 0000000000-1-1127001-94-72-61-1189-81-30-1800012300000000 >: javax.transaction.xa.XAException'
> org.jboss.as.test.jbossts.crashrec.test.JMSProxyMessagingServerCrashRecoveryTestCase.haltConnectionAfterDbCommits(org.jboss.as.test.jbossts.crashrec.test.JMSProxyMessagingServerCrashRecoveryTestCase)
> Run 1: JMSProxyMessagingServerCrashRecoveryTestCase.haltConnectionAfterDbCommits:277->TestBaseOneServer.checkIfTxLogsAreEmpty:564->TestBaseOneServer.checkIfTransactionManagerLogStoreIsEmpy:619 Recovery failed, some Uids still left in the tx log - number of pending uids before test: 0, pending uids after test: 1. Pending Uids are: 0:ffff7f000001:-a865f1e:59afdfbb:64[["0:ffff7f000001:-a865f1e:59afdfbb:6e"]],
> Run 2: JMSProxyMessagingServerCrashRecoveryTestCase.haltConnectionAfterDbCommits JBoss log parsed file /home/istraka/repositories/jboss-other-repositories/tests-transactions/jbossts/target/jbossas-jbossts/standalone/log/JMSProxyMessagingServerCrashRecoveryTestCase_haltConnectionAfterDbCommits_jts_server.log contains not expected string XAException on line 5951 with text '2017-09-06 13:46:42,888 WARN [com.arjuna.ats.jtax] (Periodic Recovery) ARJUNA024023: XAResourceRecord.commit caused an XA error: XAException.XAER_NOTA from resource XAResourceWrapperImpl@730871ea[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)4028496b pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:846be472-92f7-11e7-b284-340286a805f7] in transaction < 131072, 32, 36, 0000000000-1-1127001-11121-96-3089-81-33-6900010097889871, 0000000000-1-1127001-11121-96-3089-81-33-6900010900000000 >: javax.transaction.xa.XAException'
> org.jboss.as.test.jbossts.crashrec.test.JMSProxyMessagingServerCrashRecoveryTestCase.haltConnectionAfterDbCommitsWithTestXA(org.jboss.as.test.jbossts.crashrec.test.JMSProxyMessagingServerCrashRecoveryTestCase)
> Run 1: JMSProxyMessagingServerCrashRecoveryTestCase.haltConnectionAfterDbCommitsWithTestXA:289->TestBaseOneServer.checkIfTxLogsAreEmpty:564->TestBaseOneServer.checkIfTransactionManagerLogStoreIsEmpy:619 Recovery failed, some Uids still left in the tx log - number of pending uids before test: 0, pending uids after test: 1. Pending Uids are: 0:ffff7f000001:4087749a:59afe058:64[["0:ffff7f000001:4087749a:59afe058:73"]],
> Run 2: JMSProxyMessagingServerCrashRecoveryTestCase.haltConnectionAfterDbCommitsWithTestXA JBoss log parsed file /home/istraka/repositories/jboss-other-repositories/tests-transactions/jbossts/target/jbossas-jbossts/standalone/log/JMSProxyMessagingServerCrashRecoveryTestCase_haltConnectionAfterDbCommitsWithTestXA_jts_server.log contains not expected string XAException on line 5996 with text '2017-09-06 13:49:18,766 WARN [com.arjuna.ats.jtax] (Periodic Recovery) ARJUNA024023: XAResourceRecord.commit caused an XA error: XAException.XAER_NOTA from resource XAResourceWrapperImpl@1bb543cb[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)1e73c422 pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:846be472-92f7-11e7-b284-340286a805f7] in transaction < 131072, 32, 36, 0000000000-1-112700164-121116-10289-81-328800010097889871, 0000000000-1-112700164-121116-10289-81-328800011400000000 >: javax.transaction.xa.XAException'
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (JGRP-2250) Stuck Threads - BLOCKED infinitely on - JGroups - org.jgroups.protocols.FlowControl$Credit.decrementIfEnoughCredits(FlowControl.java:567)
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2250?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2250:
--------------------------------
This can have many causes, e.g. a thread pool exhausted in the receiver, a thread stuck in application code etc. Without more info, this is hard to diagnose.
Also, 3.4.1 is ~5 years old, I suggest to upgrade to a more recent version, as I don't support such old releases...
> Stuck Threads - BLOCKED infinitely on - JGroups - org.jgroups.protocols.FlowControl$Credit.decrementIfEnoughCredits(FlowControl.java:567)
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2250
> URL: https://issues.jboss.org/browse/JGRP-2250
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.1
> Environment: Oracle Linux - Exalogic/Exadata stack
> AS: Weblogic 12.1.3
> DB: Oracle 12.1.0.2
> Reporter: Rohit Singh
> Assignee: Bela Ban
> Priority: Blocker
> Labels: Infinispan, JGroups
>
> Ours is a J2EE application (clustered across 4 nodes) internally using *{color:red}Infinispan Cache (Ver 6.0.2) with JGroups (Ver 3.4.1){color}* as transport layer of our cache.
> Application had been running perfectly fine, but suddenly on one node, one cache-put got stuck with below stack trace. *(Cause being blocked on org.jgroups.protocols.FlowControl$Credit.decrementIfEnoughCredits(FlowControl.java:567)).*
> Now all further puts are getting stuck - blocked - on the same line on the same node. Other nodes are working fine in this respect.
> Currently, while raising the issue, the threads are still in stuck state. And the first stuck thread is stuck from last 27 hours.
> Stack Trace:
> "[STUCK] ExecuteThread: '37' for queue: 'weblogic.kernel.Default (self-tuning)'" #107862 daemon prio=1 os_prio=0 tid=0x00007f5964373000 nid=0x75a9 in Object.wait() [0x00007f57d596b000]
> java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at *{color:red}org.jgroups.protocols.FlowControl$Credit.decrementIfEnoughCredits(FlowControl.java:567){color}*
> - locked <0x00007f5e64893168> (a org.jgroups.protocols.FlowControl$Credit)
> at org.jgroups.protocols.UFC.handleDownMessage(UFC.java:121)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:330)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:340)
> at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1024)
> at org.jgroups.JChannel.down(JChannel.java:760)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:683)
> at org.jgroups.blocks.RequestCorrelator.sendUnicastRequest(RequestCorrelator.java:202)
> at org.jgroups.blocks.UnicastRequest.sendRequest(UnicastRequest.java:43)
> at org.jgroups.blocks.Request.execute(Request.java:83)
> at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:399)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:353)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:521)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:281)
> at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.handleNonTxWriteCommand(BaseDistributionInterceptor.java:233)
> at org.infinispan.interceptors.distribution.NonTxDistributionInterceptor.visitPutKeyValueCommand(NonTxDistributionInterceptor.java:72)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:321)
> at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:402)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitPutKeyValueCommand(EntryWrappingInterceptor.java:164)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(AbstractLockingInterceptor.java:68)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:219)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:141)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1306)
> at org.infinispan.CacheImpl.putInternal(CacheImpl.java:878)
> at org.infinispan.CacheImpl.put(CacheImpl.java:870)
> at org.infinispan.DecoratedCache.put(DecoratedCache.java:401)
> at com.nucleus.finnone.pro.cache.common.NeutrinoCache.put(NeutrinoCache.java:18)
> at com.nucleus.config.persisted.service.ConfigurationServiceImpl.getConfigurationGroupFor(ConfigurationServiceImpl.java:478)
> *Note: Seems related to below-*
> https://issues.jboss.org/browse/JGRP-1675
> https://issues.jboss.org/browse/ISPN-3645
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9788) EJB over HTTP fails with Arrays in Request
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-9788?page=com.atlassian.jira.plugin.... ]
jaikiran pai commented on WFLY-9788:
------------------------------------
Never mind, I think I now have a test which reproduces your CCE too, even with my current patch.
> EJB over HTTP fails with Arrays in Request
> ------------------------------------------
>
> Key: WFLY-9788
> URL: https://issues.jboss.org/browse/WFLY-9788
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 11.0.0.Final
> Reporter: Heiko Lettmann
> Attachments: Test.zip
>
>
> I stumbled over the issue WFLY-9573. Then I updated to wildfly-http-client-1.0.9.Final which made a few invocations work. There I discovered another issue. I attached a modified Quickstart version to demonstrate it!
> Exception is on the client side:
> Exception in thread "main" javax.ejb.EJBException: java.io.IOException: java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.String
> at org.jboss.as.ejb3.remote.AssociationImpl.receiveInvocationRequest(AssociationImpl.java:128)
> at org.wildfly.httpclient.ejb.HttpInvocationHandler.lambda$handleInternal$0(HttpInvocationHandler.java:130)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.String
> at org.wildfly.httpclient.ejb.HttpInvocationHandler$1.getRequestContent(HttpInvocationHandler.java:204)
> at org.jboss.as.ejb3.remote.AssociationImpl.receiveInvocationRequest(AssociationImpl.java:126)
> ... 4 more
> Caused by: java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.String
> at org.wildfly.httpclient.ejb.HttpInvocationHandler$1.getRequestContent(HttpInvocationHandler.java:178)
> ... 5 more
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months