[JBoss JIRA] (DROOLS-2157) DMN Editor: Contexts: Add special behaviour of last row
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2157?page=com.atlassian.jira.plugi... ]
Michael Anstis resolved DROOLS-2157.
------------------------------------
Resolution: Done
> DMN Editor: Contexts: Add special behaviour of last row
> -------------------------------------------------------
>
> Key: DROOLS-2157
> URL: https://issues.jboss.org/browse/DROOLS-2157
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Michael Anstis
>
> The last row of a {{Context}} should span all columns and populate the last {{ContextEntry}} in the {{Context}}. It should not have a variable. This is the XML for a _regular_ row and the _final_ row:
> {code}
> <semantic:context id="_f4f86e5f-e3e3-4b99-9260-8086764e598f">
> <semantic:contextEntry>
> <semantic:variable id="_779ca919-15d8-48d0-a9f0-e0203e60fac6" name="in1"/>
> <semantic:literalExpression id="_4b8b8cc1-a56c-4673-8334-96e178cd04a4">
> <semantic:text>"literal exp" </semantic:text>
> </semantic:literalExpression>
> </semantic:contextEntry>
> <semantic:contextEntry>
> <semantic:literalExpression id="_297181da-d0d5-4137-960b-34836d5570e5">
> <semantic:text>"result" </semantic:text>
> </semantic:literalExpression>
> </semantic:contextEntry>
> </semantic:context>
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9592) Arrays in Method Parameters are causing EJBAccessException for @PermitAll Methods
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9592?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar closed WFLY-9592.
-----------------------------
Resolution: Out of Date
Please check if it works in WildFly 11 and reopen if it does.
WF11 has completely new security layer.
> Arrays in Method Parameters are causing EJBAccessException for @PermitAll Methods
> ---------------------------------------------------------------------------------
>
> Key: WFLY-9592
> URL: https://issues.jboss.org/browse/WFLY-9592
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Environment: Wildfly 10.1.0.Final in an Arquillian Managed Container Test
> Reporter: Marcus Handte
> Priority: Minor
>
> EJB methods with array parameters are causing EJBAccessExceptions when they are annotated with @PermitAll. This bug seemed to be present in 8.0.0.Alpha2 and was fixed (see WFLY-1658). But it seems to be present again in 10.1.0.Final.
> For my own use case, this is not a problem since I can simply change the method signatures to use lists instead of arrays. However, I can imagine that this could be a more significant problem for people trying to run existing code that they do not want to (or cannot) touch.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (DROOLS-2161) Recursive function definitions in context entries are raising compile time errors
by Fedor Gavrilov (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2161?page=com.atlassian.jira.plugi... ]
Fedor Gavrilov commented on DROOLS-2161:
----------------------------------------
java.lang.AssertionError: DMNMessage{ severity=ERROR, type=FAILED_XML_VALIDATION, message='Failed XML validation of DMN file: cvc-elt.1: Cannot find the declaration of element 'semantic:definitions'.', sourceId='null', exception='SAXParseException : cvc-elt.1: Cannot find the declaration of element 'semantic:definitions'.', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Variable named 'h' is missing its type reference on node 'x'', sourceId='_95c8b5cc-4dd3-4a7b-bd93-d2f709c88bf2', exception='', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Variable named 'g' is missing its type reference on node 'x'', sourceId='_9e512834-3b21-47ec-902b-5e9525b01f07', exception='', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Variable named 'new list' is missing its type reference on node 'x'', sourceId='_7aad66b5-f3a7-4eae-a717-3c94eeb3858d', exception='', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Variable named 'x' is missing its type reference on node 'x'', sourceId='_eb1123e4-ddd4-44d7-8103-7a8d1523c7d0', exception='', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Parameter named 'list' is missing its type reference on node 'x'', sourceId='_234ad53b-b2e2-4cb4-b578-1d22546d06af', exception='', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Parameter named 'limit' is missing its type reference on node 'x'', sourceId='_632ea9f5-c827-47ee-926f-0973466e99b6', exception='', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Parameter named 'n' is missing its type reference on node 'x'', sourceId='_a4180fb5-08f5-4bff-a56c-bc9ee9e98939', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, type=ERR_COMPILING_FEEL, message='Error compiling FEEL expression 'if n + 1 > limit then
new list
else
f( n+1, limit, new list )' for name 'f' on node 'x': Unknown variable 'f'', sourceId='_89fb1571-a993-46fe-a8a7-0b51e11614a0', exception='', feelEvent='UnknownVariableErrorEvent : Unknown variable 'f''}
DMNMessage{ severity=ERROR, type=ERR_COMPILING_FEEL, message='Error compiling FEEL expression 'if n + 1 > limit then
append( list, n )
else
h( n+1, limit, append( list, n ) )' for name 'h' on node 'x': Unknown variable 'h'', sourceId='_a8c548dd-77e4-4a9e-8490-4485754433f4', exception='', feelEvent='UnknownVariableErrorEvent : Unknown variable 'h''}
> Recursive function definitions in context entries are raising compile time errors
> ---------------------------------------------------------------------------------
>
> Key: DROOLS-2161
> URL: https://issues.jboss.org/browse/DROOLS-2161
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.4.1.Final
> Reporter: Edson Tirelli
> Assignee: Fedor Gavrilov
> Attachments: ContextRecursion.dmn
>
>
> Recursive function definitions in contexts are raising compile time errors but are executing correctly.
> See attached model for example. Functions "f" and "h" raise compile time errors.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFCORE-2780) Improve buffer-pool model description
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2780?page=com.atlassian.jira.plugi... ]
Romain Pelisse updated WFCORE-2780:
-----------------------------------
Description:
Current state of buffer-pool model description:
{code}
[standalone@localhost:9990 /] /subsystem=io/buffer-pool=foo:read-resource-description
{
"outcome" => "success",
"result" => {
"description" => "Defines buffer pool",
"capabilities" => [{
"name" => "org.wildfly.io.buffer-pool",
"dynamic" => true
}],
"attributes" => {
"buffer-size" => {
"type" => INT,
"description" => "The size of each buffer slice in bytes, if not set optimal value is calculated based on available RAM resources in your system.",
"expressions-allowed" => true,
"required" => false,
"nillable" => true,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "all-services"
},
"buffers-per-slice" => {
"type" => INT,
"description" => "How many buffers per slice, if not set optimal value is calculated based on available RAM resources in your system.",
"expressions-allowed" => true,
"required" => false,
"nillable" => true,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "all-services"
},
"direct-buffers" => {
"type" => BOOLEAN,
"description" => "Does the buffer pool use direct buffers, some platforms don't support direct buffers",
"expressions-allowed" => true,
"required" => false,
"nillable" => true,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "all-services"
}
},
"operations" => undefined,
"notifications" => undefined,
"children" => {}
}
}
{code}
Following improvements should be done to it:
* In {{buffer-size}} and {{buffers-per-slice}} description there is mentioned something called 'slice'. Nowhere is described what it is. Suggested improvement: Explain what slice is, preferably in buffer-pool model description.
* In {{buffer-size}} and {{buffers-per-slice}} description there is this sentence: ''...if not set optimal value is calculated based on available RAM resources in your system" - how it is calculated? Is there any default fixed value? User would like to know this. Suggestion: Add explanation about default value.
* In {{direct-buffers}} description there is mentioned that some platforms don't support direct buffers? Is there mentioned which one or what determines whether direct buffers are supported on given platform? Suggested improvement: Explain what element determines whether direct buffers are supported.
> Improve buffer-pool model description
> -------------------------------------
>
> Key: WFCORE-2780
> URL: https://issues.jboss.org/browse/WFCORE-2780
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Romain Pelisse
> Assignee: Romain Pelisse
> Priority: Minor
>
> Current state of buffer-pool model description:
> {code}
> [standalone@localhost:9990 /] /subsystem=io/buffer-pool=foo:read-resource-description
> {
> "outcome" => "success",
> "result" => {
> "description" => "Defines buffer pool",
> "capabilities" => [{
> "name" => "org.wildfly.io.buffer-pool",
> "dynamic" => true
> }],
> "attributes" => {
> "buffer-size" => {
> "type" => INT,
> "description" => "The size of each buffer slice in bytes, if not set optimal value is calculated based on available RAM resources in your system.",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> "buffers-per-slice" => {
> "type" => INT,
> "description" => "How many buffers per slice, if not set optimal value is calculated based on available RAM resources in your system.",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> "direct-buffers" => {
> "type" => BOOLEAN,
> "description" => "Does the buffer pool use direct buffers, some platforms don't support direct buffers",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> }
> },
> "operations" => undefined,
> "notifications" => undefined,
> "children" => {}
> }
> }
> {code}
> Following improvements should be done to it:
> * In {{buffer-size}} and {{buffers-per-slice}} description there is mentioned something called 'slice'. Nowhere is described what it is. Suggested improvement: Explain what slice is, preferably in buffer-pool model description.
> * In {{buffer-size}} and {{buffers-per-slice}} description there is this sentence: ''...if not set optimal value is calculated based on available RAM resources in your system" - how it is calculated? Is there any default fixed value? User would like to know this. Suggestion: Add explanation about default value.
> * In {{direct-buffers}} description there is mentioned that some platforms don't support direct buffers? Is there mentioned which one or what determines whether direct buffers are supported on given platform? Suggested improvement: Explain what element determines whether direct buffers are supported.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9592) Arrays in Method Parameters are causing EJBAccessException for @PermitAll Methods
by Marcus Handte (JIRA)
Marcus Handte created WFLY-9592:
-----------------------------------
Summary: Arrays in Method Parameters are causing EJBAccessException for @PermitAll Methods
Key: WFLY-9592
URL: https://issues.jboss.org/browse/WFLY-9592
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 10.1.0.Final
Environment: Wildfly 10.1.0.Final in an Arquillian Managed Container Test
Reporter: Marcus Handte
Priority: Minor
EJB methods with array parameters are causing EJBAccessExceptions when they are annotated with @PermitAll. This bug seemed to be present in 8.0.0.Alpha2 and was fixed (see WFLY-1658). But it seems to be present again in 10.1.0.Final.
For my own use case, this is not a problem since I can simply change the method signatures to use lists instead of arrays. However, I can imagine that this could be a more significant problem for people trying to run existing code that they do not want to (or cannot) touch.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (DROOLS-2162) Error evaluating constraint
by Herve Remisio (JIRA)
Herve Remisio created DROOLS-2162:
-------------------------------------
Summary: Error evaluating constraint
Key: DROOLS-2162
URL: https://issues.jboss.org/browse/DROOLS-2162
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.4.1.Final
Reporter: Herve Remisio
Assignee: Mario Fusco
Priority: Blocker
Attachments: 2017-12-04_12-33-29.png
We detected a very strange behavior when processing Rules that contain expressions like "...startsWith(..".
!2017-12-04_12-33-29.png|thumbnail!
Sometimes this error disappears when we simply re-upload the Rule file and it gets recompiled.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9591) Correct attributes representing Artemis addresses
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-9591?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-9591:
------------------------------
Summary: Correct attributes representing Artemis addresses (was: Add ParameterCorrector to attributes representing Artemis addresses)
> Correct attributes representing Artemis addresses
> -------------------------------------------------
>
> Key: WFLY-9591
> URL: https://issues.jboss.org/browse/WFLY-9591
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> Artemis 2.x has changed the naming convention for its resources.
> JMS Queue (resp. topic) no longer uses the "jms.queue." (resp. "jms.topic.") prefix to name its address and core queues.
> In the messaging-activemq subsystem, there are many attributes that correspond to such addresses.
> In the default configuration, we specified addresses for expiry and DLQ in the address-setting resources:
> {code}
> <address-setting name="#"
> dead-letter-address="jms.queue.DLQ"
> expiry-address="jms.queue.ExpiryQueue" />
> {code}
> This configuration must now be updated to use the new address naming convention:
> {code}
> <address-setting name="#"
> dead-letter-address="DLQ"
> expiry-address="ExpiryQueue" />
> {code}
> In order to preserve backwards compatibility, we must also "correct" previous configuration when they are loaded.
> If we detect that an attribute that corresponds to an Artemis address has a value that starts with "jms.queue." or "jms.topic.", we log a warning that such value is no longer correct for Artemis and use instead the value without the prefix.
> There is also a special case for the cluster-connection that was using the "jms" value in the default configuration to forward any address that started with "jms" (i.e. any JMS resources) to the cluster.
> This is no longer correct with Artemis 2.4 and instead we must use the "" (empty string) so that any addresses are forwarded to the cluster.
> Again, we must also correct the attribute if its value is "jms" to use "" instead.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9591) Add ParameterCorrector to attributes representing Artemis addresses
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-9591:
---------------------------------
Summary: Add ParameterCorrector to attributes representing Artemis addresses
Key: WFLY-9591
URL: https://issues.jboss.org/browse/WFLY-9591
Project: WildFly
Issue Type: Bug
Components: JMS
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
Artemis 2.x has changed the naming convention for its resources.
JMS Queue (resp. topic) no longer uses the "jms.queue." (resp. "jms.topic.") prefix to name its address and core queues.
In the messaging-activemq subsystem, there are many attributes that correspond to such addresses.
In the default configuration, we specified addresses for expiry and DLQ in the address-setting resources:
{code}
<address-setting name="#"
dead-letter-address="jms.queue.DLQ"
expiry-address="jms.queue.ExpiryQueue" />
{code}
This configuration must now be updated to use the new address naming convention:
{code}
<address-setting name="#"
dead-letter-address="DLQ"
expiry-address="ExpiryQueue" />
{code}
In order to preserve backwards compatibility, we must also "correct" previous configuration when they are loaded.
If we detect that an attribute that corresponds to an Artemis address has a value that starts with "jms.queue." or "jms.topic.", we log a warning that such value is no longer correct for Artemis and use instead the value without the prefix.
There is also a special case for the cluster-connection that was using the "jms" value in the default configuration to forward any address that started with "jms" (i.e. any JMS resources) to the cluster.
This is no longer correct with Artemis 2.4 and instead we must use the "" (empty string) so that any addresses are forwarded to the cluster.
Again, we must also correct the attribute if its value is "jms" to use "" instead.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months