[JBoss JIRA] (JGRP-1965) Change default thread pool rejection policy to "abort"
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1965?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1965:
-----------------------------------------------
Romain Pelisse <rpelisse(a)redhat.com> changed the Status of [bug 1275362|https://bugzilla.redhat.com/show_bug.cgi?id=1275362] from ASSIGNED to POST
> Change default thread pool rejection policy to "abort"
> ------------------------------------------------------
>
> Key: JGRP-1965
> URL: https://issues.jboss.org/browse/JGRP-1965
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.6
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> Currently, JGroups transport thread pools use discard as a rejection policy. Thus if there are no available threads, and the queue is full, the executor will silently drop the task.
> Abort will throw a RejectedExecutionException, in which case, which JGroups catches to populate the num_rejected_msgs statistic. This is a better default, so that users can monitor this value to determine whether or not to modify their thread pool configuration. Otherwise, num_rejected_msgs is 0, which might be a source of confusion.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-5536) Recovery manager is not able to recover MDB and shows warnings on each run.
by Martyn Taylor (JIRA)
[ https://issues.jboss.org/browse/WFLY-5536?page=com.atlassian.jira.plugin.... ]
Martyn Taylor commented on WFLY-5536:
-------------------------------------
IIUC the only thing the TM needs from the XAResourceWrapper.getJNDI is a unique string that identifies the resource manager. In Artemis it is possible to have a single connection factory (with a single JNDI) talk to multiple servers (resource managers) for example in a clustered environment. This is the reason we append the NodeID to the JNDI name. It is a bit of a hack imo but this is the solution we agreed on with TX and Artemis guys.
The JNDI name is still present in this scenario from what I can see from [~jmesnil] post which should be enough information for the TM. So I can not see any reason why it should fail to remove the log entry. That said I will replicate this locally and see if there is another underlying issue with Artemis XAResources.
> Recovery manager is not able to recover MDB and shows warnings on each run.
> ---------------------------------------------------------------------------
>
> Key: WFLY-5536
> URL: https://issues.jboss.org/browse/WFLY-5536
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR2
> Reporter: Hayk Hovsepyan
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: MDB_JMS_XA.log
>
>
> Recovery manager is not able to recover MDB and shows warnings.
> This causes to see the same warning log in server each time recovery is run.
> This happens when server is crashed before transaction state is saved.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-5589) IllegalStateException when shutting down the server started with default standalone-full-ha.xml
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-5589?page=com.atlassian.jira.plugin.... ]
Chao Wang reassigned WFLY-5589:
-------------------------------
Assignee: Chao Wang (was: Jason Greene)
> IllegalStateException when shutting down the server started with default standalone-full-ha.xml
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-5589
> URL: https://issues.jboss.org/browse/WFLY-5589
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.0.0.CR4
> Reporter: Martin Švehla
> Assignee: Chao Wang
> Priority: Critical
>
> When I start WildFly 10.0.0.CR4 with default standalone-full-ha.xml configuration and then shut it down, I'll get following ERROR in the server log:
> {code}
> 09:18:19,143 ERROR [org.jgroups.JChannel] (MSC service thread 1-2) JGRP000020: failed destroying the protocol stack: java.lang.IllegalStateException
> at org.jboss.as.network.SocketBindingManagerImpl$UnnamedRegistryImpl.unregisterBinding(SocketBindingManagerImpl.java:501)
> at org.jboss.as.network.ManagedDatagramSocketBinding.close(ManagedDatagramSocketBinding.java:73)
> at org.jboss.as.clustering.jgroups.ManagedSocketFactory.close(ManagedSocketFactory.java:148)
> at org.jgroups.protocols.UDP.closeUnicastSocket(UDP.java:577)
> at org.jgroups.protocols.UDP.destroySockets(UDP.java:429)
> at org.jgroups.protocols.UDP.destroy(UDP.java:294)
> at org.jgroups.stack.ProtocolStack.destroy(ProtocolStack.java:887)
> at org.jgroups.JChannel.stopStack(JChannel.java:1005)
> at org.jgroups.JChannel._close(JChannel.java:990)
> at org.jgroups.JChannel.close(JChannel.java:385)
> at org.wildfly.clustering.jgroups.spi.service.ChannelBuilder.stop(ChannelBuilder.java:91)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> This is regression from CR3 build and might be related to fix for https://issues.jboss.org/browse/WFCORE-1033
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-5589) IllegalStateException when shutting down the server started with default standalone-full-ha.xml
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-5589?page=com.atlassian.jira.plugin.... ]
Chao Wang commented on WFLY-5589:
---------------------------------
I think this may also happen to other potential unnamed datagram socket unregistration. IllegalStateException pops out due to https://github.com/wildfly/wildfly/commit/36f5bd99c8893a75ae0338708a5bd41... as it uses UnnamedRegistryImpl.java which depends on address value of ManagedBinding.getBindAddress() to unregister.
However, before unregistering a managed binding, it first closes datagram socket. Thus, while UnnamedRegistryImpl unregisters binding and calls its superclass DatagramSocket.getLocalSocketAddress(), it gets null value because socket was already closed.
> IllegalStateException when shutting down the server started with default standalone-full-ha.xml
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-5589
> URL: https://issues.jboss.org/browse/WFLY-5589
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.0.0.CR4
> Reporter: Martin Švehla
> Assignee: Jason Greene
> Priority: Critical
>
> When I start WildFly 10.0.0.CR4 with default standalone-full-ha.xml configuration and then shut it down, I'll get following ERROR in the server log:
> {code}
> 09:18:19,143 ERROR [org.jgroups.JChannel] (MSC service thread 1-2) JGRP000020: failed destroying the protocol stack: java.lang.IllegalStateException
> at org.jboss.as.network.SocketBindingManagerImpl$UnnamedRegistryImpl.unregisterBinding(SocketBindingManagerImpl.java:501)
> at org.jboss.as.network.ManagedDatagramSocketBinding.close(ManagedDatagramSocketBinding.java:73)
> at org.jboss.as.clustering.jgroups.ManagedSocketFactory.close(ManagedSocketFactory.java:148)
> at org.jgroups.protocols.UDP.closeUnicastSocket(UDP.java:577)
> at org.jgroups.protocols.UDP.destroySockets(UDP.java:429)
> at org.jgroups.protocols.UDP.destroy(UDP.java:294)
> at org.jgroups.stack.ProtocolStack.destroy(ProtocolStack.java:887)
> at org.jgroups.JChannel.stopStack(JChannel.java:1005)
> at org.jgroups.JChannel._close(JChannel.java:990)
> at org.jgroups.JChannel.close(JChannel.java:385)
> at org.wildfly.clustering.jgroups.spi.service.ChannelBuilder.stop(ChannelBuilder.java:91)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> This is regression from CR3 build and might be related to fix for https://issues.jboss.org/browse/WFCORE-1033
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-5596) MessageDrivenComponent startDelivery/stopDelivery is not thread safe
by James Livingston (JIRA)
James Livingston created WFLY-5596:
--------------------------------------
Summary: MessageDrivenComponent startDelivery/stopDelivery is not thread safe
Key: WFLY-5596
URL: https://issues.jboss.org/browse/WFLY-5596
Project: WildFly
Issue Type: Bug
Components: EJB, JMS
Affects Versions: 10.0.0.CR4
Reporter: James Livingston
Assignee: Jeff Mesnil
WFLY-4470 made a change to prevent MDBs being activated or deactivated multiple times, but it is not thread safe. A volatile boolean is used for the flag, but there is no protection against multiple threads invoking the methods simultaneously.
Possible effects include:
* activating the endpoint twice, with (probably) only one deactivation later, leading to not de-registering XA resources from the recovery manager properly
* activate() and deactivate() running in the wrong order if done by separate threads
Several simple solutions probably will not work correctly. Using an AtomicBoolean would stop multiple activations/deactivations from concurrent calls, but would mean that startDelivery() could return before the activation was one. Using a synchronized block or other exclusive lock would work, however since it involves invoking non-container code (the resource adapter), there could potentially be a deadlock risk if that invoked some related container functionality.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (DROOLS-932) kie-server POST fails with org.kie.server.api.marshalling.MarshallingException: Can't marshall input object:
by Stefano Picozzi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-932?page=com.atlassian.jira.plugin... ]
Stefano Picozzi commented on DROOLS-932:
----------------------------------------
Apologies, I thought previous comments by Chris has adequate test case.
I have built a test case and attached as Drools-932-TestCase.zip
> kie-server POST fails with org.kie.server.api.marshalling.MarshallingException: Can't marshall input object:
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-932
> URL: https://issues.jboss.org/browse/DROOLS-932
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.3.0.Final
> Environment: kie-server 6.3.0.FINAL with JBoss EAP 6.4.0 or Widfly 8.1.0.FINAL
> Reporter: Stefano Picozzi
> Assignee: Maciej Swiderski
> Priority: Blocker
> Attachments: Drools-932-TestCase.zip
>
>
> The GET and PUT APIs work OK, e.g. to GET KIE-SERVER details or to PUT a new container.
> However a POST to e.g. send some facts to test actual rule reasoning fails as per this log snippet:
> 07:24:27,998 INFO [org.kie.server.services.impl.KieServerImpl] (http-/0.0.0.0:8080-1) Container watch (for release id com.redhat.demos:weightwatchers:1.0) successfully started
> 07:24:45,028 ERROR [org.kie.server.services.impl.KieContainerCommandServiceImpl] (http-/0.0.0.0:8080-1) Error calling container 'watch': org.kie.server.api.marshalling.MarshallingException: Can't marshall input object: org.drools.core.runtime.impl.ExecutionResultImpl@3c402d4b
> at org.kie.server.api.marshalling.jaxb.JaxbMarshaller.marshall(JaxbMarshaller.java:187) [kie-server-api-6.3.0.Final.jar:6.3.0.Final]
> at org.kie.server.services.impl.KieContainerCommandServiceImpl.callContainer(KieContainerCommandServiceImpl.java:114) [kie-server-services-common-6.3.0.Final.jar:6.3.0.Final]
> at org.kie.server.remote.rest.drools.CommandResource.manageContainer(CommandResource.java:73) [kie-server-rest-drools-6.3.0.Final.jar:6.3.0.Final]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_65]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_65]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_65]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:541) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:400) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> Caused by: javax.xml.bind.MarshalException
> - with linked exception:
> [com.sun.istack.SAXException2: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
> javax.xml.bind.JAXBException: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.]
> at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:326) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:251) [jaxb-impl-2.2.11.jar:2.2.11]
> at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:95) [jboss-jaxb-api_2.2_spec-1.0.4.Final-redhat-3.jar:1.0.4.Final-redhat-3]
> at org.kie.server.api.marshalling.jaxb.JaxbMarshaller.marshall(JaxbMarshaller.java:185) [kie-server-api-6.3.0.Final.jar:6.3.0.Final]
> ... 32 more
> Caused by: com.sun.istack.SAXException2: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
> javax.xml.bind.JAXBException: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
> at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:247) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:262) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:653) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:158) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:360) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:696) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.ArrayBeanInfoImpl.serializeBody(ArrayBeanInfoImpl.java:142) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:696) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:158) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:360) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsSoleContent(XMLSerializer.java:593) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeRoot(ClassBeanInfoImpl.java:341) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:494) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:323) [jaxb-impl-2.2.11.jar:2.2.11]
> ... 35 more
> Caused by: javax.xml.bind.JAXBException: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
> at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getBeanInfo(JAXBContextImpl.java:582) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:648) [jaxb-impl-2.2.11.jar:2.2.11]
> ... 46 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (DROOLS-932) kie-server POST fails with org.kie.server.api.marshalling.MarshallingException: Can't marshall input object:
by Stefano Picozzi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-932?page=com.atlassian.jira.plugin... ]
Stefano Picozzi updated DROOLS-932:
-----------------------------------
Attachment: Drools-932-TestCase.zip
Test case files to reproduce DROOLS-932.
First pull down the docker image that has the Decision Server runtime using, e.g.
$ docker pull spicozzi/weightwatcher2
The execute the scripts in the attachment in order 0, 1, 2, 3
> kie-server POST fails with org.kie.server.api.marshalling.MarshallingException: Can't marshall input object:
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-932
> URL: https://issues.jboss.org/browse/DROOLS-932
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.3.0.Final
> Environment: kie-server 6.3.0.FINAL with JBoss EAP 6.4.0 or Widfly 8.1.0.FINAL
> Reporter: Stefano Picozzi
> Assignee: Maciej Swiderski
> Priority: Blocker
> Attachments: Drools-932-TestCase.zip
>
>
> The GET and PUT APIs work OK, e.g. to GET KIE-SERVER details or to PUT a new container.
> However a POST to e.g. send some facts to test actual rule reasoning fails as per this log snippet:
> 07:24:27,998 INFO [org.kie.server.services.impl.KieServerImpl] (http-/0.0.0.0:8080-1) Container watch (for release id com.redhat.demos:weightwatchers:1.0) successfully started
> 07:24:45,028 ERROR [org.kie.server.services.impl.KieContainerCommandServiceImpl] (http-/0.0.0.0:8080-1) Error calling container 'watch': org.kie.server.api.marshalling.MarshallingException: Can't marshall input object: org.drools.core.runtime.impl.ExecutionResultImpl@3c402d4b
> at org.kie.server.api.marshalling.jaxb.JaxbMarshaller.marshall(JaxbMarshaller.java:187) [kie-server-api-6.3.0.Final.jar:6.3.0.Final]
> at org.kie.server.services.impl.KieContainerCommandServiceImpl.callContainer(KieContainerCommandServiceImpl.java:114) [kie-server-services-common-6.3.0.Final.jar:6.3.0.Final]
> at org.kie.server.remote.rest.drools.CommandResource.manageContainer(CommandResource.java:73) [kie-server-rest-drools-6.3.0.Final.jar:6.3.0.Final]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_65]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_65]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_65]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:541) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:400) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> Caused by: javax.xml.bind.MarshalException
> - with linked exception:
> [com.sun.istack.SAXException2: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
> javax.xml.bind.JAXBException: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.]
> at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:326) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:251) [jaxb-impl-2.2.11.jar:2.2.11]
> at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:95) [jboss-jaxb-api_2.2_spec-1.0.4.Final-redhat-3.jar:1.0.4.Final-redhat-3]
> at org.kie.server.api.marshalling.jaxb.JaxbMarshaller.marshall(JaxbMarshaller.java:185) [kie-server-api-6.3.0.Final.jar:6.3.0.Final]
> ... 32 more
> Caused by: com.sun.istack.SAXException2: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
> javax.xml.bind.JAXBException: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
> at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:247) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:262) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:653) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:158) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:360) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:696) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.ArrayBeanInfoImpl.serializeBody(ArrayBeanInfoImpl.java:142) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:696) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:158) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:360) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsSoleContent(XMLSerializer.java:593) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeRoot(ClassBeanInfoImpl.java:341) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:494) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:323) [jaxb-impl-2.2.11.jar:2.2.11]
> ... 35 more
> Caused by: javax.xml.bind.JAXBException: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
> at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getBeanInfo(JAXBContextImpl.java:582) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:648) [jaxb-impl-2.2.11.jar:2.2.11]
> ... 46 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-1080) Remove compile time dep from cli module to process-controller
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1080?page=com.atlassian.jira.plugi... ]
Ken Wills commented on WFCORE-1080:
-----------------------------------
[~bstansberry] Oops, sorry about that, I should have realized.
> Remove compile time dep from cli module to process-controller
> -------------------------------------------------------------
>
> Key: WFCORE-1080
> URL: https://issues.jboss.org/browse/WFCORE-1080
> Project: WildFly Core
> Issue Type: Task
> Components: CLI
> Affects Versions: 2.0.0.CR8
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.0.CR9
>
>
> EmbedHostControllerHandler is importing CommandLineConstants from the process-controller module in order to pick up a couple string constants. I want to eliminate this link from the client side modules to the server side modules.
> Plus the same strings are directly included in the class elsewhere. ;)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-1080) Remove compile time dep from cli module to process-controller
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1080?page=com.atlassian.jira.plugi... ]
Ken Wills edited comment on WFCORE-1080 at 10/27/15 6:17 PM:
-------------------------------------------------------------
[~bstansberry] Oops, sorry about that, I should have realized, that does explain the direct usage in a lot of cases vs the use of constants though :)
was (Author: luck3y):
[~bstansberry] Oops, sorry about that, I should have realized.
> Remove compile time dep from cli module to process-controller
> -------------------------------------------------------------
>
> Key: WFCORE-1080
> URL: https://issues.jboss.org/browse/WFCORE-1080
> Project: WildFly Core
> Issue Type: Task
> Components: CLI
> Affects Versions: 2.0.0.CR8
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.0.CR9
>
>
> EmbedHostControllerHandler is importing CommandLineConstants from the process-controller module in order to pick up a couple string constants. I want to eliminate this link from the client side modules to the server side modules.
> Plus the same strings are directly included in the class elsewhere. ;)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-1080) Remove compile time dep from cli module to process-controller
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1080:
----------------------------------------
Summary: Remove compile time dep from cli module to process-controller
Key: WFCORE-1080
URL: https://issues.jboss.org/browse/WFCORE-1080
Project: WildFly Core
Issue Type: Task
Components: CLI
Affects Versions: 2.0.0.CR8
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 2.0.0.CR9
EmbedHostControllerHandler is importing CommandLineConstants from the process-controller module in order to pick up a couple string constants. I want to eliminate this link from the client side modules to the server side modules.
Plus the same strings are directly included in the class elsewhere. ;)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month