October 2018 - jboss-jira - Jboss List Archives

[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, and the real problem will be really hard to find. 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/...]) 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. > 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, and the real problem will be really hard to find. 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] (WFCORE-4165) The SuspendController is not exposed via a capability

by Brian Stansberry (Jira)

Brian Stansberry created WFCORE-4165: ---------------------------------------- Summary: The SuspendController is not exposed via a capability Key: WFCORE-4165 URL: https://issues.jboss.org/browse/WFCORE-4165 Project: WildFly Core Issue Type: Bug Components: Management Reporter: Brian Stansberry Assignee: Jeff Mesnil Various services in the appserver depend on the SuspendController via SuspendController.SERVICE_NAME. This should be exposed via a capability. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10837) IIOP subsystem requires port binding to be defined which was not necessary in prior WFLY versions

by Eduardo Martins (Jira)

[ https://issues.jboss.org/browse/WFLY-10837?page=com.atlassian.jira.plugin... ] Eduardo Martins commented on WFLY-10837: ---------------------------------------- [~brian.stansberry] thanks for the help at low level > IIOP subsystem requires port binding to be defined which was not necessary in prior WFLY versions > ------------------------------------------------------------------------------------------------- > > Key: WFLY-10837 > URL: https://issues.jboss.org/browse/WFLY-10837 > Project: WildFly > Issue Type: Bug > Components: IIOP > Reporter: Ondra Chaloupka > Assignee: Tomasz Adamski > Priority: Blocker > Fix For: 14.0.0.Final > > > If the {{standalone-*.xml}} configuration defines to use IIOP subsystem but it does not defines the port binding element > {code} > <orb socket-binding="iiop"/> > {code} > The server starts with error > {code} > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.iiop-openjdk.orb-service: org.jboss.msc.service.StartException in service jboss.iiop-openjdk.orb-service: java.lang.IllegalStateException: WFLYIIOP0115: No IIOP socket bindings have been configured > at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:150) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698) > at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.IllegalStateException: WFLYIIOP0115: No IIOP socket bindings have been configured > at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:109) > ... 8 more > {code} > The attribute of the {{socket-binding}} in the model is not defined as {{required}}. > {code} > "socket-binding" => { > "type" => STRING, > "description" => "The name of the socket binding configuration that specifies the ORB port.", > "attribute-group" => "orb", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L, > "access-constraints" => {"sensitive" => {"socket-binding-ref" => {"type" => "core"}}}, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > } > {code} > Up to that declaring the iiop socket binding was not necessary in WildFly 13.0.0.Final. Could that be a backward compatibility problem too? > Up to that -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10837) IIOP subsystem requires port binding to be defined which was not necessary in prior WFLY versions

by Eduardo Martins (Jira)

[ https://issues.jboss.org/browse/WFLY-10837?page=com.atlassian.jira.plugin... ] Eduardo Martins commented on WFLY-10837: ---------------------------------------- As all subsystems, IIOP should keep full compatibility for all schemas used by EAP 7.x, i.e provide same functionalities by translating configs of different versions. Wrt schemas used by EAP 6.4 or older we can address that at migration tool and manual migration docs. > IIOP subsystem requires port binding to be defined which was not necessary in prior WFLY versions > ------------------------------------------------------------------------------------------------- > > Key: WFLY-10837 > URL: https://issues.jboss.org/browse/WFLY-10837 > Project: WildFly > Issue Type: Bug > Components: IIOP > Reporter: Ondra Chaloupka > Assignee: Tomasz Adamski > Priority: Blocker > Fix For: 14.0.0.Final > > > If the {{standalone-*.xml}} configuration defines to use IIOP subsystem but it does not defines the port binding element > {code} > <orb socket-binding="iiop"/> > {code} > The server starts with error > {code} > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.iiop-openjdk.orb-service: org.jboss.msc.service.StartException in service jboss.iiop-openjdk.orb-service: java.lang.IllegalStateException: WFLYIIOP0115: No IIOP socket bindings have been configured > at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:150) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698) > at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.IllegalStateException: WFLYIIOP0115: No IIOP socket bindings have been configured > at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:109) > ... 8 more > {code} > The attribute of the {{socket-binding}} in the model is not defined as {{required}}. > {code} > "socket-binding" => { > "type" => STRING, > "description" => "The name of the socket binding configuration that specifies the ORB port.", > "attribute-group" => "orb", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L, > "access-constraints" => {"sensitive" => {"socket-binding-ref" => {"type" => "core"}}}, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > } > {code} > Up to that declaring the iiop socket binding was not necessary in WildFly 13.0.0.Final. Could that be a backward compatibility problem too? > Up to that -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4164) The read-feature-description requirements output does not include requirements defined via RuntimeCapability.getRequirements

by Brian Stansberry (Jira)

Brian Stansberry created WFCORE-4164: ---------------------------------------- Summary: The read-feature-description requirements output does not include requirements defined via RuntimeCapability.getRequirements Key: WFCORE-4164 URL: https://issues.jboss.org/browse/WFCORE-4164 Project: WildFly Core Issue Type: Bug Components: Management Reporter: Brian Stansberry Assignee: Brian Stansberry Title says it all. Perhaps the thing to do is create a CapabilityReferenceRecorder for these and include them in IMMR.getRequirements. We'd need to be sure to not double-record them though. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11177) Add an initial private capability for the JPA subsystem

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-11177: --------------------------------------- Summary: Add an initial private capability for the JPA subsystem Key: WFLY-11177 URL: https://issues.jboss.org/browse/WFLY-11177 Project: WildFly Issue Type: Sub-task Components: JPA / Hibernate Reporter: Brian Stansberry Assignee: Brian Stansberry At some point we want a public capability for JPA, so it can expose a formal contract to other subsystem (e.g. weld.) But sorting out what that capability exposes doesn't need to block adding a private capability first. Having the private capability will allow the JPA subsystem to properly expose the requirements it has on capabilities exposed by other subsystems. And that will allow Galleon to properly understand those relationships when it generates configurations as part of server configuration. So this subtask is to add such a private capability, with the remaining work of sorting out what public contract it will provide leftover as part of the parent issue. It's not a problem to take a private capability and in the future make it public. And it's not a problem to change what a private capability exposes, i.e. in preparation for making it public. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7521) JPA subsystem does not expose a proper capability contract

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-7521?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-7521: -------------------------------------- Assignee: Brian Stansberry (was: Scott Marlow) > JPA subsystem does not expose a proper capability contract > ---------------------------------------------------------- > > Key: WFLY-7521 > URL: https://issues.jboss.org/browse/WFLY-7521 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > > Capabilities provided to other subsystems by JPA should be via a contract, and it's uses of other subsystems should be via a contract. > The latter depends on the other subsystems resolving an issue equivalent to this one, if they haven't already. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7521) JPA subsystem does not expose a proper capability contract

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-7521?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-7521: ---------------------------------------- The question about what to expose to outside subsystems is a valid one, but resolving that isn't required in order to initially register an internal private capability for the subsystem. Doing that will then allow the subsystem to declare its model dependencies on other capabilities, e.g. the ones that bring transaction features. Since I'm working on exposing those tx capabilities (see WFLY-11166), the need to properly consume them is now more urgent. So I'm going to file a subtask for adding such a private capability. > JPA subsystem does not expose a proper capability contract > ---------------------------------------------------------- > > Key: WFLY-7521 > URL: https://issues.jboss.org/browse/WFLY-7521 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Reporter: Brian Stansberry > Assignee: Scott Marlow > Priority: Major > > Capabilities provided to other subsystems by JPA should be via a contract, and it's uses of other subsystems should be via a contract. > The latter depends on the other subsystems resolving an issue equivalent to this one, if they haven't already. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11176) Messaging transaction integrations should use capability requirements

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-11176: --------------------------------------- Summary: Messaging transaction integrations should use capability requirements Key: WFLY-11176 URL: https://issues.jboss.org/browse/WFLY-11176 Project: WildFly Issue Type: Enhancement Components: JMS Reporter: Brian Stansberry Assignee: Jeff Mesnil Once WFLY-11166 and WFLY-11174 are complete the various messaging resources that create services that depend on the services associated with the new transactions and jca capabilities should themselves declare capabilities and add the needed capability requirements. These look to be the pooled connection factory resources and the jms bridge resources -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11175) Simplify TransactionManager integration in JMSBridgeService

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-11175: --------------------------------------- Summary: Simplify TransactionManager integration in JMSBridgeService Key: WFLY-11175 URL: https://issues.jboss.org/browse/WFLY-11175 Project: WildFly Issue Type: Enhancement Components: JMS Reporter: Brian Stansberry Assignee: Brian Stansberry JMSBridgeService has an odd static method called from start() where it does an MSC ServiceRegistry lookup to find the TransactionManager service. That would be unreliable if the service had no MSC dependency on the TM service. But JMSBridgeAdd creates such a dependency when it installs the bridge service. This whole thing should be converted into a normal service injection. -- 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