June 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (LOGMGR-279) The configuration API removes handler references before the handler is removed from a logger/handler

by James Perkins (Jira)

[ https://issues.redhat.com/browse/LOGMGR-279?page=com.atlassian.jira.plugi... ] James Perkins updated LOGMGR-279: --------------------------------- Fix Version/s: 2.2.0.Final 2.1.17.Final 2.3.0.Beta1 > The configuration API removes handler references before the handler is removed from a logger/handler > ---------------------------------------------------------------------------------------------------- > > Key: LOGMGR-279 > URL: https://issues.redhat.com/browse/LOGMGR-279 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Perkins > Assignee: James Perkins > Priority: Critical > Fix For: 2.2.0.Final, 2.1.17.Final, 2.3.0.Beta1 > > > Using the configuration API to remove a handler from a logger and a handler in the same transaction does not the handler from a logger or a different handler. The handler reference is removed and closed before the attempt to remove the handler from the logger or handler. This ends up leaving the handler on the logger or on the handler so messages are still published to the handler. > Note too that this could also be an issue with the post configuration actions as they require the handler reference as well. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-279) The configuration API removes handler references before the handler is removed from a logger/handler

by James Perkins (Jira)

James Perkins created LOGMGR-279: ------------------------------------ Summary: The configuration API removes handler references before the handler is removed from a logger/handler Key: LOGMGR-279 URL: https://issues.redhat.com/browse/LOGMGR-279 Project: JBoss Log Manager Issue Type: Bug Reporter: James Perkins Assignee: James Perkins Using the configuration API to remove a handler from a logger and a handler in the same transaction does not the handler from a logger or a different handler. The handler reference is removed and closed before the attempt to remove the handler from the logger or handler. This ends up leaving the handler on the logger or on the handler so messages are still published to the handler. Note too that this could also be an issue with the post configuration actions as they require the handler reference as well. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13590) JGroups subsystem logs "version is missing in the configuration file" warning on startup

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13590?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13590: -------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/13368, https://github.com/wildfly/wildfly/pull/13384 (was: https://github.com/wildfly/wildfly/pull/13384) > JGroups subsystem logs "version is missing in the configuration file" warning on startup > ---------------------------------------------------------------------------------------- > > Key: WFLY-13590 > URL: https://issues.redhat.com/browse/WFLY-13590 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 20.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > Fix For: 21.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13590) JGroups subsystem logs "version is missing in the configuration file" warning on startup

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13590?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13590: -------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/13384 (was: https://github.com/wildfly/wildfly/pull/13368) > JGroups subsystem logs "version is missing in the configuration file" warning on startup > ---------------------------------------------------------------------------------------- > > Key: WFLY-13590 > URL: https://issues.redhat.com/browse/WFLY-13590 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 20.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > Fix For: 21.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13616) Distributed session manager should trigger HttpSessionAttributeListener.attributeRemoved events on session destroy

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-13616: ----------------------------------- Summary: Distributed session manager should trigger HttpSessionAttributeListener.attributeRemoved events on session destroy Key: WFLY-13616 URL: https://issues.redhat.com/browse/WFLY-13616 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 20.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Justification: * This is the behavior of the non-distributed session manager * This is the behavior of the servlet container reference implementation * JSF relies on these events being triggered on session destroy. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13615) JaccServices need to depend up Elytron JACC Service

by Darran Lofthouse (Jira)

Darran Lofthouse created WFLY-13615: --------------------------------------- Summary: JaccServices need to depend up Elytron JACC Service Key: WFLY-13615 URL: https://issues.redhat.com/browse/WFLY-13615 Project: WildFly Issue Type: Bug Components: EE, EJB, Web (Undertow) Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 21.0.0.Beta1 Three DeploymentUnitProcessors register a JaccService, if Elytron ihas registered a capability to indicate it is handling JACC a dependency should be added on the service installed by the Elytron subsystem. Presently it is a little racey as to if Elytron will have activated the JACC PolicyConfigurationFactory before the deployment makes use of it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13612) Bean Validation Problem In EJB inheritance

by Ivo Studensky (Jira)

[ https://issues.redhat.com/browse/WFLY-13612?page=com.atlassian.jira.plugi... ] Ivo Studensky reassigned WFLY-13612: ------------------------------------ Assignee: Ivo Studensky (was: Brian Stansberry) > Bean Validation Problem In EJB inheritance > ------------------------------------------ > > Key: WFLY-13612 > URL: https://issues.redhat.com/browse/WFLY-13612 > Project: WildFly > Issue Type: Bug > Components: Bean Validation > Affects Versions: 20.0.0.Final > Reporter: huaxu wu > Assignee: Ivo Studensky > Priority: Major > > > {code:java} > @Path("/test_action") > public interface TestResource { > @Path("test") > @POST > @Consumes(MediaType.APPLICATION_FORM_URLENCODED) > @Produces(MediaType.APPLICATION_JSON) > GeneralOperationResult test2(@FormParam("asdf") @NotBlank String asdf); > } > {code} > {code:java} > @Stateless > public class TestResourceImpl implements TestResource { > @Override > public GeneralOperationResult test2(String asdf) { > return GeneralOperationResult.createSuccess("test"); > } > } > {code} > The above code, the @NotBlank annotation works on wildfly19, but not on wildfly20. > To make it work on wildfly20, I must add @NotBlank annotation to the override method. > I wonder it's bug or it's your design? > The above code, If I remove the @Stateless annotation, the @NotBlank annotation works as expectd. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5013) Remove the wildfly-openssl i386 bindings

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-5013?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-5013: -------------------------------- Fix Version/s: 13.0.0.Final > Remove the wildfly-openssl i386 bindings > ---------------------------------------- > > Key: WFCORE-5013 > URL: https://issues.redhat.com/browse/WFCORE-5013 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Blocker > Fix For: 13.0.0.Final > > > We should remove the wildfly-openssl-linux-i386 and the wildfly-openssl-windows-i386 bindings for WildFly Core 13.0.0.Final (i.e., WildFly 21 Final). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12375) Server returns 2 JSESSIONID cookies

by Parul Sharma (Jira)

[ https://issues.redhat.com/browse/WFLY-12375?page=com.atlassian.jira.plugi... ] Parul Sharma commented on WFLY-12375: ------------------------------------- [~nicolas.n] Can you please attach myApp? So I can recreate this issue quickly. Thanks > Server returns 2 JSESSIONID cookies > ------------------------------------ > > Key: WFLY-12375 > URL: https://issues.redhat.com/browse/WFLY-12375 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 17.0.1.Final > Reporter: Nicolas NESMON > Assignee: Parul Sharma > Priority: Major > Labels: COOKIES, JSESSIONID > > Please find below the source code of my simplified JAX-RS application: > {code:java} > @ApplicationPath("myApp") > public class Application extends javax.ws.rs.core.Application { > public Application() { > } > @Override > public Set<Object> getSingletons() { > return Collections.singleton(new HelloWorldResource()); > } > } > {code} > {code:java} > @Path("/") > @Produces(MediaType.TEXT_PLAIN) > public class HelloWorldResource { > @Context > private HttpServletRequest httpServletRequest; > @GET > public Response helloWorld() { > HttpSession session = this.httpServletRequest.getSession(false); > return Response.ok(session == null ? "Hello world" : "Bye bye world") > .cookie(new NewCookie("JSESSIONID", "id", "demo", null, null, -1, false)).build(); > } > } > {code} > When deploying this application in WF 17.0.1.Final and running following request: > {noformat} > GET http://localhost:8080/demo/myApp/ > Host: localhost:8080 > User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0 > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 > Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3 > Accept-Encoding: gzip, deflate > Connection: keep-alive > Upgrade-Insecure-Requests: 1 > Pragma: no-cache > Cache-Control: no-cache > Cookie: JSESSIONID=Hello => without this cookie, I only get the cookie I created. > {noformat} > I get following response > {noformat} > HTTP/1.1 200 OK > Connection: keep-alive > Set-Cookie: JSESSIONID=id;Version=1;Path=/demo > Set-Cookie: JSESSIONID=hello.vpi070236; path=/demo > Content-Type: text/plain;charset=UTF-8 > Content-Length: 11 > Date: Tue, 13 Aug 2019 23:28:15 GMT > {noformat} > As you may notice, there are 2 JSESSIONID cookies in the response: > * The one I was expecting with "id" value since I created it. > * Another one created by the server even if I did not ask for it since in my code I don't create no HTTP session. And by the way this JSESSIONID cookie is created but there no server side session created...weird > Any idea why this second JSESSIONID cookies is created by the server ? > Since my real application don't use HTTP session at all the workaround I found is to set session tracking mode to URL: > {noformat} > <web-app> > <session-config> > <tracking-mode>URL</tracking-mode> > </session-config> > </web-app> > {noformat} > Thanks -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13614) Upgrade Artemis Native to 1.0.2

by Bartosz Spyrko-Smietanko (Jira)

[ https://issues.redhat.com/browse/WFLY-13614?page=com.atlassian.jira.plugi... ] Bartosz Spyrko-Smietanko moved JBEAP-19739 to WFLY-13614: --------------------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-13614 (was: JBEAP-19739) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Fix Version/s: (was: 7.3.3.GA) > Upgrade Artemis Native to 1.0.2 > ------------------------------- > > Key: WFLY-13614 > URL: https://issues.redhat.com/browse/WFLY-13614 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Bartosz Spyrko-Smietanko > Assignee: Bartosz Spyrko-Smietanko > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2020