October 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-659) Make all mechanism implementations final

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-659?page=com.atlassian.jira.plugin.sy... ] Jan Kalina reassigned ELY-659: ------------------------------ Assignee: Jan Kalina > Make all mechanism implementations final > ---------------------------------------- > > Key: ELY-659 > URL: https://issues.jboss.org/browse/ELY-659 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Mechanisms, HTTP, SASL > Reporter: David Lloyd > Assignee: Jan Kalina > Priority: Critical > Fix For: 1.2.0.Beta10 > > > It is very important to make all the mechanism implementations final. Relatedly, they should have no protected members. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9361) DwmNeverTestCase assumes clustered invocations will always go to the same node

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-9361?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-9361. ---------------------------------- Fix Version/s: 11.0.0.Final Resolution: Done > DwmNeverTestCase assumes clustered invocations will always go to the same node > ------------------------------------------------------------------------------ > > Key: WFLY-9361 > URL: https://issues.jboss.org/browse/WFLY-9361 > Project: WildFly > Issue Type: Bug > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 11.0.0.Final > > > This test was only passing due to a bug in discovery -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1423) Elytron/Remoting/EJB - Exception from failed authentication differs depending on previous calls

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1423?page=com.atlassian.jira.plugin.s... ] Jan Kalina moved JBEAP-13564 to ELY-1423: ----------------------------------------- Project: WildFly Elytron (was: JBoss Enterprise Application Platform) Key: ELY-1423 (was: JBEAP-13564) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Authentication Client (was: EJB) (was: Remoting) (was: Security) Affects Version/s: 1.2.0.Beta8 (was: 7.1.0.ER2) > Elytron/Remoting/EJB - Exception from failed authentication differs depending on previous calls > ----------------------------------------------------------------------------------------------- > > Key: ELY-1423 > URL: https://issues.jboss.org/browse/ELY-1423 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Affects Versions: 1.2.0.Beta8 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Critical > > Exception presented to a client when EJB authentication fails should be the same for first authentication and subsequent authentications. > I have following scenario: > {noformat} > EJB Client -> EntryBean (server1) -> WhoAmIBean (server2) > {noformat} > the Client provides correct credentials to server 1 and EntryBean makes reauthentication to server2. > When I use wrong credentials for server2 in EntryBean, the call fails with: > {noformat} > org.jboss.ejb.client.RequestSendFailedException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed > {noformat} > When I run the scenario twice and use a correct credentials in EntryBean first and wrong in the second run, then the Exception is different: > {noformat} > org.jboss.ejb.client.RequestSendFailedException: org.wildfly.security.auth.AuthenticationException: JBREM000308: Authentication failed (no mechanisms left) > {noformat} > From a client POV the exception should be the same in every call: > * to allow safer exception handling in client code > * to avoid disclosure shared connection details -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1423) Elytron/Remoting/EJB - Exception from failed authentication differs depending on previous calls

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1423?page=com.atlassian.jira.plugin.s... ] Jan Kalina updated ELY-1423: ---------------------------- Labels: (was: eap72) > Elytron/Remoting/EJB - Exception from failed authentication differs depending on previous calls > ----------------------------------------------------------------------------------------------- > > Key: ELY-1423 > URL: https://issues.jboss.org/browse/ELY-1423 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Affects Versions: 1.2.0.Beta8 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Critical > > Exception presented to a client when EJB authentication fails should be the same for first authentication and subsequent authentications. > I have following scenario: > {noformat} > EJB Client -> EntryBean (server1) -> WhoAmIBean (server2) > {noformat} > the Client provides correct credentials to server 1 and EntryBean makes reauthentication to server2. > When I use wrong credentials for server2 in EntryBean, the call fails with: > {noformat} > org.jboss.ejb.client.RequestSendFailedException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed > {noformat} > When I run the scenario twice and use a correct credentials in EntryBean first and wrong in the second run, then the Exception is different: > {noformat} > org.jboss.ejb.client.RequestSendFailedException: org.wildfly.security.auth.AuthenticationException: JBREM000308: Authentication failed (no mechanisms left) > {noformat} > From a client POV the exception should be the same in every call: > * to allow safer exception handling in client code > * to avoid disclosure shared connection details -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1771) Serialization is triggering rule multiple times

by Christopher Brecht (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1771?page=com.atlassian.jira.plugi... ] Christopher Brecht updated DROOLS-1771: --------------------------------------- Description: I attached a reproducer of the problem. If I am executing the rules without serialization everything is working correctly. You can see the output we expect without serialization. The EventA at 3:00:30 shouldn’t trigger the rule one at time 3:05:00. Using serialization, event/rule triggering seems to ignore the temporal order of timed events. +*WITH SERIALIZATION *+ STATE OUT Fri Jan 01 03:03:00 CET 2010 com.reproducer.EventA@614aeccc[value=1,timestamp=Fri Jan 01 03:02:00 CET 2010] STATE IN Fri Jan 01 03:05:00 CET 2010 com.reproducer.EventA@444548a0[value=0,timestamp=Fri Jan 01 03:00:30 CET 2010] STATE IN Fri Jan 01 03:05:00 CET 2010 com.reproducer.EventA@773c0293[value=0,timestamp=Fri Jan 01 03:04:00 CET 2010] STATE OUT Fri Jan 01 03:07:00 CET 2010 com.reproducer.EventA@319854f0[value=1,timestamp=Fri Jan 01 03:02:00 CET 2010] STATE OUT Fri Jan 01 03:07:00 CET 2010 com.reproducer.EventA@415156bf[value=1,timestamp=Fri Jan 01 03:06:00 CET 2010] +*WITHOUT SERIALIZATION *+ STATE OUT Fri Jan 01 03:03:00 CET 2010 com.reproducer.EventA@659925f4[value=1,timestamp=Fri Jan 01 03:02:00 CET 2010] STATE IN Fri Jan 01 03:05:00 CET 2010 com.reproducer.EventA@562c877a[value=0,timestamp=Fri Jan 01 03:04:00 CET 2010] STATE OUT Fri Jan 01 03:07:00 CET 2010 com.reproducer.EventA@3b569985[value=1,timestamp=Fri Jan 01 03:06:00 CET 2010] was: I attached a reproducer of the problem. If I am executing the rules without serialization everything is working correctly. You can see the output we expect without serialization. The EventA at 3:00:30 shouldn’t trigger the rule one at time 3:05:00. Using serialization, event/rule triggering seems to ignore the temporal order of timed events. +*WITH SERIALIZATION *+ STATE OUT Fri Jan 01 03:03:00 CET 2010 com.reproducer.EventA@614aeccc[value=1,timestamp=Fri Jan 01 03:02:00 CET 2010] STATE IN Fri Jan 01 03:05:00 CET 2010 com.reproducer.EventA@444548a0[value=0,timestamp=Fri Jan 01 03:00:30 CET 2010] STATE IN Fri Jan 01 03:05:00 CET 2010 com.reproducer.EventA@773c0293[value=0,timestamp=Fri Jan 01 03:04:00 CET 2010] STATE OUT Fri Jan 01 03:07:00 CET 2010 com.reproducer.EventA@319854f0[value=1,timestamp=Fri Jan 01 03:02:00 CET 2010] STATE OUT Fri Jan 01 03:07:00 CET 2010 com.reproducer.EventA@415156bf[value=1,timestamp=Fri Jan 01 03:06:00 CET 2010] +*WITHOUT SERIALIZATION *+ 2017-10-20 10:47:04 INFO o.d.c.k.b.impl.KieRepositoryImpl - KieModule was added: MemoryKieModule[releaseId=org.default:artifact:1.0.0-SNAPSHOT] STATE OUT Fri Jan 01 03:03:00 CET 2010 com.reproducer.EventA@659925f4[value=1,timestamp=Fri Jan 01 03:02:00 CET 2010] STATE IN Fri Jan 01 03:05:00 CET 2010 com.reproducer.EventA@562c877a[value=0,timestamp=Fri Jan 01 03:04:00 CET 2010] STATE OUT Fri Jan 01 03:07:00 CET 2010 com.reproducer.EventA@3b569985[value=1,timestamp=Fri Jan 01 03:06:00 CET 2010] > Serialization is triggering rule multiple times > ------------------------------------------------ > > Key: DROOLS-1771 > URL: https://issues.jboss.org/browse/DROOLS-1771 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.2.0.Final, 7.3.0.Final > Reporter: Christopher Brecht > Assignee: Mario Fusco > Attachments: EventA.java, Person.java, Reproducer.java > > > I attached a reproducer of the problem. If I am executing the rules without serialization everything is working correctly. You can see the output we expect without serialization. > The EventA at 3:00:30 shouldn’t trigger the rule one at time 3:05:00. Using serialization, event/rule triggering seems to ignore the temporal order of timed events. > +*WITH SERIALIZATION *+ > STATE OUT Fri Jan 01 03:03:00 CET 2010 com.reproducer.EventA@614aeccc[value=1,timestamp=Fri Jan 01 03:02:00 CET 2010] > STATE IN Fri Jan 01 03:05:00 CET 2010 com.reproducer.EventA@444548a0[value=0,timestamp=Fri Jan 01 03:00:30 CET 2010] > STATE IN Fri Jan 01 03:05:00 CET 2010 com.reproducer.EventA@773c0293[value=0,timestamp=Fri Jan 01 03:04:00 CET 2010] > STATE OUT Fri Jan 01 03:07:00 CET 2010 com.reproducer.EventA@319854f0[value=1,timestamp=Fri Jan 01 03:02:00 CET 2010] > STATE OUT Fri Jan 01 03:07:00 CET 2010 com.reproducer.EventA@415156bf[value=1,timestamp=Fri Jan 01 03:06:00 CET 2010] > +*WITHOUT SERIALIZATION *+ > STATE OUT Fri Jan 01 03:03:00 CET 2010 com.reproducer.EventA@659925f4[value=1,timestamp=Fri Jan 01 03:02:00 CET 2010] > STATE IN Fri Jan 01 03:05:00 CET 2010 com.reproducer.EventA@562c877a[value=0,timestamp=Fri Jan 01 03:04:00 CET 2010] > STATE OUT Fri Jan 01 03:07:00 CET 2010 com.reproducer.EventA@3b569985[value=1,timestamp=Fri Jan 01 03:06:00 CET 2010] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1771) Serialization is triggering rule multiple times

by Christopher Brecht (JIRA)

Christopher Brecht created DROOLS-1771: ------------------------------------------ Summary: Serialization is triggering rule multiple times Key: DROOLS-1771 URL: https://issues.jboss.org/browse/DROOLS-1771 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.3.0.Final, 7.2.0.Final Reporter: Christopher Brecht Assignee: Mario Fusco Attachments: EventA.java, Person.java, Reproducer.java I attached a reproducer of the problem. If I am executing the rules without serialization everything is working correctly. You can see the output we expect without serialization. The EventA at 3:00:30 shouldn’t trigger the rule one at time 3:05:00. Using serialization, event/rule triggering seems to ignore the temporal order of timed events. +*WITH SERIALIZATION *+ STATE OUT Fri Jan 01 03:03:00 CET 2010 com.reproducer.EventA@614aeccc[value=1,timestamp=Fri Jan 01 03:02:00 CET 2010] STATE IN Fri Jan 01 03:05:00 CET 2010 com.reproducer.EventA@444548a0[value=0,timestamp=Fri Jan 01 03:00:30 CET 2010] STATE IN Fri Jan 01 03:05:00 CET 2010 com.reproducer.EventA@773c0293[value=0,timestamp=Fri Jan 01 03:04:00 CET 2010] STATE OUT Fri Jan 01 03:07:00 CET 2010 com.reproducer.EventA@319854f0[value=1,timestamp=Fri Jan 01 03:02:00 CET 2010] STATE OUT Fri Jan 01 03:07:00 CET 2010 com.reproducer.EventA@415156bf[value=1,timestamp=Fri Jan 01 03:06:00 CET 2010] +*WITHOUT SERIALIZATION *+ 2017-10-20 10:47:04 INFO o.d.c.k.b.impl.KieRepositoryImpl - KieModule was added: MemoryKieModule[releaseId=org.default:artifact:1.0.0-SNAPSHOT] STATE OUT Fri Jan 01 03:03:00 CET 2010 com.reproducer.EventA@659925f4[value=1,timestamp=Fri Jan 01 03:02:00 CET 2010] STATE IN Fri Jan 01 03:05:00 CET 2010 com.reproducer.EventA@562c877a[value=0,timestamp=Fri Jan 01 03:04:00 CET 2010] STATE OUT Fri Jan 01 03:07:00 CET 2010 com.reproducer.EventA@3b569985[value=1,timestamp=Fri Jan 01 03:06:00 CET 2010] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1748) Drools workbench datasource on Wildfly domain.

by Walter Medvedeo (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1748?page=com.atlassian.jira.plugi... ] Walter Medvedeo closed DROOLS-1748. ----------------------------------- Missing documentation was properly added and merged into master and 7.4.x branches > Drools workbench datasource on Wildfly domain. > ---------------------------------------------- > > Key: DROOLS-1748 > URL: https://issues.jboss.org/browse/DROOLS-1748 > Project: Drools > Issue Type: Bug > Affects Versions: 7.0.0.Final, 7.3.0.Final > Environment: Drools workbench on Wildfly domain cluster > Reporter: Marijan Cavar > Assignee: Walter Medvedeo > Priority: Critical > > After starting workbench war (version 7.3 and 7.0, both Final) on Wildfly 10.1 domain cluster, got the issues with data source. > [Server:server-one] 13:09:07,908 WARN [org.kie.workbench.common.screens.datasource.management.backend.DataSourceManagementBootstrap] (pool-14-thread-1) Initialize deployments task finished with errors: operation execution failed. :WFLYCTL0030: No resource definition is registered for address [("subsystem" => "datasources")] > Problem does not affect Wildfly standalone configuration, only domain configuration using profiles. > WFLYCTL0030 warning says the syntax problem using jboss-cli.sh. In domain cluster it's used /profile=full-ha/subsystem=datasource/... > In standalone syntax is: /subsystem=datasource/. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9446) mvn idea:idea in parent pom giving error

by sujay hegde (JIRA)

[ https://issues.jboss.org/browse/WFLY-9446?page=com.atlassian.jira.plugin.... ] sujay hegde commented on WFLY-9446: ----------------------------------- Ok Cool! thanks, So you mean one can directly import the Wildfly Project into IntelliJ? > mvn idea:idea in parent pom giving error > ---------------------------------------- > > Key: WFLY-9446 > URL: https://issues.jboss.org/browse/WFLY-9446 > Project: WildFly > Issue Type: Feature Request > Reporter: sujay hegde > Assignee: Jason Greene > > [INFO] WildFly Test Suite: Integration - Smoke ............ SKIPPED > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 04:48 min > [INFO] Finished at: 2017-10-16T18:37:36+05:30 > [INFO] Final Memory: 148M/388M > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-idea-plugin:2.2.1: idea (default-cli) on project wildfly-clustering: Execution default-cli of goal org.apache.maven.plugins:maven-idea-plugin:2.2.1:idea failed.: NullPointerExcept ion -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e swit ch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please rea d the following articles: > [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutio nException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the command > [ERROR] mvn <goals> -rf :wildfly-clustering -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3366) Upgrade JBoss Remoting to 5.0.5.Final

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3366?page=com.atlassian.jira.plugi... ] Jason Greene updated WFCORE-3366: --------------------------------- Fix Version/s: 3.0.7.Final > Upgrade JBoss Remoting to 5.0.5.Final > ------------------------------------- > > Key: WFCORE-3366 > URL: https://issues.jboss.org/browse/WFCORE-3366 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Remoting > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 4.0.0.Alpha1, 3.0.7.Final > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9268) Upgrade Hibernate Search to 5.8.1 with Elasticsearch Support

by Leandro Kersting de Freitas (JIRA)

[ https://issues.jboss.org/browse/WFLY-9268?page=com.atlassian.jira.plugin.... ] Leandro Kersting de Freitas updated WFLY-9268: ---------------------------------------------- Summary: Upgrade Hibernate Search to 5.8.1 with Elasticsearch Support (was: Upgrade Hibernate Search to 5.8.0 with Elasticsearch Support) > Upgrade Hibernate Search to 5.8.1 with Elasticsearch Support > ------------------------------------------------------------ > > Key: WFLY-9268 > URL: https://issues.jboss.org/browse/WFLY-9268 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Leandro Kersting de Freitas > Assignee: Jason Greene > Fix For: 11.0.0.Final > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 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 October 2017