December 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9621) Nonintuitive error message when for loop is used inside of if/try/batch constructs

by Erich Duda (JIRA)

Erich Duda created WFLY-9621: -------------------------------- Summary: Nonintuitive error message when for loop is used inside of if/try/batch constructs Key: WFLY-9621 URL: https://issues.jboss.org/browse/WFLY-9621 Project: WildFly Issue Type: Bug Components: CLI Affects Versions: 11.0.0.Final Reporter: Erich Duda Assignee: Jason Greene CLI enables to use for loop construct for looping over commands or operations. See WFCORE-3236 for details. Because of design limitations of CLI, using of for loop is not supported inside of if, try, for and batch constructs. However if you try to do that, error message is not intuitive in all cases and it is difficult to find out why the code does not work. Let's see on real examples. {code:title=Using for inside if} [standalone@embedded /] if (outcome != success) of /system-property=test:read-resource [standalone@embedded /] for propName in :read-children-names(child-type=system-property) [standalone@embedded /] echo $propName Unrecognized variable propName {code} As you can see in the example, when you write aforementioned commands into the CLI, no error is thrown until you use the variable declared in the for construct. Additionally the error message is not saying anything about that using of "for" is not allowed inside of "if". {code:title=Using for inside try} [standalone@embedded /] try [standalone@embedded /] for propName in :read-children-names(child-type=system-property) [standalone@embedded /] echo $propName Unrecognized variable propName {code} The same applies here as for "if" case. {code:title=Using for inside batch} [standalone@embedded /] batch [standalone@embedded / #] for propName in :read-children-names(child-type=system-property) The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable). {code} In the batch case, the error message is better (it says that command is not available), but still it is not clear why the command is not available. {code:title=Using for inside for} [standalone@embedded /] for propName in :read-children-names(child-type=system-property) [standalone@embedded /] for propName in :read-children-names(child-type=system-property) for is not allowed while in for block {code} Using of nested for loops generates nice error message which clearly explains what is wrong. All other cases should throw similar error. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2192) DMN QName regex problem and assimilated for function drools:kind

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2192?page=com.atlassian.jira.plugi... ] Matteo Mortari reassigned DROOLS-2192: -------------------------------------- Assignee: Matteo Mortari (was: Edson Tirelli) > DMN QName regex problem and assimilated for function drools:kind > ---------------------------------------------------------------- > > Key: DROOLS-2192 > URL: https://issues.jboss.org/browse/DROOLS-2192 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > > DMN QName regex does not match with serialization strategy. > A qname string serialization as > {code:java} > {http://namespace}localPart > {code} > would fail the regex of MarshallingUtils. > Additionally FunctionDefinition could now rely on the additionalAttributes generally available at the level of DMNModelInstrumentedBase (which would also serialize any other type of additional attributes, preserving from any original .dmn file). > Finally, it was noted calling getDecisionResultByName on DMNResultImpl by passing a wrong name would have thrown the stacktrace for wrong use of Optional.get(), instead of returning null as per getDecisionResultById() of the same class. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2192) DMN QName regex problem and assimilated for function drools:kind

by Matteo Mortari (JIRA)

Matteo Mortari created DROOLS-2192: -------------------------------------- Summary: DMN QName regex problem and assimilated for function drools:kind Key: DROOLS-2192 URL: https://issues.jboss.org/browse/DROOLS-2192 Project: Drools Issue Type: Bug Components: dmn engine Reporter: Matteo Mortari Assignee: Edson Tirelli DMN QName regex does not match with serialization strategy. A qname string serialization as {code:java} {http://namespace}localPart {code} would fail the regex of MarshallingUtils. Additionally FunctionDefinition could now rely on the additionalAttributes generally available at the level of DMNModelInstrumentedBase (which would also serialize any other type of additional attributes, preserving from any original .dmn file). Finally, it was noted calling getDecisionResultByName on DMNResultImpl by passing a wrong name would have thrown the stacktrace for wrong use of Optional.get(), instead of returning null as per getDecisionResultById() of the same class. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2191) Test SharedSessionParallelTest.testLongRunningRule2 fails randomly on Kie Jenkins

by Tibor Zimányi (JIRA)

Tibor Zimányi created DROOLS-2191: ------------------------------------- Summary: Test SharedSessionParallelTest.testLongRunningRule2 fails randomly on Kie Jenkins Key: DROOLS-2191 URL: https://issues.jboss.org/browse/DROOLS-2191 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.6.0.Final Reporter: Tibor Zimányi Assignee: Tibor Zimányi The mentioned test fails randomly on Kie Jenkins. It must be investigated. https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/drools/281/testRe... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1366) Cannot access remote KIE maven repo - Unauthorized access 401

by Vlastimil Eliáš (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1366?page=com.atlassian.jira.plugi... ] Vlastimil Eliáš deleted DROOLS-1366: ------------------------------------ > Cannot access remote KIE maven repo - Unauthorized access 401 > ------------------------------------------------------------- > > Key: DROOLS-1366 > URL: https://issues.jboss.org/browse/DROOLS-1366 > Project: Drools > Issue Type: Bug > Reporter: Sambhaji Biradar > Assignee: Mario Fusco > > Using the latest 6.5 version, we are getting unauthorized access error. From the other posts I see that this issue was resolved in earlier versions but wondering if this issue was introduced again in 6.5. I tried this solution with no success - https://issues.jboss.org/browse/DROOLS-436. > Could someone help resolving the issue please? > > #NOTE: This is an Aether internal implementation file, its format can be changed without prior notice. > #Mon Nov 21 19:20:51 EST 2016 > maven-metadata-central.xml.error=Could not transfer metadata com.xxx.xxx.ruleengine\:fraudrules\:1.1-SNAPSHOT/maven-metadata.xml from/to central (http\://repo1.maven.org/maven2/)\: Connect to repo1.maven.org\:80 timed out > maven-metadata-guvnor-m2-repo.xml.error=Could not transfer metadata com.xxx.xxx.ruleengine\:rules\:1.1-SNAPSHOT/maven-metadata.xml from/to guvnor-m2-repo (http\://10.xxx.77.xxx\:8080/kie-drools-wb/maven2/)\: Unauthorized (401) > maven-metadata-workbench.xml.lastUpdated=1479774051131 > maven-metadata-guvnor-m2-repo.xml/@default-guvnor-m2-repo-http\://10.xxx.77.xxx\:8080/kie-drools-wb/maven2/.lastUpdated=1479774051096 > maven-metadata-central.xml/@default-central-http\://repo1.maven.org/maven2/.lastUpdated=1479774050359 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-214) [QE] - Disable Middleware Manager

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-214?page=com.atlassian.jira.pl... ] Hayk Hovsepyan updated HAWKULARQE-214: -------------------------------------- Description: https://bugzilla.redhat.com/show_bug.cgi?id=1526791 Remove Middleware Manager from CFME UI: Menu: Middleware Control -> Explorer Cloud Intel -> Reports More info at: http://pad.engineering.redhat.com/middleware-deletion-task Disable Middleware Manager provider in CFME Tests framework. was: https://bugzilla.redhat.com/show_bug.cgi?id=1526791 Remove Middleware Manager from CFME UI: Menu: Middleware Control -> Explorer Cloud Intel -> Reports Disable Middleware Manager provider in CFME Tests framework. > [QE] - Disable Middleware Manager > --------------------------------- > > Key: HAWKULARQE-214 > URL: https://issues.jboss.org/browse/HAWKULARQE-214 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Michael Foley > Priority: Blocker > > https://bugzilla.redhat.com/show_bug.cgi?id=1526791 > Remove Middleware Manager from CFME UI: > Menu: Middleware > Control -> Explorer > Cloud Intel -> Reports > More info at: http://pad.engineering.redhat.com/middleware-deletion-task > Disable Middleware Manager provider in CFME Tests framework. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2190) DMN: Run TCK suite from a specified branch within our build

by Tibor Zimányi (JIRA)

Tibor Zimányi created DROOLS-2190: ------------------------------------- Summary: DMN: Run TCK suite from a specified branch within our build Key: DROOLS-2190 URL: https://issues.jboss.org/browse/DROOLS-2190 Project: Drools Issue Type: Task Components: dmn engine Affects Versions: 7.5.0.Final Reporter: Tibor Zimányi Assignee: Tibor Zimányi Fix For: 7.6.0.Final Currently we are able to download and run only master branch of DMN TCK git repository. Maven SCM plugin we use contains settings that we can use to run TCK tests from specified branch. These settings should be added to Maven SCM plugin configuration we have in kie-dmn-tck module. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7247) Wildfly 10 JSESSIONIDSSOs not being created

by Brian Wallis (JIRA)

[ https://issues.jboss.org/browse/WFLY-7247?page=com.atlassian.jira.plugin.... ] Brian Wallis commented on WFLY-7247: ------------------------------------ Is it known if this issue is fixed in 11.x? If so it would be useful to note that here (and possibly back in the linked forum threads). > Wildfly 10 JSESSIONIDSSOs not being created > ------------------------------------------- > > Key: WFLY-7247 > URL: https://issues.jboss.org/browse/WFLY-7247 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final, 10.1.0.Final > Reporter: M Wardell > Assignee: Jason Greene > > Found on wildfly 10.1 and 10.0. With SSO enabled, the server can startup in a state where not all the deployments get the SSO auth mechanism. Possibly caused by a missing dependency between the UndertowDeploymentInfoService and SingleSignOnService, which could be allowing the deployments to start before the SSO auth mechanism is registered in the host service. > Issue in intermittent on startup. After most startups the JESSSIONIDSSO is reliably generated during login. After some startups the JSESSIONIDSSO is never created after login. > Details in the referenced forum thread. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-187) The ClassLoaderLogContextSelector check for the log context should return null

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-187?page=com.atlassian.jira.plugin... ] James Perkins updated LOGMGR-187: --------------------------------- Priority: Blocker (was: Major) > The ClassLoaderLogContextSelector check for the log context should return null > ------------------------------------------------------------------------------ > > Key: LOGMGR-187 > URL: https://issues.jboss.org/browse/LOGMGR-187 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Perkins > Assignee: James Perkins > Priority: Blocker > Fix For: 2.1.0.Alpha6 > > > The {{ClassLoaderLogContextSelector}} check for the registered {{LogContext}} returns {{defaultSelector.getLogContext()}} in the {{check()}} method and should return {{null}}. > {code:title=Previous Version} > private final PrivilegedAction<LogContext> logContextAction = new PrivilegedAction<LogContext>() { > public LogContext run() { > for (Class<?> caller : GATEWAY.getClassContext()) { > final ClassLoader classLoader = caller.getClassLoader(); > final LogContext result = check(classLoader); > if (result != null) { > return result; > } > } > return defaultSelector.getLogContext(); > } > private LogContext check(final ClassLoader classLoader) { > if (classLoader != null && !logApiClassLoaders.contains(classLoader)) { > final LogContext context = contextMap.get(classLoader); > if (context != null) { > return context; > } > if (checkParentClassLoaders) { > return check(classLoader.getParent()); > } > } > return null; > } > }; > {code} > {code:title=Current Version} > private final PrivilegedAction<LogContext> logContextAction = new PrivilegedAction<LogContext>() { > public LogContext run() { > final Class<?> callingClass = JDKSpecific.findCallingClass(logApiClassLoaders); > return callingClass == null ? defaultSelector.getLogContext() : check(callingClass.getClassLoader()); > } > private LogContext check(final ClassLoader classLoader) { > final LogContext context = contextMap.get(classLoader); > if (context != null) { > return context; > } > final ClassLoader parent = classLoader.getParent(); > if (parent != null && checkParentClassLoaders && ! logApiClassLoaders.contains(parent)) { > return check(parent); > } > return defaultSelector.getLogContext(); > } > }; > {code} > The new version only checks the first caller found, then returns the default. The older version checks the callers until it finds a non-null value finally returning the default if no callers were found with associated contexts. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-187) The ClassLoaderLogContextSelector check for the log context should return null

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-187?page=com.atlassian.jira.plugin... ] James Perkins updated LOGMGR-187: --------------------------------- Fix Version/s: 2.1.0.Alpha6 > The ClassLoaderLogContextSelector check for the log context should return null > ------------------------------------------------------------------------------ > > Key: LOGMGR-187 > URL: https://issues.jboss.org/browse/LOGMGR-187 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Perkins > Assignee: James Perkins > Fix For: 2.1.0.Alpha6 > > > The {{ClassLoaderLogContextSelector}} check for the registered {{LogContext}} returns {{defaultSelector.getLogContext()}} in the {{check()}} method and should return {{null}}. > {code:title=Previous Version} > private final PrivilegedAction<LogContext> logContextAction = new PrivilegedAction<LogContext>() { > public LogContext run() { > for (Class<?> caller : GATEWAY.getClassContext()) { > final ClassLoader classLoader = caller.getClassLoader(); > final LogContext result = check(classLoader); > if (result != null) { > return result; > } > } > return defaultSelector.getLogContext(); > } > private LogContext check(final ClassLoader classLoader) { > if (classLoader != null && !logApiClassLoaders.contains(classLoader)) { > final LogContext context = contextMap.get(classLoader); > if (context != null) { > return context; > } > if (checkParentClassLoaders) { > return check(classLoader.getParent()); > } > } > return null; > } > }; > {code} > {code:title=Current Version} > private final PrivilegedAction<LogContext> logContextAction = new PrivilegedAction<LogContext>() { > public LogContext run() { > final Class<?> callingClass = JDKSpecific.findCallingClass(logApiClassLoaders); > return callingClass == null ? defaultSelector.getLogContext() : check(callingClass.getClassLoader()); > } > private LogContext check(final ClassLoader classLoader) { > final LogContext context = contextMap.get(classLoader); > if (context != null) { > return context; > } > final ClassLoader parent = classLoader.getParent(); > if (parent != null && checkParentClassLoaders && ! logApiClassLoaders.contains(parent)) { > return check(parent); > } > return defaultSelector.getLogContext(); > } > }; > {code} > The new version only checks the first caller found, then returns the default. The older version checks the callers until it finds a non-null value finally returning the default if no callers were found with associated contexts. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

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