July 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-10796) Warning about JSF version 'NONE' is shown in logs

by Jan Kašík (JIRA)

[ https://issues.jboss.org/browse/WFLY-10796?page=com.atlassian.jira.plugin... ] Jan Kašík updated WFLY-10796: ----------------------------- Description: Following warning is shown in log upon server start: {code} 2018-08-02 16:13:28,487 WARN [org.jboss.as.jsf] (MSC service thread 1-3) WFLYJSF0005: Unknown JSF version 'NONE'. Default version 'main' will be used instead. {code} Seems like, that 'NONE' constant from WildFly code is somehow used instead of default 'main' value. Version 'NONE' is not specified anywhere, so this warning should not be present. From my point of view, it seems like I am trying set slot 'NONE' to be the default. But nothing like that is happening. was: Following warning is shown in log upon server start: {code} 2018-08-02 16:13:28,487 WARN [org.jboss.as.jsf] (MSC service thread 1-3) WFLYJSF0005: Unknown JSF version 'NONE'. Default version 'main' will be used instead. {code} Seems like, that 'NONE' constant from WildFly code is somehow used instead of default 'main' value. Version 'NONE' is not specified anywhere, so this warning should not be present. > Warning about JSF version 'NONE' is shown in logs > -------------------------------------------------- > > Key: WFLY-10796 > URL: https://issues.jboss.org/browse/WFLY-10796 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 14.0.0.Beta2 > Reporter: Jan Kašík > Assignee: Dmitrii Tikhomirov > > Following warning is shown in log upon server start: > {code} > 2018-08-02 16:13:28,487 WARN [org.jboss.as.jsf] (MSC service thread 1-3) WFLYJSF0005: Unknown JSF version 'NONE'. Default version 'main' will be used instead. > {code} > Seems like, that 'NONE' constant from WildFly code is somehow used instead of default 'main' value. Version 'NONE' is not specified anywhere, so this warning should not be present. From my point of view, it seems like I am trying set slot 'NONE' to be the default. But nothing like that is happening. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

3 days, 22 hours

2
1
0 / 0

[JBoss JIRA] (ELY-776) Eliminate reference to "slot" from module configurations

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-776?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse reassigned ELY-776: ------------------------------------ Assignee: Darran Lofthouse > Eliminate reference to "slot" from module configurations > -------------------------------------------------------- > > Key: ELY-776 > URL: https://issues.jboss.org/browse/ELY-776 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: David Lloyd > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta15 > > > The final version of our client XSD should accept a name for modules but no slot. Instead, either the new name-only APIs should be used or a ModuleIdentifier created via that class's "fromString" method. Module slots are deprecated. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

3 days, 22 hours

2
1
0 / 0

[JBoss JIRA] (JBRULES-3445) DSL expander expands lines in /* */comment block

by Mario Fusco (JIRA)

Mario Fusco created JBRULES-3445: ------------------------------------ Summary: DSL expander expands lines in /* */comment block Key: JBRULES-3445 URL: https://issues.jboss.org/browse/JBRULES-3445 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mario Fusco Assignee: Mario Fusco When you comment some code in dslr file, the expander still tries to expand it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

5 months

3
10
0 / 0

[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)

1 year, 1 month

2
1
0 / 0

[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)

6 years, 1 month

1
0
0 / 0

[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)

6 years, 1 month

1
0
0 / 0

[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)

6 years, 1 month

1
0
0 / 0

[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)

6 years, 1 month

1
0
0 / 0

[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)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-12341) Upgrade Narayana to 5.9.6.Final

by Martin Stefanko (Jira)

[ https://issues.jboss.org/browse/WFLY-12341?page=com.atlassian.jira.plugin... ] Martin Stefanko updated WFLY-12341: ----------------------------------- Fix Version/s: (was: 17.0.0.Alpha1) (was: 17.0.0.Final) > Upgrade Narayana to 5.9.6.Final > ------------------------------- > > Key: WFLY-12341 > URL: https://issues.jboss.org/browse/WFLY-12341 > Project: WildFly > Issue Type: Component Upgrade > Components: Transactions > Reporter: Martin Stefanko > Assignee: Ondrej Chaloupka > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2019