[Red Hat JIRA] (WFCORE-5155) A NullPointException was found in a wildfly-jar-maven-plugin test
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFCORE-5155?page=com.atlassian.jira.plug... ]
James Perkins edited comment on WFCORE-5155 at 10/12/20 6:10 PM:
-----------------------------------------------------------------
This appears to be a race between the {{LogContextConfiguration.prepare()}} being invoked and the service starting. The prepare should be invoked before the service is even started.
I've raised the priority to critical as this could result in a {{socket-handler}} failing to be added even during boot.
was (Author: jamezp):
This appears to be a race between the {{LogContextConfiguration.prepare()}} being invoked and the service starting. The prepare should be invoked before the service is even started.
> A NullPointException was found in a wildfly-jar-maven-plugin test
> -----------------------------------------------------------------
>
> Key: WFCORE-5155
> URL: https://issues.redhat.com/browse/WFCORE-5155
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Critical
>
> WFCORE-5114 made a slight change with how the configuration API commits the logging changes. When upgrading the core version in wildfly-jar-maven-plugin a test failure occurred in the PR https://github.com/wildfly-extras/wildfly-jar-maven-plugin/pull/137.
> {code}
> Error: BootLoggingConfigurationTestCase.testSocketHandler:321->executeOperation:711 Operation {
> "operation" => "composite",
> "address" => [],
> "rollback-on-runtime-failure" => true,
> "steps" => [
> {
> "operation" => "add",
> "address" => [
> ("socket-binding-group" => "standard-sockets"),
> ("remote-destination-outbound-socket-binding" => "log-server")
> ],
> "host" => "127.0.0.1",
> "port" => 10514
> },
> {
> "operation" => "add",
> "address" => [
> ("subsystem" => "logging"),
> ("socket-handler" => "socket")
> ],
> "named-formatter" => "PATTERN",
> "outbound-socket-binding-ref" => "log-server"
> },
> {
> "operation" => "add-handler",
> "address" => [
> ("subsystem" => "logging"),
> ("root-logger" => "ROOT")
> ],
> "name" => "socket"
> }
> ]
> } failed: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => {"WFLYCTL0080: Failed services" => {"org.wildfly.logging.handler.\"org.wildfly.logging.handler.socket\"" => "Failed to start service
> Caused by: java.lang.NullPointerException"}}}}
> {code}
> The NPE is in the service where the {{DelayedHandler}} instance is used, but returns {{null}} for some reason. I could not reproduce this locally, however it did happen locally for me with the {{ascyn-handler}} in the test. This may be a way to reproduce this locally.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFCORE-5155) A NullPointException was found in a wildfly-jar-maven-plugin test
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFCORE-5155?page=com.atlassian.jira.plug... ]
James Perkins updated WFCORE-5155:
----------------------------------
Priority: Critical (was: Major)
> A NullPointException was found in a wildfly-jar-maven-plugin test
> -----------------------------------------------------------------
>
> Key: WFCORE-5155
> URL: https://issues.redhat.com/browse/WFCORE-5155
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Critical
>
> WFCORE-5114 made a slight change with how the configuration API commits the logging changes. When upgrading the core version in wildfly-jar-maven-plugin a test failure occurred in the PR https://github.com/wildfly-extras/wildfly-jar-maven-plugin/pull/137.
> {code}
> Error: BootLoggingConfigurationTestCase.testSocketHandler:321->executeOperation:711 Operation {
> "operation" => "composite",
> "address" => [],
> "rollback-on-runtime-failure" => true,
> "steps" => [
> {
> "operation" => "add",
> "address" => [
> ("socket-binding-group" => "standard-sockets"),
> ("remote-destination-outbound-socket-binding" => "log-server")
> ],
> "host" => "127.0.0.1",
> "port" => 10514
> },
> {
> "operation" => "add",
> "address" => [
> ("subsystem" => "logging"),
> ("socket-handler" => "socket")
> ],
> "named-formatter" => "PATTERN",
> "outbound-socket-binding-ref" => "log-server"
> },
> {
> "operation" => "add-handler",
> "address" => [
> ("subsystem" => "logging"),
> ("root-logger" => "ROOT")
> ],
> "name" => "socket"
> }
> ]
> } failed: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => {"WFLYCTL0080: Failed services" => {"org.wildfly.logging.handler.\"org.wildfly.logging.handler.socket\"" => "Failed to start service
> Caused by: java.lang.NullPointerException"}}}}
> {code}
> The NPE is in the service where the {{DelayedHandler}} instance is used, but returns {{null}} for some reason. I could not reproduce this locally, however it did happen locally for me with the {{ascyn-handler}} in the test. This may be a way to reproduce this locally.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFCORE-5155) A NullPointException was found in a wildfly-jar-maven-plugin test
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFCORE-5155?page=com.atlassian.jira.plug... ]
James Perkins commented on WFCORE-5155:
---------------------------------------
This appears to be a race between the {{LogContextConfiguration.prepare()}} being invoked and the service starting. The prepare should be invoked before the service is even started.
> A NullPointException was found in a wildfly-jar-maven-plugin test
> -----------------------------------------------------------------
>
> Key: WFCORE-5155
> URL: https://issues.redhat.com/browse/WFCORE-5155
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Major
>
> WFCORE-5114 made a slight change with how the configuration API commits the logging changes. When upgrading the core version in wildfly-jar-maven-plugin a test failure occurred in the PR https://github.com/wildfly-extras/wildfly-jar-maven-plugin/pull/137.
> {code}
> Error: BootLoggingConfigurationTestCase.testSocketHandler:321->executeOperation:711 Operation {
> "operation" => "composite",
> "address" => [],
> "rollback-on-runtime-failure" => true,
> "steps" => [
> {
> "operation" => "add",
> "address" => [
> ("socket-binding-group" => "standard-sockets"),
> ("remote-destination-outbound-socket-binding" => "log-server")
> ],
> "host" => "127.0.0.1",
> "port" => 10514
> },
> {
> "operation" => "add",
> "address" => [
> ("subsystem" => "logging"),
> ("socket-handler" => "socket")
> ],
> "named-formatter" => "PATTERN",
> "outbound-socket-binding-ref" => "log-server"
> },
> {
> "operation" => "add-handler",
> "address" => [
> ("subsystem" => "logging"),
> ("root-logger" => "ROOT")
> ],
> "name" => "socket"
> }
> ]
> } failed: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => {"WFLYCTL0080: Failed services" => {"org.wildfly.logging.handler.\"org.wildfly.logging.handler.socket\"" => "Failed to start service
> Caused by: java.lang.NullPointerException"}}}}
> {code}
> The NPE is in the service where the {{DelayedHandler}} instance is used, but returns {{null}} for some reason. I could not reproduce this locally, however it did happen locally for me with the {{ascyn-handler}} in the test. This may be a way to reproduce this locally.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (ELY-1998) IllegalStateException: unable to create JcaTlsCrypto: DEFAULT SecureRandom not available when configuring BC FIPS on JDK 11
by Diana Vilkolakova (Jira)
[ https://issues.redhat.com/browse/ELY-1998?page=com.atlassian.jira.plugin.... ]
Diana Vilkolakova closed ELY-1998.
----------------------------------
Resolution: Explained
> IllegalStateException: unable to create JcaTlsCrypto: DEFAULT SecureRandom not available when configuring BC FIPS on JDK 11
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1998
> URL: https://issues.redhat.com/browse/ELY-1998
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Reporter: Diana Vilkolakova
> Assignee: Diana Vilkolakova
> Priority: Major
>
> The below steps require ELY-1982 bugfix to work.
> Configure security providers in java.security file:
> {code}
> security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
> security.provider.2=org.bouncycastle.jsse.provider.BouncyCastleJsseProvider
> security.provider.3=SUN
> {code}
> Add the bc-fips.jar and bctls-fips-1.0.10.jar to the CLASSPATH and generate keystore in JBOSS_HOME/standalone/configuration folder:
> {code}
> keytool -genkeypair -alias appserver -keyalg RSA -keysize 2048 -keypass password -keystore "fips.keystore" -provider org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider -providerpath $CLASSPATH -storetype BCFKS -storepass password -dname "CN=testserver,OU=TESTOU,O=TESTO,L=TESTL,ST=TESTCZ,C=TESTCZ" -validity 730 -v
> {code}
> Try to configure `server-ssl-context`:
> {code}
> module add --name=org.bouncycastle.fips --resources=/path/to/bc-fips-1.0.2.jar:/path/to/bctls-fips-1.0.10.jar
> /subsystem=elytron/provider-loader=bc:add(module=org.bouncycastle.fips)
> /subsystem=elytron/key-store=fipsKS:add(path=fips.keystore, relative-to=jboss.server.config.dir, credential-reference={clear-text=password}, type="BCFKS", providers=bc)
> /subsystem=elytron/key-manager=fipsKM:add(key-store=fipsKS, algorithm="X509", credential-reference={clear-text=password}, providers=bc)
> /subsystem=elytron/server-ssl-context=fipsSSC:add(key-manager=fipsKM, protocols=["TLSv1.2"], providers=bc)
> {code}
> The last command results in:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.fipsSSC" => "Failed to start service
> Caused by: java.lang.IllegalStateException: unable to create JcaTlsCrypto: DEFAULT SecureRandom not available
> Caused by: java.security.NoSuchAlgorithmException: DEFAULT SecureRandom not available"}},
> "rolled-back" => true
> }
> {code}
> The exception is happening [on this line|https://github.com/Skyllarr/wildfly-elytron/blob/ELY-1982/ssl/src/ma...] . This exception can be avoided by either using *new SecureRandom()* instead of null during initialization of sslContext, or by configuring securerandom with using *CryptoServicesRegistrar.setSecureRandom(new SecureRandom());* in code beforehand (this would require bc dependency).
> I tried to configure secure random statically by setting *securerandom.strongAlgorithms=DEFAULT:BCFIPS* in java.security or by trying to pass secure random as parameter to constructor with
> {code}
> security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider "C:DEFRND[SHA512];ENABLE{ALL};"
> {code}
> but neither had any effect. I did not find how to configure this statically for Java 11 in BC documentation.
> We could pass new instance of SecureRandom when initializing sslContext (if bouncycastle is used), or set secureRandom beforehand, or catch this exception and then use `new SecureRandom()`. But should we force the users to use SecureRandom set in the code by us? If users want to use Bouncycastle they should configure the secure random themselves since it is needed by the provider?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (ELY-1998) IllegalStateException: unable to create JcaTlsCrypto: DEFAULT SecureRandom not available when configuring BC FIPS on JDK 11
by Diana Vilkolakova (Jira)
[ https://issues.redhat.com/browse/ELY-1998?page=com.atlassian.jira.plugin.... ]
Diana Vilkolakova reassigned ELY-1998:
--------------------------------------
Assignee: Diana Vilkolakova
> IllegalStateException: unable to create JcaTlsCrypto: DEFAULT SecureRandom not available when configuring BC FIPS on JDK 11
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1998
> URL: https://issues.redhat.com/browse/ELY-1998
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Reporter: Diana Vilkolakova
> Assignee: Diana Vilkolakova
> Priority: Major
>
> The below steps require ELY-1982 bugfix to work.
> Configure security providers in java.security file:
> {code}
> security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
> security.provider.2=org.bouncycastle.jsse.provider.BouncyCastleJsseProvider
> security.provider.3=SUN
> {code}
> Add the bc-fips.jar and bctls-fips-1.0.10.jar to the CLASSPATH and generate keystore in JBOSS_HOME/standalone/configuration folder:
> {code}
> keytool -genkeypair -alias appserver -keyalg RSA -keysize 2048 -keypass password -keystore "fips.keystore" -provider org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider -providerpath $CLASSPATH -storetype BCFKS -storepass password -dname "CN=testserver,OU=TESTOU,O=TESTO,L=TESTL,ST=TESTCZ,C=TESTCZ" -validity 730 -v
> {code}
> Try to configure `server-ssl-context`:
> {code}
> module add --name=org.bouncycastle.fips --resources=/path/to/bc-fips-1.0.2.jar:/path/to/bctls-fips-1.0.10.jar
> /subsystem=elytron/provider-loader=bc:add(module=org.bouncycastle.fips)
> /subsystem=elytron/key-store=fipsKS:add(path=fips.keystore, relative-to=jboss.server.config.dir, credential-reference={clear-text=password}, type="BCFKS", providers=bc)
> /subsystem=elytron/key-manager=fipsKM:add(key-store=fipsKS, algorithm="X509", credential-reference={clear-text=password}, providers=bc)
> /subsystem=elytron/server-ssl-context=fipsSSC:add(key-manager=fipsKM, protocols=["TLSv1.2"], providers=bc)
> {code}
> The last command results in:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.fipsSSC" => "Failed to start service
> Caused by: java.lang.IllegalStateException: unable to create JcaTlsCrypto: DEFAULT SecureRandom not available
> Caused by: java.security.NoSuchAlgorithmException: DEFAULT SecureRandom not available"}},
> "rolled-back" => true
> }
> {code}
> The exception is happening [on this line|https://github.com/Skyllarr/wildfly-elytron/blob/ELY-1982/ssl/src/ma...] . This exception can be avoided by either using *new SecureRandom()* instead of null during initialization of sslContext, or by configuring securerandom with using *CryptoServicesRegistrar.setSecureRandom(new SecureRandom());* in code beforehand (this would require bc dependency).
> I tried to configure secure random statically by setting *securerandom.strongAlgorithms=DEFAULT:BCFIPS* in java.security or by trying to pass secure random as parameter to constructor with
> {code}
> security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider "C:DEFRND[SHA512];ENABLE{ALL};"
> {code}
> but neither had any effect. I did not find how to configure this statically for Java 11 in BC documentation.
> We could pass new instance of SecureRandom when initializing sslContext (if bouncycastle is used), or set secureRandom beforehand, or catch this exception and then use `new SecureRandom()`. But should we force the users to use SecureRandom set in the code by us? If users want to use Bouncycastle they should configure the secure random themselves since it is needed by the provider?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFLY-13949) JNDI lookup for JMS Queue failing
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13949?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFLY-13949:
---------------------------------------
Component/s: JMS
Assignee: Emmanuel Hugonnet (was: Brian Stansberry)
> 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
>
>
> 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
[Red Hat JIRA] (WFLY-13954) Class not found error in Jakarta EE 9 deployment stage
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13954?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-13954:
-----------------------------------------
[~hantsy]
Is this using a build from ee-9/dist maven module of my ee-9 branch? (https://github.com/bstansberry/wildfly/tree/ee-9).
WildFly master does not support EE 9.
> 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.
>
> ```
> 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.
> ```
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFLY-13959) WildFly management API should allow configuration of AMQ 7 broker's critical analyser
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13959?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13959:
------------------------------------
Comment: was deleted
(was: Can you change the title etc then? It's clearer to only use the term CLI when we are talking about things that are specific to that tool.
Sorry; we cross-posted. :))
> WildFly management API should allow configuration of AMQ 7 broker's critical analyser
> -------------------------------------------------------------------------------------
>
> Key: WFLY-13959
> URL: https://issues.redhat.com/browse/WFLY-13959
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 21.0.0.Beta1
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> Increasingly we are getting cases where embedded AMQ brokers get shutdown because of some issues with critical sections. This can be prevented by changing critical analyser policy but currently there is no way of configuring it in JBoss CLI.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months