[JBoss JIRA] (DROOLS-4973) Defined DMN collection unary checks do not pass
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-4973?page=com.atlassian.jira.plug... ]
Yeser Amer commented on DROOLS-4973:
------------------------------------
[~jomarko] [~danielezonca] The cause of the issue can be explained with the current logic used by FEEL evaluator to compare two collections. According to this logic, 2 collections are equals if they contain the same elements IN THE SAME ORDER. You can find this logic in EvalHelper.java class, line 651.
Then, to solve the first failed test in the reported case, simply change "?=[{Price:3300,Name:"CAR"}, {Price:2000,Name:"PC"}]" to "?=[{Price:2000,Name:"PC"},{Price:3300,Name:"CAR"}]" and the test will pass with success. Don't know the reason of this logic in FEEL, if is expected or not.
> Defined DMN collection unary checks do not pass
> -----------------------------------------------
>
> Key: DROOLS-4973
> URL: https://issues.redhat.com/browse/DROOLS-4973
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.32.0.Final
> Reporter: Jozef Marko
> Assignee: Daniele Zonca
> Priority: Critical
> Labels: drools-tools
> Attachments: MySpace_eshop.zip
>
>
> Import the attached project and click Build, then Test.
> The re are defined 2 groups of 2 equivalent tests. In each group one test has a collection unary check defined with UI editor and one test defined a collection unary check with textual editor. The issue is tests with the unary check defined via textual editor do not pass.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (JGRP-1860) Custom classloader in RpcDispatcher
by Todd Sandor (Jira)
[ https://issues.redhat.com/browse/JGRP-1860?page=com.atlassian.jira.plugin... ]
Todd Sandor commented on JGRP-1860:
-----------------------------------
Thanks Bela.
I had a couple other porting questions, I sent them to " Porting-Guide/Release-Notes between 3.6.14 and 4.0.15" here javagroups-users(a)lists.sourceforge.net as they are not appropriate here.
I did try to start a new "help" discussion here https://sourceforge.net/p/javagroups/discussion/18795/
but when I hit the "Send email to create a new topic" nothing seemed to occur ...
Cheers
> Custom classloader in RpcDispatcher
> -----------------------------------
>
> Key: JGRP-1860
> URL: https://issues.redhat.com/browse/JGRP-1860
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 3.2.13
> Reporter: Dennis Reed
> Assignee: Bela Ban
> Priority: Major
> Fix For: 3.4.5, 3.5
>
>
> RpcDispatcher is hard-coded to use JGroups' classloader when marshalling the users's custom objects over RPC.
> RpcDispatcher uses Util.objectFromByteBuffer to unmarshall, which uses an ObjectInputStream. ObjectInputStream uses the classloader of its caller's class (Util).
> RpcDispatcher does allow a custom marshaller to be used (implementing RpcDispatcher.Marshaller), but since Util.objectFromByteBuffer hard-codes the use of ObjectInputStream, a custom marshaller cannot simply set the classloader and then delegate back to the default JGroups code.
> Util.objectFromBuffer should be enhanced to use a custom ObjectInputStream implementation that overrides resolveClass to use a custom classloader, and an API should be added to RpcDispatcher to pass in the classloader to use.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-13009) moduleAvailability message is sent before module has started
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13009?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz commented on WFLY-13009:
--------------------------------------------
Just to note that there can be a significant difference between the time that deploymentAdded is called versus deploymentStarted in the case of @Singleton beans with the @Startup annotation. In this case, the bean with @Startup is asked to perform eager initialization (i.e. the bean is initialized before the deployment starts receiving requests) and there is a mechanism involving StartupCountdown which delays the firing of the deploymentStarted method until the eager initialization completes. This emphasises the fact that the moduleAvailable message really should be sent out on deploymentStarted and not deploymentAvailable.
> moduleAvailability message is sent before module has started
> ------------------------------------------------------------
>
> Key: WFLY-13009
> URL: https://issues.redhat.com/browse/WFLY-13009
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 19.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
>
> When EJBs are deployed in a clustered server environment, moduleAvailability messages are sent from the server to all connected EJB client applications in order to inform the client that the module is available on that node.
> The sending of moduleAvailability messages involves the DeploymentRepository, which records which modules are deployed, and the ModuleAvailabilityListener, which is a DeploymentRepositoryListener which gets called at various stages of module deployment (adding, starting, stopping).
> It looks as though moduleAvailability message are being sent earlier than they should be; in other words, sent when the module is added to the repository and not when the module is later started. This can cause client invocations on the module to return a NoSuchEJBException even after the moduleAvailability message has been sent to the client, causing what is seen in EJBCLIENT-362.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months