August 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-2774) Select a data type from the DMN canvas

by Guilherme Carreiro (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2774?page=com.atlassian.jira.plugi... ] Guilherme Carreiro commented on DROOLS-2774: -------------------------------------------- [~uxdlc] I'm not sure if it's solved. Sometimes the user can click in some elements in the canvas and select the data type right there (without using the properties panel). Like here: !Screen Shot 2018-08-10 at 10.23.36 AM.png|thumbnail! I think that would be nice to have a prototype of this kind of scenario. [~manstis] worked on this component that I showed above, so he can provide details. It's basically is the same component that we're showing in the properties panel, but in the canvas. > Select a data type from the DMN canvas > --------------------------------------- > > Key: DROOLS-2774 > URL: https://issues.jboss.org/browse/DROOLS-2774 > Project: Drools > Issue Type: Story > Components: DMN Editor > Reporter: Liz Clayton > Assignee: Liz Clayton > Labels: UX, UXTeam, drools-tools > Attachments: Screen Shot 2018-08-10 at 10.23.36 AM.png, select.png > > > *Background* > Persona: Business analyst or Rules practitioner > Use Cases: > * From the DMN canvas view - as a user I want to *select* a data type, from a list of available data types, so I can associate it with a DMN node. > * From the DMN canvas view - as a user I want a *means to* add a desired data type to the list of available data types. > * From the DMN canvas view - as a user I want a *means to* edit a desired data type from the list of available data types. > Functional considerations/ pre conditions: > * Actions will be offered or spawned from right dock properties panel. > * Design needs to be consistent with Stunner and PF components. > Verification conditions: > * Scrum team and PO review. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1427) Credential store type PKCS12 works fine when using OracleJDK and OpenJDK but doesn't work using IBM JDK.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1427?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1427: ---------------------------------- Fix Version/s: 1.5.4.CR1 (was: 1.5.3.Final) > Credential store type PKCS12 works fine when using OracleJDK and OpenJDK but doesn't work using IBM JDK. > -------------------------------------------------------------------------------------------------------- > > Key: ELY-1427 > URL: https://issues.jboss.org/browse/ELY-1427 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Reporter: Hynek Švábek > Priority: Critical > Fix For: 1.5.4.CR1 > > > Credential store type PKCS12 works fine when using OracleJDK and OpenJDK. > Problem occurs when we use IBM JDK, add-alias works fine for first time, but for add-alias for second time with same alias name we expect message about duplicity rather than current error message about SecretKeyFactory not availability. > {code} > "WFLYCTL0158: Operation handler failed: java.lang.RuntimeException: WFLYELY00009: Unable to complete operation. 'ELY09504: Cannot acquire a credential from the credential store->Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available->1.2.840.113549.1.7.1 SecretKeyFactory not available'", > {code} > *NOTE* > I met same problem with Oracle JDK 1.8 u66, with u144 is everythink ok. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1425) Add support for JASPIC / JSR-196

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1425?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1425: ---------------------------------- Fix Version/s: 1.5.4.CR1 (was: 1.5.3.Final) > Add support for JASPIC / JSR-196 > -------------------------------- > > Key: ELY-1425 > URL: https://issues.jboss.org/browse/ELY-1425 > Project: WildFly Elytron > Issue Type: Feature Request > Components: EE, HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.5.4.CR1 > > > This is an overall tracking task for changes required to WildFly Elytron to support JASPIC. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1409) Update HTTP authentication mechanism API to support re-use of response handlers

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1409?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1409: ---------------------------------- Fix Version/s: 1.5.4.CR1 (was: 1.5.3.Final) > Update HTTP authentication mechanism API to support re-use of response handlers > ------------------------------------------------------------------------------- > > Key: ELY-1409 > URL: https://issues.jboss.org/browse/ELY-1409 > Project: WildFly Elytron > Issue Type: Task > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.5.4.CR1 > > > At the moment the response handler can only access the response, it can not access anything from the request unless created with access to the request. > Making the scopes available should allow for state to be transferred on the request scope. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1332) NSS tools based PKCS11 provider defined in Elytron doesn't survive server reload

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1332?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1332: ---------------------------------- Fix Version/s: 1.5.4.CR1 (was: 1.5.3.Final) > NSS tools based PKCS11 provider defined in Elytron doesn't survive server reload > -------------------------------------------------------------------------------- > > Key: ELY-1332 > URL: https://issues.jboss.org/browse/ELY-1332 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Josef Cacek > Fix For: 1.5.4.CR1 > > > When a SunPKCS11 provider is defined in Elytron subsystem on the top of NSS keystore (e.g. a FIPS one), then the server reload fails with "ProviderException: Secmod module already configured". > The server.log contains: > {noformat} > 08:12:56,073 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.security.providers.nss: org.jboss.msc.service.StartException in service org.wildfly.security.providers.nss: java.lang.reflect.InvocationTargetException > at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:224) > at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:160) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.reflect.InvocationTargetException > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:190) > ... 7 more > Caused by: java.security.ProviderException: Secmod module already configured > at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:276) > at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:107) > ... 12 more > .. > 08:12:56,140 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("provider-loader" => "nss") > ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.providers.nss" => "java.lang.reflect.InvocationTargetException > Caused by: java.lang.reflect.InvocationTargetException > Caused by: java.security.ProviderException: Secmod module already configured"}} > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-816) Support for masked passwords in client XML config

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-816?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-816: --------------------------------- Fix Version/s: 1.5.4.CR1 (was: 1.5.3.Final) > Support for masked passwords in client XML config > ------------------------------------------------- > > Key: ELY-816 > URL: https://issues.jboss.org/browse/ELY-816 > Project: WildFly Elytron > Issue Type: Task > Reporter: David Lloyd > Assignee: Jan Kalina > Priority: Critical > Fix For: 1.5.4.CR1 > > > We need a way to support masked passwords in the auth configuration file, either as: > * A dedicated masked-password-type XML type > * Adding necessary fields to hashed-password-type > * Adding a modular crypt format > Needs to be supported anywhere passwords are allowed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

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

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-533?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-533: --------------------------------- Fix Version/s: 1.5.4.CR1 (was: 1.5.3.Final) > Deprecate all legacy code > ------------------------- > > Key: ELY-533 > URL: https://issues.jboss.org/browse/ELY-533 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.5.4.CR1 > > > 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.5.0#75005)

7 years, 9 months

1
0
0 / 0

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

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-243?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-243: --------------------------------- Fix Version/s: 1.5.4.CR1 (was: 1.5.3.Final) > Ensure reference to repository is removed from pom > -------------------------------------------------- > > Key: ELY-243 > URL: https://issues.jboss.org/browse/ELY-243 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Darran Lofthouse > Fix For: 1.5.4.CR1 > > > 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.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1597) Identity Restoration where the Principal is not quite enough.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1597?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1597: ---------------------------------- Fix Version/s: 1.5.4.CR1 (was: 1.5.3.Final) > Identity Restoration where the Principal is not quite enough. > ------------------------------------------------------------- > > Key: ELY-1597 > URL: https://issues.jboss.org/browse/ELY-1597 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.5.4.CR1 > > > Presently our authentication process is build around a SecurityRealm being able to create a RealmIdentity which we then convert to an AuthorizationIdentity which is then converted to a SecurityIdentity after applying appropriate SecurityDomain configured mappings. > Generally in a SecurityRealm one of two different methods tend to be used to create the RealmIdentity. > {code:java} > RealmIdentity getRealmIdentity(Principal principal) throws RealmUnavailableException > {code} > or > {code:java} > RealmIdentity getRealmIdentity(Evidence evidence) throws RealmUnavailableException > {code} > Generally from the realms we know about, where the Principal form of the method is used the realm will likely load the attributes that go into the AuthorizationIdentity from another source, however for the form that takes Evidence often the attributes can be derived from the evidence. > Where we persist identities to be restored later such as identity propagation, batch, clustering etc we persist the name of the identity and use it to restore the identity using the Principal form of the above methods. For cases where an identity was originally created using evidence we no longer have sufficient information to recreate the identity. > This Enhancement is to review how we can address this. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1504) Support Elytron specific callbacks with JASPIC ServerAuthenticationModules

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1504?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1504: ---------------------------------- Fix Version/s: 1.5.4.CR1 (was: 1.5.3.Final) > Support Elytron specific callbacks with JASPIC ServerAuthenticationModules > -------------------------------------------------------------------------- > > Key: ELY-1504 > URL: https://issues.jboss.org/browse/ELY-1504 > Project: WildFly Elytron > Issue Type: Feature Request > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.5.4.CR1 > > > JASPIC already supports the use of a CallbackHandler for communication between the ServerAuthenticationModule and the container the first stage of implementation is to support the callbacks mandated by the spec - this task is to follow up and add support for Elytron specific callbacks. > The reason to split this out is we may still want to handle our core lifecycle related callbacks so of the remaining callbacks we will need to decide which ones we want to support. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 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 August 2018