[JBoss JIRA] (DROOLS-932) kie-server POST fails with org.kie.server.api.marshalling.MarshallingException: Can't marshall input object:
by Stefano Picozzi (JIRA)
Stefano Picozzi created DROOLS-932:
--------------------------------------
Summary: 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: Edson Tirelli
Priority: Blocker
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, 9 months
- 1
- 0
[JBoss JIRA] (WFLY-5388) Intermittent java.io.IOException: UT010029: Stream is closed in Java EE 7 using provided undertow, resteasy, and jackson
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5388?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-5388:
--------------------------------------
I have no idea why but chrome seems to be requesting /optaconf-webapp/rest/conference twice, then cancelling the second one which results in the IOException. I am changing this to a RESTeasy issue. SynchronousDispatcher should not be logging IOExceptions at this level.
> Intermittent java.io.IOException: UT010029: Stream is closed in Java EE 7 using provided undertow, resteasy, and jackson
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5388
> URL: https://issues.jboss.org/browse/WFLY-5388
> Project: WildFly
> Issue Type: Bug
> Components: REST, Web (Undertow)
> Affects Versions: 8.2.1.Final, 9.0.1.Final, 10.0.0.CR1
> Reporter: Matyas Danter
> Assignee: Stuart Douglas
>
> When using Java EE 7, rest, jackson, with an AngularJS front end there's an intermittent exception when accessing REST endpoints. The exception stack trace in DEBUG level is here: http://pastebin.com/xjqMMkns . A reproducer can be found here https://github.com/ge0ffrey/optaconf .
> The exception seems to not affect the expected behavior of my application. I did see something similar for JBoss EAP 6.3.0 being categorized as blocker level due to the exception log level being inappropriate.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
- 1
- 0
[JBoss JIRA] (WFLY-5100) Server does not start when transaction subsystem configures journal object store
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/WFLY-5100?page=com.atlassian.jira.plugin.... ]
Amos Feng resolved WFLY-5100.
-----------------------------
Resolution: Done
> Server does not start when transaction subsystem configures journal object store
> --------------------------------------------------------------------------------
>
> Key: WFLY-5100
> URL: https://issues.jboss.org/browse/WFLY-5100
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 10.0.0.Beta1, 10.0.0.Beta2, 10.0.0.CR1
> Reporter: Ondřej Chaloupka
> Assignee: Amos Feng
> Priority: Blocker
> Fix For: 10.0.0.Final
>
> Attachments: standalone.xml
>
>
> Currently when object store is configured to use journal to save the txn log the server won't start.
> For WFLY 10.Beta1 there is trouble of attributes naming - see WFLY-5078. But either when used old naming [1] (hornetq instead of activemq) the server fails to start [2].
> For WFLY 10.CR1 the naming works fine and {{use-journal-store}} works when used via jboss-cli.sh but the server starts still with the errors.
> [1]
> {code}
> /subsystem=transactions:write-attribute(name=use-journal-store, value=true)
> {code}
> [2]
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 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)
> Caused by: com.arjuna.ats.arjuna.exceptions.FatalError: ARJUNA012135: Could not create Store type: com.arjuna.ats.internal.arjuna.objectstore.hornetq.HornetqObjectStoreAdaptor
> at com.arjuna.ats.arjuna.objectstore.StoreManager.initStore(StoreManager.java:155)
> at com.arjuna.ats.arjuna.objectstore.StoreManager.getActionStore(StoreManager.java:110)
> at com.arjuna.ats.arjuna.objectstore.StoreManager.getRecoveryStore(StoreManager.java:67)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.CommitMarkableResourceRecordRecoveryModule.<init>(CommitMarkableResourceRecordRecoveryModule.java:156)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
> at java.lang.Class.newInstance(Class.java:442)
> at com.arjuna.common.internal.util.ClassloadingUtility.loadAndInstantiateClass(ClassloadingUtility.java:135)
> at com.arjuna.common.internal.util.ClassloadingUtility.loadAndInstantiateClassesWithInit(ClassloadingUtility.java:192)
> at com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean.getRecoveryModules(RecoveryEnvironmentBean.java:444)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.loadModules(PeriodicRecovery.java:865)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.<init>(PeriodicRecovery.java:121)
> at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:107)
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.<init>(RecoveryManager.java:477)
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.manager(RecoveryManager.java:132)
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.manager(RecoveryManager.java:112)
> at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.create(RecoveryManagerService.java:54)
> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:119)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> Caused by: java.lang.NoClassDefFoundError: org/apache/activemq/artemis/core/journal/SequentialFileFactory
> at com.arjuna.ats.internal.arjuna.objectstore.hornetq.HornetqObjectStoreAdaptor.<init>(HornetqObjectStoreAdaptor.java:78)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
> at java.lang.Class.newInstance(Class.java:442)
> at com.arjuna.common.internal.util.ClassloadingUtility.loadAndInstantiateClass(ClassloadingUtility.java:135)
> at com.arjuna.ats.arjuna.objectstore.StoreManager.initStore(StoreManager.java:151)
> ... 24 more
> Caused by: java.lang.ClassNotFoundException: org.apache.activemq.artemis.core.journal.SequentialFileFactory from [Module "org.jboss.jts:main" from local module loader @707f7052 (finder: local module finder @11028347 (roots: /home/ochaloup/jboss/jboss-eap-7.0.0.DR8/modules,/home/ochaloup/jboss/jboss-eap-7.0.0.DR8/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
> ... 32 more
> ...
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "transactions")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.txn.ArjunaRecoveryManager" => "org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: Failed to start service
> Caused by: com.arjuna.ats.arjuna.exceptions.FatalError: ARJUNA012135: Could not create Store type: com.arjuna.ats.internal.arjuna.objectstore.hornetq.HornetqObjectStoreAdaptor
> Caused by: java.lang.NoClassDefFoundError: org/apache/activemq/artemis/core/journal/SequentialFileFactory
> Caused by: java.lang.ClassNotFoundException: org.apache.activemq.artemis.core.journal.SequentialFileFactory from [Module \"org.jboss.jts:main\" from local module loader @707f7052 (finder: local module finder @11028347 (roots: /home/ochaloup/jboss/jboss-eap-7.0.0.DR8/modules,/home/ochaloup/jboss/jboss-eap-7.0.0.DR8/modules/system/layers/base))]"}}
> INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0186: Services which failed to start: service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: Failed to start service
> {code}
> The reason is explained in comment
> https://issues.jboss.org/browse/WFLY-5078?focusedCommentId=13098047#comme...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
- 1
- 0
[JBoss JIRA] (WFLY-5374) Server start-up fails on IBM JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
by Clebert Suconic (JIRA)
[ https://issues.jboss.org/browse/WFLY-5374?page=com.atlassian.jira.plugin.... ]
Clebert Suconic reassigned WFLY-5374:
-------------------------------------
Assignee: Jeff Mesnil (was: Clebert Suconic)
Assigning Back to Jeff so he can backport the fix to a fork or something
> Server start-up fails on IBM JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
> ---------------------------------------------------------------------------------
>
> Key: WFLY-5374
> URL: https://issues.jboss.org/browse/WFLY-5374
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR1, 10.0.0.CR2
> Environment: IBM 1.8 - 64-bit:
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT - tr.r14.java_20150625_95081.01
> GC - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: javacore.20150921.051514.4815.0002.txt
>
>
> EAP 7.0.0.DR10/Wildfly 10 CR1 fails to start on IBM 1.8 (64) on RHEL 6/7. This is regression against previous version.
> Console log:
> {code}[hudson@messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /tmp/dr10/jboss-eap-7.0
> JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java
> JAVA_OPTS: -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 05:15:10,530 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 05:15:10,915 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 05:15:11,052 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 05:15:12,492 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> 05:15:12,726 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 05:15:12,760 INFO [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
> 05:15:12,771 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
> 05:15:12,814 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
> 05:15:12,839 INFO [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
> 05:15:12,842 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 05:15:12,874 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
> 05:15:12,858 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 05:15:12,880 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
> 05:15:12,886 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 05:15:12,890 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
> 05:15:12,961 INFO [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
> 05:15:12,973 INFO [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 05:15:12,990 INFO [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
> 05:15:13,061 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,062 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 05:15:13,065 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,078 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 05:15:13,150 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
> 05:15:13,218 INFO [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
> 05:15:13,218 INFO [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 05:15:13,361 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
> 05:15:13,361 INFO [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
> 05:15:13,463 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 05:15:13,492 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
> 05:15:13,499 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
> 05:15:13,598 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
> 05:15:13,598 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
> 05:15:13,656 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 05:15:13,680 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 05:15:13,826 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 05:15:13,928 INFO [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
> 05:15:13,938 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
> 05:15:14,053 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
> 05:15:14,163 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
> 05:15:14,187 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
> 05:15:14,296 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 05:15:14,302 WARN [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,303 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
> 05:15:14,303 WARN [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,304 WARN [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,305 WARN [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,315 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
> 05:15:14,317 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
> Unhandled exception
> Type=Segmentation error vmState=0x00000000
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
> RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
> RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
> R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
> R14=00007F0FD02A9020 R15=0000000000000000
> RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
> EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
> xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
> xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
> xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
> xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
> xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
> xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
> xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
> xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
> xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
> xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
> xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
> xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
> xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
> Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
> Module_base_address=00007F100C58E000
> Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
> CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F100C606C45 [libj9vm28.so+0x78c45])
> (0x00007F100C61BECA [libj9vm28.so+0x8deca])
> ---------------------------------------
> JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
> JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
> JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
> JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
> JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
> JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
> JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
> JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
> JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
> JVMDUMP013I Processed dump event "gpf", detail "".
> {code}
> Java version:
> {code}java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT - tr.r14.java_20150625_95081.01
> GC - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
- 1
- 0
[JBoss JIRA] (WFLY-5374) Server start-up fails on IBM JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
by Clebert Suconic (JIRA)
[ https://issues.jboss.org/browse/WFLY-5374?page=com.atlassian.jira.plugin.... ]
Clebert Suconic commented on WFLY-5374:
---------------------------------------
https://issues.apache.org/jira/browse/ARTEMIS-237
> Server start-up fails on IBM JDK 1.8 (64-bit) on RHEL 6/7 in full/full-ha profile
> ---------------------------------------------------------------------------------
>
> Key: WFLY-5374
> URL: https://issues.jboss.org/browse/WFLY-5374
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR1, 10.0.0.CR2
> Environment: IBM 1.8 - 64-bit:
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT - tr.r14.java_20150625_95081.01
> GC - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> Reporter: Miroslav Novak
> Assignee: Clebert Suconic
> Priority: Blocker
> Attachments: javacore.20150921.051514.4815.0002.txt
>
>
> EAP 7.0.0.DR10/Wildfly 10 CR1 fails to start on IBM 1.8 (64) on RHEL 6/7. This is regression against previous version.
> Console log:
> {code}[hudson@messaging-20 bin]$ sh standalone.sh -c standalone-full-ha.xml
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /tmp/dr10/jboss-eap-7.0
> JAVA: /qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28//bin/java
> JAVA_OPTS: -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 05:15:10,530 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 05:15:10,915 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 05:15:11,052 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.CR1) starting
> 05:15:12,492 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 30) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> 05:15:12,726 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 05:15:12,760 INFO [org.xnio] (MSC service thread 1-1) XNIO version 3.3.2.Final
> 05:15:12,771 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.2.Final
> 05:15:12,814 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 44) WFLYCLINF0001: Activating Infinispan subsystem.
> 05:15:12,839 INFO [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 45) WFLYIIOP0001: Activating IIOP Subsystem
> 05:15:12,842 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 66) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 05:15:12,874 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 68) WFLYWS0002: Activating WebServices Extension
> 05:15:12,858 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 52) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 05:15:12,880 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 49) WFLYCLJG0001: Activating JGroups subsystem.
> 05:15:12,886 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 43) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
> 05:15:12,890 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 57) WFLYNAM0001: Activating Naming Subsystem
> 05:15:12,961 INFO [org.jboss.as.security] (ServerService Thread Pool -- 64) WFLYSEC0002: Activating Security Subsystem
> 05:15:12,973 INFO [org.jboss.as.security] (MSC service thread 1-5) WFLYSEC0001: Current PicketBox version=4.9.3.Final
> 05:15:12,990 INFO [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.0.Final)
> 05:15:13,061 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,062 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 39) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 05:15:13,065 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.0.CR1 starting
> 05:15:13,078 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
> 05:15:13,150 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.10.Final
> 05:15:13,218 INFO [org.jboss.as.naming] (MSC service thread 1-7) WFLYNAM0003: Starting Naming Service
> 05:15:13,218 INFO [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 05:15:13,361 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 128 (per class), which is derived from thread worker pool sizing.
> 05:15:13,361 INFO [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 32 (per class), which is derived from the number of CPUs on this host.
> 05:15:13,463 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 67) WFLYUT0014: Creating file handler for path '/tmp/dr10/jboss-eap-7.0/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 05:15:13,492 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0012: Started server default-server.
> 05:15:13,499 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0018: Host default-host starting
> 05:15:13,598 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
> 05:15:13,598 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:8009
> 05:15:13,656 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> 05:15:13,680 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 71) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> 05:15:13,826 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 05:15:13,928 INFO [org.wildfly.iiop.openjdk] (MSC service thread 1-4) WFLYIIOP0009: CORBA ORB Service started
> 05:15:13,938 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /tmp/dr10/jboss-eap-7.0/standalone/deployments
> 05:15:14,053 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.1.0.Final
> 05:15:14,163 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/journal,bindingsDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/largemessages,pagingDirectory=/tmp/dr10/jboss-eap-7.0/standalone/data/activemq/paging)
> 05:15:14,187 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221012: Using AIO Journal
> 05:15:14,296 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 05:15:14,302 WARN [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket DatagramSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,303 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-amqp-protocol]. Adding protocol support for: AMQP
> 05:15:14,303 WARN [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,304 WARN [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the send buffer of socket MulticastSocket was set to 1MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 05:15:14,305 WARN [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=446a359f-6041-11e5-895c-5dd24064fdad-953422266)) JGRP000015: the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 05:15:14,315 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
> 05:15:14,317 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221043: Protocol module found: [artemis-stomp-protocol]. Adding protocol support for: STOMP
> Unhandled exception
> Type=Segmentation error vmState=0x00000000
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F100C601D90 Handler2=00007F1007DD03F0 InaccessibleAddress=0000000000000000
> RDI=0000000002C82D00 RSI=0000000000000000 RAX=00007F0FDCB3977F RBX=0000000000000000
> RCX=0000000000000000 RDX=00007F0FDCB39780 R8=00007F0FDCB39780 R9=00007F100C667A58
> R10=00007F0FD03885C0 R11=0000000000200246 R12=0000000002C82D00 R13=00000000000001F4
> R14=00007F0FD02A9020 R15=0000000000000000
> RIP=00007F100C606C45 GS=0000 FS=0000 RSP=00007F0FDCB394C0
> EFlags=0000000000210246 CS=0033 RBP=00007F0FDCB39770 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f1008067fe0 (f: 134643680.000000, d: 6.902435e-310)
> xmm1 0000000002c82d00 (f: 46673152.000000, d: 2.305960e-316)
> xmm2 0000000002c82a78 (f: 46672504.000000, d: 2.305928e-316)
> xmm3 00000000029a16c8 (f: 43652808.000000, d: 2.156735e-316)
> xmm4 0000000000000005 (f: 5.000000, d: 2.470328e-323)
> xmm5 00000000029a1828 (f: 43653160.000000, d: 2.156753e-316)
> xmm6 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm7 0000000000000001 (f: 1.000000, d: 4.940656e-324)
> xmm8 4169e3bd00000000 (f: 0.000000, d: 1.357361e+07)
> xmm9 3fcb1f59ad7ad780 (f: 2910509056.000000, d: 2.118942e-01)
> xmm10 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
> xmm11 be88000000000000 (f: 0.000000, d: -1.788139e-07)
> xmm12 bcd2800000000000 (f: 0.000000, d: -1.026956e-15)
> xmm13 bc34000000000000 (f: 0.000000, d: -1.084202e-18)
> xmm14 3c66353ab386a94d (f: 3011946752.000000, d: 9.631153e-18)
> xmm15 4030a2b23f3baa00 (f: 1060874752.000000, d: 1.663553e+01)
> Module=/qa/tools/opt/x86_64/ibm-java-x86_64-80_2015_07_28/jre/lib/amd64/compressedrefs/libj9vm28.so
> Module_base_address=00007F100C58E000
> Target=2_80_20150630_255633 (Linux 3.10.0-229.1.2.el7.x86_64)
> CPU=amd64 (8 logical CPUs) (0x4dce1d000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F100C606C45 [libj9vm28.so+0x78c45])
> (0x00007F100C61BECA [libj9vm28.so+0x8deca])
> ---------------------------------------
> JVMDUMP039I Processing dump event "gpf", detail "" at 2015/09/21 05:15:14 - please wait.
> JVMDUMP032I JVM requested System dump using '/tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp' in response to an event
> JVMDUMP010I System dump written to /tmp/dr10/jboss-eap-7.0/bin/core.20150921.051514.4815.0001.dmp
> JVMDUMP032I JVM requested Java dump using '/tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt' in response to an event
> JVMDUMP010I Java dump written to /tmp/dr10/jboss-eap-7.0/bin/javacore.20150921.051514.4815.0002.txt
> JVMDUMP032I JVM requested Snap dump using '/tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc' in response to an event
> JVMDUMP010I Snap dump written to /tmp/dr10/jboss-eap-7.0/bin/Snap.20150921.051514.4815.0003.trc
> JVMDUMP007I JVM Requesting JIT dump using '/tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp'
> JVMDUMP010I JIT dump written to /tmp/dr10/jboss-eap-7.0/bin/jitdump.20150921.051514.4815.0004.dmp
> JVMDUMP013I Processed dump event "gpf", detail "".
> {code}
> Java version:
> {code}java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT - tr.r14.java_20150625_95081.01
> GC - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
- 1
- 0
[JBoss JIRA] (WFLY-5425) http-listener requires 'https' socket-binding, part 2
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5425?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-5425.
----------------------------------
Resolution: Out of Date
Fixed by https://github.com/wildfly/wildfly/commit/b20e5fd
> http-listener requires 'https' socket-binding, part 2
> -----------------------------------------------------
>
> Key: WFLY-5425
> URL: https://issues.jboss.org/browse/WFLY-5425
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Reporter: Vsevolod Golovanov
> Assignee: Stuart Douglas
>
> Continuing WFLY-2836.
> Is there a way to override {{http-listener}}'s {{redirect-socket}} attribute default value ("https") to be null?
> {quote}This is just default value, looking at the downside of not having default value for redirect-socket would be that people would not configure it, which would result in problems when having apps that require secure transport.{quote}
> Our app doesn't require secure transport.
> {code}redirect-socket=""{code}
> results in
> {noformat}
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[956,166]
> Message: "JBAS014704: '' is an invalid value for parameter redirect-socket. Values must have a minimum length of 1 characters"
> {noformat}
> This:
> {code}redirect-socket="null"{code}
> treats it literally:
> {noformat}
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.undertow.listener.someapp-http-listener is missing [jboss.binding.null]"]}
> {noformat}
> So we're forced to have a https socket-binding. Which is not a "just define some binding" problem. It's a "negotiate with customers&sysadmins/document it/provide options to configure it" problem.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
- 1
- 0
[JBoss JIRA] (JGRP-1844) Remove shared transport
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1844?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1844:
--------------------------------
Why can't you create multiple fork channels ? Each fork channel is independent from the others, while they have the same view and address.
The reason for sharing the views is that I made a big mistake a couple of years ago by introducing "service views" which complicated things and were never quite correct compared to JGroups views (google for jgroups "service view").
Can you clarify your use case above with an example ? I'm pretty dead set on removing the shared transport, unless there's a convincing use case / requirement against it...
> Remove shared transport
> -----------------------
>
> Key: JGRP-1844
> URL: https://issues.jboss.org/browse/JGRP-1844
> Project: JGroups
> Issue Type: Task
> Affects Versions: 3.5
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> I'm thinking of deprecating the shared transport [1] and remove it in 4.0. The replacement would be fork channels [2].
> Here's my reasoning:
> * Shared transports are quite a complex beast: initialization (ref counting), cluster-name and local-addr are not used in TP when shared, duplicate logic. Removing this will make the code base smaller
> * All protocols *above* shared transports are not shared, e.g. FD_SOCK, NAKACK, UNICAST etc all maintain their own threads, retransmission tables, sockets etc. With fork channels, everything up to the FORK protocol *is* shared
> * TUNNEL doesn't work with shared transports (throws an exception)
> * Hidden insertion of TP$ProtocolAdapter into the stack when shared transports are used
> * Unneeded cost of sending N-1 messages (e.g. with TCP). Currently we send a message with dest null and no IP multicast capable transport to all physical addresses in the transport, which is a waste
> Thoughts ? My +100 for removing shared transports in 4.0...
> [1] http://www.jgroups.org/manual/html/user-advanced.html#SharedTransport
> [2] http://www.jgroups.org/manual/html/user-advanced.html#ForkChannel
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
- 1
- 0
[JBoss JIRA] (JGRP-1844) Remove shared transport
by Rich DiCroce (JIRA)
[ https://issues.jboss.org/browse/JGRP-1844?page=com.atlassian.jira.plugin.... ]
Rich DiCroce edited comment on JGRP-1844 at 9/29/15 5:40 PM:
-------------------------------------------------------------
I have a project with a (probably rare) use case that requires participation in multiple independent channels. Shared transport is useful for reducing resource usage in this case. Fork channels are not an acceptable substitute because each channel has different participants, and fork channels have the limitation that the fork's view is always the same as the main channel's view.
So if shared transport is to be deprecated and removed, some accommodation should be made to deal with the above. Perhaps by changing fork channels such that their view is a subset of the main view. Fork allows "asymmetric" clusters where fork channels may be present on some members but not others, but that is currently not reflected in the fork's view. That means there's no way to easily determine which members are actually participating in the fork. This feels very strange to me, especially since fork channels do have their own addresses. It seems like it should be the other way around: rather than inheriting membership but not address, the fork channel should inherit address but not membership.
EDIT: I was wrong about the address, that is indeed the same on both the fork and the main. I must've been looking at the wrong channels. But the point about the view still stands.
was (Author: rcd):
I have a project with a (probably rare) use case that requires participation in multiple independent channels. Shared transport is useful for reducing resource usage in this case. Fork channels are not an acceptable substitute because each channel has different participants, and fork channels have the limitation that the fork's view is always the same as the main channel's view.
So if shared transport is to be deprecated and removed, some accommodation should be made to deal with the above. Perhaps by changing fork channels such that their view is a subset of the main view. Fork allows "asymmetric" clusters where fork channels may be present on some members but not others, but that is currently not reflected in the fork's view. That means there's no way to easily determine which members are actually participating in the fork. This feels very strange to me, especially since fork channels do have their own addresses. It seems like it should be the other way around: rather than inheriting membership but not address, the fork channel should inherit address but not membership.
> Remove shared transport
> -----------------------
>
> Key: JGRP-1844
> URL: https://issues.jboss.org/browse/JGRP-1844
> Project: JGroups
> Issue Type: Task
> Affects Versions: 3.5
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> I'm thinking of deprecating the shared transport [1] and remove it in 4.0. The replacement would be fork channels [2].
> Here's my reasoning:
> * Shared transports are quite a complex beast: initialization (ref counting), cluster-name and local-addr are not used in TP when shared, duplicate logic. Removing this will make the code base smaller
> * All protocols *above* shared transports are not shared, e.g. FD_SOCK, NAKACK, UNICAST etc all maintain their own threads, retransmission tables, sockets etc. With fork channels, everything up to the FORK protocol *is* shared
> * TUNNEL doesn't work with shared transports (throws an exception)
> * Hidden insertion of TP$ProtocolAdapter into the stack when shared transports are used
> * Unneeded cost of sending N-1 messages (e.g. with TCP). Currently we send a message with dest null and no IP multicast capable transport to all physical addresses in the transport, which is a waste
> Thoughts ? My +100 for removing shared transports in 4.0...
> [1] http://www.jgroups.org/manual/html/user-advanced.html#SharedTransport
> [2] http://www.jgroups.org/manual/html/user-advanced.html#ForkChannel
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
- 1
- 0
[JBoss JIRA] (JGRP-1844) Remove shared transport
by Rich DiCroce (JIRA)
[ https://issues.jboss.org/browse/JGRP-1844?page=com.atlassian.jira.plugin.... ]
Rich DiCroce commented on JGRP-1844:
------------------------------------
I have a project with a (probably rare) use case that requires participation in multiple independent channels. Shared transport is useful for reducing resource usage in this case. Fork channels are not an acceptable substitute because each channel has different participants, and fork channels have the limitation that the fork's view is always the same as the main channel's view.
So if shared transport is to be deprecated and removed, some accommodation should be made to deal with the above. Perhaps by changing fork channels such that their view is a subset of the main view. Fork allows "asymmetric" clusters where fork channels may be present on some members but not others, but that is currently not reflected in the fork's view. That means there's no way to easily determine which members are actually participating in the fork. This feels very strange to me, especially since fork channels do have their own addresses. It seems like it should be the other way around: rather than inheriting membership but not address, the fork channel should inherit address but not membership.
> Remove shared transport
> -----------------------
>
> Key: JGRP-1844
> URL: https://issues.jboss.org/browse/JGRP-1844
> Project: JGroups
> Issue Type: Task
> Affects Versions: 3.5
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> I'm thinking of deprecating the shared transport [1] and remove it in 4.0. The replacement would be fork channels [2].
> Here's my reasoning:
> * Shared transports are quite a complex beast: initialization (ref counting), cluster-name and local-addr are not used in TP when shared, duplicate logic. Removing this will make the code base smaller
> * All protocols *above* shared transports are not shared, e.g. FD_SOCK, NAKACK, UNICAST etc all maintain their own threads, retransmission tables, sockets etc. With fork channels, everything up to the FORK protocol *is* shared
> * TUNNEL doesn't work with shared transports (throws an exception)
> * Hidden insertion of TP$ProtocolAdapter into the stack when shared transports are used
> * Unneeded cost of sending N-1 messages (e.g. with TCP). Currently we send a message with dest null and no IP multicast capable transport to all physical addresses in the transport, which is a waste
> Thoughts ? My +100 for removing shared transports in 4.0...
> [1] http://www.jgroups.org/manual/html/user-advanced.html#SharedTransport
> [2] http://www.jgroups.org/manual/html/user-advanced.html#ForkChannel
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
- 1
- 0
[JBoss JIRA] (WFCORE-832) Access control exceptions missing for non-existent resources
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-832?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-832:
-----------------------------------------
Thanks.
I agree that rolling them up would be both difficult and could lead to other bugs.
I think what you have is ok, so long as there is a clear pattern that always applies and can be documented. Something like:
"If in the exceptions section there is an entry with a wildcard value in an element of its address, this indicates there is resource type definition registered under that exact element, but that there are no actual resource instances of that type. If there are actual resource instances of a type, there will be individual exceptions entries for those resources."
> Access control exceptions missing for non-existent resources
> ------------------------------------------------------------
>
> Key: WFCORE-832
> URL: https://issues.jboss.org/browse/WFCORE-832
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Harald Pehl
> Assignee: Kabir Khan
>
> When asking for the access control metadata using (r-r-d) on *existing* resources I get an exceptions block:
> {code}
> /server-group=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
> "outcome" => "success",
> "result" => [{
> "address" => [("server-group" => "*")],
> "outcome" => "success",
> "result" => {
> "description" => undefined,
> "attributes" => undefined,
> "operations" => undefined,
> "notifications" => undefined,
> "children" => {
> "deployment" => {"model-description" => undefined},
> "jvm" => {"model-description" => undefined},
> "deployment-overlay" => {"model-description" => undefined},
> "system-property" => {"model-description" => undefined}
> },
> "access-control" => {
> "default" => {
> "read" => true,
> "write" => false,
> "attributes" => {
> "management-subsystem-endpoint" => {
> "read" => true,
> "write" => false
> },
> "profile" => {
> "read" => true,
> "write" => false
> },
> "socket-binding-default-interface" => {
> "read" => true,
> "write" => false
> },
> "socket-binding-group" => {
> "read" => true,
> "write" => false
> },
> "socket-binding-port-offset" => {
> "read" => true,
> "write" => false
> }
> },
> "operations" => {
> "read-children-types" => {"execute" => true},
> "whoami" => {"execute" => true},
> "map-clear" => {"execute" => false},
> "list-get" => {"execute" => true},
> "write-attribute" => {"execute" => false},
> "replace-deployment" => {"execute" => false},
> "stop-servers" => {"execute" => false},
> "remove" => {"execute" => false},
> "list-add" => {"execute" => false},
> "map-put" => {"execute" => false},
> "read-attribute-group-names" => {"execute" => true},
> "restart-servers" => {"execute" => false},
> "resume-servers" => {"execute" => false},
> "read-resource-description" => {"execute" => true},
> "read-resource" => {"execute" => true},
> "add" => {"execute" => false},
> "suspend-servers" => {"execute" => false},
> "reload-servers" => {"execute" => false},
> "query" => {"execute" => true},
> "read-operation-description" => {"execute" => true},
> "map-get" => {"execute" => true},
> "list-clear" => {"execute" => false},
> "read-attribute" => {"execute" => true},
> "map-remove" => {"execute" => false},
> "read-attribute-group" => {"execute" => true},
> "undefine-attribute" => {"execute" => false},
> "read-children-names" => {"execute" => true},
> "start-servers" => {"execute" => false},
> "read-operation-names" => {"execute" => true},
> "list-remove" => {"execute" => false},
> "read-children-resources" => {"execute" => true}
> }
> },
> "exceptions" => {"[(\"server-group\" => \"main-server-group\")]" => {
> "read" => true,
> "write" => true,
> "attributes" => {
> "management-subsystem-endpoint" => {
> "read" => true,
> "write" => false
> },
> "profile" => {
> "read" => true,
> "write" => true
> },
> "socket-binding-default-interface" => {
> "read" => true,
> "write" => false
> },
> "socket-binding-group" => {
> "read" => true,
> "write" => true
> },
> "socket-binding-port-offset" => {
> "read" => true,
> "write" => false
> }
> },
> "operations" => {
> "read-children-types" => {"execute" => true},
> "whoami" => {"execute" => true},
> "map-clear" => {"execute" => true},
> "list-get" => {"execute" => true},
> "write-attribute" => {"execute" => true},
> "replace-deployment" => {"execute" => true},
> "stop-servers" => {"execute" => true},
> "remove" => {"execute" => false},
> "list-add" => {"execute" => true},
> "map-put" => {"execute" => true},
> "read-attribute-group-names" => {"execute" => true},
> "restart-servers" => {"execute" => true},
> "resume-servers" => {"execute" => true},
> "read-resource-description" => {"execute" => true},
> "read-resource" => {"execute" => true},
> "add" => {"execute" => false},
> "suspend-servers" => {"execute" => true},
> "reload-servers" => {"execute" => true},
> "query" => {"execute" => true},
> "read-operation-description" => {"execute" => true},
> "map-get" => {"execute" => true},
> "list-clear" => {"execute" => true},
> "read-attribute" => {"execute" => true},
> "map-remove" => {"execute" => true},
> "read-attribute-group" => {"execute" => true},
> "undefine-attribute" => {"execute" => true},
> "read-children-names" => {"execute" => true},
> "start-servers" => {"execute" => true},
> "read-operation-names" => {"execute" => true},
> "list-remove" => {"execute" => true},
> "read-children-resources" => {"execute" => true}
> },
> "address" => [("server-group" => "main-server-group")]
> }}
> }
> }
> }]
> }
> {code}
> However when using the same operation on *non-existng* resources I don't see an exception block:
> {code}
> /server-group=*/deployment=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
> {
> "outcome" => "success",
> "result" => [{
> "address" => [
> ("server-group" => "*"),
> ("deployment" => "*")
> ],
> "outcome" => "success",
> "result" => {
> "description" => undefined,
> "access-constraints" => {"application" => {"deployment" => {"type" => "core"}}},
> "attributes" => undefined,
> "operations" => undefined,
> "notifications" => undefined,
> "children" => {},
> "access-control" => {
> "default" => {
> "read" => true,
> "write" => false,
> "attributes" => {
> "enabled" => {
> "read" => true,
> "write" => false
> },
> "name" => {
> "read" => true,
> "write" => false
> },
> "runtime-name" => {
> "read" => true,
> "write" => false
> }
> },
> "operations" => {
> "read-children-types" => {"execute" => true},
> "whoami" => {"execute" => true},
> "map-clear" => {"execute" => false},
> "list-get" => {"execute" => true},
> "write-attribute" => {"execute" => false},
> "remove" => {"execute" => false},
> "deploy" => {"execute" => false},
> "list-add" => {"execute" => false},
> "map-put" => {"execute" => false},
> "read-attribute-group-names" => {"execute" => true},
> "redeploy" => {"execute" => false},
> "read-resource-description" => {"execute" => true},
> "read-resource" => {"execute" => true},
> "add" => {"execute" => false},
> "query" => {"execute" => true},
> "read-operation-description" => {"execute" => true},
> "map-get" => {"execute" => true},
> "list-clear" => {"execute" => false},
> "read-attribute" => {"execute" => true},
> "map-remove" => {"execute" => false},
> "read-attribute-group" => {"execute" => true},
> "undefine-attribute" => {"execute" => false},
> "read-children-names" => {"execute" => true},
> "read-operation-names" => {"execute" => true},
> "list-remove" => {"execute" => false},
> "read-children-resources" => {"execute" => true},
> "undeploy" => {"execute" => false}
> }
> },
> "exceptions" => {}
> }
> }
> }]
> }
> {code}
> Some notes on the domain:
> - Built from WildFly 10 master
> - No deployments present
> - Role {{main-maintainer}} is a server group scoped role based on Maintainer and scoped to main-server-group
> - Role {{other-monitor}} is a server group scoped role based on Monitor and scoped to other-server-group
> What we would need is a way to *always* get the exceptions no matter whether the resource exists. In the console we create a so-called security context which uses wildcard r-r-d operations like the ones above. This security context is used later on to show / hide UI controls.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
- 1
- 0