[JBoss JIRA] (WFLY-10808) Default Value of local-receiver-pass-by-value in jboss-ejb-client Descriptor is Not Respected
by Cheng Fang (Jira)
[ https://issues.jboss.org/browse/WFLY-10808?page=com.atlassian.jira.plugin... ]
Cheng Fang commented on WFLY-10808:
-----------------------------------
tests added to wildfly repo via PR https://github.com/wildfly/wildfly/pull/12368
> Default Value of local-receiver-pass-by-value in jboss-ejb-client Descriptor is Not Respected
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-10808
> URL: https://issues.jboss.org/browse/WFLY-10808
> Project: WildFly
> Issue Type: Bug
> Components: EE, EJB
> Affects Versions: 11.0.0.Final, 12.0.0.Final, 13.0.0.Final
> Reporter: Joshua Swett
> Assignee: Bartosz Baranowski
> Priority: Minor
> Labels: downstream_dependency
> Fix For: 16.0.0.Beta1, 16.0.0.Final
>
> Attachments: TestWAR.war
>
>
> The jboss-ejb-client.xml deployment descriptor file can be used to configure the pass semantics of the local EJB receiver using the local-receiver-pass-by-value attribute.
> As per the EJB spec, the default behaviour should be to pass by value, and this is appropriately reflected in the jboss-ejb-client XSD. As of Wildfly 11, the *omission* of the local-receiver-pass-by-value attribute in a jboss-ejb-client deployment descriptor actually results in remote EJB parameters and the return value being passed by reference as opposed to the documented default of being passed by value.
> It appears that this bug is a result of changes made for WFLY-5403. The root cause is that the EJBClientDescriptorMetaDataProcessor.java class only uses the pass-by-value receiver if the local-receiver-pass-by-value attribute is Boolean.TRUE (line 177 in 13.0.0.Final), but EJBClientDescriptor10Parser.java defaults the value to null if it is not included in the jboss-ejb-client.xml (line 132 in 13.0.0.Final). The old and working behaviour was to fallback to the value configured at the ejb subsystem level if the jboss-ejb-client.xml excluded the attribute.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (DROOLS-2733) Support MVEL Dialect using custom inline accumulate code with external declarations in the executable model
by Luca Molteni (Jira)
[ https://issues.jboss.org/browse/DROOLS-2733?page=com.atlassian.jira.plugi... ]
Luca Molteni updated DROOLS-2733:
---------------------------------
Sprint: 2019 Week 26-28 (was: 2019 Week 29-31)
> Support MVEL Dialect using custom inline accumulate code with external declarations in the executable model
> -----------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-2733
> URL: https://issues.jboss.org/browse/DROOLS-2733
> Project: Drools
> Issue Type: Feature Request
> Components: executable model
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Optional
>
> The executable model doesn't support custom inline accumulate code that uses external declarations such as
> {code:java}
> String str = "import " + Person.class.getCanonicalName() + ";\n" +
> "rule R dialect \"mvel\" when\n" +
> " String( $l : length )" +
> " $sum : Integer() from accumulate (\n" +
> " Person( age > 18, $age : age ), init( int sum = 0 * $l; ), action( sum += $age; ), reverse( sum -= $age; ), result( sum )\n" +
> " )" +
> "then\n" +
> " insert($sum);\n" +
> "end";
> {code}
> (Notice that in the init we multiply the sum value with the length of string)
> But it can support such style using the "classic" generation of accumulate classes which gets compiled among the executable model and instantiate during the execution of the DSL.
> This mechanism is broken with the MVEL dialect, as we don't have such generated classes.
> Probably what we should do instead is putting MVEL expressions in the DSL directly such as
> {code:java}
> accumulateScript("initCode", "accCode", "reverseCode");
> {code}
> and then during interpretation create a new MVEL context and execute the accumulate in memory
> See
> AccumulateUnsupportedTest.testMVELAccumulate
> AccumulateUnsupportedTest.testMVELAccumulate2WM
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (DROOLS-2830) kie-maven-plugin can't resolve custom operators declared in project's kmodule.xml
by Luca Molteni (Jira)
[ https://issues.jboss.org/browse/DROOLS-2830?page=com.atlassian.jira.plugi... ]
Luca Molteni updated DROOLS-2830:
---------------------------------
Sprint: 2019 Week 29-31
> kie-maven-plugin can't resolve custom operators declared in project's kmodule.xml
> ---------------------------------------------------------------------------------
>
> Key: DROOLS-2830
> URL: https://issues.jboss.org/browse/DROOLS-2830
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.9.0.Final
> Reporter: Esteban Aliverti
> Assignee: Luca Molteni
> Priority: Major
> Attachments: sample2.zip
>
>
> The kie-maven-plugin fails to build a KieBase when it uses a custom operator defined in the projects' kmodule.xml.
> As far as I can tell, it seems like the kie-maven-plugin is not even using the project's kmodule.xml but it is using a predefined one.
> The same project works when using Drools 6.5.
> I'm attaching a simple project showing this problem. The project won't build when using version 7.9 but it will work fine then using version 6.5. Just unzip the .zip file and run _mvn clean package_
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months