[JBoss JIRA] (WFWIP-159) Artemis logging codes/IDs have changed for CORE protocol
by Miroslav Novak (Jira)
Miroslav Novak created WFWIP-159:
------------------------------------
Summary: Artemis logging codes/IDs have changed for CORE protocol
Key: WFWIP-159
URL: https://issues.jboss.org/browse/WFWIP-159
Project: WildFly WIP
Issue Type: Bug
Components: Artemis
Reporter: Miroslav Novak
Assignee: Justin Bertram
Artemis logging codes for CORE protocol has changed in scope of jira: https://issues.apache.org/jira/browse/ARTEMIS-1018
For example in WF14 if standalone JMS client failed to connect then it was logged with code AMQ119007:
{code}
Caused by: ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ119007: Cannot connect to server(s). Tried with all available servers.]
{code}
but newly it would have code AMQ219007:
{code}
Caused by: ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ219007: Cannot connect to server(s). Tried with all available servers.]
{code}
This is problem for any user/customer who had monitoring based on those codes as this will require to change it.
The reason for change was because those codes were duplicated between AMQP and CORE protocol. As CORE protocol is default and AMQP is not supported for EAP ti would makes sense to change AMQP codes instead and keep codes for CORE protocol without any change.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11907) NPE trying to use Resteasy Client inside CDI Async Event
by Matěj Novotný (Jira)
[ https://issues.jboss.org/browse/WFLY-11907?page=com.atlassian.jira.plugin... ]
Matěj Novotný commented on WFLY-11907:
--------------------------------------
Uuf, I can see where the NPE is coming from now.
If you run CDI Async event, you are on a new thread pool, which is defined [here in wfly|https://github.com/wildfly/wildfly/blob/master/weld/subsystem/src/ma...]. The catch is, this thread pool nullifies its TCCL as can be seen [here|https://github.com/wildfly/wildfly/blob/master/weld/subsystem/src/ma...].
And finally, RestEasy relies on it not being null but never checks it [here in {{RegisterBuiltin}}|https://github.com/resteasy/Resteasy/blob/master/resteasy-core/src/main/java/org/jboss/resteasy/plugins/providers/RegisterBuiltin.java#L108].
> 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: Matěj Novotný
> 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)
7 years, 1 month
[JBoss JIRA] (WFCORE-4387) Fix typo in remoting descriptions
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFCORE-4387?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-4387:
------------------------------------------
Ah I see what you mean now - the line wrapping in Jira was also misleading - splitting onto multiple lines in the properties is leading to the whitespace being incorrectly removed.
> Fix typo in remoting descriptions
> ---------------------------------
>
> Key: WFCORE-4387
> URL: https://issues.jboss.org/browse/WFCORE-4387
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 9.0.0.Beta2
> Reporter: Teresa Miyar Gil
> Assignee: Teresa Miyar Gil
> Priority: Minor
>
> Some descriptions lack a space on line break:
> {code:java}
> "authorize-id" => {
> "type" => STRING,
> "description" => "The SASL authorization ID. Used as authentication user name to use if no authentication CallbackHandler is specifiedand the se
> lected SASL mechanism demands a user name.",
> ....
> "heartbeat-interval" => {
> "type" => INT,
> "description" => "The interval to use for connection heartbeat, in milliseconds. If the connection is idle in the outbound directionfor this amount of time, a ping message will be sent, which will trigger a corresponding reply message.",
> "expressions-allowed" => true,
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFCORE-4387) Fix typo in remoting descriptions
by Teresa Miyar Gil (Jira)
[ https://issues.jboss.org/browse/WFCORE-4387?page=com.atlassian.jira.plugi... ]
Teresa Miyar Gil commented on WFCORE-4387:
------------------------------------------
[~dlofthouse]I see in the local descriptions properties file the following:
{code:java}
endpoint.heartbeat-interval=The interval to use for connection heartbeat, in milliseconds. If the connection is idle in the outbound direction\
for this amount of time, a ping message will be sent, which will trigger a corresponding reply message.
{code}
I need to check but I think is the "direction\" should be "direction \"
> Fix typo in remoting descriptions
> ---------------------------------
>
> Key: WFCORE-4387
> URL: https://issues.jboss.org/browse/WFCORE-4387
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 9.0.0.Beta2
> Reporter: Teresa Miyar Gil
> Assignee: Teresa Miyar Gil
> Priority: Minor
>
> Some descriptions lack a space on line break:
> {code:java}
> "authorize-id" => {
> "type" => STRING,
> "description" => "The SASL authorization ID. Used as authentication user name to use if no authentication CallbackHandler is specifiedand the se
> lected SASL mechanism demands a user name.",
> ....
> "heartbeat-interval" => {
> "type" => INT,
> "description" => "The interval to use for connection heartbeat, in milliseconds. If the connection is idle in the outbound directionfor this amount of time, a ping message will be sent, which will trigger a corresponding reply message.",
> "expressions-allowed" => true,
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11906) Managed Executor Task Fails with CDI if created from Batchlet
by Matěj Novotný (Jira)
[ https://issues.jboss.org/browse/WFLY-11906?page=com.atlassian.jira.plugin... ]
Matěj Novotný commented on WFLY-11906:
--------------------------------------
[~clerum] FYI, with the Arjuna fix from WFLY-11858, I can get {{Start Batch with Send using Async CDI Event}} working with following output:
{code}
09:29:17,738 INFO [class com.outjected.demo.MyTestBatchlet] (Batch Thread - 8) Running inside a batchlet and will send to: test(a)test.local with type: ASYNC
09:29:17,739 INFO [class com.outjected.demo.DemoAsyncEventObserver] (Weld Thread Pool -- 5) Starting DemoAsyncEventObserver with sendTo of test(a)test.local
09:29:17,740 INFO [class com.outjected.demo.DemoTask] (Weld Thread Pool -- 5) Sent to test(a)test.local
{code}
The {{Start Batch with Send using Managed Exectuor}} is still giving the same error (WFLYWELD0039: Singleton not set...).
Since you are using {{CDI.current()}} there and that is caller sensitive, WildFly does its best to identify which archive does the call belong to based on {{ClassLoader}}.
There is a class named [{{ModuleGroupSingletonProvider}}|https://github.com/wildfly/wildfly/blob/master/weld/subsystem/src/main/java/org/jboss/as/weld/services/ModuleGroupSingletonProvider.java] that holds known references to CLs which have some Weld container running and can, based on CL, return the container instance. With this test, there is only the following (expected) entry in the map:
{code}
ModuleClassLoader for Module "deployment.demo.war" from Service Module Loader
{code}
And while queried from within the Batch task, following CL is used:
{code}
ModuleClassLoader for Module "org.jboss.as.ee" version 16.0.0.Final from local module loader @534df152 (finder: local module finder @52e677af (roots: /home/manovotn/GitRepo/wildfly/dist/target/wildfly-16.0.0.Final/modules,/home/manovotn/GitRepo/wildfly/dist/target/wildfly-16.0.0.Final/modules/system/layers/base))
{code}
Note that the first sample with Async events only works because there is no {{CDI.current()}} used in there. Adding it will blow it all the same with the only difference being that TCCL is {{null}} as [Weld deliberately provides an executor with erased TCCL to prevent leaks|https://github.com/wildfly/wildfly/blob/master/weld/subsystem/src/m...].
> Managed Executor Task Fails with CDI if created from Batchlet
> -------------------------------------------------------------
>
> Key: WFLY-11906
> URL: https://issues.jboss.org/browse/WFLY-11906
> Project: WildFly
> Issue Type: Bug
> Components: Batch, CDI / Weld, Concurrency Utilities
> Affects Versions: 16.0.0.Final
> Environment: Java 8
> Reporter: Cody Lerum
> Assignee: Cheng Fang
> Priority: Major
>
> This previously was working (verified in reproducer) on Wildfly 14.0.1
> Inside of a batchlet if a Managed Executor Task is executed and that Task uses CDI.current() an exception is thrown
> {code:java}
> 11:00:02,343 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) java.lang.IllegalStateException: WFLYWELD0039: Singleton not set for ModuleClassLoader for Module "org.jboss.as.ee" version 16.0.0.Final from local module loader @78e94dcf (finder: local module finder @233fe9b6 (roots: V:\opt\wildfly-16.0.0.Final\modules,V:\opt\wildfly-16.0.0.Final\modules\system\layers\base)). This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:77)
> 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:134)
> 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.weld.Container.instance(Container.java:57)
> 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.weld.WeldProvider.getCDI(WeldProvider.java:69)
> 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at javax.enterprise.inject.spi.CDI.lambda$getCDIProvider$0(CDI.java:87)
> 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174)
> 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.TreeMap$KeySpliterator.tryAdvance(TreeMap.java:2770)
> 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:126)
> 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:498)
> 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:485)
> 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.FindOps$FindOp.evaluateSequential(FindOps.java:152)
> 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.ReferencePipeline.findFirst(ReferencePipeline.java:464)
> 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at javax.enterprise.inject.spi.CDI.getCDIProvider(CDI.java:88)
> 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at javax.enterprise.inject.spi.CDI.current(CDI.java:64)
> 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at com.outjected.demo.DemoTask.run(DemoTask.java:27)
> 11:00:02,347 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.ee.concurrent.ControlPointUtils$ControlledRunnable.run(ControlPointUtils.java:105)
> 11:00:02,347 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 11:00:02,347 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266)
> 11:00:02,347 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.FutureTask.run(FutureTask.java)
> 11:00:02,348 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.run(ManagedFutureTask.java:141)
> 11:00:02,348 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 11:00:02,348 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 11:00:02,348 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.lang.Thread.run(Thread.java:748)
> 11:00:02,349 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250)
> 11:00:02,349 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.ee.concurrent.service.ElytronManagedThreadFactory$ElytronManagedThread.run(ElytronManagedThreadFactory.java:85)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFCORE-4387) Fix typo in remoting descriptions
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFCORE-4387?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-4387:
------------------------------------------
This sounds more to be in relation to how the specific client has chosen to represent the long line rather than an issue in the actual description.
> Fix typo in remoting descriptions
> ---------------------------------
>
> Key: WFCORE-4387
> URL: https://issues.jboss.org/browse/WFCORE-4387
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 9.0.0.Beta2
> Reporter: Teresa Miyar Gil
> Assignee: Teresa Miyar Gil
> Priority: Minor
>
> Some descriptions lack a space on line break:
> {code:java}
> "authorize-id" => {
> "type" => STRING,
> "description" => "The SASL authorization ID. Used as authentication user name to use if no authentication CallbackHandler is specifiedand the se
> lected SASL mechanism demands a user name.",
> ....
> "heartbeat-interval" => {
> "type" => INT,
> "description" => "The interval to use for connection heartbeat, in milliseconds. If the connection is idle in the outbound directionfor this amount of time, a ping message will be sent, which will trigger a corresponding reply message.",
> "expressions-allowed" => true,
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month