[JBoss JIRA] (DROOLS-3944) DMN Editor: Data type usability study
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3944?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton updated DROOLS-3944:
--------------------------------------
Sprint: 2019 Week 23-25
> DMN Editor: Data type usability study
> -------------------------------------
>
> Key: DROOLS-3944
> URL: https://issues.jboss.org/browse/DROOLS-3944
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Environment: Version 7.4
> Reporter: Elizabeth Clayton
> Assignee: Sarahjane Clark
> Priority: Major
> Labels: UX, UXTeam, Usability, drools-tools
>
> Lightweight usability study to test the ease of use in viewing, creating, editing and deleting data types, particularly structured data types.
> GOALS: Access the Data Type editor in terms of productivity and usability.
> * Ease of use when creating a complex type (concern: minimizing the mouse usage.)
> * Ease of use when saving a basic data type (e.g. age: number)
> * Discoverability of actions in the kebab menu, especially, insert nested, delete.
> * Ease of use/accuracy: Type-ahead of the data type selector.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
3 months, 1 week
[JBoss JIRA] (JBEE-158) EL 3 LambdaExpression failing with an exception irreversibly pollutes variable scope
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/JBEE-158?page=com.atlassian.jira.plugin.s... ]
Scott Marlow commented on JBEE-158:
-----------------------------------
fyi [~ctomc] [~doublep_] created a pr with same change to upstream [https://github.com/eclipse-ee4j/el-ri/pull/98]
> EL 3 LambdaExpression failing with an exception irreversibly pollutes variable scope
> ------------------------------------------------------------------------------------
>
> Key: JBEE-158
> URL: https://issues.jboss.org/browse/JBEE-158
> Project: JBoss Enterprise Spec APIs
> Issue Type: Bug
> Components: jboss-el-api
> Affects Versions: jboss-el-api_3.0_spec-1.0.2.Final
> Reporter: Paul Pogonyshev
> Assignee: Tomaž Cerar
> Priority: Major
> Labels: el-expresion, patch
> Fix For: jboss-el-api_3.0_spec-1.0.6.Final
>
> Attachments: lambda-expression-scoping-fix.diff
>
>
> When a lambda expression is exited with an exception, its variables are left on stack and cannot be removed from it without hacks. My usecase is a customly defined function that uses exceptions as means of non-local exit, but the bug triggers even without custom functions, as demonstrated below.
> Test case:
> {noformat}
> ELProcessor processor = new ELProcessor ();
> processor.defineBean ("x", null);
> try {
> processor.eval ("(x -> x.bug ()) ('bug')");
> }
> catch (RuntimeException exception) {
> // This is expected, there is no method bug() on strings.
> }
> processor.eval ("x"); // This must evaluate to null, but instead evaluates to "bug".
> {noformat}
> Proposed fix will be attached as a short patch against 'javax/el/LambdaExpression.java'.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (WFLY-11907) NPE trying to use Resteasy Client inside CDI Async Event
by Ronald Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-11907?page=com.atlassian.jira.plugin... ]
Ronald Sigal commented on WFLY-11907:
-------------------------------------
I see that the javadoc for java.lang.Thread.getContextClassLoader() says
{code}
Returns:
the context ClassLoader for this Thread, or null indicating the system class loader (or, failing that, the bootstrap class loader)
{code}
so it would be wrong to do nothing.
There are 14 references to this method in RESTEasy 3.9 (ignoring test code). Maybe the appropriate thing to do is context dependent. I'll look.
> 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: Ronald Sigal
> 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, 4 months
[JBoss JIRA] (JGRP-2234) Unlocked locks stay locked forever
by William Collishaw (Jira)
[ https://issues.jboss.org/browse/JGRP-2234?page=com.atlassian.jira.plugin.... ]
William Collishaw commented on JGRP-2234:
-----------------------------------------
Hey all,
Any proposed time line for the 3.6.18 release with this fix?
Thanks,
William
> Unlocked locks stay locked forever
> ----------------------------------
>
> Key: JGRP-2234
> URL: https://issues.jboss.org/browse/JGRP-2234
> Project: JGroups
> Issue Type: Bug
> Reporter: Bram Klein Gunnewiek
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.11, 3.6.18
>
> Attachments: ClusterSplitLockTest.java, jg_clusterlock_output_testfail.txt
>
>
> As discussed in the mailing list we have issues where locks from the central lock protocol stay locked forever when the coordinator of the cluster disconnects. We can reproduce this with the attached ClusterSplitLockTest.java. Its a race condition and we need to run the test a lot of times (sometimes > 20) before we encounter a failure.
> What we think is happening:
> In a three node cluster (node A, B and C where node A is the coordinator) unlock requests from B and/or C can be missed when node A leaves and B and/or C don't have the new view installed yet. When, for example, node B takes over coordination it creates the lock table based on the back-ups. Lets say node C has locked the lock with name 'lockX'. Node C performs an unlock of 'lockX' just after node A (gracefully) leaves and sends the unlock request to node A since node C doesn't have the correct view installed yet. Node B has recreated the lock table where 'lockX' is locked by Node C. Node C doesn't resend the unlock request so 'lockX' gets locked forever.
> Attached is the testng test we wrote and the output of a test failure.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (WFCORE-4525) Fix failing tests on IBM JDK
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFCORE-4525?page=com.atlassian.jira.plugi... ]
James Perkins reassigned WFCORE-4525:
-------------------------------------
Assignee: (was: James Perkins)
> Fix failing tests on IBM JDK
> ----------------------------
>
> Key: WFCORE-4525
> URL: https://issues.jboss.org/browse/WFCORE-4525
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Richard Opalka
> Priority: Major
> Attachments: forked-booter.png, ibm-jdk8.png, oracle-jdk.png
>
>
> The following tests are failing on latest IBM JDK 8:
> ---
> # testsuite/standalone
> SilentModeTestCase
> # testsuite/manualmode
> CLIEmbedHostControllerTestCase
> CLIEmbedServerTestCase
> ---
> Tested on:
> ---
> java version "1.8.0_211"
> Java(TM) SE Runtime Environment (build 8.0.5.36 - pxa6480sr5fp36-20190510_01(SR5 FP36))
> IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20190502_415899 (JIT enabled, AOT enabled)
> OpenJ9 - 46e57f9
> OMR - 06a046a
> IBM - 0b909bf)
> JCL - 20190409_01 based on Oracle jdk8u211-b25
> ---
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (WFLY-2859) Treating all JAX-RS components as CDI Beans has some negative consequences
by Ronald Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-2859?page=com.atlassian.jira.plugin.... ]
Ronald Sigal commented on WFLY-2859:
------------------------------------
Update: there has been additional discussion about this issue on RESTEASY-1015, and it should be fixed in RESTEASY-2315.
> Treating all JAX-RS components as CDI Beans has some negative consequences
> --------------------------------------------------------------------------
>
> Key: WFLY-2859
> URL: https://issues.jboss.org/browse/WFLY-2859
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, REST
> Affects Versions: 8.0.0.CR1, 16.0.0.Beta1
> Reporter: Matt Drees
> Assignee: Stuart Douglas
> Priority: Major
>
> It seems that wildfly is now treating all jax-rs Providers and Resources as CDI Beans. This is probably fine most of the time, but there are some Provider classes that cause UnproxyableResolutionException (WELD-001437) errors, due to the fact that resteasy-cdi attempts to get bean reference whose type is identical to the bean class.
> See the forum link for a specific instance of this.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months