October 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AG-95) ResultSet.close() isn't called directly

by Luis Barreiro (Jira)

[ https://issues.jboss.org/browse/AG-95?page=com.atlassian.jira.plugin.syst... ] Luis Barreiro resolved AG-95. ----------------------------- Fix Version/s: 1.2 Resolution: Done > ResultSet.close() isn't called directly > --------------------------------------- > > Key: AG-95 > URL: https://issues.jboss.org/browse/AG-95 > Project: Agroal > Issue Type: Bug > Components: pool > Affects Versions: 1.1 > Reporter: Jesper Pedersen > Assignee: Luis Barreiro > Priority: Critical > Fix For: 1.2 > > > When you call ResultSet.close() the underlying close() method isn't called until the statement tracker takes care of it -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11151) Wildfly 14 mixes up HTML response in JSF applications

by Tamás Ábele (Jira)

[ https://issues.jboss.org/browse/WFLY-11151?page=com.atlassian.jira.plugin... ] Tamás Ábele updated WFLY-11151: ------------------------------- Steps to Reproduce: Mentioned on github in the two cases (was: Mentioned on github) > Wildfly 14 mixes up HTML response in JSF applications > ----------------------------------------------------- > > Key: WFLY-11151 > URL: https://issues.jboss.org/browse/WFLY-11151 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 14.0.0.Final > Reporter: Tamás Ábele > Assignee: Jason Greene > Priority: Major > > Introduced in wildfly 14 we receive a new JSF implementation (developed years ago), which is based on mojarra 2.3.5. In certain circumstances this JSF runtime hides the real problem, and makes from an invalid HTML a valid one, and spoils it somewhere else you would never guess, or produces an invalid partial response. Anything can happen. This way the JSF runtime makes it really hard to find the real problem. This behavior led to a more severe error than the original one in two reported cases at github. > I opened an issue ([eclipse-ee4j/mojarra#4488|https://github.com/eclipse-ee4j/mojarra/issues/...]) about this, but the mojarra development team closed this issue without solving it, despite the fact how vulnerable JSF become to component rendering problems. Now a lot of teams starting to move towards wildfly 14. They are likely to face similar magical errors like us. In the other case ([jboss/mojarra#21|https://github.com/jboss/mojarra/issues/21]) the developer team switched back to JSF 2.2. I’m also worried to change to wildfly 14, because of the future magical errors it will cause in our systems. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11151) Wildfly 14 mixes up HTML response in JSF applications

by Tamás Ábele (Jira)

[ https://issues.jboss.org/browse/WFLY-11151?page=com.atlassian.jira.plugin... ] Tamás Ábele updated WFLY-11151: ------------------------------- Description: Introduced in wildfly 14 we receive a new JSF implementation (developed years ago), which is based on mojarra 2.3.5. In certain circumstances this JSF runtime hides the real problem, and makes from an invalid HTML a valid one, and spoils it somewhere else you would never guess, or produces an invalid partial response. Anything can happen. This way the JSF runtime makes it really hard to find the real problem. This behavior led to a more severe error than the original one in two reported cases at github. I opened an issue ([eclipse-ee4j/mojarra#4488|https://github.com/eclipse-ee4j/mojarra/issues/...]) about this, but the mojarra development team closed this issue without solving it, despite the fact how vulnerable JSF become to component rendering problems. Now a lot of teams starting to move towards wildfly 14. They are likely to face similar magical errors like us. In the other case ([jboss/mojarra#21|https://github.com/jboss/mojarra/issues/21]) the developer team switched back to JSF 2.2. I’m also worried to change to wildfly 14, because of the future magical errors it will cause in our systems. was: Introduced in wildfly 14 we receive a new JSF implementation (developed years ago), which is based on mojarra 2.3.5. In certain circumstances this JSF runtime hides the real problem, and makes from an invalid HTML a valid one, and spoils it somewhere else you would never guess, or produces an invalid partial response. Anything can happen. This way the JSF runtime makes it really hard to find the real problem. This behavior led to a more severe error than the original one in two reported cases at github. I opened an issue ([eclipse-ee4j/mojarra#4488|https://github.com/eclipse-ee4j/mojarra/issues/...]) but the mojarra development team closed this issue without solving it, despite the fact how vulnerable JSF become to component rendering problems. Now a lot of teams starting to move towards wildfly 14. They are likely to face similar magical errors like us. In the other case ([jboss/mojarra#21|https://github.com/jboss/mojarra/issues/21]) the developer team switched back to JSF 2.2. I’m also worried to change to wildfly 14, because of the future magical errors it will cause in our systems. > Wildfly 14 mixes up HTML response in JSF applications > ----------------------------------------------------- > > Key: WFLY-11151 > URL: https://issues.jboss.org/browse/WFLY-11151 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 14.0.0.Final > Reporter: Tamás Ábele > Assignee: Jason Greene > Priority: Major > > Introduced in wildfly 14 we receive a new JSF implementation (developed years ago), which is based on mojarra 2.3.5. In certain circumstances this JSF runtime hides the real problem, and makes from an invalid HTML a valid one, and spoils it somewhere else you would never guess, or produces an invalid partial response. Anything can happen. This way the JSF runtime makes it really hard to find the real problem. This behavior led to a more severe error than the original one in two reported cases at github. > I opened an issue ([eclipse-ee4j/mojarra#4488|https://github.com/eclipse-ee4j/mojarra/issues/...]) about this, but the mojarra development team closed this issue without solving it, despite the fact how vulnerable JSF become to component rendering problems. Now a lot of teams starting to move towards wildfly 14. They are likely to face similar magical errors like us. In the other case ([jboss/mojarra#21|https://github.com/jboss/mojarra/issues/21]) the developer team switched back to JSF 2.2. I’m also worried to change to wildfly 14, because of the future magical errors it will cause in our systems. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11151) Wildfly 14 mixes up HTML response in JSF applications

by Tamás Ábele (Jira)

[ https://issues.jboss.org/browse/WFLY-11151?page=com.atlassian.jira.plugin... ] Tamás Ábele updated WFLY-11151: ------------------------------- Description: Introduced in wildfly 14 we receive a new JSF implementation (developed years ago), which is based on mojarra 2.3.5. In certain circumstances this JSF runtime hides the real problem, and makes from an invalid HTML a valid one, and spoils it somewhere else you would never guess, or produces an invalid partial response. Anything can happen. This way the JSF runtime makes it really hard to find the real problem. This behavior led to a more severe error than the original one in two reported cases at github. I opened an issue ([eclipse-ee4j/mojarra#4488|https://github.com/eclipse-ee4j/mojarra/issues/...]) but the mojarra development team closed this issue without solving it, despite the fact how vulnerable JSF become to component rendering problems. Now a lot of teams starting to move towards wildfly 14. They are likely to face similar magical errors like us. In the other case ([jboss/mojarra#21|https://github.com/jboss/mojarra/issues/21]) the developer team switched back to JSF 2.2. I’m also worried to change to wildfly 14, because of the future magical errors it will cause in our systems. was: Introduced in wildfly 14 we receive a new JSF implementation (developed years ago), JSF 2.3.5 which is based on mojarra. In certain circumstances this JSF runtime hides the real problem, and makes from an invalid HTML a valid one, and spoils it somewhere else you would never guess, or produces an invalid partial response. Anything can happen. This way the JSF runtime makes it really hard to find the real problem. This behavior led to a more severe error than the original one in two reported cases at github. I opened an issue ([eclipse-ee4j/mojarra#4488|https://github.com/eclipse-ee4j/mojarra/issues/...]) but the mojarra development team closed this issue without solving it, despite the fact how vulnerable JSF become to component rendering problems. Now a lot of teams starting to move towards wildfly 14. They are likely to face similar magical errors like us. In the other case ([jboss/mojarra#21|https://github.com/jboss/mojarra/issues/21]) the developer team switched back to JSF 2.2. I’m also worried to change to wildfly 14, because of the future magical errors it will cause in our systems. > Wildfly 14 mixes up HTML response in JSF applications > ----------------------------------------------------- > > Key: WFLY-11151 > URL: https://issues.jboss.org/browse/WFLY-11151 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 14.0.0.Final > Reporter: Tamás Ábele > Assignee: Jason Greene > Priority: Major > > Introduced in wildfly 14 we receive a new JSF implementation (developed years ago), which is based on mojarra 2.3.5. In certain circumstances this JSF runtime hides the real problem, and makes from an invalid HTML a valid one, and spoils it somewhere else you would never guess, or produces an invalid partial response. Anything can happen. This way the JSF runtime makes it really hard to find the real problem. This behavior led to a more severe error than the original one in two reported cases at github. > I opened an issue ([eclipse-ee4j/mojarra#4488|https://github.com/eclipse-ee4j/mojarra/issues/...]) but the mojarra development team closed this issue without solving it, despite the fact how vulnerable JSF become to component rendering problems. Now a lot of teams starting to move towards wildfly 14. They are likely to face similar magical errors like us. In the other case ([jboss/mojarra#21|https://github.com/jboss/mojarra/issues/21]) the developer team switched back to JSF 2.2. I’m also worried to change to wildfly 14, because of the future magical errors it will cause in our systems. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11153) Upgrade RESTEasy to 3.6.1.SP1

by Alessio Soldano (Jira)

Alessio Soldano created WFLY-11153: -------------------------------------- Summary: Upgrade RESTEasy to 3.6.1.SP1 Key: WFLY-11153 URL: https://issues.jboss.org/browse/WFLY-11153 Project: WildFly Issue Type: Component Upgrade Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: 15.0.0.Alpha1 Upgrade RESTEasy to 3.6.1.Final for better JDK11 compatibility. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11152) Upgrade JBossWS to 5.2.4.Final

by Alessio Soldano (Jira)

Alessio Soldano created WFLY-11152: -------------------------------------- Summary: Upgrade JBossWS to 5.2.4.Final Key: WFLY-11152 URL: https://issues.jboss.org/browse/WFLY-11152 Project: WildFly Issue Type: Component Upgrade Components: Web Services Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: 15.0.0.Alpha1 Upgrade JBossWS to 5.2.4.Final (including all sub-components), for better JDK11 compatibilty. This also includes upgrade Apache CXF to 3.2.6 version. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11151) Wildfly 14 mixes up HTML response in JSF applications

by Tamás Ábele (Jira)

[ https://issues.jboss.org/browse/WFLY-11151?page=com.atlassian.jira.plugin... ] Tamás Ábele updated WFLY-11151: ------------------------------- Component/s: JSF > Wildfly 14 mixes up HTML response in JSF applications > ----------------------------------------------------- > > Key: WFLY-11151 > URL: https://issues.jboss.org/browse/WFLY-11151 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 14.0.0.Final > Reporter: Tamás Ábele > Assignee: Jason Greene > Priority: Major > > Introduced in wildfly 14 we receive a new JSF implementation (developed years ago), JSF 2.3.5 which is based on mojarra. In certain circumstances this JSF runtime hides the real problem, and makes from an invalid HTML a valid one, and spoils it somewhere else you would never guess, or produces an invalid partial response. Anything can happen. This way the JSF runtime makes it really hard to find the real problem. This behavior led to a more severe error than the original one in two reported cases at github. > I opened an issue ([eclipse-ee4j/mojarra#4488|https://github.com/eclipse-ee4j/mojarra/issues/...]) but the mojarra development team closed this issue without solving it, despite the fact how vulnerable JSF become to component rendering problems. Now a lot of teams starting to move towards wildfly 14. They are likely to face similar magical errors like us. In the other case ([jboss/mojarra#21|https://github.com/jboss/mojarra/issues/21]) the developer team switched back to JSF 2.2. I’m also worried to change to wildfly 14, because of the future magical errors it will cause in our systems. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11113) Update to JAXB 2.3.1

by Alessio Soldano (Jira)

[ https://issues.jboss.org/browse/WFLY-11113?page=com.atlassian.jira.plugin... ] Alessio Soldano updated WFLY-11113: ----------------------------------- Fix Version/s: 15.0.0.Alpha1 > Update to JAXB 2.3.1 > -------------------- > > Key: WFLY-11113 > URL: https://issues.jboss.org/browse/WFLY-11113 > Project: WildFly > Issue Type: Component Upgrade > Components: REST, Web Services > Affects Versions: 14.0.0.Final > Reporter: Jan Blizňák > Assignee: Alessio Soldano > Priority: Major > Labels: Java11 > Fix For: 15.0.0.Alpha1 > > > The new release of JAXB should fix some issues with JDK11 (such as warnings WFLY-11044) > Full diff https://github.com/javaee/jaxb-v2/compare/2.3.0...2.3.1 > Note: this release no longer contains jaxb-core artifact which was merged into jaxb-runtime https://github.com/javaee/jaxb-v2/commit/32fda2fbee71c2df04c52fc8eb368769... > Note2: there is a change in dependencies, some of the org.glassfish.jaxb:* artifacts used to depend on relaxngDatatype:relaxngDatatype (which is excluded in WF \[1\],\[2\],\[3\]), now replaced with com.sun.xml.bind.external:relaxng-datatype. WF is using com.github.relaxng:relaxngDatatype instead, not sure, if it is compatible out of the box. > \[1\] https://github.com/wildfly/wildfly/blob/master/pom.xml#L1293-L1298 > \[2\] https://github.com/wildfly/wildfly/blob/master/pom.xml#L3848-L3853 > \[3\] https://github.com/wildfly/wildfly/blob/master/pom.xml#L6728 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11151) Wildfly 14 mixes up HTML response in JSF applications

by Tamás Ábele (Jira)

[ https://issues.jboss.org/browse/WFLY-11151?page=com.atlassian.jira.plugin... ] Tamás Ábele updated WFLY-11151: ------------------------------- Affects Version/s: 14.0.0.Final > Wildfly 14 mixes up HTML response in JSF applications > ----------------------------------------------------- > > Key: WFLY-11151 > URL: https://issues.jboss.org/browse/WFLY-11151 > Project: WildFly > Issue Type: Bug > Affects Versions: 14.0.0.Final > Reporter: Tamás Ábele > Assignee: Jason Greene > Priority: Major > > Introduced in wildfly 14 we receive a new JSF implementation (developed years ago), JSF 2.3.5 which is based on mojarra. In certain circumstances this JSF runtime hides the real problem, and makes from an invalid HTML a valid one, and spoils it somewhere else you would never guess, or produces an invalid partial response. Anything can happen. This way the JSF runtime makes it really hard to find the real problem. This behavior led to a more severe error than the original one in two reported cases at github. > I opened an issue ([eclipse-ee4j/mojarra#4488|https://github.com/eclipse-ee4j/mojarra/issues/...]) but the mojarra development team closed this issue without solving it, despite the fact how vulnerable JSF become to component rendering problems. Now a lot of teams starting to move towards wildfly 14. They are likely to face similar magical errors like us. In the other case ([jboss/mojarra#21|https://github.com/jboss/mojarra/issues/21]) the developer team switched back to JSF 2.2. I’m also worried to change to wildfly 14, because of the future magical errors it will cause in our systems. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11151) Wildfly 14 mixes up HTML response in JSF applications

by Tamás Ábele (Jira)

[ https://issues.jboss.org/browse/WFLY-11151?page=com.atlassian.jira.plugin... ] Tamás Ábele updated WFLY-11151: ------------------------------- Summary: Wildfly 14 mixes up HTML response in JSF applications (was: Wildfly 14 mix up HTML response in JSF applications) > Wildfly 14 mixes up HTML response in JSF applications > ----------------------------------------------------- > > Key: WFLY-11151 > URL: https://issues.jboss.org/browse/WFLY-11151 > Project: WildFly > Issue Type: Bug > Reporter: Tamás Ábele > Assignee: Jason Greene > Priority: Major > > Introduced in wildfly 14 we receive a new JSF implementation (developed years ago), JSF 2.3.5 which is based on mojarra. In certain circumstances this JSF runtime hides the real problem, and makes from an invalid HTML a valid one, and spoils it somewhere else you would never guess, or produces an invalid partial response. Anything can happen. This way the JSF runtime makes it really hard to find the real problem. This behavior led to a more severe error than the original one in two reported cases at github. > I opened an issue ([eclipse-ee4j/mojarra#4488|https://github.com/eclipse-ee4j/mojarra/issues/...]) but the mojarra development team closed this issue without solving it, despite the fact how vulnerable JSF become to component rendering problems. Now a lot of teams starting to move towards wildfly 14. They are likely to face similar magical errors like us. In the other case ([jboss/mojarra#21|https://github.com/jboss/mojarra/issues/21]) the developer team switched back to JSF 2.2. I’m also worried to change to wildfly 14, because of the future magical errors it will cause in our systems. -- This message was sent by Atlassian Jira (v7.12.1#712002)

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