September 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2285) ObjectMessage: handle objects with incorrect size

by Bela Ban (JIRA)

Bela Ban created JGRP-2285: ------------------------------ Summary: ObjectMessage: handle objects with incorrect size Key: JGRP-2285 URL: https://issues.jboss.org/browse/JGRP-2285 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 5.0 An ObjectMessage accepts objects of type SizeStreamable. When such an object has an incorrect serializableSize() method, the following can happen: * Say the serialized size is 1000, but serializedSize() returns 1200 * When the ObjectMessage is serialized, a length of 1200 is written, but then only 1000 bytes are serialized onto the output stream * On the receiving side, length=1200 is read and a byte array of 1200 is created * DataInput.readFully() reads 1000 bytes, but then reaches the eof of the stream, trying to read an additional 200 bytes * An exception is thrown and the reading of the message fails If we caught the exception, things would work, however this would mask other errors in the object serialization/deserialization code. If the serilization code was able to mark the position of the output stream, then we could write the *actual number of bytes written* (especially if it differs from serializedSize()); however, DataOutput doesn't give us this option! Investigate whether simply catching (and ignoring) the EOFException would work. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10985) UnsupportedOperationException thrown during start if CredentialReference is used in messaging-activemq subsystem

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFLY-10985?page=com.atlassian.jira.plugin... ] ehsavoie Hugonnet reassigned WFLY-10985: ---------------------------------------- Assignee: ehsavoie Hugonnet (was: Bartosz Baranowski) > UnsupportedOperationException thrown during start if CredentialReference is used in messaging-activemq subsystem > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-10985 > URL: https://issues.jboss.org/browse/WFLY-10985 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 14.0.0.Final > Reporter: Miroslav Novak > Assignee: ehsavoie Hugonnet > Priority: Critical > Attachments: bridge-cs001.jceks, standalone-full-ha.xml > > > If messaging subsystem is referencing elytron's credential store like in: > {code} > <bridge name="myBridge" queue-name="jms.queue.InQueue" forwarding-address="jms.queue.OutQueue" ha="true" reconnect-attempts="-1" use-duplicate-detection="true" user="johnOut" static-connectors="bridge-connector"> > <credential-reference store="bridge-cs001" alias="john_out_alias_wrong"/> > </bridge> > {code} > then during start server throws exception: > {code} > 12:49:04,367 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 66) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "messaging-activemq"), > ("server" => "default") > ]): java.lang.UnsupportedOperationException > at org.jboss.msc.service.ServiceBuilderImpl.addDependency(ServiceBuilderImpl.java:409) > at org.jboss.msc.service.DelegatingServiceBuilder.addDependency(DelegatingServiceBuilder.java:147) > at org.jboss.as.controller.security.CredentialReference.getCredentialSourceSupplier(CredentialReference.java:323) > at org.wildfly.extension.messaging.activemq.ServerAdd.addBridgeCredentialStoreReference(ServerAdd.java:732) > at org.wildfly.extension.messaging.activemq.ServerAdd.access$200(ServerAdd.java:175) > at org.wildfly.extension.messaging.activemq.ServerAdd$2.execute(ServerAdd.java:439) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467) > at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:384) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {code} > Attaching standalone-full-ha.xml with which is possible to reproduce the issue. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2924) Factor out Unit behavior to allow pluggable backends

by Edoardo Vacchi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2924?page=com.atlassian.jira.plugi... ] Edoardo Vacchi updated DROOLS-2924: ----------------------------------- Sprint: 2018 Week 33-35 (was: 2018 Week 33-35, 2018 Week 36-38) > Factor out Unit behavior to allow pluggable backends > ---------------------------------------------------- > > Key: DROOLS-2924 > URL: https://issues.jboss.org/browse/DROOLS-2924 > Project: Drools > Issue Type: Task > Reporter: Edoardo Vacchi > Assignee: Edoardo Vacchi > Labels: Stunner > > e.g.: > - rule units (Drools) > - process units (jBPM) > etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10796) Warning about JSF version 'NONE' is shown in logs

by Jan Kašík (JIRA)

[ https://issues.jboss.org/browse/WFLY-10796?page=com.atlassian.jira.plugin... ] Jan Kašík updated WFLY-10796: ----------------------------- Attachment: (was: consoleText.zip) > Warning about JSF version 'NONE' is shown in logs > -------------------------------------------------- > > Key: WFLY-10796 > URL: https://issues.jboss.org/browse/WFLY-10796 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 14.0.0.Beta2 > Reporter: Jan Kašík > Assignee: Farah Juma > > Following warning is shown in log upon server start: > {code} > 2018-08-02 16:13:28,487 WARN [org.jboss.as.jsf] (MSC service thread 1-3) WFLYJSF0005: Unknown JSF version 'NONE'. Default version 'main' will be used instead. > {code} > Seems like, that 'NONE' constant from WildFly code is somehow used instead of default 'main' value. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10796) Warning about JSF version 'NONE' is shown in logs

by Jan Kašík (JIRA)

[ https://issues.jboss.org/browse/WFLY-10796?page=com.atlassian.jira.plugin... ] Jan Kašík updated WFLY-10796: ----------------------------- Attachment: consoleText.zip > Warning about JSF version 'NONE' is shown in logs > -------------------------------------------------- > > Key: WFLY-10796 > URL: https://issues.jboss.org/browse/WFLY-10796 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 14.0.0.Beta2 > Reporter: Jan Kašík > Assignee: Farah Juma > Attachments: consoleText.zip > > > Following warning is shown in log upon server start: > {code} > 2018-08-02 16:13:28,487 WARN [org.jboss.as.jsf] (MSC service thread 1-3) WFLYJSF0005: Unknown JSF version 'NONE'. Default version 'main' will be used instead. > {code} > Seems like, that 'NONE' constant from WildFly code is somehow used instead of default 'main' value. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10997) [GSS](7.2.z) WildFlyInitialContextFactory EJB proxy security behavior inconsistent with different context lookups

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-10997?page=com.atlassian.jira.plugin... ] Lin Gao moved JBEAP-15395 to WFLY-10997: ---------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-10997 (was: JBEAP-15395) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: EJB (was: EJB) Affects Version/s: (was: 7.1.4.GA) Fix Version/s: (was: 7.2.1.GA) > [GSS](7.2.z) WildFlyInitialContextFactory EJB proxy security behavior inconsistent with different context lookups > ----------------------------------------------------------------------------------------------------------------- > > Key: WFLY-10997 > URL: https://issues.jboss.org/browse/WFLY-10997 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Lin Gao > Assignee: Lin Gao > Labels: downstream_dependency > Original Estimate: 3 days > Remaining Estimate: 3 days > > WildFlyInitialContextFactory EJB proxy security behavior inconsistent with different context lookups > Using WildFlyInitialContextFactory and calling a remote EJB server. > Observations: > 1) If the ejb lookup is "reproducer/TestSLSB!test.Test" (basically like a RemoteNaming lookup), the ejb is invoked successfully, but the caller is seen as anonymous instead of the ejbuser which is specified in the Context properties. > Using the ejb-client type lookup: ejb:/reproducer/TestSLSB!test.Test , then it shows up as ejbuser as expected > 2) if a client creates 2 InitialContexts and uses the lookup reproducer/TestSLSB!test.Test" on ctx1 , then uses the lookup "ejb:/reproducer/TestSLSB!test.Test " on ctx2 in that order, then they both show anonymous (as if it uses only the context that was created first). > If you switch the order, and use ejb:/reproducer/TestSLSB!test.Test first, then they both show ejbuser -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10997) [GSS](7.2.z) WildFlyInitialContextFactory EJB proxy security behavior inconsistent with different context lookups

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-10997?page=com.atlassian.jira.plugin... ] Lin Gao updated WFLY-10997: --------------------------- Labels: downstream_dependency (was: ) > [GSS](7.2.z) WildFlyInitialContextFactory EJB proxy security behavior inconsistent with different context lookups > ----------------------------------------------------------------------------------------------------------------- > > Key: WFLY-10997 > URL: https://issues.jboss.org/browse/WFLY-10997 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Lin Gao > Assignee: Lin Gao > Labels: downstream_dependency > Original Estimate: 3 days > Remaining Estimate: 3 days > > WildFlyInitialContextFactory EJB proxy security behavior inconsistent with different context lookups > Using WildFlyInitialContextFactory and calling a remote EJB server. > Observations: > 1) If the ejb lookup is "reproducer/TestSLSB!test.Test" (basically like a RemoteNaming lookup), the ejb is invoked successfully, but the caller is seen as anonymous instead of the ejbuser which is specified in the Context properties. > Using the ejb-client type lookup: ejb:/reproducer/TestSLSB!test.Test , then it shows up as ejbuser as expected > 2) if a client creates 2 InitialContexts and uses the lookup reproducer/TestSLSB!test.Test" on ctx1 , then uses the lookup "ejb:/reproducer/TestSLSB!test.Test " on ctx2 in that order, then they both show anonymous (as if it uses only the context that was created first). > If you switch the order, and use ejb:/reproducer/TestSLSB!test.Test first, then they both show ejbuser -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10985) UnsupportedOperationException thrown during start if CredentialReference is used in messaging-activemq subsystem

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-10985?page=com.atlassian.jira.plugin... ] Bartosz Baranowski reassigned WFLY-10985: ----------------------------------------- Assignee: Bartosz Baranowski (was: Jeff Mesnil) > UnsupportedOperationException thrown during start if CredentialReference is used in messaging-activemq subsystem > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-10985 > URL: https://issues.jboss.org/browse/WFLY-10985 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 14.0.0.Final > Reporter: Miroslav Novak > Assignee: Bartosz Baranowski > Priority: Critical > Attachments: bridge-cs001.jceks, standalone-full-ha.xml > > > If messaging subsystem is referencing elytron's credential store like in: > {code} > <bridge name="myBridge" queue-name="jms.queue.InQueue" forwarding-address="jms.queue.OutQueue" ha="true" reconnect-attempts="-1" use-duplicate-detection="true" user="johnOut" static-connectors="bridge-connector"> > <credential-reference store="bridge-cs001" alias="john_out_alias_wrong"/> > </bridge> > {code} > then during start server throws exception: > {code} > 12:49:04,367 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 66) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "messaging-activemq"), > ("server" => "default") > ]): java.lang.UnsupportedOperationException > at org.jboss.msc.service.ServiceBuilderImpl.addDependency(ServiceBuilderImpl.java:409) > at org.jboss.msc.service.DelegatingServiceBuilder.addDependency(DelegatingServiceBuilder.java:147) > at org.jboss.as.controller.security.CredentialReference.getCredentialSourceSupplier(CredentialReference.java:323) > at org.wildfly.extension.messaging.activemq.ServerAdd.addBridgeCredentialStoreReference(ServerAdd.java:732) > at org.wildfly.extension.messaging.activemq.ServerAdd.access$200(ServerAdd.java:175) > at org.wildfly.extension.messaging.activemq.ServerAdd$2.execute(ServerAdd.java:439) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467) > at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:384) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {code} > Attaching standalone-full-ha.xml with which is possible to reproduce the issue. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AG-93) Prevents calls to setAutoCommit that don't change the auto-commit state

by Luis Barreiro (JIRA)

[ https://issues.jboss.org/browse/AG-93?page=com.atlassian.jira.plugin.syst... ] Luis Barreiro resolved AG-93. ----------------------------- Resolution: Done > Prevents calls to setAutoCommit that don't change the auto-commit state > ------------------------------------------------------------------------ > > Key: AG-93 > URL: https://issues.jboss.org/browse/AG-93 > Project: Agroal > Issue Type: Bug > Components: pool > Affects Versions: 1.1 > Reporter: Luis Barreiro > Assignee: Luis Barreiro > Fix For: 1.2 > > > Calls to setAutoCommit always set it as a dirty attribute, even if they don't effectively change auto-commit state. This will cause another call to setAutoCommit when returning the connection to the pool. > Some drivers don't do well with calls to setAutoCommit when in transaction. This change will prevent those calls (as long as it's set to false in the configuration). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AG-93) Prevents calls to setAutoCommit that don't change the auto-commit state

by Luis Barreiro (JIRA)

Luis Barreiro created AG-93: ------------------------------- Summary: Prevents calls to setAutoCommit that don't change the auto-commit state Key: AG-93 URL: https://issues.jboss.org/browse/AG-93 Project: Agroal Issue Type: Bug Components: pool Affects Versions: 1.1 Reporter: Luis Barreiro Assignee: Luis Barreiro Fix For: 1.2 Calls to setAutoCommit always set it as a dirty attribute, even if they don't effectively change auto-commit state. This will cause another call to setAutoCommit when returning the connection to the pool. Some drivers don't do well with calls to setAutoCommit when in transaction. This change will prevent those calls (as long as it's set to false in the configuration). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2018