March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1459) Question mark (?) triggers invalid name error in execution and validation

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1459?page=com.atlassian.jira.plugi... ] Edson Tirelli commented on DROOLS-1459: --------------------------------------- You are correct, I missed that `?` can be used as a starting character for variable names. > Question mark (?) triggers invalid name error in execution and validation > ------------------------------------------------------------------------- > > Key: DROOLS-1459 > URL: https://issues.jboss.org/browse/DROOLS-1459 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Mélanie Gauthier > Assignee: Edson Tirelli > > But it is a valid character in name, it is added by rule 30 of FEEL grammar. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6607) Broadcast/Discovery group is possible to create with just a name

by Claudio Miranda (JIRA)

[ https://issues.jboss.org/browse/WFLY-6607?page=com.atlassian.jira.plugin.... ] Claudio Miranda commented on WFLY-6607: --------------------------------------- As the PR is merged, I think this issue may be resolved as done. > Broadcast/Discovery group is possible to create with just a name > ---------------------------------------------------------------- > > Key: WFLY-6607 > URL: https://issues.jboss.org/browse/WFLY-6607 > Project: WildFly > Issue Type: Bug > Components: JMS, Web Console > Affects Versions: 10.0.0.Final > Reporter: Chen Maoqian > Assignee: Chen Maoqian > > When defining new broadcast-group in Configuration: Subsystems Subsystem: Messaging - ActiveMQ Messaging Provider: default > user must define name, at least one connector and then either socket-binding or jgroups-channel-name (not both of them, just one) > At this moment it's possible to create broadcast group with just a name which is wrong. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1459) Question mark (?) triggers invalid name error in execution and validation

by Mélanie Gauthier (JIRA)

Mélanie Gauthier created DROOLS-1459: ---------------------------------------- Summary: Question mark (?) triggers invalid name error in execution and validation Key: DROOLS-1459 URL: https://issues.jboss.org/browse/DROOLS-1459 Project: Drools Issue Type: Bug Components: dmn engine Reporter: Mélanie Gauthier Assignee: Edson Tirelli But it is a valid character in name, it is added by rule 30 of FEEL grammar. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-957) Coverity static analysis: DefaultSingleSignOn.getIdentity() not synchronized

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ELY-957?page=com.atlassian.jira.plugin.sy... ] Paul Ferraro commented on ELY-957: ---------------------------------- [~mchoma] The purpose of moving the synchronized modifier to an internal synchronized block is not meant to change the behavior - just the signature of the public methods. I'm not sure what you mean by "future implementations" being safe. The DefaultSingleSignOn and DefaultSingleSignOnEntry objects are an implementation detail of the DefaultSingleSignOnManager implementation. Any implementation of SingleSignOnManager is free to enforce whatever threading constraints it wants/needs. e.g. https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/... > Coverity static analysis: DefaultSingleSignOn.getIdentity() not synchronized > ---------------------------------------------------------------------------- > > Key: ELY-957 > URL: https://issues.jboss.org/browse/ELY-957 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Affects Versions: 1.1.0.Beta24 > Reporter: Martin Choma > Assignee: Paul Ferraro > Priority: Minor > > Coverity static-analysis scan found getter is not synchronized, while setter is. > {code} > public SecurityIdentity getIdentity() { > return this.entry.getCachedIdentity().getSecurityIdentity(); > } > {code} > Current implementation is correct because in DefaultSingleSignOnEntry (currently only avalaible implementation of SingleSignOnEntry) cachedIdentity is volatile. > However other implementations can be wrongly implemented. Once getIdentity() would be marked with synchronize modifier, such problem shouldn't occure. > https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=84908... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-983) WildFlySasl.MECHANISM_QUERY_ALL is taken into account in ExternalSasl*Factory.createSasl* methods

by Josef Cacek (JIRA)

Josef Cacek created ELY-983: ------------------------------- Summary: WildFlySasl.MECHANISM_QUERY_ALL is taken into account in ExternalSasl*Factory.createSasl* methods Key: ELY-983 URL: https://issues.jboss.org/browse/ELY-983 Project: WildFly Elytron Issue Type: Bug Reporter: Josef Cacek Assignee: Darran Lofthouse The description of {{MECHANISM_QUERY_ALL}} filtering property says: {quote} This flag is only effective on calls to SaslServerFactory.getMechanismNames(Map) or SaslClientFactory.getMechanismNames(Map) for Elytron-provided SASL factories. {quote} It's not true for EXTERNAL SASL mechanism factories, where it's taken into account also in {{createSaslServer/Client}} methods. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5319) fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-5319?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-5319: ------------------------------------ [https://mail.google.com/mail/u/0/#search/label%3Apullrequests+org.jboss.a...] shows that the failure in our CI testing was: {quote} org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest: java.lang.AssertionError: entity manager should not of been closed by the reaper thread at org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest(TxTimeoutTestCase.java:197) {quote} It is probably more important to test that the entity manager is not invoked by multiple threads, than whether the application thread attempts to end the transaction before the reaper thread or reaper thread before app thread. > fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure > --------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5319 > URL: https://issues.jboss.org/browse/WFLY-5319 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Attachments: server.zip > > > https://gist.github.com/scottmarlow/6409290362f35f2d1320 contains the error exception -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-982) Filtering properties for EXTERNAL SASL mechanism differs from Oracle implementaion

by Josef Cacek (JIRA)

Josef Cacek created ELY-982: ------------------------------- Summary: Filtering properties for EXTERNAL SASL mechanism differs from Oracle implementaion Key: ELY-982 URL: https://issues.jboss.org/browse/ELY-982 Project: WildFly Elytron Issue Type: Bug Reporter: Josef Cacek Assignee: Darran Lofthouse SASL mechanism filtering in Elytron {{ExternalSasl*}} factories differs from Oracle one. http://docs.oracle.com/javase/jndi/tutorial/ldap/security/sasl.html Oracle has EXTERNAL mechanism valid for policies: * javax.security.sasl.policy.noplaintext * javax.security.sasl.policy.noactive * javax.security.sasl.policy.nodictionary Elytron factories doesn't allow EXTERNAL mechanism for these filtering properties set to true. [~dlofthouse] If the changed filtering policy is intentional, please reject this issue. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5319) fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-5319?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-5319: ------------------------------------ Just challenging myself and my assertion in the negativeTxTimeoutVerifyReaperThreadCanceledTxTest method. Current code is: {code} /** * Repeat the same test as test_negativeTxTimeoutTest but also ensure that the reaper thread canceled the tx. * If this test fails, it could be that the tx reaper thread name changed or we are using a different tx manager. * * @throws Exception */ // @Ignore // WFLY-5319 is for fixing this test (see failure https://gist.github.com/scottmarlow/6409290362f35f2d1320) @Test @InSequence(3) public void test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest() throws Exception { TestEntityManager.clearState(); assertFalse("entity manager state is not reset", TestEntityManager.getClosedByReaperThread()); SFSB1 sfsb1 = lookup("ejbjar/SFSB1", SFSB1.class); try { sfsb1.createEmployeeWaitForTxTimeout(true, "Wily", "1 Appletree Lane", 10); } catch (Exception e) { // ignore the tx rolled back exception // } assertFalse("entity manager should not of been closed by the reaper thread", TestEntityManager.getClosedByReaperThread()); assertTrue("transaction was canceled by reaper thread", SFSB1.isAfterCompletionCalledByTMTimeoutThread()); } {code} We are failing the second assertion "assertTrue("transaction was canceled by reaper thread", SFSB1.isAfterCompletionCalledByTMTimeoutThread())". I am trying to get more information out of this test case by recording the thread name of which the afterCompletion was called from (should be the reaper thread or application thread. Once we have the thread name from the failing case, we can determine next steps to update the test. > fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure > --------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5319 > URL: https://issues.jboss.org/browse/WFLY-5319 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Attachments: server.zip > > > https://gist.github.com/scottmarlow/6409290362f35f2d1320 contains the error exception -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5319) fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-5319?page=com.atlassian.jira.plugin.... ] Scott Marlow edited comment on WFLY-5319 at 3/1/17 12:12 PM: ------------------------------------------------------------- Attached server.log which is from following steps: 1. Update testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/mockprovider/txtimeout/TxTimeoutTestCase.java, delete the @Ignore on the class: {quote} @Ignore // WFLY-5319 is for fixing this test {quote} 2. Change into folder testsuite/integration/basic 3. mvn clean install -Dtest=org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase I could pass this test locally on my T540 laptop but on test machine, I was able to see the failure: {quote} ------------------------------------------------------- T E S T S ------------------------------------------------------- Running org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase Tests run: 3, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 3.866 sec <<< FAILURE! - in org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest(org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase) Time elapsed: 1.409 sec <<< FAILURE! java.lang.AssertionError: transaction was canceled by reaper thread at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.assertTrue(Assert.java:41) at org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest(TxTimeoutTestCase.java:173) Results : Failed tests: TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest:173 transaction was canceled by reaper thread {quote} See attached server.log which is from this test run. I'm not sure if [WFLY-6212] is at the root of the problem or something else. was (Author: smarlow): Attached server.log which is from following steps: 1. Update testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/mockprovider/txtimeout/TxTimeoutTestCase.java, delete the @Ignore on the class: {quote} @Ignore // WFLY-5319 is for fixing this test {quote} 2. Change into folder testsuite/integration/basic 3. mvn clean install -Dtest=org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase I could pass this test locally on my T540 laptop but on test machine, I was able to see the failure: {quote} test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest(org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase) Time elapsed: 1.409 sec <<< FAILURE! java.lang.AssertionError: transaction was canceled by reaper thread at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.assertTrue(Assert.java:41) at org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest(TxTimeoutTestCase.java:173) {quote} See attached server.log which is from this test run. I'm not sure if [WFLY-6212] is at the root of the problem or something else. > fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure > --------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5319 > URL: https://issues.jboss.org/browse/WFLY-5319 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Attachments: server.zip > > > https://gist.github.com/scottmarlow/6409290362f35f2d1320 contains the error exception -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2161) UNICAST3: message delivery fails after disconnect-connect sequence

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2161?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2161: -------------------------------- git bisect shows the offending commit to be {{509cfe}}; this is where {{message_processing_policy}} in the transport was set to "max" (from "submit") as default. Changing this back to "max" fixes the issue. The problem is that {{MaxOneThreadPerSender}} creates message batches for each sender's address in its table and uses the batches to queue messages when a message for a given sender is already being processed. However, the dest and sender's address of those batches is not changed on a disconnect-connect sequence, which results in messages being sent to old UUIDs, which are discarded by the transport logic when comparing the destination address of a batch with the local address. A simple solution is to remove entries from that table on a disconnect and on a view change (remove entries for left members). > UNICAST3: message delivery fails after disconnect-connect sequence > ------------------------------------------------------------------ > > Key: JGRP-2161 > URL: https://issues.jboss.org/browse/JGRP-2161 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Critical > Fix For: 4.1, 4.0.1 > > > When disconnecting and reconnecting a channel, unicast messages are not delivered. {{ConnectTest.testDisconnectConnectndMessageSending()}} reproduces the issue. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 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 March 2017