May 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5331) Support for Enums in Test Scenario

by Yeser Amer (Jira)

Yeser Amer created DROOLS-5331: ---------------------------------- Summary: Support for Enums in Test Scenario Key: DROOLS-5331 URL: https://issues.redhat.com/browse/DROOLS-5331 Project: Drools Issue Type: Feature Request Reporter: Yeser Amer Assignee: Yeser Amer -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5264) Cancelling artifact upload dialog does not clear file chooser field

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-5264?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-5264: -------------------------------- Steps to Reproduce: * Click the _Settings_ button * Click _Artifacts_ * Click _Upload_ * Click _Choose File..._ * Select a random TXT file * Click _Cancel_ * Click _Upload_ * Observe same file still present in file chooser field was: * Click the ""Settings"" button * Click ""Artifacts"" * Click ""Upload"" * Click ""Choose File..."" * Select a random TXT file * Click ""Cancel"" * Click ""Upload"" * Observe same file still present in file chooser field > Cancelling artifact upload dialog does not clear file chooser field > ------------------------------------------------------------------- > > Key: DROOLS-5264 > URL: https://issues.redhat.com/browse/DROOLS-5264 > Project: Drools > Issue Type: Bug > Components: Artifact Repository > Affects Versions: 7.37.0.Final > Reporter: Jozef Marko > Assignee: Jozef Marko > Priority: Minor > Labels: drools-tools > Attachments: artifact-upload-cleared.webm, artifact-upload-not-cleared.webm > > > Behavior before the fix: > [^artifact-upload-not-cleared.webm] > Behavior after fix: > [^artifact-upload-cleared.webm] -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5317) Scenario Simulation shows misleading data type if DMN applies a constraint

by Yeser Amer (Jira)

[ https://issues.redhat.com/browse/DROOLS-5317?page=com.atlassian.jira.plug... ] Yeser Amer updated DROOLS-5317: ------------------------------- Priority: Critical (was: Minor) > Scenario Simulation shows misleading data type if DMN applies a constraint > -------------------------------------------------------------------------- > > Key: DROOLS-5317 > URL: https://issues.redhat.com/browse/DROOLS-5317 > Project: Drools > Issue Type: Bug > Affects Versions: 7.37.0.Final > Reporter: Yeser Amer > Assignee: Yeser Amer > Priority: Critical > Labels: drools-tools > Fix For: 7.38.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5317) Scenario Simulation shows misleading data type if DMN applies a constraint

by Yeser Amer (Jira)

[ https://issues.redhat.com/browse/DROOLS-5317?page=com.atlassian.jira.plug... ] Yeser Amer updated DROOLS-5317: ------------------------------- Issue Type: Bug (was: Feature Request) > Scenario Simulation shows misleading data type if DMN applies a constraint > -------------------------------------------------------------------------- > > Key: DROOLS-5317 > URL: https://issues.redhat.com/browse/DROOLS-5317 > Project: Drools > Issue Type: Bug > Affects Versions: 7.37.0.Final > Reporter: Yeser Amer > Assignee: Yeser Amer > Priority: Minor > Labels: drools-tools > Fix For: 7.38.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5330) DMN coercion of decision service parameter interaction with typecheck

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-5330?page=com.atlassian.jira.plug... ] Matteo Mortari commented on DROOLS-5330: ---------------------------------------- Linking to [KOGITO-2181] since the problem emerged when the original reported highlighted the issue use case via chat. > DMN coercion of decision service parameter interaction with typecheck > --------------------------------------------------------------------- > > Key: DROOLS-5330 > URL: https://issues.redhat.com/browse/DROOLS-5330 > Project: Drools > Issue Type: Enhancement > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > > The coercion of decision service parameter, was always considering typecheck, while interaction with typecheck should be taken into account also while DS parameter are being inspected for coercion from singleton list. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5330) DMN coercion of decision service parameter interaction with typecheck

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-5330: -------------------------------------- Summary: DMN coercion of decision service parameter interaction with typecheck Key: DROOLS-5330 URL: https://issues.redhat.com/browse/DROOLS-5330 Project: Drools Issue Type: Enhancement Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari The coercion of decision service parameter, was always considering typecheck, while interaction with typecheck should be taken into account also while DS parameter are being inspected for coercion from singleton list. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-243) Ensure reference to repository is removed from pom

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-243?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-243: --------------------------------- Fix Version/s: 1.12.0.CR3 (was: 1.12.0.CR2) > Ensure reference to repository is removed from pom > -------------------------------------------------- > > Key: ELY-243 > URL: https://issues.redhat.com/browse/ELY-243 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Darran Lofthouse > Priority: Major > Fix For: 1.12.0.CR3 > > > We need to ensure the reference to the JBoss repo is removed from the pom and artefacts are available from Maven Central. > Also at this point probably good to put the steps in place for Elytron to also be available from Maven Central. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-533) Deprecate all legacy code

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-533?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-533: --------------------------------- Fix Version/s: 1.12.0.CR3 (was: 1.12.0.CR2) > Deprecate all legacy code > ------------------------- > > Key: ELY-533 > URL: https://issues.redhat.com/browse/ELY-533 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.12.0.CR3 > > > In a few places we have legacy behaviour within the project to assist migration from previous JBoss / WildFly releases - this code should be flagged as deprecated to encourage minimal use. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1440) FlexibleIdentityAssociation should runAs the known SecurityIdentity before associating itself.

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1440?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1440: ---------------------------------- Fix Version/s: 1.12.0.CR3 (was: 1.12.0.CR2) > FlexibleIdentityAssociation should runAs the known SecurityIdentity before associating itself. > ---------------------------------------------------------------------------------------------- > > Key: ELY-1440 > URL: https://issues.redhat.com/browse/ELY-1440 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Major > Fix For: 1.12.0.CR3 > > > This API was introduced to cover the case where authentication happens late in a request, generally that is quite a rare event. > Even though the API may be popular it would likely happen once for a session and all future requests for that session the identity would be known in advance. > At the moment by not running as the existing identity we are loosing all automatic identity outflow opportunities as calls pass from the servlet container to the EJB container. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1682) Fallback to another SASL client mechanism when SASL client initialisation fails

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1682?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1682: ---------------------------------- Fix Version/s: 1.12.0.CR3 (was: 1.12.0.CR2) > Fallback to another SASL client mechanism when SASL client initialisation fails > ------------------------------------------------------------------------------- > > Key: ELY-1682 > URL: https://issues.redhat.com/browse/ELY-1682 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Affects Versions: 1.7.0.CR1 > Reporter: Martin Choma > Priority: Major > Fix For: 1.12.0.CR3 > > Attachments: org.jboss.eapqe.krbldap.eap71.tests.krb.ejb.KerberosEjbGssapiTestCase-output.txt > > > {code:title=HipChat conversation} > Martin Choma: I have got this situation here; Server is authenticated with GSSAPI and PLAIN. Client has only username/password credential - no kerberos credential. > But client tries to create GssapiSaslClient as well (which make problem on IBM). Once I set .setSaslMechanismSelector(SaslMechanismSelector.fromString("PLAIN")) scenario works ok. > I wonder could Authentication Client be smart enough to not try to initialize authentication mechanisms which it has not credentials for? > Darran Lofthouse: Client side GSSAPI we tend not to have configured credentials as the mech obtains from OS level. The mech should fail and allow the next mech to be selected > Martin Choma: Ok, so I will create issue. Seems on client side this mechanism fallback does not work properly. (At least in IBM JDK case). > In this case it is initialization of mechanism which is failing, so maybe fallback does not have chance to get involved. > Darran Lofthouse: Sounds possible, if a mech can not initialise we should likely treat it as a failed mech and move on - maybe something needed in Remoting > though for that one as that is where that loop happens but start with an ELY issue > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 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 May 2020