November 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1327) Drools declared types cannot be references in jBPM Drools expressions due to compilation order.

by Martin Cimbalek (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1327?page=com.atlassian.jira.plugi... ] Martin Cimbalek updated DROOLS-1327: ------------------------------------ Comment: was deleted (was: Verified with 6.4.0.CR1) > Drools declared types cannot be references in jBPM Drools expressions due to compilation order. > ----------------------------------------------------------------------------------------------- > > Key: DROOLS-1327 > URL: https://issues.jboss.org/browse/DROOLS-1327 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.4.0.Final > Environment: JBoss BPM Suite 6.3.3.GA > Reporter: Duncan Doyle > Assignee: Mario Fusco > Fix For: 7.0.0.Beta3 > > > When you declare a type in a DRL using the "declare" syntax, that type cannot be referenced by Drools LHS expressions in a Sequence Flow (for example in the context of an X-OR Gateway). The DRL and BPMN2 file are in the same project. > The problem is the order of compilation of CompositeKnowledgeBuilderImpl. The builder compiles the process definitions before the DRLs, which results in a situation where the declared types used in the process are not yet available in the Drools ProjectClassloader when. the process is compiled. > Easy fix is to compile the process after the rules, which makes sense as the rules will normally not really on processes, but processes can really on rules. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1327) Drools declared types cannot be references in jBPM Drools expressions due to compilation order.

by Martin Cimbalek (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1327?page=com.atlassian.jira.plugi... ] Martin Cimbalek commented on DROOLS-1327: ----------------------------------------- Verified with 6.4.0.CR1 > Drools declared types cannot be references in jBPM Drools expressions due to compilation order. > ----------------------------------------------------------------------------------------------- > > Key: DROOLS-1327 > URL: https://issues.jboss.org/browse/DROOLS-1327 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.4.0.Final > Environment: JBoss BPM Suite 6.3.3.GA > Reporter: Duncan Doyle > Assignee: Mario Fusco > Fix For: 7.0.0.Beta3 > > > When you declare a type in a DRL using the "declare" syntax, that type cannot be referenced by Drools LHS expressions in a Sequence Flow (for example in the context of an X-OR Gateway). The DRL and BPMN2 file are in the same project. > The problem is the order of compilation of CompositeKnowledgeBuilderImpl. The builder compiles the process definitions before the DRLs, which results in a situation where the declared types used in the process are not yet available in the Drools ProjectClassloader when. the process is compiled. > Easy fix is to compile the process after the rules, which makes sense as the rules will normally not really on processes, but processes can really on rules. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1983) Root cause of failing parsing should be used as failure description

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1983?page=com.atlassian.jira.plugi... ] Jean-Francois Denise reassigned WFCORE-1983: -------------------------------------------- Assignee: Brian Stansberry (was: Jean-Francois Denise) > Root cause of failing parsing should be used as failure description > ------------------------------------------------------------------- > > Key: WFCORE-1983 > URL: https://issues.jboss.org/browse/WFCORE-1983 > Project: WildFly Core > Issue Type: Bug > Components: Server > Reporter: Jean-Francois Denise > Assignee: Brian Stansberry > > It happens that the CLI does a custom parsing of the value in case ModelNode.fromString fails (whatever the exception). > The issue is that the custom parsing doesn't follow the ModelNode parsing syntax and parse everything as String. So the resulting ModelNode that is serialised and sent to the server has been transformed. > I am surprised that we don't have more of such failures. For example, when numbers are located inside custom complex structure such as: {mynumber=9999} that will be sent as an OBJECT containing a STRING although the valid DMR syntax {"my number"=>999} would be sent as an OBJECT containing an INT. > Some server side subsystems are smart enough to call into asXXX methods and not check the type? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1983) Root cause of failing parsing should be used as failure description

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1983?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-1983: ----------------------------------------- Component/s: Server (was: CLI) > Root cause of failing parsing should be used as failure description > ------------------------------------------------------------------- > > Key: WFCORE-1983 > URL: https://issues.jboss.org/browse/WFCORE-1983 > Project: WildFly Core > Issue Type: Bug > Components: Server > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > It happens that the CLI does a custom parsing of the value in case ModelNode.fromString fails (whatever the exception). > The issue is that the custom parsing doesn't follow the ModelNode parsing syntax and parse everything as String. So the resulting ModelNode that is serialised and sent to the server has been transformed. > I am surprised that we don't have more of such failures. For example, when numbers are located inside custom complex structure such as: {mynumber=9999} that will be sent as an OBJECT containing a STRING although the valid DMR syntax {"my number"=>999} would be sent as an OBJECT containing an INT. > Some server side subsystems are smart enough to call into asXXX methods and not check the type? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1983) Root cause of failing parsing should be used a failure description

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1983?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-1983: ----------------------------------------- Summary: Root cause of failing parsing should be used a failure description (was: CLI type decision INT/STRING LONG/STRING) > Root cause of failing parsing should be used a failure description > ------------------------------------------------------------------ > > Key: WFCORE-1983 > URL: https://issues.jboss.org/browse/WFCORE-1983 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > It happens that the CLI does a custom parsing of the value in case ModelNode.fromString fails (whatever the exception). > The issue is that the custom parsing doesn't follow the ModelNode parsing syntax and parse everything as String. So the resulting ModelNode that is serialised and sent to the server has been transformed. > I am surprised that we don't have more of such failures. For example, when numbers are located inside custom complex structure such as: {mynumber=9999} that will be sent as an OBJECT containing a STRING although the valid DMR syntax {"my number"=>999} would be sent as an OBJECT containing an INT. > Some server side subsystems are smart enough to call into asXXX methods and not check the type? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1983) Root cause of failing parsing should be used as failure description

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1983?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-1983: ----------------------------------------- Summary: Root cause of failing parsing should be used as failure description (was: Root cause of failing parsing should be used a failure description) > Root cause of failing parsing should be used as failure description > ------------------------------------------------------------------- > > Key: WFCORE-1983 > URL: https://issues.jboss.org/browse/WFCORE-1983 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > It happens that the CLI does a custom parsing of the value in case ModelNode.fromString fails (whatever the exception). > The issue is that the custom parsing doesn't follow the ModelNode parsing syntax and parse everything as String. So the resulting ModelNode that is serialised and sent to the server has been transformed. > I am surprised that we don't have more of such failures. For example, when numbers are located inside custom complex structure such as: {mynumber=9999} that will be sent as an OBJECT containing a STRING although the valid DMR syntax {"my number"=>999} would be sent as an OBJECT containing an INT. > Some server side subsystems are smart enough to call into asXXX methods and not check the type? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1983) CLI type decision INT/STRING LONG/STRING

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1983?page=com.atlassian.jira.plugi... ] Jean-Francois Denise edited comment on WFCORE-1983 at 11/16/16 8:30 AM: ------------------------------------------------------------------------ I have looked at the server side handling of arguments for the read-resource (ReadResourceHandler). When the numbers or String are in range, aproper adaptation is made on the server side. :read-resource(recursive-depth="9"), :read-resource(recursive-depth=9L), :read-resource(recursive-depth=9.4), are property converted from STRING/LONG/DOUBLE to INT. With an out of range value (:read-resource(recursive-depth=999999999999)). The cli converts the out of range depth to STRING and send the request. The conversion to INT fails and the exception is swallowed in ModelTypeValidator.matches. The server side should keep a reference to the last thrown exception and throw that instead of the generic type mismatch. was (Author: jdenise): I have looked at the server side handling of arguments for the read-resource (ReadResourceHandler). The faulty operation is: :read-resource(recursive-depth=999999999999). The cli converts the out of range depth to STRING and send the request. The server handler validates each parameter and checks for the value type. The only valid type for recursive-depth is INT. So the operation fails with "WFLYCTL0097: Wrong type for 'recursive-depth'. Expected [INT] but was STRING". Same occurs for list-add.index. > CLI type decision INT/STRING LONG/STRING > ---------------------------------------- > > Key: WFCORE-1983 > URL: https://issues.jboss.org/browse/WFCORE-1983 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > It happens that the CLI does a custom parsing of the value in case ModelNode.fromString fails (whatever the exception). > The issue is that the custom parsing doesn't follow the ModelNode parsing syntax and parse everything as String. So the resulting ModelNode that is serialised and sent to the server has been transformed. > I am surprised that we don't have more of such failures. For example, when numbers are located inside custom complex structure such as: {mynumber=9999} that will be sent as an OBJECT containing a STRING although the valid DMR syntax {"my number"=>999} would be sent as an OBJECT containing an INT. > Some server side subsystems are smart enough to call into asXXX methods and not check the type? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7080) Creating ssl context with only required attribute cause NPE

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7080?page=com.atlassian.jira.plugin.... ] Martin Choma commented on WFLY-7080: ------------------------------------ Shouldnt't be keyManager required for server-ssl-context? What would be a use case for key-managers=null in case of server-ssl-context? Key-managares in elytron holds reference to key-store. Can it be somehow intended to create server-ssl-context without configured keystore through elytron? Coming to my mind e.g. setting keystore through system property javax.net.ssl.keyStore? > Creating ssl context with only required attribute cause NPE > ----------------------------------------------------------- > > Key: WFLY-7080 > URL: https://issues.jboss.org/browse/WFLY-7080 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > Labels: user_experience > Fix For: 11.0.0.Alpha1 > > > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=server2:add(protocols=[TLSv1_2]) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {noformat} > In log of server there is exception: > {noformat} > 07:12:21,014 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.security.ssl-context.server2: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:275) > at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45) > at org.wildfly.extension.elytron.SSLDefinitions$3.lambda$getValueSupplier$1(SSLDefinitions.java:411) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > 07:12:21,016 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("server-ssl-context" => "server2") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7111) Distributable web applications cause Infinispan exceptions when Elytron is used

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/WFLY-7111?page=com.atlassian.jira.plugin.... ] Pedro Igor updated WFLY-7111: ----------------------------- Fix Version/s: 11.0.0.Alpha1 > Distributable web applications cause Infinispan exceptions when Elytron is used > ------------------------------------------------------------------------------- > > Key: WFLY-7111 > URL: https://issues.jboss.org/browse/WFLY-7111 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Pedro Igor > Priority: Blocker > Fix For: 11.0.0.Alpha1 > > > When a distributable secured web application mapped to Elytron domain is deployed to EAP and accessed. It throws intermittently {{org.infinispan.util.concurrent.TimeoutException}} > *Expected behavior:* > Distributable applications should be accessible without exceptions when Elytron is used. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7111) Distributable web applications cause Infinispan exceptions when Elytron is used

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/WFLY-7111?page=com.atlassian.jira.plugin.... ] Pedro Igor updated WFLY-7111: ----------------------------- Fix Version/s: (was: No Release) > Distributable web applications cause Infinispan exceptions when Elytron is used > ------------------------------------------------------------------------------- > > Key: WFLY-7111 > URL: https://issues.jboss.org/browse/WFLY-7111 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Pedro Igor > Priority: Blocker > > When a distributable secured web application mapped to Elytron domain is deployed to EAP and accessed. It throws intermittently {{org.infinispan.util.concurrent.TimeoutException}} > *Expected behavior:* > Distributable applications should be accessible without exceptions when Elytron is used. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 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 November 2016