[JBoss JIRA] (DROOLS-441) drools-guvnor 5.5, declarative model, create more than one fact type, BPMN process does not load
by niraj gupta (JIRA)
[ https://issues.jboss.org/browse/DROOLS-441?page=com.atlassian.jira.plugin... ]
niraj gupta commented on DROOLS-441:
------------------------------------
Thanks Davide for quick response.
My Declarative model is like below
View Source: DecModel1
1. | declare MEmp
2. | eid: Integer
3. | ename: String
4. | end
5. |
6. | declare EBank
7. | bid: Integer
8. | end
My Process is very simple start --> script task (System.out.println("AA");) --> end
My Process no longer using Model
Yes, it is working fine with single bean. I also having the same doubt creation of the second bean is having some problem, but unfortunately no exception, even i put try catch in few calls.
The moment i put 2nd bean and go to process to update AA to BB, and build deploy the package. now using console i am accessing this process which is printing AA not BB.
This is my problem.
Hope i explained you in detail. but still let me know in case need more details.
Thanks,
Niraj
> drools-guvnor 5.5, declarative model, create more than one fact type, BPMN process does not load
> ------------------------------------------------------------------------------------------------
>
> Key: DROOLS-441
> URL: https://issues.jboss.org/browse/DROOLS-441
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Environment: Tomcat 6.0.35, jBPM 5.5.Final
> Reporter: niraj gupta
> Assignee: Mark Proctor
> Labels: drools-guvnor
>
> I am using ‘drools-guvnor 5.5.0.Final’ open source tool for designing the business process (BPMN2). I end up in an issue and looking for help. Following is the scenario
> I created a package then process then after build, deploy execute successfully. Now I came back to guvnor and made few changes in the process. Then after same build, deploy execute successfully. But now this time I am creating a declarative model having 2 facts, also modifying business process. Then after same build, deploy execute successfully. This time modified/latest business process doesn’t load into console. This is my problem. However I trouble shoot and google following are my observations:
> • I am running this application in tomcat 6.0.35
> • It works perfectly with POJO Model Jar approach.
> • It works perfectly with declarative model but having single fact.
> • I am not seeing any exceptions either in UI or console logs
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (DROOLS-441) drools-guvnor 5.5, declarative model, create more than one fact type, BPMN process does not load
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/DROOLS-441?page=com.atlassian.jira.plugin... ]
Davide Sottara commented on DROOLS-441:
---------------------------------------
Could you please provide some additional detail or, better, a reproducer?
We'd need to know at least:
- declared beans
- BPMN process
- how the process uses the beans
It seems that something happens during the creation of the second bean and/or the modification of the process.
Does the problem arise if you just add the second bean? or if you just modify the process?
There might be an error - or a bug - in any of the steps above.
Thanks!
Davide
> drools-guvnor 5.5, declarative model, create more than one fact type, BPMN process does not load
> ------------------------------------------------------------------------------------------------
>
> Key: DROOLS-441
> URL: https://issues.jboss.org/browse/DROOLS-441
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Environment: Tomcat 6.0.35, jBPM 5.5.Final
> Reporter: niraj gupta
> Assignee: Mark Proctor
> Labels: drools-guvnor
>
> I am using ‘drools-guvnor 5.5.0.Final’ open source tool for designing the business process (BPMN2). I end up in an issue and looking for help. Following is the scenario
> I created a package then process then after build, deploy execute successfully. Now I came back to guvnor and made few changes in the process. Then after same build, deploy execute successfully. But now this time I am creating a declarative model having 2 facts, also modifying business process. Then after same build, deploy execute successfully. This time modified/latest business process doesn’t load into console. This is my problem. However I trouble shoot and google following are my observations:
> • I am running this application in tomcat 6.0.35
> • It works perfectly with POJO Model Jar approach.
> • It works perfectly with declarative model but having single fact.
> • I am not seeing any exceptions either in UI or console logs
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JGRP-1785) TOA, inconsistent message delivery
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/JGRP-1785?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo commented on JGRP-1785:
-----------------------------------
[~belaban], unfortunately I'm busy with ISPN issues currently. I'll try to take a look this week.
> TOA, inconsistent message delivery
> ----------------------------------
>
> Key: JGRP-1785
> URL: https://issues.jboss.org/browse/JGRP-1785
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.5
> Environment: Fedora release 17 (Beefy Miracle)
> Reporter: Ryan Emerson
> Assignee: Pedro Ruivo
> Fix For: 3.5
>
>
> When sending total order messages between two nodes, for a prolonged period of time, an inconsistency is encountered when comparing each node's total order of messages.
> I believe this issue is related to how sequence numbers are handled in the implementation, not the protocol itself. I appreciate that TOA is designed for environments where the subset of destinations in the network varies, however I have been unable to reproduce this error when the total number of nodes is > 2. It is still possible that this inconsistency may occur after a large amount of time when the number of nodes is > 2.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-2459) Serialization of java.time classes on EJB calls fails
by Steven Pessall (JIRA)
[ https://issues.jboss.org/browse/WFLY-2459?page=com.atlassian.jira.plugin.... ]
Steven Pessall commented on WFLY-2459:
--------------------------------------
I just tested it with 8.0.0.Final. With that version the problem does not occur anymore.
> Serialization of java.time classes on EJB calls fails
> -----------------------------------------------------
>
> Key: WFLY-2459
> URL: https://issues.jboss.org/browse/WFLY-2459
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Beta1
> Environment: JBoss AS 7.2
> Reporter: Steven Pessall
> Assignee: David Lloyd
> Labels: AS7, EJB3
>
> First of all: We stumbled on the issue desribed here on JBoss AS 7.2, but the relevant source coude seems to be unchanged in WildFly.
> In method org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation() a ClonerConfiguration object is programmatically created for the configuration of a org.jboss.marshalling.cloner.SerializingCloner instance.
> The default configuration causes IllegalAccessExceptions when serializing classes of the new java.time package (Java 8) respectively for the org.threeten library (Java 7 backport of JSR-310).
> Stacktrace:
> java.lang.RuntimeException: JBAS014154: Failed to marshal EJB parameters
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.clone(LocalEjbReceiver.java:270) [jboss-as-ejb3-7.2.0.Final.jar:7.2.0.Final]
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.clone(LocalEjbReceiver.java:259) [jboss-as-ejb3-7.2.0.Final.jar:7.2.0.Final]
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:170) [jboss-as-ejb3-7.2.0.Final.jar:7.2.0.Final]
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
> at org.jboss.ejb.client.EJBHomeCreateInterceptor.handleInvocation(EJBHomeCreateInterceptor.java:79) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:177) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:161) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:124) [jboss-ejb-client-1.0.16.Final.jar:1.0.16.Final]
> at com.sun.proxy.$Proxy124.getList(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:267) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
> at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
> at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
> at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:263) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
> at org.jboss.weld.bean.builtin.CallableMethodHandler.invoke(CallableMethodHandler.java:52) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
> at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:105) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
> at kam.cmd.boundary.access.MDListService$431771952$Proxy$_$$_Weld$Proxy$.getList(MDListService$431771952$Proxy$_$$_Weld$Proxy$.java) [cmd-core-boundary-0.0.10-SNAPSHOT.jar:]
> at kam.cmd.client.AbstractMasterDataClient.getData(AbstractMasterDataClient.java:57) [cmd-core-client-base-0.0.10-SNAPSHOT.jar:]
> at kam.cmd.client.ejb.EJBMasterDataClient$Proxy$_$$_WeldClientProxy.getData(EJBMasterDataClient$Proxy$_$$_WeldClientProxy.java) [cmd-core-client-ejb-0.0.10-SNAPSHOT.jar:]
> at kam.cmd.resourcebrowser.BackwareBrowser.getRes(BackwareBrowser.java:37) [classes:]
> at kam.cmd.resourcebrowser.BackwareBrowser$Proxy$_$$_WeldClientProxy.getRes(BackwareBrowser$Proxy$_$$_WeldClientProxy.java) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) [resteasy-jaxrs-2.3.5.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:257) [resteasy-jaxrs-2.3.5.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:222) [resteasy-jaxrs-2.3.5.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:211) [resteasy-jaxrs-2.3.5.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542) [resteasy-jaxrs-2.3.5.Final.jar:]
> ... 19 more
> Caused by: java.io.InvalidClassException: org.threeten.bp.Ser; Illegal access exception occurred accessing the constructor: java.lang.IllegalAccessException: Class org.jboss.marshalling.reflect.PublicReflectiveCreator can not access a member of class org.threeten.bp.Ser with modifiers "public"
> at org.jboss.marshalling.reflect.PublicReflectiveCreator.create(PublicReflectiveCreator.java:43)
> at org.jboss.marshalling.cloner.SerializingCloner.clone(SerializingCloner.java:240)
> at org.jboss.marshalling.cloner.SerializingCloner.clone(SerializingCloner.java:174)
> at org.jboss.marshalling.cloner.SerializingCloner.clone(SerializingCloner.java:134)
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.clone(LocalEjbReceiver.java:268) [jboss-as-ejb3-7.2.0.Final.jar:7.2.0.Final]
> ... 57 more
> The cause of the problem is, that the default configuration of the SerializingCloner uses the class org.jboss.marshalling.reflect.PublicReflectiveCreator for the instantiation of the serialized classes, which tries to directly call the default constructor. While the class org.threeten.bp.Ser does have a public constructor, the class itself only has package visibility, causing the IllegalAccessException.
> There is another implementation org.jboss.marshalling.reflect.ReflectiveCreator, which actually forces the accessibility of the constructor to be true. If an instance of this class was configured as externalizedCreator in ClonerConfiguration, the problem would be solved. But currently there is no way to influence the ClonerConfiguration used by the class LocalEjbReceiver.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JGRP-1800) OverlappingMergeTest testRegularMessageSending does not receive all expected mcast messages
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1800?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1800:
---------------------------
Fix Version/s: (was: 3.5)
> OverlappingMergeTest testRegularMessageSending does not receive all expected mcast messages
> -------------------------------------------------------------------------------------------
>
> Key: JGRP-1800
> URL: https://issues.jboss.org/browse/JGRP-1800
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL, Solairis
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> testRegularMessageSending is a kind of smoke test for the stack used in OverlappingMergeTest:
> - three channels a,b,c are created with a particular stack (see modifyConfigs)
> - each of a,b,c sends 5 multicast messages to the group, with message payloads "1", "2", "3", "4", "5"
> - the receiver in each channel collects up the multicasts received
> - the test checks that all 15 messages are received by each of the channels, and an assertion error is thrown is this is not the case
> This test is failing occasionally. An example of the error:
> {noformat}
> Error Message
> (C) num_mcasts=C: 1 C: 2 C: 3 C: 4 C: 5 A: 1 B: 1 A: 2 B: 2 B: 3 B: 4 A: 4 B: 5 A: 5 expected: 15)
> Stacktrace
> java.lang.AssertionError
> at org.jgroups.tests.OverlappingMergeTest.checkReceivedMessages(OverlappingMergeTest.java:476)
> at org.jgroups.tests.OverlappingMergeTest.testRegularMessageSending(OverlappingMergeTest.java:66)
> {noformat}
> This assertion error indicates that multicast #3 was not received from A by C.
> This is a very simple scenario and failures should not be occurring. I mention this error as there are other merge tests, namely:
> * testOverlappingMergeWithBC
> * testOverlappingMergeWithABC
> which are more complex, but when we look at their failures, they fail on an initial step similar to the one described above.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JGRP-1745) Optimize in-memory object size
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1745?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1745:
---------------------------
Fix Version/s: 4.0
(was: 3.5)
Ongoing task
> Optimize in-memory object size
> ------------------------------
>
> Key: JGRP-1745
> URL: https://issues.jboss.org/browse/JGRP-1745
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> Get the Java Object Layout tool from [1] and
> * Measure the size of objects which are frequently allocated in memory, e.g.
> ** Message
> ** Event
> ** Header subclasses (TpHeader, UNICAST3$Header, STABLE$Header, NakaAckHeader3)
> Try to remove fields which are not absolutely needed and / or can be moved into the superclass.
> E.g.: {{NakAckHeader2.sender}} might get removed: can't we determine the sender from the message ? (Maybe not, if sender is the original sender, not the sender of the message)
> [1] https://github.com/Sanne/java-object-layout
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JGRP-1785) TOA, inconsistent message delivery
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1785?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1785:
--------------------------------
[~pruivo], what's the status ? I hope to release 3.5 within the next 6-8 weeks...
> TOA, inconsistent message delivery
> ----------------------------------
>
> Key: JGRP-1785
> URL: https://issues.jboss.org/browse/JGRP-1785
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.5
> Environment: Fedora release 17 (Beefy Miracle)
> Reporter: Ryan Emerson
> Assignee: Pedro Ruivo
> Fix For: 3.5
>
>
> When sending total order messages between two nodes, for a prolonged period of time, an inconsistency is encountered when comparing each node's total order of messages.
> I believe this issue is related to how sequence numbers are handled in the implementation, not the protocol itself. I appreciate that TOA is designed for environments where the subset of destinations in the network varies, however I have been unable to reproduce this error when the total number of nodes is > 2. It is still possible that this inconsistency may occur after a large amount of time when the number of nodes is > 2.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months