December 2020 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (WFCORE-5203) Update Google guava to 30.0-jre

by Boris Unckel (Jira)

[ https://issues.redhat.com/browse/WFCORE-5203?page=com.atlassian.jira.plug... ] Boris Unckel commented on WFCORE-5203: -------------------------------------- [~brian.stansberry] [PR 13788|https://github.com/wildfly/wildfly/pull/13788] will fail as long as WF CORE [PR 4406|https://github.com/wildfly/wildfly-core/pull/4406] is missing. WF CORE PR 4406 integration test will fail, as long as PR 13788 is missing. > Update Google guava to 30.0-jre > ------------------------------- > > Key: WFCORE-5203 > URL: https://issues.redhat.com/browse/WFCORE-5203 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Test Suite > Affects Versions: 14.0.0.Beta2 > Reporter: Boris Unckel > Priority: Major > > Update Google guava to [30.0-jre|https://mvnrepository.com/artifact/com.google.guava/guava/30.0-jre]. Exclude all dependencies but [failureaccess 1.0.1|https://mvnrepository.com/artifact/com.google.guava/failureaccess/1...] according to [Google Guava Important Warnings #3|https://github.com/google/guava]. > [Release Notes|https://github.com/google/guava/releases/tag/v30.0] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14163) Move "org.bouncycastle:bcmail-jdk15on" Dependency Management to WildFly Core

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-14163?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-14163: ------------------------------------ Git Pull Request: https://github.com/wildfly/wildfly/pull/13786 (was: https://github.com/wildfly/wildfly/pull/13780) > Move "org.bouncycastle:bcmail-jdk15on" Dependency Management to WildFly Core > ---------------------------------------------------------------------------- > > Key: WFLY-14163 > URL: https://issues.redhat.com/browse/WFLY-14163 > Project: WildFly > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 22.0.0.Beta1 > > > At the moment this is defined in WildFly but it means the version is not in sync with the other BouncyCastle modules which are defined in WildFly Core. > There are a couple of other examples where dependency management happens in core for a module which is defined in WildFly such as Under and Elytron Web servlet specific modules. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-13954) Class not found error in Jakarta EE 9 deployment stage

by hantsy bai (Jira)

[ https://issues.redhat.com/browse/WFLY-13954?page=com.atlassian.jira.plugi... ] hantsy bai closed WFLY-13954. ----------------------------- Resolution: Not a Bug > Class not found error in Jakarta EE 9 deployment stage > ------------------------------------------------------ > > Key: WFLY-13954 > URL: https://issues.redhat.com/browse/WFLY-13954 > Project: WildFly > Issue Type: Bug > Components: EE > Affects Versions: 21.0.0.Beta1 > Reporter: hantsy bai > Assignee: Brian Stansberry > Priority: Major > > When I deployed a Jakarata EE 9 applicaiton into 21, got the following exception in the deployment progress. > {code} > 11:05:04,558 INFO [org.jboss.weld.Bootstrap] (Weld Thread Pool -- 4) WELD-000119: Not generating any bean definitions from com.example.GreetingResource because of underlying class loa > ding error: Type jakarta.ws.rs.core.Response from [Module "deployment.jakartaee9-starter-boilerplate.war" from Service Module Loader] not found. If this is unexpected, enable DEBUG lo > gging to see the full error. > 11:05:04,558 WARN [org.jboss.modules.define] (Weld Thread Pool -- 2) Failed to define class com.example.JaxrsActivator in Module "deployment.jakartaee9-starter-boilerplate.war" from S > ervice Module Loader: java.lang.NoClassDefFoundError: Failed to link com/example/JaxrsActivator (Module "deployment.jakartaee9-starter-boilerplate.war" from Service Module Loader): jak > arta/ws/rs/core/Application > at java.base/java.lang.ClassLoader.defineClass1(Native Method) > at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017) > at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1096) > at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:424) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:555) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126) > at org.jboss.modules.Module.loadModuleClass(Module.java:731) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > at org.jboss.as.weld@21.0.0.Beta1//org.jboss.as.weld.WeldModuleResourceLoader.classForName(WeldModuleResourceLoader.java:68) > at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadClass(AnnotatedTypeLoader.java:82) > at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadAnnotatedType(AnnotatedTypeLoader.java:62) > at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.bootstrap.FastAnnotatedTypeLoader.loadAnnotatedType(FastAnnotatedTypeLoader.java:108) > at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:87) > at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:55) > at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:52) > at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62) > at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > at org.jboss.threads@2.4.0.Final//org.jboss.threads.JBossThread.run(JBossThread.java:513) > 11:05:04,558 INFO [org.jboss.weld.Bootstrap] (Weld Thread Pool -- 2) WELD-000119: Not generating any bean definitions from com.example.JaxrsActivator because of underlying class loadi > ng error: Type Failed to link com.example.JaxrsActivator (Module "deployment.jakartaee9-starter-boilerplate.war" from Service Module Loader): jakarta.ws.rs.core.Application not found. > If this is unexpected, enable DEBUG logging to see the full error. > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-13954) Class not found error in Jakarta EE 9 deployment stage

by hantsy bai (Jira)

[ https://issues.redhat.com/browse/WFLY-13954?page=com.atlassian.jira.plugi... ] hantsy bai commented on WFLY-13954: ----------------------------------- Thanks. > Class not found error in Jakarta EE 9 deployment stage > ------------------------------------------------------ > > Key: WFLY-13954 > URL: https://issues.redhat.com/browse/WFLY-13954 > Project: WildFly > Issue Type: Bug > Components: EE > Affects Versions: 21.0.0.Beta1 > Reporter: hantsy bai > Assignee: Brian Stansberry > Priority: Major > > When I deployed a Jakarata EE 9 applicaiton into 21, got the following exception in the deployment progress. > {code} > 11:05:04,558 INFO [org.jboss.weld.Bootstrap] (Weld Thread Pool -- 4) WELD-000119: Not generating any bean definitions from com.example.GreetingResource because of underlying class loa > ding error: Type jakarta.ws.rs.core.Response from [Module "deployment.jakartaee9-starter-boilerplate.war" from Service Module Loader] not found. If this is unexpected, enable DEBUG lo > gging to see the full error. > 11:05:04,558 WARN [org.jboss.modules.define] (Weld Thread Pool -- 2) Failed to define class com.example.JaxrsActivator in Module "deployment.jakartaee9-starter-boilerplate.war" from S > ervice Module Loader: java.lang.NoClassDefFoundError: Failed to link com/example/JaxrsActivator (Module "deployment.jakartaee9-starter-boilerplate.war" from Service Module Loader): jak > arta/ws/rs/core/Application > at java.base/java.lang.ClassLoader.defineClass1(Native Method) > at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017) > at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1096) > at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:424) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:555) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126) > at org.jboss.modules.Module.loadModuleClass(Module.java:731) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > at org.jboss.as.weld@21.0.0.Beta1//org.jboss.as.weld.WeldModuleResourceLoader.classForName(WeldModuleResourceLoader.java:68) > at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadClass(AnnotatedTypeLoader.java:82) > at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadAnnotatedType(AnnotatedTypeLoader.java:62) > at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.bootstrap.FastAnnotatedTypeLoader.loadAnnotatedType(FastAnnotatedTypeLoader.java:108) > at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:87) > at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:55) > at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:52) > at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62) > at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > at org.jboss.threads@2.4.0.Final//org.jboss.threads.JBossThread.run(JBossThread.java:513) > 11:05:04,558 INFO [org.jboss.weld.Bootstrap] (Weld Thread Pool -- 2) WELD-000119: Not generating any bean definitions from com.example.JaxrsActivator because of underlying class loadi > ng error: Type Failed to link com.example.JaxrsActivator (Module "deployment.jakartaee9-starter-boilerplate.war" from Service Module Loader): jakarta.ws.rs.core.Application not found. > If this is unexpected, enable DEBUG logging to see the full error. > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-5217) Add deployment Phase constants for Reactive Messaging and RSO

by Kabir Khan (Jira)

Kabir Khan created WFCORE-5217: ---------------------------------- Summary: Add deployment Phase constants for Reactive Messaging and RSO Key: WFCORE-5217 URL: https://issues.redhat.com/browse/WFCORE-5217 Project: WildFly Core Issue Type: Task Components: Server Reporter: Kabir Khan Assignee: Kabir Khan -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-13949) JNDI lookup for JMS Queue failing

by Francis Griffin (Jira)

[ https://issues.redhat.com/browse/WFLY-13949?page=com.atlassian.jira.plugi... ] Francis Griffin commented on WFLY-13949: ---------------------------------------- Ping ? > JNDI lookup for JMS Queue failing > --------------------------------- > > Key: WFLY-13949 > URL: https://issues.redhat.com/browse/WFLY-13949 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 20.0.1.Final > Reporter: Francis Griffin > Assignee: Emmanuel Hugonnet > Priority: Major > Attachments: dpsrTest.tgz, dpsrTest.tgz, dpsrTest.tgz > > > I have a JMS app which has been running successfully under WF10 for some years. I'm trying to migrate to WF20, but getting an error trying to look up the JMS Queue. The JDK is OpenJDK 11. > I've tried to make the reproducible case as simple as possible. The server is unpacked from the downloaded tar.gz, and is not modified except to add a guest user for JMS (which is not needed for the reproducible case, since we never actually create a Connection). The queue is the DLQ queue defined in the distribution. > The error is a NameNotFoundException: > Exception in thread "main" javax.naming.NameNotFoundException: jms/queue -- service jboss.naming.context.java.jboss.exported.jms.queue > at org.jboss.as.naming@20.0.1.Final//org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) > at org.jboss.as.naming@20.0.1.Final//org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207) > at org.jboss.as.naming@20.0.1.Final//org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193) > at org.jboss.as.naming@20.0.1.Final//org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189) > at org.wildfly.naming-client@1.0.13.Final//org.wildfly.naming.client.remote.RemoteServerTransport.handleLookup(RemoteServerTransport.java:203) > at org.wildfly.naming-client@1.0.13.Final//org.wildfly.naming.client.remote.RemoteServerTransport$1.handleMessage(RemoteServerTransport.java:123) > at org.jboss.remoting@5.0.18.Final//org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430) > at org.jboss.remoting@5.0.18.Final//org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:991) > at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) > at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) > at java.base/java.lang.Thread.run(Thread.java:834) > No matter what queue name I use, the lookup is failing on the string jms/queue rather than the expected jms/queue/DLQ. > I fully expect that this is some stupid error on my part, something I'm looking at and just not seeing, because I know of others (albeit using Windows) who are using 20.0.1.Final for the full app without issue. But I can't for the life of me see what it is. > Tha actual full application looks up a ConnectionFactory of "jms/RemoteConnectionFactory" and creates Connections and Sessions before looking up the Queue name. The lookup for the factory name works perfectly, as does the other stuff, but the lookup for the Queue name gets the same NameNotFoundException shown above. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFWIP-338) Bootable JAR - Cloud - Enable json logging

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFWIP-338?page=com.atlassian.jira.plugin... ] James Perkins commented on WFWIP-338: ------------------------------------- This would be my suggestion https://github.com/wildfly-extras/wildfly-jar-maven-plugin/pull/171. > Bootable JAR - Cloud - Enable json logging > ------------------------------------------ > > Key: WFWIP-338 > URL: https://issues.redhat.com/browse/WFWIP-338 > Project: WildFly WIP > Issue Type: Enhancement > Reporter: Jean Francois Denise > Assignee: Jean Francois Denise > Priority: Major > > In an openshift context it would be interesting to enable json logging. For Bootable JAR we would evolve the <cloud> element with <enable-json-logging>true|false</enable-json-logging>. > Logging subsystem and logging.properties would have to be updated during packaging. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14168) Override README.txt in WildFly Preview

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-14168: --------------------------------------- Summary: Override README.txt in WildFly Preview Key: WFLY-14168 URL: https://issues.redhat.com/browse/WFLY-14168 Project: WildFly Issue Type: Task Components: Server Reporter: Brian Stansberry Assignee: Brian Stansberry Use a different README.txt in WildFly Preview that explains a bit about its TP nature and, at least for now, talks a bit about the bytecode transformation stuff. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-13640) Provide Support for MicroProfile Reactive Messaging 1.0 for Kafka

by Kabir Khan (Jira)

[ https://issues.redhat.com/browse/WFLY-13640?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFLY-13640: ------------------------------ Summary: Provide Support for MicroProfile Reactive Messaging 1.0 for Kafka (was: Provide Support for MicroProfile Reactive Messaging) > Provide Support for MicroProfile Reactive Messaging 1.0 for Kafka > ----------------------------------------------------------------- > > Key: WFLY-13640 > URL: https://issues.redhat.com/browse/WFLY-13640 > Project: WildFly > Issue Type: Feature Request > Reporter: Bilgehan Ozpeynirci > Assignee: Kabir Khan > Priority: Major > > This currently lives in [https://github.com/wildfly-extras/wildfly-mp-reactive-feature-pack]. Investigate stability and readiness for inclusion in WildFly. This may be using the upcoming feature-pack artifact dependency mechanism > > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14167) Concurrent @Stateful EJB invocations to different cluster members do not respect @AccessTimeout

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-14167: ----------------------------------- Summary: Concurrent @Stateful EJB invocations to different cluster members do not respect @AccessTimeout Key: WFLY-14167 URL: https://issues.redhat.com/browse/WFLY-14167 Project: WildFly Issue Type: Bug Components: Clustering, EJB Affects Versions: 21.0.1.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Currently, @Stateful EJB sychronization is handled by the StatefulSessionSynchronizationInterceptor. However, this mechanism is not cluster aware. Consequently, if a client makes concurrent invocations to a given EJB on multiple cluster members, synchronization is handled by the EJB cache itself, ignoring any AccessTimeout defined by the bean or method. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 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 December 2020