June 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13546) Upgrade smallrye-open-api to 1.2.5

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-13546: ----------------------------------- Summary: Upgrade smallrye-open-api to 1.2.5 Key: WFLY-13546 URL: https://issues.redhat.com/browse/WFLY-13546 Project: WildFly Issue Type: Component Upgrade Components: MP OpenAPI Affects Versions: 20.0.0.Beta1 Reporter: Paul Ferraro Assignee: Paul Ferraro Fixes https://github.com/smallrye/smallrye-open-api/issues/349 -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13545) Smallrye OpenAPI annotaton scanner throws StackOverflowError when processing JAX-RS resource classes which implement a locator that will return the class itself

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13545?page=com.atlassian.jira.plugi... ] Paul Ferraro moved JBEAP-19601 to WFLY-13545: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-13545 (was: JBEAP-19601) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: MP OpenAPI (was: MP OpenAPI) Affects Version/s: 20.0.0.Beta1 (was: EAP-XP-1.0.0.GA-CR1) (was: EAP-XP-1.0.0.GA-CR2) > Smallrye OpenAPI annotaton scanner throws StackOverflowError when processing JAX-RS resource classes which implement a locator that will return the class itself > ---------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-13545 > URL: https://issues.redhat.com/browse/WFLY-13545 > Project: WildFly > Issue Type: Bug > Components: MP OpenAPI > Affects Versions: 20.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > When deploying a WAR which contains a JAX-RS resource class which is declaring a locator that is supposed to return the resource class itself - i.e. {{this}} - the depoyment fails with a {{StackOverflowError}}. > The annotation scanner loops until the stack overflow happens because it tries to process the JAX-RS resource class recursively and maybe the process tself should be protected against this case. > The following stack trace represents the output of a deployment failure when an attempt to deploy a WAR with such a resource: > {code} > at org.jboss.logging@3.4.1.Final-redhat-00001//org.jboss.logging.Logger.getLogger(Logger.java:2490) > at io.smallrye.openapi//io.smallrye.openapi.runtime.scanner.dataobject.DataObjectDeque.<init>(DataObjectDeque.java:38) > at io.smallrye.openapi//io.smallrye.openapi.runtime.scanner.OpenApiDataObjectScanner.<init>(OpenApiDataObjectScanner.java:138) > at io.smallrye.openapi//io.smallrye.openapi.runtime.scanner.OpenApiDataObjectScanner.process(OpenApiDataObjectScanner.java:163) > at io.smallrye.openapi//io.smallrye.openapi.runtime.util.SchemaFactory.typeToSchema(SchemaFactory.java:360) > at io.smallrye.openapi//io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.createResponseFromJaxRsMethod(OpenApiAnnotationScanner.java:924) > at io.smallrye.openapi//io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsMethod(OpenApiAnnotationScanner.java:688) > at io.smallrye.openapi//io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.lambda$processJaxRsResourceClass$0(OpenApiAnnotationScanner.java:422) > at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) > at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) > at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) > at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177) > at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1603) > at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) > at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) > at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) > at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) > at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497) > at io.smallrye.openapi//io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsResourceClass(OpenApiAnnotationScanner.java:420) > at io.smallrye.openapi//io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsSubResource(OpenApiAnnotationScanner.java:511) > at io.smallrye.openapi//io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsResourceClass(OpenApiAnnotationScanner.java:426) > at io.smallrye.openapi//io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsSubResource(OpenApiAnnotationScanner.java:511) > at io.smallrye.openapi//io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsResourceClass(OpenApiAnnotationScanner.java:426) > at io.smallrye.openapi//io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner.processJaxRsSubResource(OpenApiAnnotationScanner.java:511) > ... > {code} > The failure was initially noticed during RESTEasy tests against EAP XP 1.0.0 CR1 and CR2. > The SmallRye OpenAPI versions that I tested this against are 1.1.21 and 1.1.22. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13542) Container does not enforce bean-managed concurrency for timeout methods

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-13542?page=com.atlassian.jira.plugi... ] Cheng Fang commented on WFLY-13542: ----------------------------------- I don't think this is a bug. See related issue AS7-3119 for detailed discussion. When multiple executions of the same timer overlaps while the first exection is still running, WildFly drops other overlapping executions of the same timer, to prevent over-flooding the bean instance and also to avoid confusing users. After all, the purpose of a specific timer is to do something at a certain time, which is already fulfilled by running the first execution. > Container does not enforce bean-managed concurrency for timeout methods > ----------------------------------------------------------------------- > > Key: WFLY-13542 > URL: https://issues.redhat.com/browse/WFLY-13542 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 19.1.0.Final > Reporter: Fábio Silva > Assignee: Cheng Fang > Priority: Major > > Bean-managed concurrency for @Singleton EJBs is not enforced for timeout methods annotated with @Schedule. When a timeout is fired while the previous one is still running, the timeout method is not called. Instead, WildFly logs a warning like the following: > {code:java} > 20:58:54,000 WARN [org.jboss.as.ejb3.timer] (EJB default - 2) WFLYEJB0043: A previous execution of timer [id=aa716284-ef7b-4bb3-a356-a8ca187255c4 timedObjectId=myweb.myweb.MySingleton auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@303bd2d5 previousRun=Sun May 31 20:57:10 BRT 2020 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Sun May 31 20:58:54 BRT 2020 timerState=IN_TIMEOUT info=null] ScheduleExpression [second=0/1;minute=*;hour=*;dayOfMonth=*;month=*;dayOfWeek=*;year=*;timezoneID=null;start=null;end=null] is still in progress, skipping this overlapping scheduled execution at: Sun May 31 20:58:54 BRT 2020. > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13540) Ensure DefaultJMSConnection factory is first in the list to avoid null jndi bindings

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13540?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-13540: ----------------------------------------- [~luck3y] Is the plan for resolving this to resolve it with a fix version of whatever wildfly s2i release will incorporate the wildfly-cekit-modules change? > Ensure DefaultJMSConnection factory is first in the list to avoid null jndi bindings > ------------------------------------------------------------------------------------ > > Key: WFLY-13540 > URL: https://issues.redhat.com/browse/WFLY-13540 > Project: WildFly > Issue Type: Bug > Reporter: Ken Wills > Assignee: Ken Wills > Priority: Critical > > See: WFLY-13424 for underlying cause. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4972) LayersTest doesn't follow module aliases

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFCORE-4972?page=com.atlassian.jira.plug... ] Brian Stansberry updated WFCORE-4972: ------------------------------------- Summary: LayersTest doesn't follow module aliases (was: LatersTest doesn't follow module aliases) > LayersTest doesn't follow module aliases > ---------------------------------------- > > Key: WFCORE-4972 > URL: https://issues.redhat.com/browse/WFCORE-4972 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Jean Francois Denise > Assignee: Jean Francois Denise > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4926) Upgrade WildFly Elytron from 1.11.3.Final to 1.11.4.Final

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFCORE-4926?page=com.atlassian.jira.plug... ] Brian Stansberry updated WFCORE-4926: ------------------------------------- Security: (was: Red Hat Internal) > Upgrade WildFly Elytron from 1.11.3.Final to 1.11.4.Final > --------------------------------------------------------- > > Key: WFCORE-4926 > URL: https://issues.redhat.com/browse/WFCORE-4926 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Ilia Vassilev > Assignee: Darran Lofthouse > Priority: Major > Labels: downstream_dependency > Fix For: 12.0.0.Beta3 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4928) Upgrade WildFly Elytron Web from 1.7.0.Final to 1.7.1.Final

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFCORE-4928?page=com.atlassian.jira.plug... ] Brian Stansberry updated WFCORE-4928: ------------------------------------- Security: (was: Red Hat Internal) > Upgrade WildFly Elytron Web from 1.7.0.Final to 1.7.1.Final > ----------------------------------------------------------- > > Key: WFCORE-4928 > URL: https://issues.redhat.com/browse/WFCORE-4928 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Ilia Vassilev > Assignee: Darran Lofthouse > Priority: Major > Labels: downstream_dependency > Fix For: 12.0.0.Beta2 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4959) Feature for checking module installation in JBoss

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFCORE-4959?page=com.atlassian.jira.plug... ] Brian Stansberry updated WFCORE-4959: ------------------------------------- Labels: domain-mode (was: ) > Feature for checking module installation in JBoss > ------------------------------------------------- > > Key: WFCORE-4959 > URL: https://issues.redhat.com/browse/WFCORE-4959 > Project: WildFly Core > Issue Type: Feature Request > Reporter: Joao Paulo Goncalves > Assignee: Brian Stansberry > Priority: Major > Labels: domain-mode > > Using CLI tool or Administrative Console is not possible at this moment to check if a custom added module was added correctly, especially in domain mode. The only alternative available is to add host per host. This approach takes time, and for unused users there isn't some visual (GUI) to help them. > JBoss CLI approach: > module --add --source=jar1,jar2 --target=/path-of-module --host=your-host OR module --add --source=jar1,jar2 --target=/path-of-module --host=all (deploy the module in all hosts that belongs to the domain) -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4959) Feature for checking module installation in JBoss

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFCORE-4959?page=com.atlassian.jira.plug... ] Brian Stansberry reassigned WFCORE-4959: ---------------------------------------- Assignee: (was: Brian Stansberry) > Feature for checking module installation in JBoss > ------------------------------------------------- > > Key: WFCORE-4959 > URL: https://issues.redhat.com/browse/WFCORE-4959 > Project: WildFly Core > Issue Type: Feature Request > Components: Management > Reporter: Joao Paulo Goncalves > Priority: Major > Labels: domain-mode > > Using CLI tool or Administrative Console is not possible at this moment to check if a custom added module was added correctly, especially in domain mode. The only alternative available is to add host per host. This approach takes time, and for unused users there isn't some visual (GUI) to help them. > JBoss CLI approach: > module --add --source=jar1,jar2 --target=/path-of-module --host=your-host OR module --add --source=jar1,jar2 --target=/path-of-module --host=all (deploy the module in all hosts that belongs to the domain) -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4959) Feature for checking module installation in JBoss

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFCORE-4959?page=com.atlassian.jira.plug... ] Brian Stansberry updated WFCORE-4959: ------------------------------------- Component/s: Management > Feature for checking module installation in JBoss > ------------------------------------------------- > > Key: WFCORE-4959 > URL: https://issues.redhat.com/browse/WFCORE-4959 > Project: WildFly Core > Issue Type: Feature Request > Components: Management > Reporter: Joao Paulo Goncalves > Assignee: Brian Stansberry > Priority: Major > Labels: domain-mode > > Using CLI tool or Administrative Console is not possible at this moment to check if a custom added module was added correctly, especially in domain mode. The only alternative available is to add host per host. This approach takes time, and for unused users there isn't some visual (GUI) to help them. > JBoss CLI approach: > module --add --source=jar1,jar2 --target=/path-of-module --host=your-host OR module --add --source=jar1,jar2 --target=/path-of-module --host=all (deploy the module in all hosts that belongs to the domain) -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 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 June 2020