[JBoss JIRA] Created: (JBPM-2546) creating URL with processresource failes
by Hans Guldager Knudsen (JIRA)
creating URL with processresource failes
----------------------------------------
Key: JBPM-2546
URL: https://jira.jboss.org/jira/browse/JBPM-2546
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jBPM 3.2.x
Environment: jBPM 3.2.X, ESB 4.6, AS 5.1
Reporter: Hans Guldager Knudsen
Hi!
If I load a resouce inside an ActionHandler i get an URL with the "protocolresouce" protocol - eg :
URL resouceUrl = Thread.currentThread().getContextClassLoader().getResource("resource.txt");
gives me :
processresource://recieve_bussiness_msg/classes/classes/resource.txt
But if I try to create an URL with the same form
URL recreatedUri = new URL( "processresource://recieve_bussiness_msg/classes/classes/resource.txt" );
I get an :
java.net.MalformedURLException: unknown protocol: processresource
at java.net.URL.<init>(URL.java:574)
It seems that there is no
java.net.URLStreamHandler
to handle the protocol..
I will attach example of how this could be implemented.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBPM-2588) Attribute for tag decision to validate conditions of transitions
by Wojtas Koziej (JIRA)
Attribute for tag decision to validate conditions of transitions
----------------------------------------------------------------
Key: JBPM-2588
URL: https://jira.jboss.org/jira/browse/JBPM-2588
Project: jBPM
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Runtime Engine
Reporter: Wojtas Koziej
My proposition is to extend evaluation of condition when selecting leaving transitions
<decision condition-evaluation="strict|first-matching|???">
....
</decision>
condition-evaluation (or similar attribute) meaning:
* strict - all conditions are evaluated, lets name N as number of conditions which evaluates to true. If N != 1 jBPM raise exception. Transitions without conditions are not allowed
* first-matching - jBPM evaluates conditions and leave when find first which evaluate to true. If there is no such transition jBPM raise exception. Transitions without conditions are allowed and evaluates to true.
* ??? (I don't no how to name it) - this is default and makes that jBPM behaves as described in current documentation : "So first, all transitions with a condition are evaluated. If one of those evaluate to true, that transition is taken. If no transition with a condition resolves to true, the default transition (=the first one) is taken"
It will be very helpful during development and testing.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBPM-2589) SuperState - StaleObjectStateException when timer signals the token
by Adrian Apthorp (JIRA)
SuperState - StaleObjectStateException when timer signals the token
-------------------------------------------------------------------
Key: JBPM-2589
URL: https://jira.jboss.org/jira/browse/JBPM-2589
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 3.2.6.SP1
Environment: Win XP, HSQL, JBOSS 4.2.3
Reporter: Adrian Apthorp
When I configure a timer on a superstate a StaleObjectStateException is raised when the timer is fired.
org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [org.jbpm.graph.exe.Token#578]
at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1765)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2407)
at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2307)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2607)
at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:92)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:234)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:142)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
at org.hibernate.transaction.CacheSynchronization.beforeCompletion(CacheSynchronization.java:59)
at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:114)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:247)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:86)
at com.arjuna.ats.arjuna.AtomicAction.end(AtomicAction.java:216)
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commit(TransactionImple.java:240)
at org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxInterceptorCMT.java:501)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:361)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:527)
at org.jboss.ejb.Container.invoke(Container.java:960)
at org.jboss.ejb.txtimer.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:99)
at org.jboss.ejb.txtimer.TimerImpl$TimerTaskImpl.run(TimerImpl.java:561)
at java.util.TimerThread.mainLoop(Unknown Source)
at java.util.TimerThread.run(Unknown Source)
In the following example the timer works correctly on the state node but fails on the superstate timer. Also, it seems that the timer fires for both sub-states (the message is reported twice). When I remove one of the substates the exception still occurs with the message reported once.
<state name="State 1">
<timer duedate="20 seconds" repeat="20 seconds" name="late leaving">
<script>
System.out.println("What are we waiting for ? ");
</script>
</timer>
<transition to="Moving" name="depart"></transition>
</state>
<super-state name="Moving">
<state name="Stopped">
<transition to="Started" name="start"></transition>
</state>
<state name="Started">
<transition to="Stopped" name="stop"></transition>
</state>
<timer duedate="30 seconds" repeat="30 seconds">
<script>
System.out.println("We're late ");
</script>
</timer>
<transition to="end-state1" name="arrive"></transition>
</super-state>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBPM-2602) jBPM , Drools, Seam 2.2 - Transition issue
by Gary Lamperillo (JIRA)
jBPM , Drools, Seam 2.2 - Transition issue
------------------------------------------
Key: JBPM-2602
URL: https://jira.jboss.org/jira/browse/JBPM-2602
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jBPM 3.2.7
Environment: Seam 2.2, jBPM and Drools 5
Reporter: Gary Lamperillo
When using the DroolsDecisionHandler, only one transition from a rule is allowed, when a second transition is used, the following error is received:
[ProxyWarnLog] Narrowing proxy to class org.jbpm.graph.node.EndState - this operation breaks ==
The error should not be received, since the transition is very similar, two rules have been created. When only the first rule is used the one transition works fine. the addition of the second rule with the second transition from the same package in the working memory causes this issue.
here is the process definition:
<process-definition
name="jbpm_to_rules"
xmlns="urn:jbpm.org:jpdl-3.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:jbpm.org:jpdl-3.2 http://jbpm.org/xsd/jpdl-3.2.xsd"
>
<start-state name="start">
<transition to="approval">
<action expression="#{bpmCreditList.start}"/>
</transition>
</start-state>
<decision name="approval">
<handler class="org.jboss.seam.drools.DroolsDecisionHandler">
<workingMemoryName>creditRulesWorkingMemory</workingMemoryName>
<assertObjects>
<element>#{creditScore}</element>
</assertObjects>
</handler>
<transition name="not-preferred-customer" to="done2">
<action expression="#{bpmCreditList.transitionNPC}"/>
</transition>
<transition name="modified-score" to="modified-score">
<action expression="#{bpmCreditList.approved}"/>
</transition>
</decision>
<end-state name="done2">
<event type="node-enter">
<action>expression="#{bpmCreditList.end}"/>
</action>
</event>
</end-state>
<end-state name="modified-score"> </end-state>
<task-node name="done" end-tasks="true">
<task name="nopreferred" description="Review order" >
<assignment pooled-actors="reviewers"/>
</task>
<transition name="done2" to="done2"/>
</task-node>
</process-definition>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBPM-2656) JAAS configuration within jBPM 3.2.8 not in sync
by MohReece (JIRA)
JAAS configuration within jBPM 3.2.8 not in sync
------------------------------------------------
Key: JBPM-2656
URL: https://jira.jboss.org/jira/browse/JBPM-2656
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 3.2.8
Reporter: MohReece
In the jboss-service.xml file (from the /deploy/server/default/deploy/jbpm/jbpm-service.sar/META-INF/ directory) the name attribute of the jaas:application-policy tag is set to 'jbpm-console'.
In the jboss-web.xml (from the /deploy/server/default/deploy/jbpm/jsf-console.war/WEB-INF/ directory) the value for the security-domain tag is set to 'java:/jaas/soa'.
This means that when the contents of the /deploy/ directory are copied as-is to an appropriate directory on an application server (as tested on JBoss EAP 4.3) it will not be possible to log in at the jBPM console.
It is simply solved by synching these two values (e.g. set the jaas:application-policy tag name attribute to 'soa').
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBPM-2692) Still problems with variables of Serializable objects
by Mauro Molinari (JIRA)
Still problems with variables of Serializable objects
-----------------------------------------------------
Key: JBPM-2692
URL: https://jira.jboss.org/jira/browse/JBPM-2692
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 3.2.6.SP1
Environment: jBPM 3.2.6.SP1 embedded into a web application
Reporter: Mauro Molinari
There are times in which when calling org.jbpm.context.exe.VariableInstance.getValue(), the proprty token is null. In this case, if the variable object is of a Serializable class and this class is in the PAR, calling getValue() will fail with a ClassNotFound exception if the process class loader is not the one who loaded the SerializableToByteArrayConverter class. This is because the method org.jbpm.context.exe.converter.SerializableToByteArrayConverter.revert(ByteArray) (without the token) is called and a plain ObjectInputStream is used to do the deserialization.
I don't have a simple test case to reproduce, but this is what I am doing:
- my webapp application is retreiving all the logs associated to a ProcessInstance using org.jbpm.db.LoggingSession.findLogsByProcessInstance(long)
- it is iterating over the collection and, for each ProcessLog instance, it is retreiving the variable instance values (for example: org.jbpm.context.log.VariableCreateLog the method org.jbpm.context.log.VariableLog.getVariableInstance() is called; for a org.jbpm.context.log.VariableUpdateLog the methods org.jbpm.context.log.VariableUpdateLog.getOldValue() and org.jbpm.context.log.VariableUpdateLog.getNewValue() are called and so on)
- a ClassNotFoundException is launched; the class loader in use is that of the webapp, so it's normal that the class of the variable value cannot be found, since it is a serializable class provided by the PAR.
I don't know why token is null: should it be restored by Hibernate? Looking at org.jbpm.context.exe.VariableInstance the only explicit code that sets the token property is in org.jbpm.context.exe.VariableInstance.create(Token, String, Object).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years