March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-670) Generalize inline casts to work with traits

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-670?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer updated DROOLS-670: ------------------------------------------ Fix Version/s: 7.0.0.Beta8 (was: 7.0.0.Beta7) > Generalize inline casts to work with traits > ------------------------------------------- > > Key: DROOLS-670 > URL: https://issues.jboss.org/browse/DROOLS-670 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.2.0.CR3 > Reporter: Davide Sottara > Assignee: Davide Sottara > Fix For: 7.0.0.Beta8 > > > The following constraint > {code} > Person( this#Worker( wage > 1000 ) ) > {code} > is admissible when Worker is a subtype of Person. > It should also be possible to use "#" when Worker is a donned trait. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-669) Create "behavesAs" operator to support traiting

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-669?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer updated DROOLS-669: ------------------------------------------ Fix Version/s: 7.0.0.Beta8 (was: 7.0.0.Beta7) > Create "behavesAs" operator to support traiting > ----------------------------------------------- > > Key: DROOLS-669 > URL: https://issues.jboss.org/browse/DROOLS-669 > Project: Drools > Issue Type: Feature Request > Affects Versions: 6.2.0.CR3 > Reporter: Davide Sottara > Assignee: Davide Sottara > Fix For: 7.0.0.Beta8 > > > Define an operator that would check if an object can provide *natively* all the methods required by an interface. This would ensure that, upon donning the interface as a trait, no soft field would be required, and that all methods in the interface would have a concrete implementation. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1419) Make interface AccumulateFunction<S extends Serializable> to avoid downcasting verbosity in implementations

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1419?page=com.atlassian.jira.plugi... ] Michael Biarnes Kiefer updated DROOLS-1419: ------------------------------------------- Fix Version/s: 7.0.0.Beta8 (was: 7.0.0.Beta7) > Make interface AccumulateFunction<S extends Serializable> to avoid downcasting verbosity in implementations > ----------------------------------------------------------------------------------------------------------- > > Key: DROOLS-1419 > URL: https://issues.jboss.org/browse/DROOLS-1419 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 6.5.0.Final > Reporter: Geoffrey De Smet > Assignee: Geoffrey De Smet > Priority: Minor > Fix For: 7.0.0.Beta8 > > > Fix will NOT break backwards compatibility. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2011) Inconsistency of formatter and named-formatter in console logging handler

by ted won (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2011?page=com.atlassian.jira.plugi... ] ted won updated WFCORE-2011: ---------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2001, https://github.com/wildfly/wildfly/pull/9745 (was: https://github.com/wildfly/wildfly-core/pull/2001) > Inconsistency of formatter and named-formatter in console logging handler > ------------------------------------------------------------------------- > > Key: WFCORE-2011 > URL: https://issues.jboss.org/browse/WFCORE-2011 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 3.0.0.Alpha13 > Environment: It is possible to reproduce with all profiles and all modes. > All WildFly profiles > All WildFly clustering mode > * standalone mode > * domain mode > Reporter: ted won > Assignee: ted won > Priority: Minor > Labels: logging > Attachments: COLOR-PATTERN.png, CONSOLE-console-handler.png > > > In logging subsystem the default CONSOLE console-handler is defined with COLOR-PATTERN named-formatter. > And the COLOR-PATTERN named-formatter is defined with: {noformat}"%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat} > It is working as it is defined with colors in a console. > {code:title=standalone.xml} > ... > <subsystem xmlns="urn:jboss:domain:logging:3.0"> > <console-handler name="CONSOLE"> > <level name="INFO"/> > <formatter> > <named-formatter name="COLOR-PATTERN"/> > </formatter> > </console-handler> > ... > <formatter name="COLOR-PATTERN"> > <pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/> > </formatter> > </subsystem> > ... > {code} > However there is a inconsistency in the CLI and WildFly admin console views. > In the CLI, CONSOLE formatter is: {noformat}"%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat} It is wrong and different with the working logging format in a console. > {code:title=JBoss CLI} > [standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource > { > "outcome" => "success", > "result" => { > "autoflush" => true, > "enabled" => true, > "encoding" => undefined, > "filter" => undefined, > "filter-spec" => undefined, > "formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n", > "level" => "INFO", > "name" => "CONSOLE", > "named-formatter" => "COLOR-PATTERN", > "target" => "System.out" > } > } > {code} > It should be fixed like below: > {code:title=Expected result} > [standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource > { > "outcome" => "success", > "result" => { > "autoflush" => true, > "enabled" => true, > "encoding" => undefined, > "filter" => undefined, > "filter-spec" => undefined, > "formatter" => undefined, > "level" => "INFO", > "name" => "CONSOLE", > "named-formatter" => "COLOR-PATTERN", > "target" => "System.out" > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8294) credential-reference must have defined combinations of constraints

by Michal Petrov (JIRA)

[ https://issues.jboss.org/browse/WFLY-8294?page=com.atlassian.jira.plugin.... ] Michal Petrov commented on WFLY-8294: ------------------------------------- FYI, nested attributes are currently not validated for constraints - WFCORE-2317. > credential-reference must have defined combinations of constraints > ------------------------------------------------------------------ > > Key: WFLY-8294 > URL: https://issues.jboss.org/browse/WFLY-8294 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Darran Lofthouse > > credential-reference must have defined these combinations of constraints: > requires constraint: > alias "requires" [store], > store "requires" [alias] > alternatives constraint: > clear-text "alternatives" [store] > store "alternatives" [clear-text] > optional: type -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8296) CredentialStore, set own security provider through java security config file leads to NoClassDefFoundError for custom implementation class

by Hynek Švábek (JIRA)

Hynek Švábek created WFLY-8296: ---------------------------------- Summary: CredentialStore, set own security provider through java security config file leads to NoClassDefFoundError for custom implementation class Key: WFLY-8296 URL: https://issues.jboss.org/browse/WFLY-8296 Project: WildFly Issue Type: Bug Components: Security Reporter: Hynek Švábek Assignee: Darran Lofthouse When I want to define own Custom Elytron Provider through modification of Java security provider configuration I got exception about NoClassDefFoundError on CustomImplementation class. But this class is located in same jar file as Custom Elytron Provider. I need it to define provider-name in credential-store. Is there some additional step which I missed? Jar file is attached and it is same one as here https://issues.jboss.org/browse/JBEAP-8238 from [~pskopek] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8293) Changing Elytron default-authentication-context ends in reload-required state

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-8293?page=com.atlassian.jira.plugin.... ] Martin Choma updated WFLY-8293: ------------------------------- Summary: Changing Elytron default-authentication-context ends in reload-required state (was: Changing Elytron default-authentication-context with allow-resource-service-restart ends in reload-required state) > Changing Elytron default-authentication-context ends in reload-required state > ----------------------------------------------------------------------------- > > Key: WFLY-8293 > URL: https://issues.jboss.org/browse/WFLY-8293 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > If I try to change Elytron default-authentication-context server ends in reload-required state. > {code} > /subsystem=elytron/authentication-context=auth-context:add() > /subsystem=elytron:write-attribute(name=default-authentication-context,value=auth-context) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > {code} > However attribute {{default-authentication-context}} is marked as {{"restart-required" => "no-services"}} in model > {code} > /subsystem=elytron:read-resource-description(recursive=false) > { > ... > "default-authentication-context" => { > "type" => STRING, > "description" => "The default authentication context to be associated with all deployments.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "capability-reference" => "org.wildfly.security.authentication-context", > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > ... > } > {code} > According to documentation [1] if attribute is marked as {{"restart-required" => "no-services"}} no restart of service is necessary > no-services – Applying the operation to the runtime does not require the restart of any services. This value is the default if the restart-required descriptor is not present. > [1] https://docs.jboss.org/author/display/WFLY10/Description+of+the+Managemen... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8293) Changing Elytron default-authentication-context with allow-resource-service-restart ends in reload-required state

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-8293?page=com.atlassian.jira.plugin.... ] Martin Choma updated WFLY-8293: ------------------------------- Description: If I try to change Elytron default-authentication-context server ends in reload-required state. {code} /subsystem=elytron/authentication-context=auth-context:add() /subsystem=elytron:write-attribute(name=default-authentication-context,value=auth-context) { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } } {code} However attribute {{default-authentication-context}} is marked as {{"restart-required" => "no-services"}} in model {code} /subsystem=elytron:read-resource-description(recursive=false) { ... "default-authentication-context" => { "type" => STRING, "description" => "The default authentication context to be associated with all deployments.", "expressions-allowed" => false, "required" => false, "nillable" => true, "capability-reference" => "org.wildfly.security.authentication-context", "min-length" => 1L, "max-length" => 2147483647L, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "no-services" }, ... } {code} According to documentation [1] if attribute is marked as {{"restart-required" => "no-services"}} no restart of service is necessary no-services – Applying the operation to the runtime does not require the restart of any services. This value is the default if the restart-required descriptor is not present. [1] https://docs.jboss.org/author/display/WFLY10/Description+of+the+Managemen... was: If I try to change Elytron default-authentication-context with header {{allow-resource-service-restart=true}} server ends in reload-required state. {code} /subsystem=elytron/authentication-context=auth-context:add() /subsystem=elytron:write-attribute(name=default-authentication-context,value=auth-context){allow-resource-service-restart=true} { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } } {code} Using header allow-resource-service-restart=true should restart necessary services. It seems it is caused by {{"restart-required" => "no-services"}} for {{default-authentication-context}} attribute of Elytron subsystem. See: {code} /subsystem=elytron:read-resource-description(recursive=false) { ... "default-authentication-context" => { "type" => STRING, "description" => "The default authentication context to be associated with all deployments.", "expressions-allowed" => false, "required" => false, "nillable" => true, "capability-reference" => "org.wildfly.security.authentication-context", "min-length" => 1L, "max-length" => 2147483647L, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "no-services" }, ... } {code} > Changing Elytron default-authentication-context with allow-resource-service-restart ends in reload-required state > ----------------------------------------------------------------------------------------------------------------- > > Key: WFLY-8293 > URL: https://issues.jboss.org/browse/WFLY-8293 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > If I try to change Elytron default-authentication-context server ends in reload-required state. > {code} > /subsystem=elytron/authentication-context=auth-context:add() > /subsystem=elytron:write-attribute(name=default-authentication-context,value=auth-context) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > {code} > However attribute {{default-authentication-context}} is marked as {{"restart-required" => "no-services"}} in model > {code} > /subsystem=elytron:read-resource-description(recursive=false) > { > ... > "default-authentication-context" => { > "type" => STRING, > "description" => "The default authentication context to be associated with all deployments.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "capability-reference" => "org.wildfly.security.authentication-context", > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > ... > } > {code} > According to documentation [1] if attribute is marked as {{"restart-required" => "no-services"}} no restart of service is necessary > no-services – Applying the operation to the runtime does not require the restart of any services. This value is the default if the restart-required descriptor is not present. > [1] https://docs.jboss.org/author/display/WFLY10/Description+of+the+Managemen... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8295) Elytron, Unable to authenticate with SPNEGO on IBM java if obtain-kerberos-ticket = true

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-8295?page=com.atlassian.jira.plugin.... ] Martin Choma updated WFLY-8295: ------------------------------- Steps to Reproduce: * On IBM java * Follow https://docs.jboss.org/author/display/WFLY/WildFly+Elytron+Security#WildF... * During adding kerberos-security-factory add obtain-kerberos-ticket = true option {code} /subsystem=elytron/kerberos-security-factory=krbSF:add( \ principal="HTTP/host@REALM", \ path="/path/to/http.keytab", \ obtain-kerberos-ticket="true", \ mechanism-oids=[ \ 1.2.840.113554.1.2.2, \ 1.3.6.1.5.5.2 \ ] \ ) {code} was: * On IBM java * Follow https://doc-stage.usersys.redhat.com/documentation/en-us/red_hat_jboss_en... * In step 2.4.1.1 during adding kerberos-security-factory add obtain-kerberos-ticket = true option {code} /subsystem=elytron/kerberos-security-factory=krbSF:add( \ principal="HTTP/host@REALM", \ path="/path/to/http.keytab", \ obtain-kerberos-ticket="true", \ mechanism-oids=[ \ 1.2.840.113554.1.2.2, \ 1.3.6.1.5.5.2 \ ] \ ) {code} > Elytron, Unable to authenticate with SPNEGO on IBM java if obtain-kerberos-ticket = true > ---------------------------------------------------------------------------------------- > > Key: WFLY-8295 > URL: https://issues.jboss.org/browse/WFLY-8295 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Labels: ibm-java, kerberos > > On IBM java when obtain-kerberos-ticket is set to true user always get > {code} > javax.security.auth.login.LoginException: Bad JAAS configuration: credsType and keytab values are not compatible > {code} > According to ibm documentation [1] credsType=initiator and useKeytab are really incompatible. > This constraint can't be avoided once obtain-kerberos-ticket = true, because keytab path is required in model. > {code} > "path" => { > "type" => STRING, > "description" => "The path of the KeyTab to load to obtain the credential.", > "attribute-group" => "file", > "expressions-allowed" => true, > "required" => true, > "nillable" => false, > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {code} > And keytab is always set into Kerberos login module options > {code:title=GSSCredentialSecurityFactory.java} > if (IS_IBM) { > options.put("noAddress", "true"); > options.put("credsType", (isServer && !obtainKerberosTicket) ? "acceptor" : "initiator"); > options.put("useKeytab", keyTab.toURI().toURL().toString()); > } > {code} > [1] https://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.sec... > I am not setting to blocker just because I am not sure about importance of obtain-kerberos-ticket. See my question JBEAP-9292. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8295) Elytron, Unable to authenticate with SPNEGO on IBM java if obtain-kerberos-ticket = true

by Martin Choma (JIRA)

Martin Choma created WFLY-8295: ---------------------------------- Summary: Elytron, Unable to authenticate with SPNEGO on IBM java if obtain-kerberos-ticket = true Key: WFLY-8295 URL: https://issues.jboss.org/browse/WFLY-8295 Project: WildFly Issue Type: Bug Components: Security Reporter: Martin Choma Assignee: Darran Lofthouse Priority: Critical On IBM java when obtain-kerberos-ticket is set to true user always get {code} javax.security.auth.login.LoginException: Bad JAAS configuration: credsType and keytab values are not compatible {code} According to ibm documentation [1] credsType=initiator and useKeytab are really incompatible. This constraint can't be avoided once obtain-kerberos-ticket = true, because keytab path is required in model. {code} "path" => { "type" => STRING, "description" => "The path of the KeyTab to load to obtain the credential.", "attribute-group" => "file", "expressions-allowed" => true, "required" => true, "nillable" => false, "min-length" => 1L, "max-length" => 2147483647L, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "resource-services" }, {code} And keytab is always set into Kerberos login module options {code:title=GSSCredentialSecurityFactory.java} if (IS_IBM) { options.put("noAddress", "true"); options.put("credsType", (isServer && !obtainKerberosTicket) ? "acceptor" : "initiator"); options.put("useKeytab", keyTab.toURI().toURL().toString()); } {code} [1] https://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.sec... I am not setting to blocker just because I am not sure about importance of obtain-kerberos-ticket. See my question JBEAP-9292. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 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 March 2017