[JBoss JIRA] (WFLY-3220) ARJUNA016009 ArrayIndexOutOfBoundsException during periodic recovery on EJBTransactionRecoveryService
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3220?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3220:
-----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1035216|https://bugzilla.redhat.com/show_bug.cgi?id=1035216] from VERIFIED to CLOSED
> ARJUNA016009 ArrayIndexOutOfBoundsException during periodic recovery on EJBTransactionRecoveryService
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-3220
> URL: https://issues.jboss.org/browse/WFLY-3220
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Masafumi Miura
> Assignee: Masafumi Miura
> Fix For: 8.1.0.CR1, 8.1.0.Final
>
> Attachments: WFLY-3220-byteman-script.btm
>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1035216 is also reproducible in wildfly.
> {code}
> WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.ArrayIndexOutOfBoundsException: 0
> at org.jboss.as.ejb3.remote.EJBTransactionRecoveryService.getXAResources(EJBTransactionRecoveryService.java:114)
> at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) [narayana-jts-integration-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:516) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:182) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:743) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> {code}
> I think the line 111 "new XAResource\[receiverContexts.size()\]" should be placed inside synchronized block.
> {code:java|title=ejb3/src/main/java/org/jboss/as/ejb3/remote/EJBTransactionRecoveryService.java}
> 109 @Override
> 110 public XAResource[] getXAResources() {
> 111 final XAResource[] xaResources = new XAResource[receiverContexts.size()];
> 112 synchronized (receiverContexts) {
> 113 for (int i = 0; i < receiverContexts.size(); i++) {
> 114 xaResources[i] = EJBClientManagedTransactionContext.getEJBXAResourceForRecovery(receiverContexts.get(i), arjunaTxCoreEnvironmentBean.getValue().getNodeIdentifier());
> 115 }
> 116 }
> 117 return xaResources;
> 118 }
> ...
> 124 @Override
> 125 public void receiverRegistered(final EJBReceiverContext receiverContext) {
> 126 this.receiverContexts.add(receiverContext);
> 127 }
> {code}
> I think this "java.lang.ArrayIndexOutOfBoundsException: 0" will happen in the following scenario:
> # receiverContexts.size() = 0 at the line 111
> xaResources is created with new XAResource\[0\]
> # receiverRegistered method is called from other thread between the line 111 and 112
> Now receiverContexts.size() = 1
> # As receiverContexts.size() = 1, for-loop is executed
> Then "xaResources\[0\] = ..." will get ArrayIndexOutOfBoundsException at the line 114 because xaResources is empty array.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years
[JBoss JIRA] (WFLY-3375) The HornetQ address settings are not properly inherited
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3375?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3375:
-----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1099404|https://bugzilla.redhat.com/show_bug.cgi?id=1099404] from VERIFIED to CLOSED
> The HornetQ address settings are not properly inherited
> --------------------------------------------------------
>
> Key: WFLY-3375
> URL: https://issues.jboss.org/browse/WFLY-3375
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JMS
> Affects Versions: 8.0.0.Final
> Environment: JBoss EAP 6.2.2
> Reporter: Tom Ross
> Assignee: Jeff Mesnil
> Fix For: 9.0.0.Alpha1
>
>
> When using multiple address settings in HornetQ configuration the address setting should be inherited from more generic setting by more specific setting. If two address setting are used like
> {code:xml}
> <address-settings>
> <address-setting match="#">
> <dead-letter-address>jms.queue.DLQ</dead-letter-address>
> <expiry-address>jms.queue.ExpiryQueue</expiry-address>
> <redelivery-delay>0</redelivery-delay>
> <max-delivery-attempts>5</max-delivery-attempts>
> <max-size-bytes>10485760</max-size-bytes>
> <page-size-bytes>2097152</page-size-bytes>
> <address-full-policy>PAGE</address-full-policy>
> <message-counter-history-day-limit>10</message-counter-history-day-limit>
> </address-setting>
> <address-setting match="jms.queue.testQueue">
> <dead-letter-address>jms.queue.DLQ</dead-letter-address>
> <expiry-address>jms.queue.ExpiryQueue</expiry-address>
> <redelivery-delay>0</redelivery-delay>
> <max-size-bytes>10485760</max-size-bytes>
> <page-size-bytes>2097152</page-size-bytes>
> <address-full-policy>PAGE</address-full-policy>
> <message-counter-history-day-limit>10</message-counter-history-day-limit>
> </address-setting>
> </address-settings>
> {code}
> It is expected that the setting for {{jms.queue.testQueue}} would inherit {{max-delivery-attempts}} from default address setting {{"#"}} but it does not. Instead if uses the default value for {{max-delivery-attempts}} which is *9*.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years
[JBoss JIRA] (WFLY-939) Class-Path manifest entries for WARs-in-EAR not handled properly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-939?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-939:
----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 955818|https://bugzilla.redhat.com/show_bug.cgi?id=955818] from VERIFIED to CLOSED
> Class-Path manifest entries for WARs-in-EAR not handled properly
> ----------------------------------------------------------------
>
> Key: WFLY-939
> URL: https://issues.jboss.org/browse/WFLY-939
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: James Livingston
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha1
>
>
> ManifestClassPathProcessor handles the processing of Class-Path entries in deployments. The handling of those entries in sub-deployments is broken.
> https://github.com/doctau/examples/tree/master/war-manifest-classpath builds an EAR containing a utility JAR and two WARs, where both WARs refer to the jar via Class-Path manifest headers. The jar is not in the EAR's library directory nor in application.xml
> The resulting module setup will result in the jar being added to the first WAR's module, and the remaining WAR(s) depending on a separate "jar classloader". All WARs should depend on the single shared jar classloader.
> When ManifestClassPathProcessor.handlingExistingClassPathEntry() runs for the first war, it will call createAdditionalModule(), which calls createResourceRoot(). The "deploymentUnit.addToAttachmentList(Attachments.RESOURCE_ROOTS, resourceRoot)" adds it to the resource roots for that WAR.
> When handlingExistingClassPathEntry() runs for the second (and subsequent) WAR, it will already be in the additionalModules list, so "target.addToAttachmentList(Attachments.CLASS_PATH_ENTRIES, moduleSpecification.getModuleIdentifier())" gets run.
> I believe the step of adding it to the CLASS_PATH_ENTRIES attachment needs to happen on the first WAR (so it is added as a module dependency), and it should not be added to the DU RESOURCE_ROOTS so it is not in the WAR's own classloader.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years
[JBoss JIRA] (WFLY-822) MBean created via EAR/META-INF/jboss-service.xml from class defined in JBoss module gets wrong TCCL
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-822?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-822:
----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1054972|https://bugzilla.redhat.com/show_bug.cgi?id=1054972] from VERIFIED to CLOSED
> MBean created via EAR/META-INF/jboss-service.xml from class defined in JBoss module gets wrong TCCL
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-822
> URL: https://issues.jboss.org/browse/WFLY-822
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Class Loading, Server
> Environment: Java 6u31
> Reporter: Zachary Bedell
> Assignee: jaikiran pai
> Labels: classloader, mbean, modules
> Fix For: 8.0.0.Alpha3
>
> Attachments: SarTcclTst.tbz
>
>
> When an MBean is loaded from jboss-service.xml within an EAR, the TCCL should point to the EAR deployment so that config files and other resources can be classloaded from the EAR. Under JBoss 7.1.1.Final, the TCCL in a module loaded MBean's start() method is the module's ClassLoader. No reference to the EAR deployment's classloader is available, thus EAR resources are not available within the MBean.
> It appears that org.jboss.as.service.AbstractService::invokeLifecycleMethod() incorrectly sets the TCCL to the module's defining classloader rather than the EAR's:
> {{{
> protected void invokeLifecycleMethod(final Method method) throws InvocationTargetException, IllegalAccessException {
> if (method != null) {
> final ClassLoader old = SecurityActions.setThreadContextClassLoader(mBeanInstance.getClass().getClassLoader());
> try {
> method.invoke(mBeanInstance);
> } finally {
> SecurityActions.resetThreadContextClassLoader(old);
> }
> }
> }
> }}}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years
[JBoss JIRA] (WFLY-3131) isSensitiveValue of class SensitiveVaultExpressionConstraint uses incorrect index in java.lang.String.substring method
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3131?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3131:
-----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1077838|https://bugzilla.redhat.com/show_bug.cgi?id=1077838] from VERIFIED to CLOSED
> isSensitiveValue of class SensitiveVaultExpressionConstraint uses incorrect index in java.lang.String.substring method
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3131
> URL: https://issues.jboss.org/browse/WFLY-3131
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Environment: All
> Reporter: Jay Kumar SenSharma
> Assignee: Jay Kumar SenSharma
> Fix For: 8.1.0.CR1, 8.1.0.Final
>
>
> The isSensitiveValue(ModelNode value) method of class "org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint" seems to be using the incorrect index in java.lang.String.substring method. Which is causing the following exceptions in the logs while executing the following kind of CLI command:
> {code}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=formatter, value="%d{HH:mm:ss,SSS} %-5p [%c] (${jboss.node.name} %t) %s%E%n")
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014749: Operation handler failed: String index out of range: -15",
> "rolled-back" => true
> }
> {code}
> The Exception can be seen as following in the WildFly Logs:
> {code}
> 21:58:04,821 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 25) JBAS014612: Operation ("write-attribute") failed - address: ([
> ("subsystem" => "logging"),
> ("periodic-rotating-file-handler" => "FILE")
> ]): java.lang.StringIndexOutOfBoundsException: String index out of range: -15
> at java.lang.String.substring(String.java:1911) [rt.jar:1.7.0_51]
> at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.isSensitiveValue(SensitiveVaultExpressionConstraint.java:128) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.isSensitiveAction(SensitiveVaultExpressionConstraint.java:89) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.getRequiredConstraint(SensitiveVaultExpressionConstraint.java:81) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getRequiredPermissions(DefaultPermissionFactory.java:201) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1153) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1055) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1015) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.getResourceRegistration(OperationContextImpl.java:265) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:72) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:174) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:105) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:125) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:121) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_51]
> at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_51]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:121) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years
[JBoss JIRA] (WFLY-1188) allow custom-formatter configuration
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1188?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1188:
-----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 994661|https://bugzilla.redhat.com/show_bug.cgi?id=994661] from VERIFIED to CLOSED
> allow custom-formatter configuration
> ------------------------------------
>
> Key: WFLY-1188
> URL: https://issues.jboss.org/browse/WFLY-1188
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Logging
> Reporter: Aleksandar Kostadinov
> Assignee: James Perkins
> Labels: as7, formatting, logging
> Fix For: 8.0.0.CR1
>
>
> Currently only *org.jboss.logmanager.formatters.PatternFormatter* is supported in JBoss AS7 configuration. It would be very useful to allow specifying a custom-formatter (e.g *java.util.logging.XMLFormatter*).
> At the moment one can specify another formatter in logging.properties but once the logging subsystem is initialized, the settings in logging.properties get overridden.
> A workaround would be to disable logging subsystem but that has drawbacks.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years