[JBoss JIRA] Updated: (JBPM-376) Scripts on a node do not get to write their variables before node.leave() causes other nodes to be executed.
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-376?page=all ]
Thomas Diesler updated JBPM-376:
--------------------------------
Assignee: (was: Tom Baeyens)
> Scripts on a node do not get to write their variables before node.leave() causes other nodes to be executed.
> ------------------------------------------------------------------------------------------------------------
>
> Key: JBPM-376
> URL: http://jira.jboss.com/jira/browse/JBPM-376
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Affects Versions: jBPM 3.0.1
> Reporter: Colin Wilson-Salt
>
> A script on a node requires a node.leave in order to continue execution past the node. This means that the write back of the variables to the ExecutionContext does not happen until after the following nodes have been executed.
> A workaround is to set the variables yourself, by using executionContext.setVariable before calling node.leave.
> In the following example, it looks like the variable v will be available for use in the followin nodes, but the assignment doesn't happen until after those following nodes are executed (or until the process reaches a wait state).
> <node name="x">
> <script>
> <variable name='v' access='write'/>
> <expression>
> <![CDATA[
> v = true;
> node.leave(executionContext);
> ]]>
> </expression>
> </script>
> <transition to="y"/>
> </node>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 6 months
[JBoss JIRA] Updated: (JBPM-1067) token.getAvailableTransitions() -- need equivalent that returns ordered list.
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-1067?page=all ]
Thomas Diesler updated JBPM-1067:
---------------------------------
Assignee: (was: Tom Baeyens)
> token.getAvailableTransitions() -- need equivalent that returns ordered list.
> -----------------------------------------------------------------------------
>
> Key: JBPM-1067
> URL: http://jira.jboss.com/jira/browse/JBPM-1067
> Project: JBoss jBPM
> Issue Type: Feature Request
> Components: Core Engine
> Affects Versions: jBPM jPDL 3.2.2
> Environment: All OS
> Reporter: s b
>
> This feature request is requesting:
> 1) API which adds a version of token.getAvailableTransitions() which returns an ordered List that preserves the order of the transitions as defined in the processdefinition.xml file for the node, rather than returning an unordered Set object.
> 2) Also request that TaskInstance.getAvailableTransitions() be modified to return an ordered list rather than a randomly ordered list by calling the new method.
> For example:
> ------------------------
> public class TaskInstance extends VariableContainer implements Assignable {
> ...
> public List getAvailableTransitions() {
> List transitions = null;
> if ( (! isLast())
> && (token!=null)
> ) {
> transitions = token.getAvailableTransitionsList(); // using new method
> }
> return transitions;
> }
> ...
> ----------------------------------------
> Problem:
> node.getLeavingTransitions() appears to preserve the order, but the order is apparently lost when the transistions are added to the Set which is returned by token.getAvailableTransitions().
> Preserving the ordering is highly useful when implementing a minimal data-driven interface which presents the user with the transitions to choose from. The designer could exercise some control over the presentation of the choices if only the order were preserved as defined in the processdefinition.xml file.
> Solution:
> Make a clone of "token.getAvailableTransitions()", name it "token.getAvailableTransitionsList()", and add the filtered transitions to a List instead of to a Collection, and return the list. Make sure the order is preserved the same as the transitions were defined in the "processdefinition.xml" file.
> Modify "TaskInstance.getAvailableTransitions()" to call token.getAvailableTransitionsList().
> Summary:
> Although workarounds exist with existing code, it would be very helpful (and consistent I think) to provide an API that retrieves a list of the "available transitions" that is ordered as defined in the processdefinition.xml file instead of an unordered Set or List as is currently available.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 6 months
[JBoss JIRA] Updated: (JBPM-966) Modify Hibernate mappings to enable searching for TaskInstance's by VariableInstance
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-966?page=all ]
Thomas Diesler updated JBPM-966:
--------------------------------
Assignee: (was: Tom Baeyens)
> Modify Hibernate mappings to enable searching for TaskInstance's by VariableInstance
> ------------------------------------------------------------------------------------
>
> Key: JBPM-966
> URL: http://jira.jboss.com/jira/browse/JBPM-966
> Project: JBoss jBPM
> Issue Type: Feature Request
> Components: Core Engine
> Affects Versions: jBPM jPDL 3.2
> Environment: Any
> Reporter: Richard Tomlinson
> Attachments: patches.zip
>
>
> We want to be able to *efficiently* search for task instances based on the values of one or more variable instance. For example:
> TaskInstance myTasklnstance = ....
> myTaskInstance.setVariableLocally("owner", "theOwner");
> myTaskInstance.setVariable("anId", new Long(123456));
> Using this example we would like to create a Hibernate Criteria based query that will allow us to search and retrieve the task instance using the two variables as criteria of the search. At present, this does not appear to be possible.
> Querying for TaskInstances based on one or more VariableInstance's requires a convoluted HQL expression where each variableinstance (v) is obtained with the join to task instance (ti) with "v.processInstance.id = ti.taskMgmtInstance.processInstance.id"
> Observation:
> -----------------
> TaskInstance hibernate mappings allows the retrieval of all variable instances for a given task instance. This mapping allows the resulting sql to join the JBPM_TASKINSTANCE table to JBPM_VARIABLEINSTANCE table. The JBPM_VARIABLEINSTANCE table has a FK back to JBPM_TASKINSTANCE but the Hibernate mappings do not contain the correponding reverse mapping.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 6 months
[JBoss JIRA] Updated: (JBPM-1052) getAllTaskInstances(), getAllProcessInstances()
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-1052?page=all ]
Thomas Diesler updated JBPM-1052:
---------------------------------
Assignee: (was: Tom Baeyens)
> getAllTaskInstances(), getAllProcessInstances()
> -----------------------------------------------
>
> Key: JBPM-1052
> URL: http://jira.jboss.com/jira/browse/JBPM-1052
> Project: JBoss jBPM
> Issue Type: Feature Request
> Components: Core Engine
> Affects Versions: jBPM jPDL 3.2, jBPM jPDL 3.2.1
> Reporter: s b
> Priority: Minor
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> Businesses often want a "super manager" to have the ability to see and work on the tasks of all users. With the current jBPM, it is very difficult to generate a list of all TaskInstances.
> The feature requested is a method for listing all TaskInstances regardless of user. It appears to be a simple variation on the current methods which request TaskInstances by ActorId or an array of ActorIds.
> One possibility might be to modify the query used by TaskManagementSession.findTaskInstances(String actorId) to use the SQL "LIKE" operator instead of "=" so that the % wildcard could be used to retrieve all TaskInstances. I don't know if that is portable to all databases; it works well for Oracle.
> It has been suggested that this feature can be created as custom code, but custom code becomes very expensive to maintain and integrate with new releases of jBPM for small development companies like ours.
> A similar feature to retrieve all ProcessInstances regardless of ProcessDefinition would also be highly useful for similar reasons.
> A criticism is that the method would introduce scalability / performance problems. That is always an issue that is difficult to avoid completely depending on the application. For example, a business that has thousands of workers all performing the same workflow could generate a very large list using "GraphSession.findProcessInstances(long processDefinitionId)" which would be on the same order as a hypothetical "TaskManagementSession.getAllTaskInstances()" for that particular application.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 6 months
[JBoss JIRA] Updated: (JBPM-963) NullPointerException in the Eclipse plugin
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-963?page=all ]
Thomas Diesler updated JBPM-963:
--------------------------------
Assignee: (was: Koen Aers)
> NullPointerException in the Eclipse plugin
> ------------------------------------------
>
> Key: JBPM-963
> URL: http://jira.jboss.com/jira/browse/JBPM-963
> Project: JBoss jBPM
> Issue Type: Bug
> Affects Versions: jBPM jPDL 3.2
> Environment: WinXP SP2 Eclipse 3.2.1, JDK 1.5.0_11 and/or JDK 1.4.2_13
> Reporter: Oleksandr Alesinskyy
>
> Hello,
> I have downloaded and installed jBPM suite 3.2GA then I have installed Eclipse plugin from that suite into pre-existing Eclipse 3.2.1 (by copying contents of designer/eclipse directory to Eclipse extesions directory) and have created new JBoss JBPM Process project (with sample contents) - all succesfully. Then I have checked in the project into CVS. After this on Eclise restart comes message "Can not initialize JDT tooling" and following error stack:
> java.lang.NullPointerException
> at org.jbpm.ui.util.JbpmClasspathContainer.getJarNames(Unknown Source)
> at org.jbpm.ui.util.JbpmClasspathContainer.createJbpmLibraryEntries(Unknown Source)
> at org.jbpm.ui.util.JbpmClasspathContainer.getClasspathEntries(Unknown Source)
> at org.eclipse.jdt.internal.core.JavaModelManager.containerPutIfInitializingWithSameEntries(JavaModelManager.java:494)
> at org.eclipse.jdt.core.JavaCore.setClasspathContainer(JavaCore.java:4119)
> at org.jbpm.ui.util.JbpmClasspathContainerInitializer.initialize(Unknown Source)
> at org.eclipse.jdt.internal.core.JavaModelManager.initializeContainer(JavaModelManager.java:1900)
> at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:1267)
> at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:1470)
> at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:2169)
> at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:2073)
> at org.eclipse.jdt.core.JavaCore.setClasspathContainer(JavaCore.java:4189)
> at org.eclipse.jdt.internal.launching.JREContainerInitializer.initialize(JREContainerInitializer.java:57)
> at org.eclipse.jdt.internal.core.JavaModelManager.initializeContainer(JavaModelManager.java:1900)
> at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:1267)
> at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:1470)
> at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:2169)
> at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:2073)
> at org.eclipse.jdt.internal.core.JavaModelManager.determineIfOnClasspath(JavaModelManager.java:808)
> at org.eclipse.jdt.internal.core.JavaModelManager.create(JavaModelManager.java:697)
> at org.eclipse.jdt.internal.core.JavaModelManager.create(JavaModelManager.java:626)
> at org.eclipse.jdt.core.JavaCore.create(JavaCore.java:1383)
> at org.eclipse.jdt.internal.ui.ResourceAdapterFactory.getAdapter(ResourceAdapterFactory.java:44)
> at org.eclipse.core.internal.runtime.AdapterFactoryProxy.getAdapter(AdapterFactoryProxy.java:63)
> at org.eclipse.core.internal.runtime.AdapterManager.getAdapter(AdapterManager.java:256)
> at org.eclipse.core.runtime.PlatformObject.getAdapter(PlatformObject.java:66)
> at org.eclipse.jdt.internal.ui.filters.NamePatternFilter.select(NamePatternFilter.java:62)
> at org.eclipse.jdt.internal.ui.viewsupport.ProblemTreeViewer.isFiltered(ProblemTreeViewer.java:187)
> at org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart$PackageExplorerProblemTreeViewer.isFiltered(PackageExplorerPart.java:301)
> at org.eclipse.jdt.internal.ui.viewsupport.ProblemTreeViewer.isExpandable(ProblemTreeViewer.java:174)
> at org.eclipse.jface.viewers.AbstractTreeViewer.isExpandable(AbstractTreeViewer.java:1900)
> at org.eclipse.jface.viewers.AbstractTreeViewer.updatePlus(AbstractTreeViewer.java:2487)
> at org.eclipse.jface.viewers.AbstractTreeViewer.createTreeItem(AbstractTreeViewer.java:754)
> at org.eclipse.jface.viewers.AbstractTreeViewer$1.run(AbstractTreeViewer.java:731)
> at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
> at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:705)
> at org.eclipse.jface.viewers.TreeViewer.createChildren(TreeViewer.java:892)
> at org.eclipse.jface.viewers.AbstractTreeViewer$5.run(AbstractTreeViewer.java:1288)
> at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1323)
> at org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart$PackageExplorerProblemTreeViewer.preservingSelection(PackageExplorerPart.java:404)
> at org.eclipse.jface.viewers.AbstractTreeViewer.inputChanged(AbstractTreeViewer.java:1277)
> at org.eclipse.jface.viewers.ContentViewer.setInput(ContentViewer.java:250)
> at org.eclipse.jface.viewers.StructuredViewer.setInput(StructuredViewer.java:1542)
> at org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart.createPartControl(PackageExplorerPart.java:638)
> at org.eclipse.ui.internal.ViewReference.createPartHelper(ViewReference.java:332)
> at org.eclipse.ui.internal.ViewReference.createPart(ViewReference.java:197)
> at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:566)
> at org.eclipse.ui.internal.WorkbenchPage$ActivationList.setActive(WorkbenchPage.java:3915)
> at org.eclipse.ui.internal.WorkbenchPage.restoreState(WorkbenchPage.java:2929)
> at org.eclipse.ui.internal.WorkbenchWindow.restoreState(WorkbenchWindow.java:1936)
> at org.eclipse.ui.internal.Workbench.doRestoreState(Workbench.java:2857)
> at org.eclipse.ui.internal.Workbench.access$14(Workbench.java:2805)
> at org.eclipse.ui.internal.Workbench$19.run(Workbench.java:1681)
> at org.eclipse.ui.internal.Workbench.runStartupWithProgress(Workbench.java:1421)
> at org.eclipse.ui.internal.Workbench.restoreState(Workbench.java:1679)
> at org.eclipse.ui.internal.Workbench.access$12(Workbench.java:1650)
> at org.eclipse.ui.internal.Workbench$17.run(Workbench.java:1529)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
> at org.eclipse.ui.internal.Workbench.restoreState(Workbench.java:1473)
> at org.eclipse.ui.internal.WorkbenchConfigurer.restoreState(WorkbenchConfigurer.java:183)
> at org.eclipse.ui.application.WorkbenchAdvisor.openWindows(WorkbenchAdvisor.java:702)
> at org.eclipse.ui.internal.Workbench.init(Workbench.java:1085)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1847)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
> at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95)
> at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:615)
> at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336)
> at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
> at org.eclipse.core.launcher.Main.run(Main.java:977)
> at org.eclipse.core.launcher.Main.main(Main.java:952)
> and Eclipse package explorer becomes unavailable.
> The same occurs if I install plugin on other computer and check-out the project and restart Eclipse. I#m still able to create another new jBPM Process project and work with it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 6 months
[JBoss JIRA] Updated: (JBPM-1080) Limit BAM Query to input data for simulation to time range doesn't work
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-1080?page=all ]
Thomas Diesler updated JBPM-1080:
---------------------------------
Assignee: (was: Tom Baeyens)
> Limit BAM Query to input data for simulation to time range doesn't work
> -----------------------------------------------------------------------
>
> Key: JBPM-1080
> URL: http://jira.jboss.com/jira/browse/JBPM-1080
> Project: JBoss jBPM
> Issue Type: Feature Request
> Components: Simulation
> Affects Versions: jBPM jPDL 3.2.2
> Reporter: Bernd Ruecker
> Priority: Minor
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> The GetSimulationInputCommand has a parameter "fromTimeOfDay" and "tillTimeOfDay". This should be included in the hibernate quries to supprto to query statistical data only for special times (for example shifts).
> Unfortunately, comparing the time is not really easy with supporting different databases. In MySQL, there is a TIME(xxx) function, HSQL only supports HOUR(xxx) and MINUTE(xxx).
> Si I skipped it for the moment. The mySQL ready statements are commented out in the queries file.
> Co currently, ALL statistics from all 24 hours are returned.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 6 months