January 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6020) The upgrade to undertow-core 1.3.11 causes HTTP keep-alive requests to hang.

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6020?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-6020. ---------------------------------- Fix Version/s: 10.0.0.Final Resolution: Done > The upgrade to undertow-core 1.3.11 causes HTTP keep-alive requests to hang. > ---------------------------------------------------------------------------- > > Key: WFLY-6020 > URL: https://issues.jboss.org/browse/WFLY-6020 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.CR5 > Reporter: Wouter van der Aa > Assignee: Stuart Douglas > Fix For: 10.0.0.Final > > > I just created a Jira ticket on the undertow-core bugtracker, which I do think would be a big problem (at least for us), if it is not solved on the Final version of Wildfly. > This ticket is about the hanging of Keep-Alive requests with the undertow-core version used in the CR5 release of Wildfly. See https://issues.jboss.org/browse/UNDERTOW-609 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6097) Error response handling from bean validation ignores Accept header

by Renann Prado (JIRA)

[ https://issues.jboss.org/browse/WFLY-6097?page=com.atlassian.jira.plugin.... ] Renann Prado updated WFLY-6097: ------------------------------- Attachment: delivery-optimization-ear-1.0.Final.ear The test application. > Error response handling from bean validation ignores Accept header > ------------------------------------------------------------------ > > Key: WFLY-6097 > URL: https://issues.jboss.org/browse/WFLY-6097 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final > Environment: Mac OS X El Captain > java version "1.8.0_66" > Java(TM) SE Runtime Environment (build 1.8.0_66-b17) > Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode) > Reporter: Renann Prado > Assignee: Jason Greene > Attachments: delivery-optimization-ear-1.0.Final.ear > > > Basically I have a very simple application that has request validation in the REST endpoints. > According to the documentation of RESTEasy, I should get a JSON error response if I put "application/json" in Accept header in the request. > https://docs.jboss.org/resteasy/docs/3.0.13.Final/userguide/html/Validati... > The mentioned feature worked just fine in Wildfly 9.0.2.Final. Now, however, it doesn't. > I have tried to upgrade the dependencies in the pom.xml to use dependencies from Wildfly 10.0.0.Final, but still no luck. Though the attached application deploys just fine in Wildfly 9.0.2.Final and Wildfly 10.0.0.Final. > In WF 9.0.2.Final I used to get the below error **JSON** > {code:json} > { > "exception": null, > "fieldViolations": [], > "propertyViolations": [], > "classViolations": [], > "parameterViolations": [{ > "constraintType": "PARAMETER", > "path": "registerLogisticsNetwork.arg0.name", > "message": "may not be null", > "value": "" > }], > "returnValueViolations": [] > } > {code} > In WF 10.0.0.Final I get this: > {code} > [PARAMETER] > [registerLogisticsNetwork.arg0.name] > [may not be null] > [] > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6097) Error response handling from bean validation ignores Accept header

by Renann Prado (JIRA)

[ https://issues.jboss.org/browse/WFLY-6097?page=com.atlassian.jira.plugin.... ] Renann Prado updated WFLY-6097: ------------------------------- Description: Basically I have a very simple application that has request validation in the REST endpoints. According to the documentation of RESTEasy, I should get a JSON error response if I put "application/json" in Accept header in the request. https://docs.jboss.org/resteasy/docs/3.0.13.Final/userguide/html/Validati... The mentioned feature worked just fine in Wildfly 9.0.2.Final. Now, however, it doesn't. I have tried to upgrade the dependencies in the pom.xml to use dependencies from Wildfly 10.0.0.Final, but still no luck. Though the attached application deploys just fine in Wildfly 9.0.2.Final and Wildfly 10.0.0.Final. In WF 9.0.2.Final I used to get the below error *JSON* {code:json} { "exception": null, "fieldViolations": [], "propertyViolations": [], "classViolations": [], "parameterViolations": [{ "constraintType": "PARAMETER", "path": "registerLogisticsNetwork.arg0.name", "message": "may not be null", "value": "" }], "returnValueViolations": [] } {code} In WF 10.0.0.Final I get this: {code} [PARAMETER] [registerLogisticsNetwork.arg0.name] [may not be null] [] {code} was: Basically I have a very simple application that has request validation in the REST endpoints. According to the documentation of RESTEasy, I should get a JSON error response if I put "application/json" in Accept header in the request. https://docs.jboss.org/resteasy/docs/3.0.13.Final/userguide/html/Validati... The mentioned feature worked just fine in Wildfly 9.0.2.Final. Now, however, it doesn't. I have tried to upgrade the dependencies in the pom.xml to use dependencies from Wildfly 10.0.0.Final, but still no luck. Though the attached application deploys just fine in Wildfly 9.0.2.Final and Wildfly 10.0.0.Final. In WF 9.0.2.Final I used to get the below error **JSON** {code:json} { "exception": null, "fieldViolations": [], "propertyViolations": [], "classViolations": [], "parameterViolations": [{ "constraintType": "PARAMETER", "path": "registerLogisticsNetwork.arg0.name", "message": "may not be null", "value": "" }], "returnValueViolations": [] } {code} In WF 10.0.0.Final I get this: {code} [PARAMETER] [registerLogisticsNetwork.arg0.name] [may not be null] [] {code} > Error response handling from bean validation ignores Accept header > ------------------------------------------------------------------ > > Key: WFLY-6097 > URL: https://issues.jboss.org/browse/WFLY-6097 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final > Environment: Mac OS X El Captain > java version "1.8.0_66" > Java(TM) SE Runtime Environment (build 1.8.0_66-b17) > Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode) > Reporter: Renann Prado > Assignee: Jason Greene > Attachments: delivery-optimization-ear-1.0.Final.ear > > > Basically I have a very simple application that has request validation in the REST endpoints. > According to the documentation of RESTEasy, I should get a JSON error response if I put "application/json" in Accept header in the request. > https://docs.jboss.org/resteasy/docs/3.0.13.Final/userguide/html/Validati... > The mentioned feature worked just fine in Wildfly 9.0.2.Final. Now, however, it doesn't. > I have tried to upgrade the dependencies in the pom.xml to use dependencies from Wildfly 10.0.0.Final, but still no luck. Though the attached application deploys just fine in Wildfly 9.0.2.Final and Wildfly 10.0.0.Final. > In WF 9.0.2.Final I used to get the below error *JSON* > {code:json} > { > "exception": null, > "fieldViolations": [], > "propertyViolations": [], > "classViolations": [], > "parameterViolations": [{ > "constraintType": "PARAMETER", > "path": "registerLogisticsNetwork.arg0.name", > "message": "may not be null", > "value": "" > }], > "returnValueViolations": [] > } > {code} > In WF 10.0.0.Final I get this: > {code} > [PARAMETER] > [registerLogisticsNetwork.arg0.name] > [may not be null] > [] > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6097) Error response handling from bean validation ignores Accept header

by Renann Prado (JIRA)

Renann Prado created WFLY-6097: ---------------------------------- Summary: Error response handling from bean validation ignores Accept header Key: WFLY-6097 URL: https://issues.jboss.org/browse/WFLY-6097 Project: WildFly Issue Type: Bug Affects Versions: 10.0.0.Final Environment: Mac OS X El Captain java version "1.8.0_66" Java(TM) SE Runtime Environment (build 1.8.0_66-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode) Reporter: Renann Prado Assignee: Jason Greene Basically I have a very simple application that has request validation in the REST endpoints. According to the documentation of RESTEasy, I should get a JSON error response if I put "application/json" in Accept header in the request. https://docs.jboss.org/resteasy/docs/3.0.13.Final/userguide/html/Validati... The mentioned feature worked just fine in Wildfly 9.0.2.Final. Now, however, it doesn't. I have tried to upgrade the dependencies in the pom.xml to use dependencies from Wildfly 10.0.0.Final, but still no luck. Though the attached application deploys just fine in Wildfly 9.0.2.Final and Wildfly 10.0.0.Final. In WF 9.0.2.Final I used to get the below error **JSON** {code:json} { "exception": null, "fieldViolations": [], "propertyViolations": [], "classViolations": [], "parameterViolations": [{ "constraintType": "PARAMETER", "path": "registerLogisticsNetwork.arg0.name", "message": "may not be null", "value": "" }], "returnValueViolations": [] } {code} In WF 10.0.0.Final I get this: {code} [PARAMETER] [registerLogisticsNetwork.arg0.name] [may not be null] [] {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1042) JavaDoc of StatelessKieSession should show usage of KieCommands (public API) instead of CommandFactory (internal-api)

by Duncan Doyle (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1042?page=com.atlassian.jira.plugi... ] Duncan Doyle commented on DROOLS-1042: -------------------------------------- Can be marked as done. > JavaDoc of StatelessKieSession should show usage of KieCommands (public API) instead of CommandFactory (internal-api) > --------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-1042 > URL: https://issues.jboss.org/browse/DROOLS-1042 > Project: Drools > Issue Type: Bug > Components: docs > Affects Versions: 6.4.0.Beta1 > Reporter: Duncan Doyle > Assignee: Duncan Doyle > Priority: Trivial > > The StatelessKieSession's JavaDoc shows an example on how to use the API. However, the example shown in the doc uses the internal CommandFactory API instead of the new KieCommands API. We should not encourage users to use internal APIs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6092) Upgrade Narayana to 5.2.13.Final

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-6092?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated WFLY-6092: -------------------------------- Fix Version/s: 10.1.0.Final > Upgrade Narayana to 5.2.13.Final > -------------------------------- > > Key: WFLY-6092 > URL: https://issues.jboss.org/browse/WFLY-6092 > Project: WildFly > Issue Type: Component Upgrade > Components: Transactions > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 10.1.0.Final > > > https://issues.jboss.org/browse/JBTM/fixforversion/12329358/?selectedTab=... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5950) Use servlet protocol in rts arquillian tests

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-5950?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated WFLY-5950: -------------------------------- Fix Version/s: 10.1.0.Final > Use servlet protocol in rts arquillian tests > -------------------------------------------- > > Key: WFLY-5950 > URL: https://issues.jboss.org/browse/WFLY-5950 > Project: WildFly > Issue Type: Task > Components: Transactions > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 10.1.0.Final > > > Currently default protocol is set to jmx-as7. It is recommended to use servlet instead as there are issues in RTS testsuite when using jmx protocol. > see http://discuss.arquillian.org/t/solved-randomly-before-method-runs-twice/... for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6002) Listener secure attribute doesn't work as expected

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6002?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-6002. ---------------------------------- Fix Version/s: 10.0.0.Final Resolution: Done > Listener secure attribute doesn't work as expected > -------------------------------------------------- > > Key: WFLY-6002 > URL: https://issues.jboss.org/browse/WFLY-6002 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.CR5 > Reporter: Radim Hatlapatka > Assignee: Stuart Douglas > Fix For: 10.0.0.Final > > Attachments: confidential.war > > > When setting {{secure}} attributed on {{http-listener}} and deploying web application which requires secured connection ({{<transport-guarantee>CONFIDENTIAL</transport-guarantee>}}. The web application should be accessible even from the {{http}} as the listener is defined as secured, but instead it results to redirect to https (when having redirect-socket defined) or to internal server error (when no redirect-socket). > Steps to reproduce: > # start eap and deploy attached confidential.war > # configure http-listener default as secured => /subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=secure, value=true) > # reload the server > # go to http://127.0.0.1:8080/confidential/index.jsp > # you should get 200 response code, still you get 302, which is not correct as the listener is defined as secured -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3805) JGroupsBroadcastGroupConfiguration Serialization Problem

by Clebert Suconic (JIRA)

[ https://issues.jboss.org/browse/WFLY-3805?page=com.atlassian.jira.plugin.... ] Clebert Suconic commented on WFLY-3805: --------------------------------------- Isn't this fixed ? > JGroupsBroadcastGroupConfiguration Serialization Problem > -------------------------------------------------------- > > Key: WFLY-3805 > URL: https://issues.jboss.org/browse/WFLY-3805 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 8.1.0.Final > Reporter: Yong Hao Gao > Assignee: Yong Hao Gao > Fix For: 10.1.0.Final > > > When configuring JMS connection factories using jgroups discovery group, the client will get serialization exceptions because we pass a JChannel which is not serializable. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-288) SecurityDomainJndiInjectable should allow "java:/jaas" prefixed security domain on demand

by Anil Saldanha (JIRA)

[ https://issues.jboss.org/browse/WFLY-288?page=com.atlassian.jira.plugin.s... ] Anil Saldanha commented on WFLY-288: ------------------------------------ Gentlemen - why not just close this JIRA issue as out of date? With each release, I get an email of this JIRA issue getting punted. :-) > SecurityDomainJndiInjectable should allow "java:/jaas" prefixed security domain on demand > ----------------------------------------------------------------------------------------- > > Key: WFLY-288 > URL: https://issues.jboss.org/browse/WFLY-288 > Project: WildFly > Issue Type: Feature Request > Components: Security > Reporter: Anil Saldanha > Assignee: Stefan Guilhen > Fix For: 10.1.0.Final > > > Currently, security domain strings of the form "java:/jaas/sd" are not resolving properly. IMO we should allow users to deploy applications on AS4,5,6,7 if they need to. > So have a flag inside the SecurityDomainJndiInjectable class that is turned off by default. If you turn it on, then "java:/jaas" is unprefixed if present. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 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 January 2016