August 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFWIP-77) smallrye-config: Converter Priority is not upheld

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFWIP-77?page=com.atlassian.jira.plugin.s... ] Jeff Mesnil commented on WFWIP-77: ---------------------------------- The issue seems related to the test fixture. When the converters comes from a module dependency, the @Priority annotation is not found on the class and smallrye-config uses the default value (100) at https://github.com/smallrye/smallrye-config/blob/b7d0b9fbdf14151ec89507b4... When I modify the test fixture so that the converters are bundled with the deployment, the test passes. It is a bug that the annotation is missing from the class when it is loaded through modules but that's done outside of smallrye-config or the subsystem. > smallrye-config: Converter Priority is not upheld > ------------------------------------------------- > > Key: WFWIP-77 > URL: https://issues.jboss.org/browse/WFWIP-77 > Project: WildFly WIP > Issue Type: Bug > Components: MP Config > Reporter: Michal Jurc > Assignee: Jeff Mesnil > Priority: Blocker > > Consider a scenario with two {{Coverter}} services available in service loader: > {code}@Priority(101) > public class Return101Converter implements Converter<Integer> { > @Override > public Integer convert(String value) { > return 101; > } > } > {code} > {code}@Priority(102) > public class Return102Converter implements Converter<Integer> { > @Override > public Integer convert(String value) { > return 102; > } > } > {code} > The {{@Priority}} of the {{Converter}} services is not considered, instead, their order in provider configuration file is - the first implementation will always be preferred. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1609) constraint drive authentication method in undertow doesn't work with elytron

by Bartosz Spyrko-Śmietanko (JIRA)

[ https://issues.jboss.org/browse/ELY-1609?page=com.atlassian.jira.plugin.s... ] Bartosz Spyrko-Śmietanko reassigned ELY-1609: --------------------------------------------- Assignee: Bartosz Spyrko-Śmietanko > constraint drive authentication method in undertow doesn't work with elytron > ---------------------------------------------------------------------------- > > Key: ELY-1609 > URL: https://issues.jboss.org/browse/ELY-1609 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Affects Versions: 1.4.0.Final > Reporter: Darran Lofthouse > Assignee: Bartosz Spyrko-Śmietanko > Priority: Critical > Fix For: 1.5.2.CR1 > > > When elytron is enabled constraint driven authentication method (i.e. proactive-authentication=false) has no effect. > If you try to request an unsecured page sending in an invalid user with basic authentication, you should get the page returned with constraint drive authentication and a 401 with proactive authentication. This is what happens without Elytron enabled. But if you enable Elytron it gives a 401 in both cases. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2730) CSS for test "syntax cheatsheet" dock tab design

by Eder Ignatowicz (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2730?page=com.atlassian.jira.plugi... ] Eder Ignatowicz commented on DROOLS-2730: ----------------------------------------- [~uxdlc] sorry for the delay in the response (I didn't read the whole thread). Docks size can be defined by the user, so basically you can ask the guys to have a dock in the size that you want. i.e. new UberfireDock(UberfireDockPosition.WEST, IconType.NAVICON.toString(), new DefaultPlaceRequest(NavigationExplorerScreen.SCREEN_ID), PERSPECTIVE_ID).withSize(330) .withLabel(ContentManagerConstants.INSTANCE.contentExplorerNavigation()); > CSS for test "syntax cheatsheet" dock tab design > ------------------------------------------------ > > Key: DROOLS-2730 > URL: https://issues.jboss.org/browse/DROOLS-2730 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Reporter: Liz Clayton > Assignee: Sarah Rambacher > Labels: ScenarioSimulation, UX, UXTeam > Attachments: Dock-deets.png, nospace.png, space.png > > > As a practitioner I want to reference valid expression syntax, so that I can create expression formatted Given/Expect input values when creating a scenario test outline. > *Verification conditions:* > - CSS styles that employ relevant PatternFly styles. > - CSS that articulates the design wireframe attached, and: > https://redhat.invisionapp.com/share/BVKORFBUJ24#/screens/302476080, and: > https://docs.google.com/document/d/1I_ghU9An--uQRzuVV9zXB387HLYjZcc01LXFX... > - Reviewed by scrum team prior to PR/dev delivery. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2814) MVEL uses random parameter type methods for BigDecimal.valueOf(100)

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2814?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-2814: ------------------------------------- Since we used a clone of the same algorithm also in the executable model I fixed it also there with this commit https://github.com/kiegroup/drools/commit/067aa33e9d322d6c8e6874b08c226cd... > MVEL uses random parameter type methods for BigDecimal.valueOf(100) > ------------------------------------------------------------------- > > Key: DROOLS-2814 > URL: https://issues.jboss.org/browse/DROOLS-2814 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.9.0.Final > Environment: - MVEL2 2.4.0.Final > Reporter: Toshiya Kobayashi > Assignee: Mario Fusco > Labels: support > Attachments: BigDecimalMvelTest.zip > > > When MVEL evaluates > {noformat} > java.math.BigDecimal.valueOf(100) > {noformat} > , MVEL determines a method from valueOf(double val) or valueOf(long val). > The result is not consistent. Sometimes uses valueOf(double val), Sometimes uses valueOf(long val). > ParseTools.getMethodScore() gives the same score for double and long. > https://github.com/mvel/mvel/blob/master/src/main/java/org/mvel2/util/Par... > So a selected method will depend on the order of result of "cls.getMethods()". > Reproducer: > $ unzip BigDecimalMvelTest.zip > $ cd BigDecimalMvelTest > $ mvn compile > $ ./loop.sh > It runs the MVEL test 100 times: > {noformat} > $ ./loop.sh > result = 100.0 > result = 100.0 > result = 100.0 > result = 100 > result = 100.0 > result = 100.0 > ... > {noformat} > In my environment, "100.0" is the majority but randomly see "100" as well. (I couldn't reproduce with single run with java for loop) > Expectation is constantly "100" (using valueOf(long val)) because in case of usual Java "java.math.BigDecimal.valueOf(100)", Java compiler chooses valueOf(long val) if the parameter is int. (considering "direct supertype" https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.10) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2814) MVEL uses random parameter type methods for BigDecimal.valueOf(100)

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2814?page=com.atlassian.jira.plugi... ] Mario Fusco edited comment on DROOLS-2814 at 8/1/18 12:47 PM: -------------------------------------------------------------- Since we use a clone of the same algorithm also in the executable model I fixed it also there with this commit https://github.com/kiegroup/drools/commit/067aa33e9d322d6c8e6874b08c226cd... was (Author: mfusco): Since we used a clone of the same algorithm also in the executable model I fixed it also there with this commit https://github.com/kiegroup/drools/commit/067aa33e9d322d6c8e6874b08c226cd... > MVEL uses random parameter type methods for BigDecimal.valueOf(100) > ------------------------------------------------------------------- > > Key: DROOLS-2814 > URL: https://issues.jboss.org/browse/DROOLS-2814 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.9.0.Final > Environment: - MVEL2 2.4.0.Final > Reporter: Toshiya Kobayashi > Assignee: Mario Fusco > Labels: support > Attachments: BigDecimalMvelTest.zip > > > When MVEL evaluates > {noformat} > java.math.BigDecimal.valueOf(100) > {noformat} > , MVEL determines a method from valueOf(double val) or valueOf(long val). > The result is not consistent. Sometimes uses valueOf(double val), Sometimes uses valueOf(long val). > ParseTools.getMethodScore() gives the same score for double and long. > https://github.com/mvel/mvel/blob/master/src/main/java/org/mvel2/util/Par... > So a selected method will depend on the order of result of "cls.getMethods()". > Reproducer: > $ unzip BigDecimalMvelTest.zip > $ cd BigDecimalMvelTest > $ mvn compile > $ ./loop.sh > It runs the MVEL test 100 times: > {noformat} > $ ./loop.sh > result = 100.0 > result = 100.0 > result = 100.0 > result = 100 > result = 100.0 > result = 100.0 > ... > {noformat} > In my environment, "100.0" is the majority but randomly see "100" as well. (I couldn't reproduce with single run with java for loop) > Expectation is constantly "100" (using valueOf(long val)) because in case of usual Java "java.math.BigDecimal.valueOf(100)", Java compiler chooses valueOf(long val) if the parameter is int. (considering "direct supertype" https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.10) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10757) ParseError when deploying application with netty dependency

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-10757?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-10757: ------------------------------------ Fix Version/s: 14.0.0.CR1 > ParseError when deploying application with netty dependency > ------------------------------------------------------------ > > Key: WFLY-10757 > URL: https://issues.jboss.org/browse/WFLY-10757 > Project: WildFly > Issue Type: Bug > Components: POJO > Affects Versions: 14.0.0.CR1 > Reporter: Jan Kašík > Assignee: Richard Opalka > Priority: Critical > Fix For: 14.0.0.CR1 > > > It is not possible to deploy app which has {{org.jboss.netty}} packed as a dependency. During processing of {{jboss-beans.xml}}, the deployment fails because there is an unexpected element: {{\{urn:jboss:bean-deployer:2.0}deployment}}. > {code:title=Part of log including exception|borderStyle=solid} > 2018-07-30 05:57:16.701 DEBUG o.w.e.c.c.o.OnlineManagementClient: Executing CLI operation undeploy *metamer* > 05:57:20,757 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location /home/hudson/hudson_workspace/workspace/eap-7.x-jsf-richfaces/6b4879d7/wildfly-14.0.0.Beta2-SNAPSHOT/standalone/data/content/c1/ef588d063c7cd396e765ef8452fbc43c04ce75/content > 05:57:20,779 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "metamer.war" (runtime-name: "metamer.war") > 05:57:22,206 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."metamer.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."metamer.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "metamer.war" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:151) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698) > at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) > at java.lang.Thread.run(Thread.java:748) > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYPOJO0038: Exception while parsing POJO descriptor file: "/content/metamer.war/WEB-INF/lib/netty-3.2.10.Final.jar/META-INF/jboss-beans.xml" > at org.jboss.as.pojo.KernelDeploymentParsingProcessor.parseDescriptor(KernelDeploymentParsingProcessor.java:154) > at org.jboss.as.pojo.KernelDeploymentParsingProcessor.parseDescriptors(KernelDeploymentParsingProcessor.java:125) > at org.jboss.as.pojo.KernelDeploymentParsingProcessor.deploy(KernelDeploymentParsingProcessor.java:82) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:144) > ... 8 more > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[17,1] > Message: Unexpected element '{urn:jboss:bean-deployer:2.0}deployment' > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:120) > at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:76) > at org.jboss.as.pojo.KernelDeploymentParsingProcessor.parseDescriptor(KernelDeploymentParsingProcessor.java:145) > ... 11 more > 05:57:22,210 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "metamer.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"metamer.war\".PARSE" => "WFLYSRV0153: Failed to process phase PARSE of deployment \"metamer.war\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYPOJO0038: Exception while parsing POJO descriptor file: \"/content/metamer.war/WEB-INF/lib/netty-3.2.10.Final.jar/META-INF/jboss-beans.xml\" > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[17,1] > Message: Unexpected element '{urn:jboss:bean-deployer:2.0}deployment'"}} > 05:57:22,217 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "metamer.war" was rolled back with the following failure message: > {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"metamer.war\".PARSE" => "WFLYSRV0153: Failed to process phase PARSE of deployment \"metamer.war\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYPOJO0038: Exception while parsing POJO descriptor file: \"/content/metamer.war/WEB-INF/lib/netty-3.2.10.Final.jar/META-INF/jboss-beans.xml\" > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[17,1] > Message: Unexpected element '{urn:jboss:bean-deployer:2.0}deployment'"}} > 05:57:22,266 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0028: Stopped deployment metamer.war (runtime-name: metamer.war) in 47ms > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2814) MVEL uses random parameter type methods for BigDecimal.valueOf(100)

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2814?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-2814. --------------------------------- Resolution: Done Fixed in mvel with https://github.com/mvel/mvel/commit/0283c28e0a61f4747c86442ce6663bbd5485a3dc > MVEL uses random parameter type methods for BigDecimal.valueOf(100) > ------------------------------------------------------------------- > > Key: DROOLS-2814 > URL: https://issues.jboss.org/browse/DROOLS-2814 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.9.0.Final > Environment: - MVEL2 2.4.0.Final > Reporter: Toshiya Kobayashi > Assignee: Mario Fusco > Labels: support > Attachments: BigDecimalMvelTest.zip > > > When MVEL evaluates > {noformat} > java.math.BigDecimal.valueOf(100) > {noformat} > , MVEL determines a method from valueOf(double val) or valueOf(long val). > The result is not consistent. Sometimes uses valueOf(double val), Sometimes uses valueOf(long val). > ParseTools.getMethodScore() gives the same score for double and long. > https://github.com/mvel/mvel/blob/master/src/main/java/org/mvel2/util/Par... > So a selected method will depend on the order of result of "cls.getMethods()". > Reproducer: > $ unzip BigDecimalMvelTest.zip > $ cd BigDecimalMvelTest > $ mvn compile > $ ./loop.sh > It runs the MVEL test 100 times: > {noformat} > $ ./loop.sh > result = 100.0 > result = 100.0 > result = 100.0 > result = 100 > result = 100.0 > result = 100.0 > ... > {noformat} > In my environment, "100.0" is the majority but randomly see "100" as well. (I couldn't reproduce with single run with java for loop) > Expectation is constantly "100" (using valueOf(long val)) because in case of usual Java "java.math.BigDecimal.valueOf(100)", Java compiler chooses valueOf(long val) if the parameter is int. (considering "direct supertype" https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.10) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2814) MVEL uses random parameter type methods for BigDecimal.valueOf(100)

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2814?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-2814: -------------------------------- Sprint: 2018 Week 30-32 > MVEL uses random parameter type methods for BigDecimal.valueOf(100) > ------------------------------------------------------------------- > > Key: DROOLS-2814 > URL: https://issues.jboss.org/browse/DROOLS-2814 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.9.0.Final > Environment: - MVEL2 2.4.0.Final > Reporter: Toshiya Kobayashi > Assignee: Mario Fusco > Labels: support > Attachments: BigDecimalMvelTest.zip > > > When MVEL evaluates > {noformat} > java.math.BigDecimal.valueOf(100) > {noformat} > , MVEL determines a method from valueOf(double val) or valueOf(long val). > The result is not consistent. Sometimes uses valueOf(double val), Sometimes uses valueOf(long val). > ParseTools.getMethodScore() gives the same score for double and long. > https://github.com/mvel/mvel/blob/master/src/main/java/org/mvel2/util/Par... > So a selected method will depend on the order of result of "cls.getMethods()". > Reproducer: > $ unzip BigDecimalMvelTest.zip > $ cd BigDecimalMvelTest > $ mvn compile > $ ./loop.sh > It runs the MVEL test 100 times: > {noformat} > $ ./loop.sh > result = 100.0 > result = 100.0 > result = 100.0 > result = 100 > result = 100.0 > result = 100.0 > ... > {noformat} > In my environment, "100.0" is the majority but randomly see "100" as well. (I couldn't reproduce with single run with java for loop) > Expectation is constantly "100" (using valueOf(long val)) because in case of usual Java "java.math.BigDecimal.valueOf(100)", Java compiler chooses valueOf(long val) if the parameter is int. (considering "direct supertype" https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.10) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2792) [DMN Designer] Data-types: Grid: LiteralExpression

by Liz Clayton (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2792?page=com.atlassian.jira.plugi... ] Liz Clayton commented on DROOLS-2792: ------------------------------------- [~manstis] I can offer ux considerations, but you probably have the best window into how this decision will affect the overall consistency/experience between the various cell and table types. Some considerations from my perspective: * Is there a possibility that the first input field could obscure the second if they are in the same editor? If so, then that could pose a usability problem if left as stacked inputs. * I know (stakeholder type) folks generally prefer the perceived ease of inline actions. Do you think there would be many use cases where the user would want to rename the element but not change the type? If that's a very common use case, then the benefit of supporting that might outweigh the cost of the alternative. Regarding live Search, perhaps it's a styling thing that [~srambach] could help with. > [DMN Designer] Data-types: Grid: LiteralExpression > -------------------------------------------------- > > Key: DROOLS-2792 > URL: https://issues.jboss.org/browse/DROOLS-2792 > Project: Drools > Issue Type: Feature Request > Components: DMN Editor > Reporter: Michael Anstis > Assignee: Michael Anstis > Attachments: DROOLS-2792.odt, Screen Shot 2018-08-01 at 10.11.48 AM.png, Screen Shot 2018-08-01 at 10.20.35 AM.png > > > *_Literal Expression_* > - (x) Grid header _could_ show Output Data Type > - (/) Editing Output Data Type is possible via Properties panel > - (x) Update header when Output Data Type is changed via Properties panel -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3990) Upgrade Byteman to 4.0.4 for better JDK9+ support

by Richard Opalka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3990?page=com.atlassian.jira.plugi... ] Richard Opalka updated WFCORE-3990: ----------------------------------- Labels: Java10 Java11 Java9 (was: jdk10 jdk11 jdk9) > Upgrade Byteman to 4.0.4 for better JDK9+ support > ------------------------------------------------- > > Key: WFCORE-3990 > URL: https://issues.jboss.org/browse/WFCORE-3990 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Test Suite > Reporter: Richard Opalka > Assignee: Richard Opalka > Labels: Java10, Java11, Java9 > Fix For: 6.0.0.Alpha5 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2018