June 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11816) Bump the Undertow subsystem model version and schema to version 9

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/WFLY-11816?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-11816: ---------------------------------- Fix Version/s: 17.0.0.Final > Bump the Undertow subsystem model version and schema to version 9 > ----------------------------------------------------------------- > > Key: WFLY-11816 > URL: https://issues.jboss.org/browse/WFLY-11816 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Reporter: James Perkins > Assignee: James Perkins > Priority: Major > Fix For: 17.0.0.Alpha1, 17.0.0.Final > > > The Undertow subsystem schema should be bumped from 8 to 9 and the model version should be bumped from 8 to 9. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11816) Bump the Undertow subsystem model version and schema to version 9.

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/WFLY-11816?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-11816: ---------------------------------- Summary: Bump the Undertow subsystem model version and schema to version 9. (was: Bump Undertow schema and model version) > Bump the Undertow subsystem model version and schema to version 9. > ------------------------------------------------------------------ > > Key: WFLY-11816 > URL: https://issues.jboss.org/browse/WFLY-11816 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Reporter: James Perkins > Assignee: James Perkins > Priority: Major > Fix For: 17.0.0.Alpha1 > > > The Undertow subsystem schema should be bumped from 8 to 9 and the model version should be bumped from 8 to 9. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11816) Bump the Undertow subsystem model version and schema to version 9

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/WFLY-11816?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-11816: ---------------------------------- Summary: Bump the Undertow subsystem model version and schema to version 9 (was: Bump the Undertow subsystem model version and schema to version 9.) > Bump the Undertow subsystem model version and schema to version 9 > ----------------------------------------------------------------- > > Key: WFLY-11816 > URL: https://issues.jboss.org/browse/WFLY-11816 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Reporter: James Perkins > Assignee: James Perkins > Priority: Major > Fix For: 17.0.0.Alpha1 > > > The Undertow subsystem schema should be bumped from 8 to 9 and the model version should be bumped from 8 to 9. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11601) Weld vs Undertow bootstrap: Race condition

by Matěj Novotný (Jira)

[ https://issues.jboss.org/browse/WFLY-11601?page=com.atlassian.jira.plugin... ] Matěj Novotný commented on WFLY-11601: -------------------------------------- I am currently trying to swap around few steps in Weld bootstrap to see how that works with WFLY. I'll run that through Weld TS as well as WFLY one and if is works, we can take that route as it would mean no interference with integrator logic. > Weld vs Undertow bootstrap: Race condition > ------------------------------------------ > > Key: WFLY-11601 > URL: https://issues.jboss.org/browse/WFLY-11601 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Web (Undertow) > Affects Versions: 15.0.1.Final > Reporter: Stefan Gr > Assignee: Matěj Novotný > Priority: Major > Attachments: TestApp.zip, TestLib.zip, changes.diff, deploy-failed.txt, deploy-mixed-success.txt, deploy-success.txt, test-app-1.0.0.war, weld-core-impl-3.0.5.Final.jar, weld-core-impl-3.0.5.Final.jar > > > WFLY-9732 / WFLY-10784 moves the completion of WELD from the WeldStartService to WeldStartCompetionService. This causes a race condition with the UndertowDeploymentService which executes the servlet listeners for context-initialized which again fires ApplicationScope-initialized events in CDI. > You can find more in [WELD-2557|https://issues.jboss.org/browse/WELD-2557?focusedCommentId=1368...]. > In short: WeldStartCompletionService and UndertowDeploymentService pushes the logic to the executor service. It may happen, that the logik of undertow runs before the weld completion. Events fired in the servlet listeners won't find all event observers. > A possible solution would bo to set the WeldStartCompletionService as a dependency of the UndertowDeploymentService -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8136) Allow JAX-RS annotations in CDI @Stereotype

by Alessio Soldano (Jira)

[ https://issues.jboss.org/browse/WFLY-8136?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated WFLY-8136: ---------------------------------- Fix Version/s: 18.0.0.Beta1 > Allow JAX-RS annotations in CDI @Stereotype > ------------------------------------------- > > Key: WFLY-8136 > URL: https://issues.jboss.org/browse/WFLY-8136 > Project: WildFly > Issue Type: Feature Request > Components: CDI / Weld, REST > Affects Versions: 9.0.1.Final, 15.0.0.Final > Environment: Windows 7, JDK 1.8.0_60 > Reporter: Andreas Klemp > Assignee: Martin Stefanko > Priority: Major > Fix For: 18.0.0.Beta1 > > > A simple JAX-RS REST service can be annotated with @Produces to define the resulting mime-type. However, it is not working anymore, when the annotation is moved to a stereotype. The default application/octet-stream is used. > {code} > @Stereotype > @Produces(MediaType.APPLICATION_JSON) > @Target(ElementType.TYPE) > @Retention(RetentionPolicy.RUNTIME) > public @interface RestService { > } > @Path("/some") > @RestService > public class SomeRestService { > @GET > @Path("/") > public Response getSome() { > return Response.ok().entity("{\"x\" : 42, \"y\" : \"foo\"}").build(); > } > } > {code} > Using the following dependencies in Gradle project. > {noformat} > providedCompile( > [group: 'javax.enterprise', name: 'cdi-api', version: '1.2'], > [group: 'org.jboss.spec.javax.ws.rs', name: 'jboss-jaxrs-api_2.0_spec', version: '1.0.0.Final'], > [group: 'com.fasterxml.jackson.core', name: 'jackson-databind', version: '2.7.4'] > ) > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8136) Allow JAX-RS annotations in CDI @Stereotype

by Alessio Soldano (Jira)

[ https://issues.jboss.org/browse/WFLY-8136?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated WFLY-8136: ---------------------------------- Summary: Allow JAX-RS annotations in CDI @Stereotype (was: allow JAX-RS annotations in CDI @Stereotype) > Allow JAX-RS annotations in CDI @Stereotype > ------------------------------------------- > > Key: WFLY-8136 > URL: https://issues.jboss.org/browse/WFLY-8136 > Project: WildFly > Issue Type: Feature Request > Components: CDI / Weld, REST > Affects Versions: 9.0.1.Final, 15.0.0.Final > Environment: Windows 7, JDK 1.8.0_60 > Reporter: Andreas Klemp > Assignee: Martin Stefanko > Priority: Major > Fix For: 18.0.0.Beta1 > > > A simple JAX-RS REST service can be annotated with @Produces to define the resulting mime-type. However, it is not working anymore, when the annotation is moved to a stereotype. The default application/octet-stream is used. > {code} > @Stereotype > @Produces(MediaType.APPLICATION_JSON) > @Target(ElementType.TYPE) > @Retention(RetentionPolicy.RUNTIME) > public @interface RestService { > } > @Path("/some") > @RestService > public class SomeRestService { > @GET > @Path("/") > public Response getSome() { > return Response.ok().entity("{\"x\" : 42, \"y\" : \"foo\"}").build(); > } > } > {code} > Using the following dependencies in Gradle project. > {noformat} > providedCompile( > [group: 'javax.enterprise', name: 'cdi-api', version: '1.2'], > [group: 'org.jboss.spec.javax.ws.rs', name: 'jboss-jaxrs-api_2.0_spec', version: '1.0.0.Final'], > [group: 'com.fasterxml.jackson.core', name: 'jackson-databind', version: '2.7.4'] > ) > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-779) Preapare clean up script for ocp clusters

by Filip Brychta (Jira)

Filip Brychta created SWSQE-779: ----------------------------------- Summary: Preapare clean up script for ocp clusters Key: SWSQE-779 URL: https://issues.jboss.org/browse/SWSQE-779 Project: Kiali QE Issue Type: QE Task Reporter: Filip Brychta Assignee: Filip Brychta We run our ocp clusters in PSI where we don't have enough storage. We need to run some clean up script regularly to save disk space -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11907) NPE trying to use Resteasy Client inside CDI Async Event

by Alessio Soldano (Jira)

[ https://issues.jboss.org/browse/WFLY-11907?page=com.atlassian.jira.plugin... ] Alessio Soldano commented on WFLY-11907: ---------------------------------------- Sorry for the late feedback here. It really looks like this is something that CDI impl solves by setting the TCCL, which RESTEasy expect to be available for looking up configured providers. As part of RESTEASY-2247 we'll see if we can have a fallback mechanism (rely on the defining classloader for the RegisterBuiltin class may be?) or simply print a WARN message and move on. > NPE trying to use Resteasy Client inside CDI Async Event > -------------------------------------------------------- > > Key: WFLY-11907 > URL: https://issues.jboss.org/browse/WFLY-11907 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, REST > Affects Versions: 14.0.0.Final, 16.0.0.Final > Reporter: Cody Lerum > Assignee: Ronald Sigal > Priority: Major > > When attempting to use the Resteasy Client inside a CDI Async Event a NPE is thrown. > {code} > 12:49:33,513 ERROR [stderr] (Weld Thread Pool -- 4) java.lang.RuntimeException: java.lang.NullPointerException > 12:49:33,514 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.resteasy.plugins.providers.RegisterBuiltin.register(RegisterBuiltin.java:49) > 12:49:33,514 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.resteasy.client.jaxrs.ResteasyClientBuilder.getProviderFactory(ResteasyClientBuilder.java:362) > 12:49:33,514 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.resteasy.client.jaxrs.ResteasyClientBuilder.build(ResteasyClientBuilder.java:395) > 12:49:33,514 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.resteasy.client.jaxrs.ResteasyClientBuilder.build(ResteasyClientBuilder.java:38) > 12:49:33,514 ERROR [stderr] (Weld Thread Pool -- 4) at com.outjected.demo.ResteasyClientEventObserver.load(ResteasyClientEventObserver.java:28) > 12:49:33,514 ERROR [stderr] (Weld Thread Pool -- 4) at com.outjected.demo.ResteasyClientEventObserver.observeAsync(ResteasyClientEventObserver.java:23) > 12:49:33,514 ERROR [stderr] (Weld Thread Pool -- 4) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > 12:49:33,514 ERROR [stderr] (Weld Thread Pool -- 4) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at java.lang.reflect.Method.invoke(Method.java:498) > 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:95) > 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:85) > 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.injection.MethodInvocationStrategy$DefaultMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:109) > 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:330) > 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:308) > 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:286) > 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at javax.enterprise.inject.spi.ObserverMethod.notify(ObserverMethod.java:124) > 12:49:33,515 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.util.Observers.notify(Observers.java:166) > 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.event.ObserverNotifier.notifyAsyncObserver(ObserverNotifier.java:413) > 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.event.ObserverNotifier.lambda$notifyAsyncObservers$5(ObserverNotifier.java:356) > 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.event.ObserverNotifier.lambda$null$8(ObserverNotifier.java:438) > 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.security.spi.SecurityServices.lambda$getSecurityContextAssociator$0(SecurityServices.java:80) > 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.weld.event.ObserverNotifier.lambda$createSupplier$9(ObserverNotifier.java:435) > 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at java.util.concurrent.CompletableFuture$AsyncSupply.run$$$capture(CompletableFuture.java:1590) > 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java) > 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > 12:49:33,516 ERROR [stderr] (Weld Thread Pool -- 4) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > 12:49:33,517 ERROR [stderr] (Weld Thread Pool -- 4) at java.lang.Thread.run(Thread.java:748) > 12:49:33,517 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.threads.JBossThread.run(JBossThread.java:485) > 12:49:33,517 ERROR [stderr] (Weld Thread Pool -- 4) Caused by: java.lang.NullPointerException > 12:49:33,517 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.resteasy.plugins.providers.RegisterBuiltin.registerProviders(RegisterBuiltin.java:60) > 12:49:33,517 ERROR [stderr] (Weld Thread Pool -- 4) at org.jboss.resteasy.plugins.providers.RegisterBuiltin.register(RegisterBuiltin.java:45) > 12:49:33,517 ERROR [stderr] (Weld Thread Pool -- 4) ... 28 more > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12167) Memory leak in metrics in standalone-ha configuration

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFLY-12167?page=com.atlassian.jira.plugin... ] Jeff Mesnil reassigned WFLY-12167: ---------------------------------- Assignee: Paul Ferraro (was: Jeff Mesnil) > Memory leak in metrics in standalone-ha configuration > ----------------------------------------------------- > > Key: WFLY-12167 > URL: https://issues.jboss.org/browse/WFLY-12167 > Project: WildFly > Issue Type: Bug > Components: Clustering, MP Metrics > Affects Versions: 16.0.0.Final > Reporter: Bernd Stolle > Assignee: Paul Ferraro > Priority: Blocker > Labels: memoryleak > Attachments: Screenshot 2019-06-06 at 11.07.00.png > > > When started in standalone HA configuration every request to the recently added metrics endpoint ({{<management-if>:9990/metrics}}) lead to an increase in memory consumption until the JVM is slowed down significantly by GC to a point where even the requests to {{/health}} fail within a reasonable timeout (2s) and untlimately lead to OOM. > The same issue does not occur when WildFly is started in the default standalone configuration (non HA). > I can provide a (compressed) heap dump if required. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12167) Memory leak in metrics in standalone-ha configuration

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFLY-12167?page=com.atlassian.jira.plugin... ] Jeff Mesnil updated WFLY-12167: ------------------------------- Component/s: Clustering > Memory leak in metrics in standalone-ha configuration > ----------------------------------------------------- > > Key: WFLY-12167 > URL: https://issues.jboss.org/browse/WFLY-12167 > Project: WildFly > Issue Type: Bug > Components: Clustering, MP Metrics > Affects Versions: 16.0.0.Final > Reporter: Bernd Stolle > Assignee: Jeff Mesnil > Priority: Major > Labels: memoryleak > Attachments: Screenshot 2019-06-06 at 11.07.00.png > > > When started in standalone HA configuration every request to the recently added metrics endpoint ({{<management-if>:9990/metrics}}) lead to an increase in memory consumption until the JVM is slowed down significantly by GC to a point where even the requests to {{/health}} fail within a reasonable timeout (2s) and untlimately lead to OOM. > The same issue does not occur when WildFly is started in the default standalone configuration (non HA). > I can provide a (compressed) heap dump if required. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 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 June 2019