June 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1260) Release WildFly Elytron 1.1.0.Beta54

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1260: ------------------------------------- Summary: Release WildFly Elytron 1.1.0.Beta54 Key: ELY-1260 URL: https://issues.jboss.org/browse/ELY-1260 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta54 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ELY-1186) Elytron - authentication fails when a realm name is not specified for DIGEST-MD5 mechanism on server side

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1186?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse reassigned ELY-1186: ------------------------------------- Assignee: David Lloyd (was: Darran Lofthouse) > Elytron - authentication fails when a realm name is not specified for DIGEST-MD5 mechanism on server side > --------------------------------------------------------------------------------------------------------- > > Key: ELY-1186 > URL: https://issues.jboss.org/browse/ELY-1186 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Josef Cacek > Assignee: David Lloyd > Priority: Blocker > Fix For: 1.1.0.Beta54 > > > When a default configuration is used for DIGEST-MD5 SASL mechanism, then server suggest hostname as a realm name, but authentication fails because ServerAuthenticationContext checks mechanism configuration and fails with following exception: > {code} > @Message(id = 1092, value = "Invalid mechanism realm selection \"%s\"") > IllegalArgumentException invalidMechRealmSelection(String realmName); > {code} > *Suggested fix:* > If the server suggests realm name, then it should be able to consume it. Or if the realm name is really mandatory, then server should not suggest such a default value. IMO allowing such a default and simplifying configuration would have positive impact on user experience. > The full stacktrace (hidden): > {noformat} > javax.security.sasl.SaslException: ELY05053: [DIGEST-MD5] Callback handler failed for unknown reason [Caused by java.lang.IllegalArgumentException: ELY01092: Invalid mechanism realm selection "localhost"] > at org.wildfly.security.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:105) > at org.wildfly.security.sasl.digest.AbstractDigestMechanism.getPredigestedSaltedPassword(AbstractDigestMechanism.java:482) > at org.wildfly.security.sasl.digest.DigestSaslServer.validateDigestResponse(DigestSaslServer.java:259) > at org.wildfly.security.sasl.digest.DigestSaslServer.evaluateMessage(DigestSaslServer.java:355) > at org.wildfly.security.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:180) > at org.wildfly.security.sasl.digest.DigestSaslServer.evaluateResponse(DigestSaslServer.java:328) > at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(AuthenticationCompleteCallbackSaslServerFactory.java:58) > at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(AuthenticationTimeoutSaslServerFactory.java:106) > at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1.evaluateResponse(SecurityIdentitySaslServerFactory.java:57) > at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:245) > at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:217) > at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:470) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:897) > 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.IllegalArgumentException: ELY01092: Invalid mechanism realm selection "localhost" > at org.wildfly.security.auth.server.ServerAuthenticationContext$InitialState.setMechanismRealmName(ServerAuthenticationContext.java:1615) > at org.wildfly.security.auth.server.ServerAuthenticationContext.setMechanismRealmName(ServerAuthenticationContext.java:712) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:927) > at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:735) > at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.lambda$createSaslServer$0(TrustManagerSaslServerFactory.java:96) > at org.wildfly.security.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:101) > ... 15 more > {noformat} > Attached also server configuration and WireShark log. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8985) Missing MariaDB dialect in Infinispan JDBC store

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-8985: ------------------------------------ Summary: Missing MariaDB dialect in Infinispan JDBC store Key: WFLY-8985 URL: https://issues.jboss.org/browse/WFLY-8985 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.1.0.Final Reporter: Radoslav Husar Assignee: Radoslav Husar Fix For: 11.0.0.Beta1 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1624) Map Handling with Property Reactive Always Enabled

by KimJohn Quinn (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1624?page=com.atlassian.jira.plugi... ] KimJohn Quinn commented on DROOLS-1624: --------------------------------------- Here is a test case one of our guys put together that demonstrates the difference between watch and no-watch rules. We tried to cobble it together to be more representative of what we are doing and it is very similar. In our example, the data facts are based off of Guava's ForwardingMap. We extend it to create strong-typed facts that have explicit properties (get/set) but the bulk of our constraining is performed against the map properties. Throughout our rule session we generally are adding to the map from one rule and checking for those properties in another rule. Let me know if this provides any additional insight or if there is something different we should be doing internally. [^drools.zip] > Map Handling with Property Reactive Always Enabled > -------------------------------------------------- > > Key: DROOLS-1624 > URL: https://issues.jboss.org/browse/DROOLS-1624 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.0.0.Final > Environment: * JDK8 > * Docker running Alpine > Reporter: KimJohn Quinn > Assignee: Mario Fusco > Priority: Minor > Attachments: drools.zip > > > Referencing a conversation on [Google Groups - Drools Usage|https://groups.google.com/forum/?fromgroups#!topic/drools-usage/G7r...] and as requested by Mario Fusco... > We currently have a ruleset that relies heavily on Map facts. In Drools 6.5 we fire approximately 400 rules. > In Drools 7.0 we get only about 50 rules unless we add the "<property key="drools.propertySpecific" value="ALLOWED"/>" to the kmodule.xml, in which case we fire the full 400 rules or by using @Watch(*) or @Watch(!*) on the rules. It "seems" like only the first evaluations of the rules are firing and then no others after that. > Our flow generally follows something like below, within a stateful session, using rules only. We fire all rules per-request then close the session. > Watch for changes to the Map properties > If a certain property or properties exist a 'populate' rule fires (calls modify()) > The populate rule enriches the map fact. (calls modify()) > Based on #3, more rules fire when certain properties exist (calls modify()) > We are work heavily with rules that depend on loaded available facts up-front and computed properties throughout evaluation. > I have a couple of usage questions regarding Drools 7, the default enabling of Property Reactive and using Maps as the facts: > In general, how do maps work with property reactive and respond to modify/insert events? Does Drools look at the Map as a whole, any change re-evaluates the tree, or each individual property within the map re-evaluates the change? > In Drools 7, by defaulting the property reactive setting, does that mean all rules need to be annotated or they should they work as is (dao or map-based facts) when using modify/insert? > For reference, we are relying on this doco https://docs.jboss.org/drools/release/7.0.0.Final/drools-docs/html_single.... > I am looking into details or an example how to properly use Maps in Drools 7 with Property Reactive features always enabled (as suggested per the doco).... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1624) Map Handling with Property Reactive Always Enabled

by KimJohn Quinn (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1624?page=com.atlassian.jira.plugi... ] KimJohn Quinn updated DROOLS-1624: ---------------------------------- Attachment: drools.zip > Map Handling with Property Reactive Always Enabled > -------------------------------------------------- > > Key: DROOLS-1624 > URL: https://issues.jboss.org/browse/DROOLS-1624 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.0.0.Final > Environment: * JDK8 > * Docker running Alpine > Reporter: KimJohn Quinn > Assignee: Mario Fusco > Priority: Minor > Attachments: drools.zip > > > Referencing a conversation on [Google Groups - Drools Usage|https://groups.google.com/forum/?fromgroups#!topic/drools-usage/G7r...] and as requested by Mario Fusco... > We currently have a ruleset that relies heavily on Map facts. In Drools 6.5 we fire approximately 400 rules. > In Drools 7.0 we get only about 50 rules unless we add the "<property key="drools.propertySpecific" value="ALLOWED"/>" to the kmodule.xml, in which case we fire the full 400 rules or by using @Watch(*) or @Watch(!*) on the rules. It "seems" like only the first evaluations of the rules are firing and then no others after that. > Our flow generally follows something like below, within a stateful session, using rules only. We fire all rules per-request then close the session. > Watch for changes to the Map properties > If a certain property or properties exist a 'populate' rule fires (calls modify()) > The populate rule enriches the map fact. (calls modify()) > Based on #3, more rules fire when certain properties exist (calls modify()) > We are work heavily with rules that depend on loaded available facts up-front and computed properties throughout evaluation. > I have a couple of usage questions regarding Drools 7, the default enabling of Property Reactive and using Maps as the facts: > In general, how do maps work with property reactive and respond to modify/insert events? Does Drools look at the Map as a whole, any change re-evaluates the tree, or each individual property within the map re-evaluates the change? > In Drools 7, by defaulting the property reactive setting, does that mean all rules need to be annotated or they should they work as is (dao or map-based facts) when using modify/insert? > For reference, we are relying on this doco https://docs.jboss.org/drools/release/7.0.0.Final/drools-docs/html_single.... > I am looking into details or an example how to properly use Maps in Drools 7 with Property Reactive features always enabled (as suggested per the doco).... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1630) DMN support during incremental KieContainer upgrade

by Matteo Mortari (JIRA)

Matteo Mortari created DROOLS-1630: -------------------------------------- Summary: DMN support during incremental KieContainer upgrade Key: DROOLS-1630 URL: https://issues.jboss.org/browse/DROOLS-1630 Project: Drools Issue Type: Feature Request Reporter: Matteo Mortari Assignee: Matteo Mortari -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (JBJCA-1351) NestedWorkAndContextsTestCase#testStartWorkUnsupportedContext fails intermittently on slower machines

by Flavia Rainone (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1351?page=com.atlassian.jira.plugin... ] Flavia Rainone commented on JBJCA-1351: --------------------------------------- Hi [~simkam]! I was thinking maybe using a CountdownLatch? I don't know, I would like to give this a try (my machine is slow, and I can also use the debugger to force the threads to behave the way you descrived) before committing to using a sleep. > NestedWorkAndContextsTestCase#testStartWorkUnsupportedContext fails intermittently on slower machines > ----------------------------------------------------------------------------------------------------- > > Key: JBJCA-1351 > URL: https://issues.jboss.org/browse/JBJCA-1351 > Project: IronJacamar > Issue Type: Bug > Components: Test suite > Reporter: Martin Simka > Assignee: Martin Simka > > [NestedWorkAndContextsTestCase#testStartWorkUnsupportedContext|https://git...] fails intermittently on slower machines because nested work is started before test itself invokes barrier.await and therefore execution of second work isn't stopped. > Expected order of threads is: > test -- disabled until workA invokes barrier.await()) > workA > workB (nested work) -- disabled > But sometimes it is: > workA > workB throws Exception > I'm not sure how to fix this correctly but simplest solution seems to be adding Thread.sleep to Work -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1629) PersisteHelper and ObjectMarshallingStrategyStore are mixing ObjectMarshallingStrategies

by Manuel Castro (JIRA)

Manuel Castro created DROOLS-1629: ------------------------------------- Summary: PersisteHelper and ObjectMarshallingStrategyStore are mixing ObjectMarshallingStrategies Key: DROOLS-1629 URL: https://issues.jboss.org/browse/DROOLS-1629 Project: Drools Issue Type: Bug Components: core engine, kie server Affects Versions: 6.5.0.Final, 6.4.0.Final Reporter: Manuel Castro Assignee: Mario Fusco We are defining our custom JPAPlaceHolderResolverStrategy, parametrizing the constructuctor with the persistence unit name it handles. When we need two of them to handle different kind of Entities probably from different DataSources, the marshalling process works properly as calling to accept method before marshalling returns true for the correct ObjectMarshallingStrategy. The problem occurs while unmarshalling the entities. As the class name is being used to find the correct ObjectMarshallingStrategy from the store, the class name matches two Object Marshalling Strategies, so the first one found is returned, making the environment work in a random space. This problem could be solved adding to ObjectMarshallingStrategy interface a getName() method in order to be able to avoid the usage of the getClass().getName() approach is being used now. Then PersisteHelper must use this method to store the ProtobufferHeader and then ObjectMarshallingStrategyStore must use the method to retrieve the appropiate implementation. In order to enable backward compatibility a NamedObjectMarshallingStrategyInterface could be added to be invoked only for updated implementors. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8984) Fix tests which currently fail with -Dwildfly.tmp.enable.elytron.profile.tests

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-8984?page=com.atlassian.jira.plugin.... ] Jan Kalina moved JBEAP-11752 to WFLY-8984: ------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8984 (was: JBEAP-11752) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) > Fix tests which currently fail with -Dwildfly.tmp.enable.elytron.profile.tests > ------------------------------------------------------------------------------- > > Key: WFLY-8984 > URL: https://issues.jboss.org/browse/WFLY-8984 > Project: WildFly > Issue Type: Task > Components: Security > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > > Several tests fail with -Dwildfly.tmp.enable.elytron.profile.tests=true and -Delytron as seen in > https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterElytron > Having a cursory glance at the build log there also appears to be some tests taking about 10 minutes before failing -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2882) Review & fix xml persistence of elytron subsystem

by Rostislav Svoboda (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2882?page=com.atlassian.jira.plugi... ] Rostislav Svoboda commented on WFCORE-2882: ------------------------------------------- https://github.com/wildfly/wildfly-core/blob/master/elytron/src/main/java... only one iteration happens, this could be simplified / fixed > Review & fix xml persistence of elytron subsystem > ------------------------------------------------- > > Key: WFCORE-2882 > URL: https://issues.jboss.org/browse/WFCORE-2882 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 3.0.0.Beta27 > > > Elytron subsystem uses a mess of parsers and duplicate code in them. > Go trough all parsers and unify attribute persistence with rest of the server. > also get rid as much of custom parser code as possible. > Update XSDs where appropriate to follow common model. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

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 June 2017