January 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5484) Calling HttpServletRequest.logout() with single sign-on enabled only works every second time

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-5484?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-5484: -------------------------------------- using the linked reproducer it appears that Undertow 1.3.16.Final (which did not make it into WF10) fixes this issue. If you still see it can you post another reproducer that replicates the issue? > Calling HttpServletRequest.logout() with single sign-on enabled only works every second time > -------------------------------------------------------------------------------------------- > > Key: WFLY-5484 > URL: https://issues.jboss.org/browse/WFLY-5484 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Richard Janík > Assignee: Stuart Douglas > Priority: Blocker > Fix For: 10.0.0.CR5 > > Attachments: reproducer-jbeap-1282.zip > > > See "Steps to Reproduce". Logging out from an application only works every second time, e.g. HttpRequestServlet.logout() has to be called twice in order to have any effect > This doesn't occur without <single-sign-on/> enabled - logout() has the expected effect. The issue is security related, thus I'm adding our security team members as watchers. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6098) NullPointerException during deployment with class level @EJB and lookup

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-6098: ------------------------------------ Summary: NullPointerException during deployment with class level @EJB and lookup Key: WFLY-6098 URL: https://issues.jboss.org/browse/WFLY-6098 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 9.0.2.Final Reporter: Marco Zanker Assignee: Stuart Douglas If deploying a ejb3 SSB with a ejb reference to another bean (in my case an old ejb 2 SSB) with a mappedName-parameter, a NullPointerException occurs. @EJBs({ @EJB(name = "ejb/MyOldEJB2LocalHome", beanInterface=MyOldEJB2LocalHome.class, beanName="oldejb.jar#MyOldEJB2", mappedName = "oldejb/MyOldEJB2Local"), }) Caused by: java.lang.NullPointerException at org.jboss.as.ejb3.deployment.processors.EjbResourceInjectionAnnotationProcessor.process(EjbResourceInjectionA nnotationProcessor.java:166) at org.jboss.as.ejb3.deployment.processors.EjbResourceInjectionAnnotationProcessor.processClass(EjbResourceInjec tionAnnotationProcessor.java:146) at org.jboss.as.ejb3.deployment.processors.EjbResourceInjectionAnnotationProcessor.deploy(EjbResourceInjectionAn notationProcessor.java:106) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) Seems, if mappedName is declared, always a NullPointerException occurs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5907) NullPointerException during deployment with class level @EJB and lookup

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-5907?page=com.atlassian.jira.plugin.... ] Stuart Douglas updated WFLY-5907: --------------------------------- Summary: NullPointerException during deployment with class level @EJB and lookup (was: NullPointerException during deployment ejb-ref with mappedName) > NullPointerException during deployment with class level @EJB and lookup > ----------------------------------------------------------------------- > > Key: WFLY-5907 > URL: https://issues.jboss.org/browse/WFLY-5907 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.2.Final > Reporter: Marco Zanker > Assignee: Stuart Douglas > > If deploying a ejb3 SSB with a ejb reference to another bean (in my case an old ejb 2 SSB) with a mappedName-parameter, a NullPointerException occurs. > @EJBs({ > @EJB(name = "ejb/MyOldEJB2LocalHome", beanInterface=MyOldEJB2LocalHome.class, beanName="oldejb.jar#MyOldEJB2", mappedName = "oldejb/MyOldEJB2Local"), > }) > Caused by: java.lang.NullPointerException > at org.jboss.as.ejb3.deployment.processors.EjbResourceInjectionAnnotationProcessor.process(EjbResourceInjectionA > nnotationProcessor.java:166) > at org.jboss.as.ejb3.deployment.processors.EjbResourceInjectionAnnotationProcessor.processClass(EjbResourceInjec > tionAnnotationProcessor.java:146) > at org.jboss.as.ejb3.deployment.processors.EjbResourceInjectionAnnotationProcessor.deploy(EjbResourceInjectionAn > notationProcessor.java:106) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) > Seems, if mappedName is declared, always a NullPointerException occurs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6052) NPE on session.invalidate()

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6052?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-6052. ---------------------------------- Fix Version/s: 10.0.0.Final Resolution: Done > NPE on session.invalidate() > --------------------------- > > Key: WFLY-6052 > URL: https://issues.jboss.org/browse/WFLY-6052 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.CR5 > Reporter: Juan AMAT > Assignee: Stuart Douglas > Fix For: 10.0.0.Final > > > I created a discussion about the issue some time ago but got not answer. > See: https://developer.jboss.org/message/946976#946976 > The problem is that when a webapp is not marked as 'distributable' the undertow InMemorySessionManager is used. > As mentioned in the discussion the 'getSession' of this manager does not like to be called with a null parameter, which is what willdfy does. > This happens when single-sign-on is enable and multiple sessions are associated to the same sso session and 'invalidate' is called on one of the session. > The workaround is to marked all our webapps as distributable but this will have a performance impact. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[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)

8 years, 10 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)

8 years, 10 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)

8 years, 10 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)

8 years, 10 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)

8 years, 10 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)

8 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2016