jboss-jira August 2018

jboss-jira@lists.jboss.org

1 participants
3326 discussions

[JBoss JIRA] (WFLY-10630) HttpSessionListener.sessionDestroyed() not called if session invalidated in another WAR

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-10630?page=com.atlassian.jira.plugin... ] Bartosz Baranowski edited comment on WFLY-10630 at 8/1/18 1:30 AM: ------------------------------------------------------------------- [~bkabelka] Yeah, this wont cut it: {quote} HTTP ERROR 405 {quote} {quote} 10:09:28,362 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-1) RESTEASY002010: Failed to execute: javax.ws.rs.NotAllowedException: RESTEASY003650: No resource method found for POST, return 405 with Allow header at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:455) at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:141) {quote} Ive set up domain like: {noformat} <subsystem xmlns="urn:jboss:domain:security:2.0"> <security-domains> .... <security-domain name="sessionlistener"> <authentication> <login-module code="UsersRoles" flag="required"> <module-option name="usersProperties" value="file://${jboss.server.config.dir}/application-users.properties"/> <module-option name="rolesProperties" value="file://${jboss.server.config.dir}/application-roles.properties"/> </login-module> </authentication> </security-domain> </security-domains> </subsystem> {noformat} was (Author: baranowb): [~bkabelka] Yeah, this wont cut it: {quote} HTTP ERROR 405 {quote} {quote} 10:09:28,362 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-1) RESTEASY002010: Failed to execute: javax.ws.rs.NotAllowedException: RESTEASY003650: No resource method found for POST, return 405 with Allow header at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:455) at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:141) {quote} Ive set up domain like: {quote} <subsystem xmlns="urn:jboss:domain:security:2.0"> <security-domains> .... <security-domain name="sessionlistener"> <authentication> <login-module code="UsersRoles" flag="required"> <module-option name="usersProperties" value="file://${jboss.server.config.dir}/application-users.properties"/> <module-option name="rolesProperties" value="file://${jboss.server.config.dir}/application-roles.properties"/> </login-module> </authentication> </security-domain> </security-domains> </subsystem> {quote} > HttpSessionListener.sessionDestroyed() not called if session invalidated in another WAR > --------------------------------------------------------------------------------------- > > Key: WFLY-10630 > URL: https://issues.jboss.org/browse/WFLY-10630 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final, 13.0.0.Final > Environment: Windows 10, Java 1.8.0_131 > Reproducible with both WildFly-10.0.0.Final and Wildfly-13.0.0.Final > Reporter: Bernhard Kabelka > Assignee: Bartosz Baranowski > > For sessions shared across different WARs in a single EAR, the notification of HttpSessionListener works differently in WildFly 10.0.0.Final (and Wildfly 13.0.0.Final) than it it used to work in WildFly 8.2.0.Final: > I have an EAR containing two WARs with enabled session sharing across the WARs. Basically, one WAR contains the web UI, and the other WAR contains the REST interfaces for AJAX calls made by the UI. The user authenticates against the UI-WAR. On logout, a REST method in the AJAX-WAR is triggered which calls HttpSession.invalidate() on the user session. > In WildFly 8.2.0.Final, a HttpSessionListener in the UI-WAR gets notified immediately about session creation and destruction. > In WildFly 13.0.0.Final, however, a HttpSessionListener in either WAR only gets one of the two notifications: > * In the UI-WAR, I get a notification about the created session immediately when the login form is loaded. However, I do not receive any notification about the session destruction (unless it times out). > * In the AJAX-WAR, I do not get any notification about the session creation at all, but I immediately receive a notification about the session destruction. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2814) MVEL uses random parameter type methods for BigDecimal.valueOf(100)

by Toshiya Kobayashi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2814?page=com.atlassian.jira.plugi... ] Toshiya Kobayashi commented on DROOLS-2814: ------------------------------------------- I can understand that the right usage is to use Double or Long explicitly ("100d" or "100L"). But random results don't seem to be good. > MVEL uses random parameter type methods for BigDecimal.valueOf(100) > ------------------------------------------------------------------- > > Key: DROOLS-2814 > URL: https://issues.jboss.org/browse/DROOLS-2814 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.9.0.Final > Environment: - MVEL2 2.4.0.Final > Reporter: Toshiya Kobayashi > Assignee: Mario Fusco > Labels: support > Attachments: BigDecimalMvelTest.zip > > > When MVEL evaluates > {noformat} > java.math.BigDecimal.valueOf(100) > {noformat} > , MVEL determines a method from valueOf(double val) or valueOf(long val). > The result is not consistent. Sometimes uses valueOf(double val), Sometimes uses valueOf(long val). > ParseTools.getMethodScore() gives the same score for double and long. > https://github.com/mvel/mvel/blob/master/src/main/java/org/mvel2/util/Par... > So a selected method will depend on the order of result of "cls.getMethods()". > Reproducer: > $ unzip BigDecimalMvelTest.zip > $ cd BigDecimalMvelTest > $ mvn compile > $ ./loop.sh > It runs the MVEL test 100 times: > {noformat} > $ ./loop.sh > result = 100.0 > result = 100.0 > result = 100.0 > result = 100 > result = 100.0 > result = 100.0 > ... > {noformat} > In my environment, "100.0" is the majority but randomly see "100" as well. (I couldn't reproduce with single run with java for loop) > Expectation is constantly "100" (using valueOf(long val)) because in case of usual Java "java.math.BigDecimal.valueOf(100)", Java compiler chooses valueOf(long val) if the parameter is int. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2814) MVEL uses random parameter type methods for BigDecimal.valueOf(100)

by Toshiya Kobayashi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2814?page=com.atlassian.jira.plugi... ] Toshiya Kobayashi updated DROOLS-2814: -------------------------------------- Attachment: BigDecimalMvelTest.zip > MVEL uses random parameter type methods for BigDecimal.valueOf(100) > ------------------------------------------------------------------- > > Key: DROOLS-2814 > URL: https://issues.jboss.org/browse/DROOLS-2814 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.9.0.Final > Environment: - MVEL2 2.4.0.Final > Reporter: Toshiya Kobayashi > Assignee: Mario Fusco > Labels: support > Attachments: BigDecimalMvelTest.zip > > > When MVEL evaluates > {noformat} > java.math.BigDecimal.valueOf(100) > {noformat} > , MVEL determines a method from valueOf(double val) or valueOf(long val). > The result is not consistent. Sometimes uses valueOf(double val), Sometimes uses valueOf(long val). > ParseTools.getMethodScore() gives the same score for double and long. > https://github.com/mvel/mvel/blob/master/src/main/java/org/mvel2/util/Par... > So a selected method will depend on the order of result of "cls.getMethods()". > Reproducer: > $ unzip BigDecimalMvelTest.zip > $ cd BigDecimalMvelTest > $ mvn compile > $ ./loop.sh > It runs the MVEL test 100 times: > {noformat} > $ ./loop.sh > result = 100.0 > result = 100.0 > result = 100.0 > result = 100 > result = 100.0 > result = 100.0 > ... > {noformat} > In my environment, "100.0" is the majority but randomly see "100" as well. (I couldn't reproduce with single run with java for loop) > Expectation is constantly "100" (using valueOf(long val)) because in case of usual Java "java.math.BigDecimal.valueOf(100)", Java compiler chooses valueOf(long val) if the parameter is int. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2814) MVEL uses random parameter type methods for BigDecimal.valueOf(100)

by Toshiya Kobayashi (JIRA)

Toshiya Kobayashi created DROOLS-2814: ----------------------------------------- Summary: MVEL uses random parameter type methods for BigDecimal.valueOf(100) Key: DROOLS-2814 URL: https://issues.jboss.org/browse/DROOLS-2814 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.9.0.Final Environment: - MVEL2 2.4.0.Final Reporter: Toshiya Kobayashi Assignee: Mario Fusco When MVEL evaluates {noformat} java.math.BigDecimal.valueOf(100) {noformat} , MVEL determines a method from valueOf(double val) or valueOf(long val). The result is not consistent. Sometimes uses valueOf(double val), Sometimes uses valueOf(long val). ParseTools.getMethodScore() gives the same score for double and long. https://github.com/mvel/mvel/blob/master/src/main/java/org/mvel2/util/Par... So a selected method will depend on the order of result of "cls.getMethods()". Reproducer: $ unzip BigDecimalMvelTest.zip $ cd BigDecimalMvelTest $ mvn compile $ ./loop.sh It runs the MVEL test 100 times: {noformat} $ ./loop.sh result = 100.0 result = 100.0 result = 100.0 result = 100 result = 100.0 result = 100.0 ... {noformat} In my environment, "100.0" is the majority but randomly see "100" as well. (I couldn't reproduce with single run with java for loop) Expectation is constantly "100" (using valueOf(long val)) because in case of usual Java "java.math.BigDecimal.valueOf(100)", Java compiler chooses valueOf(long val) if the parameter is int. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2813) DMN boxed invocation missing expression NPE and Validator issue

by Matteo Mortari (JIRA)

Matteo Mortari created DROOLS-2813: -------------------------------------- Summary: DMN boxed invocation missing expression NPE and Validator issue Key: DROOLS-2813 URL: https://issues.jboss.org/browse/DROOLS-2813 Project: Drools Issue Type: Bug Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2812) FEEL Translation number coercion for QualifiedName accessor

by Matteo Mortari (JIRA)

Matteo Mortari created DROOLS-2812: -------------------------------------- Summary: FEEL Translation number coercion for QualifiedName accessor Key: DROOLS-2812 URL: https://issues.jboss.org/browse/DROOLS-2812 Project: Drools Issue Type: Bug Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari The FEEL expression for typically "Person.age" should return a BigDecimal, not an int -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 5 months

1
0
0 / 0

← Newer
1
...
330
331
332
333
Older →

Jump to page:

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