December 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4778) Legacy LDAP realm, runtime operations and access to runtime attributes fail

by Ondrej Kotek (Jira)

[ https://issues.redhat.com/browse/WFCORE-4778?page=com.atlassian.jira.plug... ] Ondrej Kotek updated WFCORE-4778: --------------------------------- Fix Version/s: 11.0.0.Final > Legacy LDAP realm, runtime operations and access to runtime attributes fail > --------------------------------------------------------------------------- > > Key: WFCORE-4778 > URL: https://issues.redhat.com/browse/WFCORE-4778 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 10.0.0.Final > Reporter: Ondrej Kotek > Assignee: Darran Lofthouse > Priority: Blocker > Labels: caching, ldap, legacy > Fix For: 11.0.0.Final > > > Runtime operations and access to runtime attributes fail for legacy LDAP realm. > {noformat} > ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("read-attribute") failed - address: ([ > ("core-service" => "management"), > ("security-realm" => "authn-by-search-time-neg-neg"), > ("authentication" => "ldap"), > ("cache" => "by-search-time") > ]): java.lang.UnsupportedOperationException > at org.jboss.msc.service.ServiceControllerImpl.awaitValue(ServiceControllerImpl.java:1115) > at org.jboss.msc.service.DelegatingServiceController.awaitValue(DelegatingServiceController.java:110) > at org.jboss.as.domain.management.security.LdapCacheResourceDefinition$BaseRuntimeOpHandler.lookupService(LdapCacheResourceDefinition.java:321) > at org.jboss.as.domain.management.security.LdapCacheResourceDefinition$BaseRuntimeOpHandler.readAttribute(LdapCacheResourceDefinition.java:288) > at org.jboss.as.domain.management.security.LdapCacheResourceDefinition$BaseRuntimeOpHandler$1.execute(LdapCacheResourceDefinition.java:269) > 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.OperationContextImpl.executeOperation(OperationContextImpl.java:1413) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:423) > at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:289) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:255) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:240) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:138) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:162) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:158) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:313) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:270) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:158) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4779) Upgrade Woodstox from 5.0.3 to 6.0.3

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/WFCORE-4779?page=com.atlassian.jira.plug... ] Ilia Vassilev reassigned WFCORE-4779: ------------------------------------- Assignee: Jeff Mesnil (was: Ivo Studensky) > Upgrade Woodstox from 5.0.3 to 6.0.3 > ------------------------------------ > > Key: WFCORE-4779 > URL: https://issues.redhat.com/browse/WFCORE-4779 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Build System > Reporter: Ilia Vassilev > Assignee: Jeff Mesnil > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4807) [DMN Designer] Do not group V&V messages by UUID

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-4807?page=com.atlassian.jira.plug... ] Michael Anstis commented on DROOLS-4807: ---------------------------------------- [~jomarko] File {{dmn1.dmn}} attached that shows the change.. in {{master}} the V&V errors are on one line in the Alerts panel (you need to hover over with your mouse to see the whole text). With this JIRA/PR applied the different V&V messages appear on different rows in the Alerts panel. > [DMN Designer] Do not group V&V messages by UUID > ------------------------------------------------ > > Key: DROOLS-4807 > URL: https://issues.redhat.com/browse/DROOLS-4807 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.30.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Attachments: V&V.png, dmn1.dmn > > > The V&V results are grouped by UUID. See attached screen-shot. > These items are reported individually by {{kie-dmn-validation}} but grouped by {{org.kie.workbench.common.dmn.showcase.backend.validation.ValidationServiceImpl}} in the _standalone_ webapp however I fear Stunner's generic {{ValidationService}} does the same in Business Central and hence reporting DMN V&V per-line may be more troublesum. > See [here|https://github.com/kiegroup/kie-wb-common/blob/master/kie-wb-common-...] that should more correctly be:- > {code} > @Override > public Collection<DiagramElementViolation<RuleViolation>> validate(Diagram diagram) { > return domainViolations(diagram).stream() > .filter(v -> Objects.nonNull(v.getUUID())) > .filter(v -> !"null".equals(v.getUUID())) > .map(v -> new ElementViolationImpl.Builder().setUuid(v.getUUID()).setDomainViolations(Collections.singletonList(v)).build()) > .collect(Collectors.toList()); > } > {code} > h3. Acceptance criteria > - Create a DMN file > - Add a Decision node with no content > - Validate it > - Each validation message should be a separate item in the Alert panel -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4807) [DMN Designer] Do not group V&V messages by UUID

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-4807?page=com.atlassian.jira.plug... ] Michael Anstis updated DROOLS-4807: ----------------------------------- Attachment: dmn1.dmn > [DMN Designer] Do not group V&V messages by UUID > ------------------------------------------------ > > Key: DROOLS-4807 > URL: https://issues.redhat.com/browse/DROOLS-4807 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.30.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Attachments: V&V.png, dmn1.dmn > > > The V&V results are grouped by UUID. See attached screen-shot. > These items are reported individually by {{kie-dmn-validation}} but grouped by {{org.kie.workbench.common.dmn.showcase.backend.validation.ValidationServiceImpl}} in the _standalone_ webapp however I fear Stunner's generic {{ValidationService}} does the same in Business Central and hence reporting DMN V&V per-line may be more troublesum. > See [here|https://github.com/kiegroup/kie-wb-common/blob/master/kie-wb-common-...] that should more correctly be:- > {code} > @Override > public Collection<DiagramElementViolation<RuleViolation>> validate(Diagram diagram) { > return domainViolations(diagram).stream() > .filter(v -> Objects.nonNull(v.getUUID())) > .filter(v -> !"null".equals(v.getUUID())) > .map(v -> new ElementViolationImpl.Builder().setUuid(v.getUUID()).setDomainViolations(Collections.singletonList(v)).build()) > .collect(Collectors.toList()); > } > {code} > h3. Acceptance criteria > - Create a DMN file > - Add a Decision node with no content > - Validate it > - Each validation message should be a separate item in the Alert panel -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4780) Stax maxAttributeSize is only vaguely respected

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/WFCORE-4780?page=com.atlassian.jira.plug... ] Ilia Vassilev moved JBEAP-18364 to WFCORE-4780: ----------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-4780 (was: JBEAP-18364) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: (was: Web Services) Affects Version/s: (was: 7.2.0.GA) QE Test Coverage: (was: +) Fix Version/s: (was: 7.3.1.GA) > Stax maxAttributeSize is only vaguely respected > ----------------------------------------------- > > Key: WFCORE-4780 > URL: https://issues.redhat.com/browse/WFCORE-4780 > Project: WildFly Core > Issue Type: Bug > Reporter: Ilia Vassilev > Assignee: Ivo Studensky > Priority: Major > > System property org.apache.cxf.stax.maxAttributeSize only vaguely limits attribute values. If I set the property to 5000 I can send up to 8295 characters in an attribute value without EAP denying the request. > Reviewing the source code for woodstox reveal that the limit is checked against the size of the buffer before the last buffer expansion. After 2459 characters the buffer is grown to 3687. After 5531 characters the limit is checked against 3687 instead of 5531 and not until 8296 characters is the limit checked against the previous buffer size 5531 which is larger than 5000. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4779) Upgrade Woodstox from 5.0.3 to ...

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/WFCORE-4779?page=com.atlassian.jira.plug... ] Ilia Vassilev moved JBEAP-18362 to WFCORE-4779: ----------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-4779 (was: JBEAP-18362) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Build System (was: Build System) Affects Version/s: (was: 7.2.4.GA) Fix Version/s: (was: 7.3.1.GA) > Upgrade Woodstox from 5.0.3 to ... > ---------------------------------- > > Key: WFCORE-4779 > URL: https://issues.redhat.com/browse/WFCORE-4779 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Build System > Reporter: Ilia Vassilev > Assignee: Ivo Studensky > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4779) Upgrade Woodstox from 5.0.3 to 6.0.3

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/WFCORE-4779?page=com.atlassian.jira.plug... ] Ilia Vassilev updated WFCORE-4779: ---------------------------------- Summary: Upgrade Woodstox from 5.0.3 to 6.0.3 (was: Upgrade Woodstox from 5.0.3 to ...) > Upgrade Woodstox from 5.0.3 to 6.0.3 > ------------------------------------ > > Key: WFCORE-4779 > URL: https://issues.redhat.com/browse/WFCORE-4779 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Build System > Reporter: Ilia Vassilev > Assignee: Ivo Studensky > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12898) Multiversion Testing for wildfly images

by Panagiotis Sotiropoulos (Jira)

Panagiotis Sotiropoulos created WFLY-12898: ---------------------------------------------- Summary: Multiversion Testing for wildfly images Key: WFLY-12898 URL: https://issues.redhat.com/browse/WFLY-12898 Project: WildFly Issue Type: Task Components: Test Suite Reporter: Panagiotis Sotiropoulos Assignee: Panagiotis Sotiropoulos Multiversion Testing for wildfly images with EAT -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3583) A comment creates an infinite loop

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-3583?page=com.atlassian.jira.plug... ] Mario Fusco resolved DROOLS-3583. --------------------------------- Resolution: Done Fixed by https://github.com/kiegroup/drools/commit/0f801589efcf450844ced95a80d776b... > A comment creates an infinite loop > ---------------------------------- > > Key: DROOLS-3583 > URL: https://issues.redhat.com/browse/DROOLS-3583 > Project: Drools > Issue Type: Bug > Affects Versions: 7.16.0.Final > Reporter: Osira Ben > Assignee: Mario Fusco > Priority: Minor > > This rule file makes the engine stuck in an infinite loop. > {code:drools} > package com.example > declare Counter > value: int > end > rule "Init" when > not Counter() > then > drools.insert(new Counter(0)); > end > rule "Loop" > when > c: Counter() > then > // removing this comment line removes the loop > c.setValue(1); > update(c); > end > {code} > But the loop is not an issue. > The issue is that if the commented line is removed the loop is gone. > This code doesn't cause the loop. > {code:drools} > package com.example > declare Counter > value: int > end > rule "Init" when > not Counter() > then > drools.insert(new Counter(0)); > end > rule "Loop" > when > c: Counter() > then > c.setValue(1); > update(c); > end > {code} > Java code used to run the engine. > {code:java} > public class DroolsLoopingTest { > public static class LoopError extends RuntimeException { > } > public static void main(String[] args) { > System.setProperty("drools.dump.dir", "."); > final KieServices ks = KieServices.Factory.get(); > final KieRepository kr = ks.getRepository(); > final KieFileSystem kfs = ks.newKieFileSystem(); > kfs.write("src/main/resources/loop.drl", new ClassPathResource("loop.drl")); > final KieBuilder kb = ks.newKieBuilder(kfs); > kb.buildAll(); > if (kb.getResults().hasMessages(Message.Level.ERROR)) > throw new RuntimeException(kb.getResults().toString()); > final KieContainer kContainer = ks.newKieContainer(kr.getDefaultReleaseId()); > KieSession kSession = kContainer.newKieSession(); > kSession.addEventListener(new DefaultAgendaEventListener() { > private int i = 0; > @Override > public void afterMatchFired(AfterMatchFiredEvent event) { > System.out.println(event); > if (++i > 10) throw new LoopError(); > } > }); > try { > kSession.fireAllRules(); > throw new RuntimeException("Expected loop error"); > } catch (LoopError e) { > System.out.println("Loop detected"); > } > } > } > {code} > I noticed a difference in generated code. > The rule file with the comment line generates this code > {code:java} > public static void defaultConsequence(KnowledgeHelper drools, com.example.Counter c, org.kie.api.runtime.rule.FactHandle c__Handle__ ) throws java.lang.Exception { org.kie.api.runtime.rule.RuleContext kcontext = drools; > // removing this comment line removes the loop > c.setValue(1); > { drools.update( c__Handle__, org.drools.core.util.bitmask.AllSetButLastBitMask.get(), com.example.Counter.class ); }; > } > {code} > While the rule file without the comment line generates this code > {code:java} > public static void defaultConsequence(KnowledgeHelper drools, com.example.Counter c, org.kie.api.runtime.rule.FactHandle c__Handle__ ) throws java.lang.Exception { org.kie.api.runtime.rule.RuleContext kcontext = drools; > c.setValue(1); > { drools.update( c__Handle__, new org.drools.core.util.bitmask.LongBitMask(2L), com.example.Counter.class ); }; > } > {code} > Expected result is that comments should not affect engine behavior. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4885) Renabble DMNPMMLRegressionIntegrationTest

by Luca Molteni (Jira)

Luca Molteni created DROOLS-4885: ------------------------------------ Summary: Renabble DMNPMMLRegressionIntegrationTest Key: DROOLS-4885 URL: https://issues.redhat.com/browse/DROOLS-4885 Project: Drools Issue Type: Bug Components: executable model Reporter: Luca Molteni Assignee: Luca Molteni See https://github.com/kiegroup/droolsjbpm-integration/pull/1864/commits/873d... This test doesn't work with the executable model -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 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 2019