[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ý edited comment on WFLY-11907 at 3/28/19 6:07 AM:
---------------------------------------------------------------
Alright, so this issue is in some way related to WFLY-11906 and the Weld-side solution I proposed there will (as a side effect) fix this issue as well.
See [my comment on that issue|https://issues.jboss.org/browse/WFLY-11906?focusedCommentId=1371430...].
Weld issue that tracks this is WELD-2573.
[~mkopecky] [~ron_sigal] while the solution for Weld will make this pass, I still think you may want to add a null check for TCCL to RestEasy.
was (Author: manovotn):
Alright, so this issue is in some way related to WFLY-11706 and the Weld-side solution I proposed there will (as a side effect) fix this issue as well.
See [my comment on that issue|https://issues.jboss.org/browse/WFLY-11906?focusedCommentId=1371430...].
Weld issue that tracks this is WELD-2573.
[~mkopecky] [~ron_sigal] while the solution for Weld will make this pass, I still think you may want to add a null check for TCCL to RestEasy.
> 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)
5 years, 9 months
[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:
--------------------------------------
Alright, so this issue is in some way related to WFLY-11706 and the Weld-side solution I proposed there will (as a side effect) fix this issue as well.
See [my comment on that issue|https://issues.jboss.org/browse/WFLY-11906?focusedCommentId=1371430...].
Weld issue that tracks this is WELD-2573.
[~mkopecky] [~ron_sigal] while the solution for Weld will make this pass, I still think you may want to add a null check for TCCL to RestEasy.
> 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)
5 years, 9 months
[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:
--------------------------------------
After some lengthy discussion with Martin, we came up with an idea of wrapping the observer notification with TCCL setting (and unsetting).
That will preserve the TCCL hence making it possible for WFLY to detect the right Weld container for {{CDI.current()}} invocation regardless of executor used.
As a side effect, this will also fix WFLY-11907.
I have created WELD-2573 to track this for Weld.
*Note that this will NOT fix regression with batch executor TCCL that this issue manifests*. That one should be investigated further (since I don't know who is behind Batch in WFLY, I am going to suppose [~cfang] will take this? :)).
> 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)
5 years, 9 months
[JBoss JIRA] (JGRP-2338) RpcDispatcher: non-reflective method invocations
by Bela Ban (Jira)
Bela Ban created JGRP-2338:
------------------------------
Summary: RpcDispatcher: non-reflective method invocations
Key: JGRP-2338
URL: https://issues.jboss.org/browse/JGRP-2338
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.1.0
Running a native image produced by the GraalVM AOT (ahead-of-time) compiler prohibits the use of Java Reflection.
However, RpcDispatcher uses {{java.lang.reflect.Method}} to invoke remote method calls.
h4. Goal
Provide a mode (in {{MethodCall}}) which doesn't require a {{MethodLookup}} table but rather takes user-provided code (e.g. a lambda) to find and invoke the correct method.
This could be done by introducing an additional mode in {{MethodCall}} based on {{ID}} which calls the (user-provided) lambda to invoke a method. The lambda would read the arguments and invoke the method based on the received ID, then return the result.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (SWSQE-669) Checklist for custom fields in order to support existing and future workflows for KIALI
by Prachi Yadav (Jira)
Prachi Yadav created SWSQE-669:
----------------------------------
Summary: Checklist for custom fields in order to support existing and future workflows for KIALI
Key: SWSQE-669
URL: https://issues.jboss.org/browse/SWSQE-669
Project: Kiali QE
Issue Type: QE Task
Reporter: Prachi Yadav
project MUST have the following custom fields in order to support existing and future workflows and visualizations:
QE Test Coverage with values +, -, and ? (Null is supported)
SFDC Cases Counter
SFDC Cases Links
These custom fields must exist as above so that we do not need to customize logic for any one-offs. The SFDC Cases * fields are there to support "integration" with our SalesForce system used by CEE/GSS for customer cases and the links here are links to SFDC customer cases.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (SWSQE-668) Checklist for custom fields in order to support existing and future workflows for Istio
by Prachi Yadav (Jira)
Prachi Yadav created SWSQE-668:
----------------------------------
Summary: Checklist for custom fields in order to support existing and future workflows for Istio
Key: SWSQE-668
URL: https://issues.jboss.org/browse/SWSQE-668
Project: Kiali QE
Issue Type: QE Task
Reporter: Prachi Yadav
project MUST have the following custom fields in order to support existing and future workflows and visualizations:
QE Test Coverage with values +, -, and ? (Null is supported)
SFDC Cases Counter
SFDC Cases Links
These custom fields must exist as above so that we do not need to customize logic for any one-offs. The SFDC Cases * fields are there to support "integration" with our SalesForce system used by CEE/GSS for customer cases and the links here are links to SFDC customer cases.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (JGRP-2337) DiagnosticsHandler without reflection
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2337?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2337:
---------------------------
Description:
Probe.sh sends commands to cluster nodes, and they are handled by each node's DiagnosticsHandler. {{"op"}} and {{"jmx"}} commands are handled via reflection.
However, reflection is not allowed by the GraalVM running in native mode, unless all attributes and methods of all protocols would be listed in a JSON file. This is apparently very costly as the native image builder creates a transitive closure over all classes whose methods and/or fields are listed in the JSON file, and thus includes too many classes in the native image.
Investigate creating a {{ProbeHandler}} for {{"jmx"}} and {{"op"}} commands, which does not use reflection. 2 alternatives come to mind:
* Offline creation and compilation: point to a list of protocols for which code is generated (an alternative ProbeHandler class). This class is then instantiated and set in the channel at runtime by the application
* Point to a running stack. The code uses reflection (obviously this needs to run in non-native mode) to generate the native {{ProbeHandler}} from the list of protocols running in the current stack. This code can then be compiled and used in native image generation.
was:
Probe.sh sends commands to cluster nodes, and they are handled by each node's DiagnosticsHandler. {{"op"}} and {{"jmx"}} commands are handled via reflection.
However, reflection is not allowed by the GraalVM running in native mode, unless all attributes and methods of all protocols would be listed in a JSON file. This is apparently very costly as the native image builder creates a transitive closure over all classes whose methods and/or fields are listed in the JSON file, and thus includes too many classes in the native image.
Investigate creating a {{ProbeHandler}} for {{"jmx""}} and {{"op"}} commands, which does not use reflection. 2 alternatives come to mind:
* Offline creation and compilation: point to a list of protocols for which code is generated (an alternative ProbeHandler class). This class is then instantiated and set in the channel at runtime by the application
* Point to a running stack. The code uses reflection (obviously this needs to run in non-native mode) to generate the native {{ProbeHandler}} from the list of protocols running in the current stack. This code can then be compiled and used in native image generation.
> DiagnosticsHandler without reflection
> -------------------------------------
>
> Key: JGRP-2337
> URL: https://issues.jboss.org/browse/JGRP-2337
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.0
>
>
> Probe.sh sends commands to cluster nodes, and they are handled by each node's DiagnosticsHandler. {{"op"}} and {{"jmx"}} commands are handled via reflection.
> However, reflection is not allowed by the GraalVM running in native mode, unless all attributes and methods of all protocols would be listed in a JSON file. This is apparently very costly as the native image builder creates a transitive closure over all classes whose methods and/or fields are listed in the JSON file, and thus includes too many classes in the native image.
> Investigate creating a {{ProbeHandler}} for {{"jmx"}} and {{"op"}} commands, which does not use reflection. 2 alternatives come to mind:
> * Offline creation and compilation: point to a list of protocols for which code is generated (an alternative ProbeHandler class). This class is then instantiated and set in the channel at runtime by the application
> * Point to a running stack. The code uses reflection (obviously this needs to run in non-native mode) to generate the native {{ProbeHandler}} from the list of protocols running in the current stack. This code can then be compiled and used in native image generation.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (SWSQE-667) Checklist for custom fields in order to support existing and future workflows for Jaeger
by Prachi Yadav (Jira)
Prachi Yadav created SWSQE-667:
----------------------------------
Summary: Checklist for custom fields in order to support existing and future workflows for Jaeger
Key: SWSQE-667
URL: https://issues.jboss.org/browse/SWSQE-667
Project: Kiali QE
Issue Type: QE Task
Reporter: Prachi Yadav
project MUST have the following custom fields in order to support existing and future workflows and visualizations:
QE Test Coverage with values +, -, and ? (Null is supported)
SFDC Cases Counter
SFDC Cases Links
These custom fields must exist as above so that we do not need to customize logic for any one-offs. The SFDC Cases * fields are there to support "integration" with our SalesForce system used by CEE/GSS for customer cases and the links here are links to SFDC customer cases.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months