[JBoss JIRA] (JGRP-2088) ArrayIndexOutOfBoundsException on ClassConfigurator.get()
by Manuel Dominguez Sarmiento (JIRA)
[ https://issues.jboss.org/browse/JGRP-2088?page=com.atlassian.jira.plugin.... ]
Manuel Dominguez Sarmiento updated JGRP-2088:
---------------------------------------------
Description:
See the following stack trace:
[ERROR] 2016-07-09 14:26:05 [UDP-multicast receiver,shared=jgroups-shared-transport] - JGRP000030: null: failed handling incoming message: java.lang.ArrayIndexOutOfBoundsException: -1
java.lang.ArrayIndexOutOfBoundsException: -1
at org.jgroups.conf.ClassConfigurator.get(ClassConfigurator.java:161)
at org.jgroups.Message.readHeader(Message.java:936)
at org.jgroups.Message.readFrom(Message.java:811)
at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1712)
at org.jgroups.protocols.TP.receive(TP.java:1654)
at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
at java.lang.Thread.run(Thread.java:745)
Stepping through the code with the debugger shows that the following line is failing at ClassConfigurator.get() with magic = -1 thus the java.lang.ArrayIndexOutOfBoundsException
return magic < 1024 ? magicMap[magic] : (Class)magicMapUser.get(Short.valueOf(magic));
See attached jgroups.xml for configuration. This showed up when upgrading to 3.6.10 from 3.6.8 which worked fine.
was:
See the following stack trace:
[ERROR] 2016-07-09 14:26:05 [UDP-multicast receiver,shared=jgroups-shared-transport] - JGRP000030: null: failed handling incoming message: java.lang.ArrayIndexOutOfBoundsException: -1
java.lang.ArrayIndexOutOfBoundsException: -1
at org.jgroups.conf.ClassConfigurator.get(ClassConfigurator.java:161)
at org.jgroups.Message.readHeader(Message.java:936)
at org.jgroups.Message.readFrom(Message.java:811)
at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1712)
at org.jgroups.protocols.TP.receive(TP.java:1654)
at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
at java.lang.Thread.run(Thread.java:745)
Stepping through the code with the debugger should that the following line is failing at ClassConfigurator.get() with magic = -1 thus the java.lang.ArrayIndexOutOfBoundsException
return magic < 1024 ? magicMap[magic] : (Class)magicMapUser.get(Short.valueOf(magic));
See attached jgroups.xml for configuration. This showed up when upgrading to 3.6.10 from 3.6.8 which worked fine.
> ArrayIndexOutOfBoundsException on ClassConfigurator.get()
> ---------------------------------------------------------
>
> Key: JGRP-2088
> URL: https://issues.jboss.org/browse/JGRP-2088
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Manuel Dominguez Sarmiento
> Assignee: Bela Ban
> Attachments: jgroups.xml
>
>
> See the following stack trace:
> [ERROR] 2016-07-09 14:26:05 [UDP-multicast receiver,shared=jgroups-shared-transport] - JGRP000030: null: failed handling incoming message: java.lang.ArrayIndexOutOfBoundsException: -1
> java.lang.ArrayIndexOutOfBoundsException: -1
> at org.jgroups.conf.ClassConfigurator.get(ClassConfigurator.java:161)
> at org.jgroups.Message.readHeader(Message.java:936)
> at org.jgroups.Message.readFrom(Message.java:811)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1712)
> at org.jgroups.protocols.TP.receive(TP.java:1654)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:745)
> Stepping through the code with the debugger shows that the following line is failing at ClassConfigurator.get() with magic = -1 thus the java.lang.ArrayIndexOutOfBoundsException
> return magic < 1024 ? magicMap[magic] : (Class)magicMapUser.get(Short.valueOf(magic));
> See attached jgroups.xml for configuration. This showed up when upgrading to 3.6.10 from 3.6.8 which worked fine.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1615) Make wildfly-init-redhat.sh consistent with wildfly-init-debian.sh
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1615?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1615:
----------------------------------------
Fix Version/s: 3.0.0.Alpha4
Assignee: Jorge Solorzano
Resolution: Done
> Make wildfly-init-redhat.sh consistent with wildfly-init-debian.sh
> ------------------------------------------------------------------
>
> Key: WFCORE-1615
> URL: https://issues.jboss.org/browse/WFCORE-1615
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Scripts
> Affects Versions: 3.0.0.Alpha2
> Reporter: Jorge Solorzano
> Assignee: Jorge Solorzano
> Priority: Trivial
> Fix For: 3.0.0.Alpha4
>
>
> To make both scripts more consistent in terms of functionality.
> Changes include:
> * Add LSB INIT INFO
> * Validate user and permisions.
> * Make output of status more standard.
> * Improve output messages.
> * Include WFCORE-1604
> Tested enviroments:
> * CentOS 6.8
> * CentOS 7.2
> * Fedora 24 Server
> The script should be functional on both pre-systemd and systemd without weird behaivior.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1604) Fail-fast start up init.d scripts on error
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1604?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1604:
----------------------------------------
Assignee: Jorge Solorzano (was: Tomaz Cerar)
> Fail-fast start up init.d scripts on error
> ------------------------------------------
>
> Key: WFCORE-1604
> URL: https://issues.jboss.org/browse/WFCORE-1604
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Scripts
> Affects Versions: 3.0.0.Alpha1
> Environment: Debian/Ubuntu - Red Hat/Fedora
> Reporter: Jorge Solorzano
> Assignee: Jorge Solorzano
> Priority: Optional
> Fix For: 3.0.0.Alpha4
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> Now that WildFly creates an startup-marker we can detect an error before timeout of the init.d startup scripts and detect if the error is from timeout or from an error in application server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-711) Detect/assume duplicate instances running
by Ricardo Arguello (JIRA)
[ https://issues.jboss.org/browse/WFLY-711?page=com.atlassian.jira.plugin.s... ]
Ricardo Arguello commented on WFLY-711:
---------------------------------------
Please close as resolved, all PRs have been merged: https://github.com/wildfly/wildfly/pull/9024
> Detect/assume duplicate instances running
> -----------------------------------------
>
> Key: WFLY-711
> URL: https://issues.jboss.org/browse/WFLY-711
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Jim Tyrrell
> Fix For: Awaiting Volunteers
>
>
> I do like the fact that address in use do not leave a running instance laying around, I would much rather see one error message rather then pages and pages. To our users this is very overwhelming, especially when they come from our competitors. Also how does this kind of error not have an error code associated with it.
> How many other exceptions do not have error codes?
> Jim-Tyrrells-MacBook-Pro-2:bin jimtyrrell$ ./standalone.sh
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /Users/jimtyrrell 1/Servers/jboss-7.0.0.CR1
> JAVA: java
> JAVA_OPTS: -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman
> =========================================================================
> 08:38:37,622 INFO [org.jboss.modules] JBoss Modules version 1.0.0.CR4
> 08:38:37,772 INFO [org.jboss.msc] JBoss MSC version 1.0.0.CR2
> 08:38:37,812 INFO [org.jboss.as] JBoss AS 7.0.0.CR1 "White Rabbit" starting
> 08:38:38,328 INFO [org.jboss.as] creating http management service using network interface (management) port (9990) securePort (-1)
> 08:38:38,333 INFO [org.jboss.as.logging] Removing bootstrap log handlers
> 08:38:38,343 INFO [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying JDBC-compliant driver class org.h2.Driver (version 1.2)
> 08:38:38,413 INFO [org.jboss.as.naming] (Controller Boot Thread) Activating Naming Subsystem
> 08:38:38,420 INFO [org.jboss.as.naming] (MSC service thread 1-4) Starting Naming Service
> 08:38:38,425 INFO [org.jboss.as.osgi] (Controller Boot Thread) Activating OSGi Subsystem
> 08:38:38,436 INFO [org.jboss.as.security] (Controller Boot Thread) Activating Security Subsystem
> 08:38:38,442 INFO [org.jboss.remoting] (MSC service thread 1-10) JBoss Remoting version 3.2.0.Beta2
> 08:38:38,448 INFO [org.xnio] (MSC service thread 1-10) XNIO Version 3.0.0.Beta3
> 08:38:38,457 INFO [org.xnio.nio] (MSC service thread 1-10) XNIO NIO Implementation Version 3.0.0.Beta3
> 08:38:38,606 INFO [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-2) The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: .:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java
> 08:38:38,616 INFO [org.jboss.as.jmx.JMXConnectorService] (MSC service thread 1-10) Starting remote JMX connector
> 08:38:38,618 INFO [org.jboss.as.ee] (Controller Boot Thread) Activating EE subsystem
> 08:38:38,618 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-9) MSC00001: Failed to start service jboss.remoting.server.management.9999: org.jboss.msc.service.StartException in service jboss.remoting.server.management.9999: java.net.BindException: Address already in use
> at org.jboss.as.remoting.AbstractStreamServerService.start(AbstractStreamServerService.java:98)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
> at java.lang.Thread.run(Thread.java:680) [:1.6.0_24]
> Caused by: java.net.BindException: Address already in use
> at sun.nio.ch.Net.bind(Native Method) [:1.6.0_24]
> at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:126) [:1.6.0_24]
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59) [:1.6.0_24]
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52) [:1.6.0_24]
> at org.xnio.nio.NioXnio.createTcpServer(NioXnio.java:162)
> at org.xnio.Xnio.createStreamServer(Xnio.java:230)
> at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:162)
> at org.jboss.as.remoting.AbstractStreamServerService.start(AbstractStreamServerService.java:93)
> ... 5 more
> 08:38:38,623 WARN [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-6) Unable to set the URLStreamHandlerFactory
> 08:38:38,624 WARN [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-6) Unable to set the ContentHandlerFactory
> 08:38:38,625 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC00001: Failed to start service jboss.serverManagement.controller.management.http: org.jboss.msc.service.StartException in service jboss.serverManagement.controller.management.http: Failed to start serverManagement socket
> at org.jboss.as.server.mgmt.HttpManagementService.start(HttpManagementService.java:89)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
> at java.lang.Thread.run(Thread.java:680) [:1.6.0_24]
> Caused by: java.net.BindException: Address already in use
> at sun.nio.ch.Net.bind(Native Method) [:1.6.0_24]
> at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:126) [:1.6.0_24]
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59) [:1.6.0_24]
> at org.jboss.sun.net.httpserver.ServerImpl.<init>(ServerImpl.java:112)
> at org.jboss.sun.net.httpserver.HttpServerImpl.<init>(HttpServerImpl.java:47)
> at org.jboss.sun.net.httpserver.DefaultHttpServerProvider.createHttpServer(DefaultHttpServerProvider.java:37)
> at org.jboss.com.sun.net.httpserver.HttpServer.create(HttpServer.java:126)
> at org.jboss.as.domain.http.server.ManagementHttpServer.create(ManagementHttpServer.java:99)
> at org.jboss.as.server.mgmt.HttpManagementService.start(HttpManagementService.java:86)
> ... 5 more
> 08:38:38,632 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-10) MSC00001: Failed to start service jboss.mbean.connector: org.jboss.msc.service.StartException in service jboss.mbean.connector: java.rmi.server.ExportException: Port already in use: 1090; nested exception is:
> java.net.BindException: Address already in use
> at org.jboss.as.jmx.JMXConnectorService.start(JMXConnectorService.java:106)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
> at java.lang.Thread.run(Thread.java:680) [:1.6.0_24]
> Caused by: java.rmi.server.ExportException: Port already in use: 1090; nested exception is:
> java.net.BindException: Address already in use
> at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:310) [:1.6.0_24]
> at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:218) [:1.6.0_24]
> at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:393) [:1.6.0_24]
> at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:129) [:1.6.0_24]
> at sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:190) [:1.6.0_24]
> at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:92) [:1.6.0_24]
> at sun.rmi.registry.RegistryImpl.<init>(RegistryImpl.java:68) [:1.6.0_24]
> at java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:222) [:1.6.0_24]
> at org.jboss.as.jmx.JMXConnectorService.start(JMXConnectorService.java:97)
> ... 5 more
> Caused by: java.net.BindException: Address already in use
> at java.net.PlainSocketImpl.socketBind(Native Method) [:1.6.0_24]
> at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383) [:1.6.0_24]
> at java.net.ServerSocket.bind(ServerSocket.java:328) [:1.6.0_24]
> at org.jboss.as.network.ManagedServerSocketBinding.bind(ManagedServerSocketBinding.java:73)
> at org.jboss.as.network.SocketBinding.createServerSocket(SocketBinding.java:149)
> at org.jboss.as.jmx.JMXConnectorService$JMXServerSocketFactory.createServerSocket(JMXConnectorService.java:194)
> at sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:649) [:1.6.0_24]
> at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:299) [:1.6.0_24]
> ... 13 more
> 08:38:38,634 ERROR [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-13) Error initializing endpoint: java.net.BindException: Address already in use /127.0.0.1:8080
> at org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:1004)
> at org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:190)
> at org.apache.catalina.connector.Connector.init(Connector.java:976)
> at org.apache.catalina.core.StandardService.addConnector(StandardService.java:351)
> at org.jboss.as.web.WebServerService.addConnector(WebServerService.java:121)
> at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
> at java.lang.Thread.run(Thread.java:680) [:1.6.0_24]
> 08:38:38,636 ERROR [org.apache.catalina.core.StandardService] (MSC service thread 1-13) Connector.initialize: LifecycleException: Protocol handler initialization failed: java.net.BindException: Address already in use /127.0.0.1:8080
> at org.apache.catalina.connector.Connector.init(Connector.java:978)
> at org.apache.catalina.core.StandardService.addConnector(StandardService.java:351)
> at org.jboss.as.web.WebServerService.addConnector(WebServerService.java:121)
> at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
> at java.lang.Thread.run(Thread.java:680) [:1.6.0_24]
> 08:38:38,638 ERROR [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-13) Error starting endpoint: java.net.BindException: Address already in use /127.0.0.1:8080
> at org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:1004)
> at org.apache.tomcat.util.net.JIoEndpoint.start(JIoEndpoint.java:1020)
> at org.apache.coyote.http11.Http11Protocol.start(Http11Protocol.java:218)
> at org.apache.catalina.connector.Connector.start(Connector.java:1051)
> at org.apache.catalina.core.StandardService.addConnector(StandardService.java:359)
> at org.jboss.as.web.WebServerService.addConnector(WebServerService.java:121)
> at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
> at java.lang.Thread.run(Thread.java:680) [:1.6.0_24]
> 08:38:38,639 ERROR [org.apache.catalina.core.StandardService] (MSC service thread 1-13) Connector.start: LifecycleException: service.getName(): "jboss.web"; Protocol handler start failed: java.net.BindException: Address already in use /127.0.0.1:8080
> at org.apache.catalina.connector.Connector.start(Connector.java:1058)
> at org.apache.catalina.core.StandardService.addConnector(StandardService.java:359)
> at org.jboss.as.web.WebServerService.addConnector(WebServerService.java:121)
> at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
> at java.lang.Thread.run(Thread.java:680) [:1.6.0_24]
> 08:38:38,675 INFO [org.jboss.as.connector] (MSC service thread 1-6) Starting JCA Subsystem (JBoss IronJacamar 1.0.0.CR2)
> 08:38:38,700 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-12) Bound data source [java:jboss/datasources/ExampleDS]
> 08:38:38,920 INFO [org.jboss.as.deployment] (MSC service thread 1-10) Started FileSystemDeploymentService for directory /Users/jimtyrrell 1/Servers/jboss-7.0.0.CR1/standalone/deployments
> 08:38:39,130 INFO [org.jboss.as.controller] (Controller Boot Thread) Service status report
> Services which failed to start:
> service jboss.remoting.server.management.9999: org.jboss.msc.service.StartException in service jboss.remoting.server.management.9999: java.net.BindException: Address already in use
> service jboss.serverManagement.controller.management.http: org.jboss.msc.service.StartException in service jboss.serverManagement.controller.management.http: Failed to start serverManagement socket
> service jboss.mbean.connector: org.jboss.msc.service.StartException in service jboss.mbean.connector: java.rmi.server.ExportException: Port already in use: 1090; nested exception is:
> java.net.BindException: Address already in use
> 08:38:39,134 ERROR [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.0.CR1 "White Rabbit" started (with errors) in 1668ms - Started 87 of 146 services (4 services failed or missing dependencies, 55 services are passive or on-demand)
> ^C08:39:03,929 INFO [org.jboss.as.logging] Restored bootstrap log handlers
> 08:39:03,933 INFO [com.arjuna.ats.jbossatx] ARJUNA32018: Destroying TransactionManagerService
> 08:39:03,933 INFO [com.arjuna.ats.jbossatx] ARJUNA32014: Stopping transaction recovery manager
> 08:39:03,934 INFO [org.jboss.as] JBoss AS 7.0.0.CR1 "White Rabbit" stopped in 4ms
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1644) PersistenceResourceXmlDescription marshals attributes in the reverse order they are added
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1644?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1644:
-------------------------------------
Affects Version/s: 2.1.0.Final
2.0.0.Final
> PersistenceResourceXmlDescription marshals attributes in the reverse order they are added
> -----------------------------------------------------------------------------------------
>
> Key: WFCORE-1644
> URL: https://issues.jboss.org/browse/WFCORE-1644
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.Final, 2.1.0.Final, 2.2.0.CR5, 3.0.0.Alpha3
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.2.0.CR6, 3.0.0.Alpha4
>
>
> This in marshalAttributes results in iterating over a reversed list:
> {code}
> //we sort attributes to make sure that attributes that marshall to elements are last
> for (AttributeDefinition ad : attributes.stream().sorted((o1, o2) -> o1.getParser().isParseAsElement() ? 1 : -1).collect(Collectors.toList())) {
> {code}
> The sorter returning -1 for all non-element attributes has that effect.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1644) PersistenceResourceXmlDescription marshals attributes in the reverse order they are added
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1644:
----------------------------------------
Summary: PersistenceResourceXmlDescription marshals attributes in the reverse order they are added
Key: WFCORE-1644
URL: https://issues.jboss.org/browse/WFCORE-1644
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 3.0.0.Alpha3, 2.2.0.CR5
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 2.2.0.CR6, 3.0.0.Alpha4
This in marshalAttributes results in iterating over a reversed list:
{code}
//we sort attributes to make sure that attributes that marshall to elements are last
for (AttributeDefinition ad : attributes.stream().sorted((o1, o2) -> o1.getParser().isParseAsElement() ? 1 : -1).collect(Collectors.toList())) {
{code}
The sorter returning -1 for all non-element attributes has that effect.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1644) PersistenceResourceXmlDescription marshals attributes in the reverse order they are added
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1644?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1644:
-------------------------------------
Description:
This in marshalAttributes results in iterating over a reversed list:
{code}
//we sort attributes to make sure that attributes that marshall to elements are last
for (AttributeDefinition ad : attributes.stream().sorted((o1, o2) -> o1.getParser().isParseAsElement() ? 1 : -1).collect(Collectors.toList())) {
{code}
The sorter returning -1 for all non-element attributes has that effect.
was:
This in marshalAttributes results in iterating over a reversed list:
{code}
//we sort attributes to make sure that attributes that marshall to elements are last
for (AttributeDefinition ad : attributes.stream().sorted((o1, o2) -> o1.getParser().isParseAsElement() ? 1 : -1).collect(Collectors.toList())) {
{code}
The sorter returning -1 for all non-element attributes has that effect.
> PersistenceResourceXmlDescription marshals attributes in the reverse order they are added
> -----------------------------------------------------------------------------------------
>
> Key: WFCORE-1644
> URL: https://issues.jboss.org/browse/WFCORE-1644
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.2.0.CR5, 3.0.0.Alpha3
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.2.0.CR6, 3.0.0.Alpha4
>
>
> This in marshalAttributes results in iterating over a reversed list:
> {code}
> //we sort attributes to make sure that attributes that marshall to elements are last
> for (AttributeDefinition ad : attributes.stream().sorted((o1, o2) -> o1.getParser().isParseAsElement() ? 1 : -1).collect(Collectors.toList())) {
> {code}
> The sorter returning -1 for all non-element attributes has that effect.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (ELY-586) Evidence check to TokenSecurityRealm
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/ELY-586?page=com.atlassian.jira.plugin.sy... ]
Pedro Igor updated ELY-586:
---------------------------
Description: We must check the presence of an evidence prior to obtaining it from the {{IdentityLocator}}. Failing to do so, an exception is during authorization. (was: We must check the presence of an evidence prior to obtaining it from the {{IdentityLocator}}.)
> Evidence check to TokenSecurityRealm
> ------------------------------------
>
> Key: ELY-586
> URL: https://issues.jboss.org/browse/ELY-586
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Realms
> Affects Versions: 1.0.2.Final
> Reporter: Pedro Igor
> Assignee: Pedro Igor
>
> We must check the presence of an evidence prior to obtaining it from the {{IdentityLocator}}. Failing to do so, an exception is during authorization.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (ELY-586) Evidence check to TokenSecurityRealm
by Pedro Igor (JIRA)
Pedro Igor created ELY-586:
------------------------------
Summary: Evidence check to TokenSecurityRealm
Key: ELY-586
URL: https://issues.jboss.org/browse/ELY-586
Project: WildFly Elytron
Issue Type: Enhancement
Components: Realms
Affects Versions: 1.0.2.Final
Reporter: Pedro Igor
Assignee: Pedro Igor
We must check the presence of an evidence prior to obtaining it from the {{IdentityLocator}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (ELY-585) Allow null authenticationID during authorization
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/ELY-585?page=com.atlassian.jira.plugin.sy... ]
Pedro Igor updated ELY-585:
---------------------------
Description: We must be able to support a null authenticationID when using an {{AuthorizeCallback}}. In this case, if an authenticated principal was previously established as a result of a successful authentication or evidence verification, we just use it to perform authorization. (was: We must be support a null authenticationID when using an {{AuthorizeCallback}}. In this case, if an authenticated principal was previously established as a result of a successful authentication or evidence verification, we just use it to perform authorization. )
> Allow null authenticationID during authorization
> ------------------------------------------------
>
> Key: ELY-585
> URL: https://issues.jboss.org/browse/ELY-585
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Callbacks
> Affects Versions: 1.0.2.Final
> Reporter: Pedro Igor
> Assignee: Pedro Igor
>
> We must be able to support a null authenticationID when using an {{AuthorizeCallback}}. In this case, if an authenticated principal was previously established as a result of a successful authentication or evidence verification, we just use it to perform authorization.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months