November 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1983) CLI type decision INT/STRING LONG/STRING

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1983?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-1983: ---------------------------------------------- I have looked at the server side handling of arguments for the read-resource (ReadResourceHandler). The faulty operation is: :read-resource(recursive-depth=999999999999). The cli converts the out of range depth to STRING and send the request. The server handler validates each parameter and checks for the value type. The only valid type for recursive-depth is INT. So the operation fails with "WFLYCTL0097: Wrong type for 'recursive-depth'. Expected [INT] but was STRING". Same occurs for list-add.index. > CLI type decision INT/STRING LONG/STRING > ---------------------------------------- > > Key: WFCORE-1983 > URL: https://issues.jboss.org/browse/WFCORE-1983 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > It happens that the CLI does a custom parsing of the value in case ModelNode.fromString fails (whatever the exception). > The issue is that the custom parsing doesn't follow the ModelNode parsing syntax and parse everything as String. So the resulting ModelNode that is serialised and sent to the server has been transformed. > I am surprised that we don't have more of such failures. For example, when numbers are located inside custom complex structure such as: {mynumber=9999} that will be sent as an OBJECT containing a STRING although the valid DMR syntax {"my number"=>999} would be sent as an OBJECT containing an INT. > Some server side subsystems are smart enough to call into asXXX methods and not check the type? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7614) Ldap security realm does not close DirContext properly

by Martin Choma (JIRA)

Martin Choma created WFLY-7614: ---------------------------------- Summary: Ldap security realm does not close DirContext properly Key: WFLY-7614 URL: https://issues.jboss.org/browse/WFLY-7614 Project: WildFly Issue Type: Bug Components: Security Affects Versions: 11.0.0.Alpha1 Reporter: Martin Choma There are methods in Elytron {{LdapSecurityRealm}} class which create/get DirContext, but does not close him in finally block. In some circumstances could cause context resource leak. * LdapSecurityRealm ** getEvidenceVerifySupport ** getCredentialAcquireSupport ** getCredential ** setCredentials * LdapRealmIdentity ** setCredentials In same class there are examples of properly closed contexts: * LdapRealmIdentity ** getCredential ** getEvidenceVerifySupport ** verifyEvidence ** getIdentity ** create ** setAttributes -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7613) Ldap security realm does not close DirContext properly

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7613?page=com.atlassian.jira.plugin.... ] Martin Choma moved JBEAP-7344 to WFLY-7613: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7613 (was: JBEAP-7344) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Target Release: (was: 7.1.0.GA) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.DR8) > Ldap security realm does not close DirContext properly > ------------------------------------------------------ > > Key: WFLY-7613 > URL: https://issues.jboss.org/browse/WFLY-7613 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > > There are methods in Elytron {{LdapSecurityRealm}} class which create/get DirContext, but does not close him in finally block. > In some circumstances could cause context resource leak. > * LdapSecurityRealm > ** getEvidenceVerifySupport > ** getCredentialAcquireSupport > ** getCredential > ** setCredentials > * LdapRealmIdentity > ** setCredentials > In same class there are examples of properly closed contexts: > * LdapRealmIdentity > ** getCredential > ** getEvidenceVerifySupport > ** verifyEvidence > ** getIdentity > ** create > ** setAttributes -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2131) UNICAST3 drops all messages until it receives the first one

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2131?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2131: -------------------------------- Scenario: a rogue member can fake a keyserver and thus send a {{JOIN_RSP}} or {{INSTALL_MERGE_VIEW}} which tricks the joiner (or merger) into thinking the rogue member is the keyserver. This is prevented by {{AUTH}} (that's why {{ASYM_ENCRYPT}} won't start if {{AUTH}} isn't present): it checks these messages and rejects them if authentication fails. The unit tests that test this are in {{ASYM_ENCRYPT_Test}}: {{nonMemberInjectingJoinResponse()}} and {{mergeViewInjectionByNonMember()}}. > UNICAST3 drops all messages until it receives the first one > ----------------------------------------------------------- > > Key: JGRP-2131 > URL: https://issues.jboss.org/browse/JGRP-2131 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.10 > Reporter: Dennis Reed > Assignee: Bela Ban > Fix For: 3.6.12, 4.0 > > > UNICAST3.getReceiverEntry returns null if it hasn't seen the first message yet. > This causes UNICAST3.handleDataReceived to drop the message. > When you add *ENCRYPT, this causes a major deadlock. *ENCRYPT will queue most messages until it gets the encryption key, which can often include the first message (so UNICAST3 won't see it yet). Then when an important message such as JOIN_RSP comes through, UNICAST3 drops it. Since UNICAST3 never lets any messages through in this case, the encryption key will never get set so that *ENCRYPT can pass the first message up and free the deadlock. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1983) CLI type decision INT/STRING LONG/STRING

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1983?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-1983: ---------------------------------------------- Another invalid conversion done by the custom parser. > CLI type decision INT/STRING LONG/STRING > ---------------------------------------- > > Key: WFCORE-1983 > URL: https://issues.jboss.org/browse/WFCORE-1983 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > It happens that the CLI does a custom parsing of the value in case ModelNode.fromString fails (whatever the exception). > The issue is that the custom parsing doesn't follow the ModelNode parsing syntax and parse everything as String. So the resulting ModelNode that is serialised and sent to the server has been transformed. > I am surprised that we don't have more of such failures. For example, when numbers are located inside custom complex structure such as: {mynumber=9999} that will be sent as an OBJECT containing a STRING although the valid DMR syntax {"my number"=>999} would be sent as an OBJECT containing an INT. > Some server side subsystems are smart enough to call into asXXX methods and not check the type? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2131) UNICAST3 drops all messages until it receives the first one

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2131?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2131: -------------------------------- Great investigation, Dennis! I'm thinking of using an out-of-channel mechanism (e.g. separate SSL socket) to obtain the secret key from the keyserver. Although, if {{ASYM_ENCRYPT}} learns about the membership via {{JOIN_RSP}} or {{INSTALL_MERGE_VIEW}} messages, it could go ahead and send a request for the secret key to the keyserver... If {{JOIN_RSP}} is the first message, then things will work, so the above mechanism would be a second-line of-defense. I'll write a unit test that uses Byteman to inject receiving a message that's not tagged as first before the {{JON_RSP}} message. This should lead to a loop of {{JOIN_REQ}} msgs sent from joiner to coordinator, eventually leading to a singleton cluster for the joiner. > UNICAST3 drops all messages until it receives the first one > ----------------------------------------------------------- > > Key: JGRP-2131 > URL: https://issues.jboss.org/browse/JGRP-2131 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.10 > Reporter: Dennis Reed > Assignee: Bela Ban > Fix For: 3.6.12, 4.0 > > > UNICAST3.getReceiverEntry returns null if it hasn't seen the first message yet. > This causes UNICAST3.handleDataReceived to drop the message. > When you add *ENCRYPT, this causes a major deadlock. *ENCRYPT will queue most messages until it gets the encryption key, which can often include the first message (so UNICAST3 won't see it yet). Then when an important message such as JOIN_RSP comes through, UNICAST3 drops it. Since UNICAST3 never lets any messages through in this case, the encryption key will never get set so that *ENCRYPT can pass the first message up and free the deadlock. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1326) Stateful working memory regression OCT-2016: nurserostering long_hint01.xml

by Jiri Locker (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1326?page=com.atlassian.jira.plugi... ] Jiri Locker commented on DROOLS-1326: ------------------------------------- Hi Matteo, that's a valid question. There are two "inverted" asserts which expect the incorrect number of fired rules and the corrupted score. Their purpose is to make sure that the original bug is still reproducible. This was important for me while I was searching for minimal reproducer but I admit it is confusing to see the test pass. The two inverted asserts are marked with a comment and the expected values should be 4 rules and "0hard/-1soft" score, which are exactly the same values as at the very end of the test. Let me know if this explanation is enough or if you need further assistance. I can even make the test not use optaplanner-core at all. > Stateful working memory regression OCT-2016: nurserostering long_hint01.xml > --------------------------------------------------------------------------- > > Key: DROOLS-1326 > URL: https://issues.jboss.org/browse/DROOLS-1326 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.0.0.Beta2 > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > Priority: Blocker > Attachments: screenshot-1.png > > > Something regressed in Drools master between 27-SEP and 11-OCT. > See: > https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/optaplanner-turtl... > I 'll ask [~jlocker] to isolate. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1359) Race condition in MVELDialectRuntimeData.getParserConfiguration

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1359?page=com.atlassian.jira.plugi... ] Matteo Mortari commented on DROOLS-1359: ---------------------------------------- Hi [~chp-anujs], thank you for this; I've checked your reproducer but rewriting it using the public Kie API, and simulating the race condition inside {{MVELDialectRuntimeData}}, does not exhibit the problem, because at build time and during initialization of a new KieSession (either from KieContainer or KieBase) +the public Kie API+ guarantees the thread safety. Below your test case modified to use the public Kie API (is just one possible example to use the public Kie API) {code:java} @Test public void testRaceCondition() { List<String> lines = new ArrayList<>(); lines.add("package testrules"); lines.add("import static " + Helper.class.getCanonicalName() + ".* "); lines.add("import " + Fact.class.getCanonicalName()); lines.add("rule \"test-rule\" "); lines.add(" when "); lines.add(" fact : Fact( staticMethod(arg) )"); lines.add(" then "); lines.add(" fact.setActivated(); "); lines.add("end"); String drl = lines.stream().collect(Collectors.joining("\n")); KieServices ks = KieServices.Factory.get(); KieRepository kr = ks.getRepository(); KieFileSystem kfs = ks.newKieFileSystem(); kfs.write("src/main/resources/DROOLS-1359.drl", drl); KieBuilder kb = ks.newKieBuilder(kfs); System.out.println("building..."); kb.buildAll(); if (kb.getResults().hasMessages(Level.ERROR)) { throw new RuntimeException("Build Errors:\n" + kb.getResults().toString()); } System.out.println("building finished."); KieContainer kContainer = ks.newKieContainer(kr.getDefaultReleaseId()); KieBase knowledgeBase = kContainer.getKieBase(); int numberOfThreads = 2; System.out.println("Starting threads..."); ExecutorService executor = Executors.newFixedThreadPool(numberOfThreads); Callable<Boolean> executeRulesTask = new Callable<Boolean>() { @Override public Boolean call() throws Exception { // Create a knowledge session KieSession session = knowledgeBase.newKieSession(); try { // Insert the fact objects session.insert(new Fact()); // Run the session session.fireAllRules(); return true; } catch (RuntimeException e) { e.printStackTrace(); return false; } finally { session.dispose(); } } }; List<Future<Boolean>> executionResults = new ArrayList<>(); for (int i = 0; i < numberOfThreads; i++) executionResults.add(executor.submit(executeRulesTask)); executor.shutdown(); boolean finalResult = true; for (int i = 0; i < numberOfThreads; i++) { try { finalResult &= executionResults.get(i).get(); } catch (InterruptedException | ExecutionException e) { finalResult = false; } } assertTrue(finalResult); } ... public class Helper { public static boolean staticMethod(String arg) { return true; } } ... public class Fact { public String getArg() { return null; } public void setActivated() { } } {code} and the {{MVELDialectRuntimeData}} quick modification to attempt the raise of the race-condition (Line 318): {code:java} this.parserConfiguration = new ParserConfiguration(); try { System.out.println("X"); Thread.sleep(2_000L); } catch (InterruptedException e) { e.printStackTrace(); } this.parserConfiguration.setImports( this.imports ); this.parserConfiguration.setPackageImports( this.packageImports ); this.parserConfiguration.setClassLoader( packageClassLoader ); {code} In conclusion: not a bug, using the public Kie API does not exhibit racing-condition issues. If you still think there are some issues with the public Kie API, kindly let us know, and thank you anyway for your report so far! > Race condition in MVELDialectRuntimeData.getParserConfiguration > --------------------------------------------------------------- > > Key: DROOLS-1359 > URL: https://issues.jboss.org/browse/DROOLS-1359 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 5.5.0.Final, 6.5.0.Final > Reporter: Anuj Shah > Assignee: Mario Fusco > > MVELDialectRuntimeData attempts to hold a lazy loaded ParserConfiguration. The getParserConfiguration method sets this to a new configuration object and then sets the imports on the configuration. Between these two steps another thread could retrieve the stale configuration and use it. This could result in a number of exceptions in compilation. > A simple fix is to delay assignment of new ParserConfiguration until after the imports are set. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1986) Generate a parser from a formal grammer of CLI

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1986?page=com.atlassian.jira.plugi... ] Jean-Francois Denise reassigned WFCORE-1986: -------------------------------------------- Assignee: Jean-Francois Denise > Generate a parser from a formal grammer of CLI > ---------------------------------------------- > > Key: WFCORE-1986 > URL: https://issues.jboss.org/browse/WFCORE-1986 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Affects Versions: 3.0.0.Alpha12 > Reporter: Hisanobu Okuda > Assignee: Jean-Francois Denise > > Having a formal grammar is a simple and good way to rigorously define things, and using a parser generator instead of writing parser code by hand will result in a reduction in defective edge cases. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7612) Replacement for org.kuali.maven.plugins:properties-maven-plugin

by gil cattaneo (JIRA)

gil cattaneo created WFLY-7612: ---------------------------------- Summary: Replacement for org.kuali.maven.plugins:properties-maven-plugin Key: WFLY-7612 URL: https://issues.jboss.org/browse/WFLY-7612 Project: WildFly Issue Type: Task Reporter: gil cattaneo Assignee: Jason Greene Hi, org.kuali.maven.plugins:properties-maven-plugin is used for wildfly 11.0.0.Alpha1-SNAPSHOT (master branch) but seem the plugin source code (and also for it dependencies) is not more available @ http://svn.kuali.org/repos/foundation/ Please, can you use some other alternative, e.g. http://www.mojohaus.org/properties-maven-plugin/ ? This is necessary for all Linux distributions that do not include the use of pre-compiled libraries (including maven plugins), available on various maven repository. e.g http://central.maven.org/maven2/ https://fedoraproject.org/wiki/Packaging:Guidelines#No_inclusion_of_pre-b... Thanks in advance Regards -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 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 November 2016