April 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4415) Upgrade JBoss Modules from 1.9.0.Final to 1.9.1.Final

by Richard Opalka (Jira)

Richard Opalka created WFCORE-4415: -------------------------------------- Summary: Upgrade JBoss Modules from 1.9.0.Final to 1.9.1.Final Key: WFCORE-4415 URL: https://issues.jboss.org/browse/WFCORE-4415 Project: WildFly Core Issue Type: Component Upgrade Components: Build System, Modules Reporter: Richard Opalka Assignee: Richard Opalka Fix For: 9.0.0.Beta3 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4414) [GSS](7.2.z) Fix backward compatibility issues of javax.api & javax.sql.api modules

by Brad Maxwell (Jira)

Brad Maxwell created WFCORE-4414: ------------------------------------ Summary: [GSS](7.2.z) Fix backward compatibility issues of javax.api & javax.sql.api modules Key: WFCORE-4414 URL: https://issues.jboss.org/browse/WFCORE-4414 Project: WildFly Core Issue Type: Bug Components: Modules Reporter: Brad Maxwell Assignee: Richard Opalka Fix For: 9.0.0.Beta3 Modules related commit of WFCORE-3684 issue (commit id b0199c5635186386df3ef7a8c2b7aac37525eee1) introduced backward compatibility issues of javax.api & javax.sql.api modules This needs to be fixed. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11977) Upgrade WildFly Naming Client to 1.0.10.Final

by Ilia Vassilev (Jira)

Ilia Vassilev created WFLY-11977: ------------------------------------ Summary: Upgrade WildFly Naming Client to 1.0.10.Final Key: WFLY-11977 URL: https://issues.jboss.org/browse/WFLY-11977 Project: WildFly Issue Type: Component Upgrade Components: Naming Reporter: Ilia Vassilev Assignee: David Lloyd Fixes the linked Context recursion bug. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11976) Upgrade WildFly Naming Client to 1.0.10.Final

by Ilia Vassilev (Jira)

Ilia Vassilev created WFLY-11976: ------------------------------------ Summary: Upgrade WildFly Naming Client to 1.0.10.Final Key: WFLY-11976 URL: https://issues.jboss.org/browse/WFLY-11976 Project: WildFly Issue Type: Component Upgrade Components: Naming Reporter: Ilia Vassilev Assignee: David Lloyd Fix For: 13.0.0.Final Fixes the linked Context recursion bug. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11976) Upgrade WildFly Naming Client to 1.0.10.Final

by Ilia Vassilev (Jira)

[ https://issues.jboss.org/browse/WFLY-11976?page=com.atlassian.jira.plugin... ] Ilia Vassilev updated WFLY-11976: --------------------------------- Fix Version/s: (was: 13.0.0.Final) > Upgrade WildFly Naming Client to 1.0.10.Final > --------------------------------------------- > > Key: WFLY-11976 > URL: https://issues.jboss.org/browse/WFLY-11976 > Project: WildFly > Issue Type: Component Upgrade > Components: Naming > Reporter: Ilia Vassilev > Assignee: David Lloyd > Priority: Major > > Fixes the linked Context recursion bug. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11956) @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method

by Joerg Baesner (Jira)

[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ] Joerg Baesner commented on WFLY-11956: -------------------------------------- Thanks Christian for confirming this to be a valid workaround, but it is not viable for you. Anyhow it is a bug calling the business method before the @PostConstruct > @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method > ---------------------------------------------------------------------------------------------------------- > > Key: WFLY-11956 > URL: https://issues.jboss.org/browse/WFLY-11956 > Project: WildFly > Issue Type: Bug > Components: Bean Validation, REST > Affects Versions: 16.0.0.Final > Reporter: Joerg Baesner > Assignee: Ronald Sigal > Priority: Major > Attachments: logging.txt, playground.zip > > > Having a bean class with {{@ApplicationScoped}}, which has a {{@PostConstruct}} and is implementing the following _Interface_: > {code} > @Path("/validated") > public interface ValidatedJaxRsInterface { > > @GET > @Valid > @Produces(MediaType.APPLICATION_JSON) > GreetingModel getHelloGreeting(); > } > {code} > will result in calling the {{getHelloGreeting}} method of the implementation class twice *_before_* the {{@PostConstruct}} is getting executed. > This can be reproduced with the attached reproducer application... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11975) Distributed web session metadata payload contains unnecessary nanosecond precision

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-11975: ----------------------------------- Summary: Distributed web session metadata payload contains unnecessary nanosecond precision Key: WFLY-11975 URL: https://issues.jboss.org/browse/WFLY-11975 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 16.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro The creation timestamp of a distributed web session is represented by a java.time.Instant. The externalizer for an Instant marshals an integer containing the nanosecond precision, which is unnecessary, as the HttpSession API only requires millisecond precision. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11970) SFSB memory leak due to Date() usage

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-11970?page=com.atlassian.jira.plugin... ] Paul Ferraro commented on WFLY-11970: ------------------------------------- {quote}I was assuming the use of Date().getTime() and System.currentTimeMillis() was so that the lastAccessed timestamp would be valid on failover on a different system{quote} Yeah, nevermind. We can't use System.nanoTime() for lastAccessedTime, since different members can have different origin times. > SFSB memory leak due to Date() usage > ------------------------------------ > > Key: WFLY-11970 > URL: https://issues.jboss.org/browse/WFLY-11970 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 11.0.0.Final > Reporter: Dennis Reed > Assignee: Paul Ferraro > Priority: Critical > > SFSB tracks expiration with "new Date().getTime()" and "System.currentTimeMillis()". > But the expiration threads are scheduled (inside JDK classes) with System.nanoTime(). > If the expiration task runs before the bean is considered expired, the expiration check fails and the bean is never expired. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11956) @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method

by Christian Zambrano (Jira)

[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ] Christian Zambrano edited comment on WFLY-11956 at 4/11/19 3:37 PM: -------------------------------------------------------------------- Hi, I am the person that reported the issue. When I opened the case with Redhat support, I did indicate that changing the name solved the issue but that is not a viable workaround because we have hundreds of rest endpoints methods that start with get. Here are all the experiments I went through and the results: Here are all the experiments I went through to try to understand this behavior: 1. Made the bean @ApplicationScope => Exhibits the behavior explained above 2. Made the bean @Stateless => Exhibits the behavior explained above 3. Made the bean @Singleton(from the ejb package) => Exhibits the behavior explained above 4. Made the bean @Singleton @Startup => Method is only called once and after the postconstruct as expected but the return value is not validated 5. Renamed the method to not start with 'get' => Method is only called once and after the postconstruct as expected was (Author: christian.zambrano): Hi, I am the person that reported the issue. When I opened the case with Redhat support, I did indicate that changing the name solved the issue but that is not a viable workaround because we have hundreds of rest endpoints methods that start with get. Here are all the experiements I went through and the results: Here are all the experiments I went through to try to understand this behavior: 1. Made the bean @ApplicationScope => Exhibits the behavior explained above 2. Made the bean @Stateless => Exhibits the behavior explained above 3. Made the bean @Singleton(from the ejb package) => Exhibits the behavior explained above 4. Made the bean @Singleton @Startup => Method is only called once and after the postconstruct as expected but the return value is not validated 5. Renamed the method to not start with 'get' => Method is only called once and after the postconstruct as expected > @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method > ---------------------------------------------------------------------------------------------------------- > > Key: WFLY-11956 > URL: https://issues.jboss.org/browse/WFLY-11956 > Project: WildFly > Issue Type: Bug > Components: Bean Validation, REST > Affects Versions: 16.0.0.Final > Reporter: Joerg Baesner > Assignee: Ronald Sigal > Priority: Major > Attachments: logging.txt, playground.zip > > > Having a bean class with {{@ApplicationScoped}}, which has a {{@PostConstruct}} and is implementing the following _Interface_: > {code} > @Path("/validated") > public interface ValidatedJaxRsInterface { > > @GET > @Valid > @Produces(MediaType.APPLICATION_JSON) > GreetingModel getHelloGreeting(); > } > {code} > will result in calling the {{getHelloGreeting}} method of the implementation class twice *_before_* the {{@PostConstruct}} is getting executed. > This can be reproduced with the attached reproducer application... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11956) @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method

by Christian Zambrano (Jira)

[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ] Christian Zambrano edited comment on WFLY-11956 at 4/11/19 3:37 PM: -------------------------------------------------------------------- Hi, I am the person that reported the issue. When I opened the case with Redhat support, I did indicate that changing the name solved the issue but that is not a viable workaround because we have hundreds of rest endpoints methods that start with get. Here are all the experiements I went through and the results: Here are all the experiments I went through to try to understand this behavior: 1. Made the bean @ApplicationScope => Exhibits the behavior explained above 2. Made the bean @Stateless => Exhibits the behavior explained above 3. Made the bean @Singleton(from the ejb package) => Exhibits the behavior explained above 4. Made the bean @Singleton @Startup => Method is only called once and after the postconstruct as expected but the return value is not validated 5. Renamed the method to not start with 'get' => Method is only called once and after the postconstruct as expected was (Author: christian.zambrano): Hi, I am the person that reported the issue. When I opened the case with Redhat support, I did indicate that changing the name solved the issue but that is not a viable workaround because we have hundreds of rest endpoints that start with get. Here are all the experiements I went through and the results: Here are all the experiments I went through to try to understand this behavior: 1. Made the bean @ApplicationScope => Exhibits the behavior explained above 2. Made the bean @Stateless => Exhibits the behavior explained above 3. Made the bean @Singleton(from the ejb package) => Exhibits the behavior explained above 4. Made the bean @Singleton @Startup => Method is only called once and after the postconstruct as expected but the return value is not validated 5. Renamed the method to not start with 'get' => Method is only called once and after the postconstruct as expected > @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method > ---------------------------------------------------------------------------------------------------------- > > Key: WFLY-11956 > URL: https://issues.jboss.org/browse/WFLY-11956 > Project: WildFly > Issue Type: Bug > Components: Bean Validation, REST > Affects Versions: 16.0.0.Final > Reporter: Joerg Baesner > Assignee: Ronald Sigal > Priority: Major > Attachments: logging.txt, playground.zip > > > Having a bean class with {{@ApplicationScoped}}, which has a {{@PostConstruct}} and is implementing the following _Interface_: > {code} > @Path("/validated") > public interface ValidatedJaxRsInterface { > > @GET > @Valid > @Produces(MediaType.APPLICATION_JSON) > GreetingModel getHelloGreeting(); > } > {code} > will result in calling the {{getHelloGreeting}} method of the implementation class twice *_before_* the {{@PostConstruct}} is getting executed. > This can be reproduced with the attached reproducer application... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 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 April 2019