Re: [jboss-user] [JBoss Tools] - Coping with versions in large multi-module osgi projects
by Ian Bull
Ian Bull [http://community.jboss.org/people/irbull] commented on
"Coping with versions in large multi-module osgi projects"
To view all comments on this blog post, visit: http://community.jboss.org/community/tools/blog/2011/09/17/coping-with-ve...
--------------------------------------------------
I'll let the OSGi purists battle the OSGi parts, but from a p2 perspective I see some things that could really get you in trouble. In particular, it's all related to the version 1.2.3.GA. (or even worse 1.0.0). p2 uses and ID/Version as a unique identifier. So, if you have a bundle called Foo version 1.2.3.GA and you realize that you messed up the build, so you built again. Now you have two different sets of bytes with the same Unique ID (Foo/1.2.3.GA).
If p2 has cached the original one somewhere (or someone has it installed), then it's anybodies guess wich version will get fetched. This is why nobody should ever reuse the same version for the same bundle.
PDE/Build takes 1.0.0.qualifier and replaces it with a timestamp, so at least part of the version changes.
Another (related) problem. If *nothing* changes in a bundle then the version should not change. Let's say JBoss version 1.2.3 is released. Tomorrow you release 1.2.4 and only 1 line of code in one bundle has changed. If all your bundles get their versoin bumped, then users will download all 628 artifacts, instead of the single artifact that changed.
BTW, the Eclipse project has over 400 bundles and they manage their versions without bumping each bundle for each build. There are techniques for doing this successfully including map files, API Tools and the Jar Comparator.
Cheers,
Ian
--------------------------------------------------
14 years, 7 months
[JBoss Messaging] - Jboss messaging failing during failover
by rajeev kumar
rajeev kumar [http://community.jboss.org/people/rajeev.aec] created the discussion
"Jboss messaging failing during failover"
To view the discussion, visit: http://community.jboss.org/message/627042#627042
--------------------------------------------------------------
Hello all,
I have sucessfully implemented a cluster on two IBM M2 servers. My node A has Jboss 4.2.3 having JMS 1.4.2 and postgres 9.0 (read-write mode) and other node lets say it B has same configuration except on this node postgres is running in read-only mode ( I used the replication mechanism provided by postgres 9.0). every thing is working fine when both server is running. but as soon as i shutdown/charshes the node A, postgres on node B takes the role of read -write but it take 10-15 sec to switch the role, in the mean time failover of jboss also takes place and it seems that JMS is not able to handle this situation. so my question is
1) Do we need constant DB connection during JMS failover.
or can any one suggest how can i handle this kind of situation.ie database and jbossfailover simultaneously.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/627042#627042]
Start a new discussion in JBoss Messaging at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 7 months
[jBPM] - StatefulKnowledgeSession signalEvent method
by Geoff Pole
Geoff Pole [http://community.jboss.org/people/instanceof] created the discussion
"StatefulKnowledgeSession signalEvent method"
To view the discussion, visit: http://community.jboss.org/message/627040#627040
--------------------------------------------------------------
Hi,
Can anyone help me to understand why the signalEvent method on the StatefulKnowledgeSession calls the ProcessInstancesWaitingForEvent query even when I provide the processInstanceId parameter?
The ProcessInstancesWaitingForEvent seems to retrieve all workflow instances that are awaititing a particular event.
I am seeing this behaviour in the context of this workflow:
http://community.jboss.org/servlet/JiveServlet/showImage/2-627040-16993/d... http://community.jboss.org/servlet/JiveServlet/downloadImage/2-627040-169...
When I start the workflow with process variables that make it take the lower path the workflow begins and waits for the first signal.
|
|
| ProcessInstance process = session.startProcess("com.bluecycle.zephyr.workflow.data-v0.0.2", processVariables); |
At this point I am able to signal the first event and the ProcessInstancesWaitingForEvent is NOT called. The workflow quickly moves and waits for the second signal.
|
|
| session.signalEvent("Signal1", null, process.getId()); |
|
At this point I can signal the second event which does succeed but this time it appeas to be calling the ProcessInstancesWaitingForEvent query to find all workflows waiting for the signal2 event..
|
|
| session.signalEvent("Signal2", null, process.getId()); |
|
The time that this takes is directly proportional to the number of workflow instances that I have waiting for the signal2 event.
Can anyone help me to understand why ProcessInstancesWaitingForEvent is being called? It seems like this is unnessercary given that I am providing the processInsnanceId. Also I'm not sure why this happens when I signal event 2, but not when I signal event 1.
The jbpm versions I have used are the ones bundled in the jbpm 5.10-Final installer download.
Thanks very much,
Geoff
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/627040#627040]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 7 months
[jBPM] - Re: How to resume a persisted processInstance?
by Ryan Peterson
Ryan Peterson [http://community.jboss.org/people/rrpeterson] created the discussion
"Re: How to resume a persisted processInstance?"
To view the discussion, visit: http://community.jboss.org/message/627035#627035
--------------------------------------------------------------
A partial answer I've found after playing with timers:
The time defined by the timer must pass within the method that invokes or retrieves the session in order to fire the next node.
In other words, a string of nodes with a timer (for instance 15 seconds) all nodes will execute up to the timer and then will return, persisting the ksession. If a Thread.sleep() for more than 15 seconds happens before calling session.dispose() in the original session.startProcess(), then the timer completes and the next nodes in the process instance will fire.
Also the same behavior happens retrieving the session via JPAKnowledgeService.loadStatefulKnowledgeSession, if a Thread.sleep() for a length over the timer value happens, then the timer expires and the next node is called.
Is there a way to setup a timer, for instance 2 hours, that when the ksession is retrived will check the time between the creation of the timer node, and current time? Otherwise I don't see how timers would be useful, unless you're willing to dedicate a thread to each processInstance to sit & poll at fixed intervals to check if timers have expired?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/627035#627035]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 7 months
[JBoss Tools] - Coping with versions in large multi-module osgi projects
by Max Rydahl Andersen
Max Rydahl Andersen [http://community.jboss.org/people/maxandersen] modified the blog post:
"Coping with versions in large multi-module osgi projects"
To view the blog post, visit: http://community.jboss.org/community/tools/blog/2011/09/17/coping-with-ve...
--------------------------------------------------------------
h1. Versions for large multi-module osgi projects
Recently I went through JBoss Tools main source code base and fixed a few long standing issues that had made it cumbersome to manage versions over the years. This blog tries to explain what we changed, why and how Tycho helped.
h1. Tycho Version Plugin
Maven has it’s own versions plugin but it only takes care of version references in pom.xml, it does not consider osgi/p2 related references. Tycho therefore has it’s own versions plugin.
Unfortunately there aren’t alot of documentation for this plugin, but by poking to Sonatype, follow the https://dev.eclipse.org/mailman/listinfo/tycho-user tycho mailing list and looking at a https://docs.sonatype.org/display/M2ECLIPSE/Staging+and+releasing+new+M2E... few hints out there I managed to get the it working. Here is my attempt to make the world more aware of the Tycho Version plugin.
h1. Usage
The core command for Tycho Versions plugin are executed in your Maven module that represents your plugin/features. The Tycho Version plugin command looks like this:
mvn org.eclipse.tycho:tycho-versions-plugin:set-version -DnewVersion=<version>
Here <version> is the version number you want for your plugins, i.e. 1.2.3.GA. If you use 1.2.3-SNAPSHOT the plugin will use 1.2.3.qualifier in the places necessary (i.e. in manifest.mf and feature.xml).
The beauty of this plugin is that with a single command you can update your plugin, features, product and updatesite references.
No manual tweaking required, except that to use it effectively your pom.xml’s should follow a few maven conventions.
That last part is what kept us in JBoss Tools to use this command until recently.
Why you ask ? Well, read on…
h1. Maven Parent/Child relationships
The reason we couldn’t use the tycho version plugin previously was that we had the following layout for each of our modules:
http://community.jboss.org/servlet/JiveServlet/showImage/38-4019-16990/mo... http://community.jboss.org/servlet/JiveServlet/downloadImage/38-4019-1699...
Each top level module has a set of submodules: plugins, tests, features and site (there are also a doc module but that is for another blog).
Each of these submodules can have children, for plugins that are all the individual plugins the main feature will include, tests are the plugin tests and so forth.
That parent represents the parent pom where the shared build configuration for JBoss Tools is stored - we use that to avoid repeating the build instructions in all 350+ buildable units.
But there is a big problem with this structure.
First of each artifact have a manual maintained version section, but do you notice all those thick red outlined lines going to the Parent from each leaf plugin, feature, etc. ?
Those red lines illustrates that each child leaf point directly to the main parent pom which makes it possible to have the build configuration in one central place but it also means that everytime we update the parent pom version we have to change it in each and every node (for us that is 605 locations).
It also have the consequence that even though we have this nice modular division of each +module+ into +tests+ and +plugins+ there is not a place to store module or submodule specific settings for our builds - that all have to take place in each leaf plugin instead of being just stated in one place.
Thus to make this sharing easier and to make it more explicit what structure is actually being versioned with the Tycho module Denis Golovin and I did a few pom refactorings.
http://community.jboss.org/servlet/JiveServlet/showImage/38-4019-16991/mo... http://community.jboss.org/servlet/JiveServlet/downloadImage/38-4019-1699...
Notice the difference ?
Each “sub-node” now uses their actual structural relative parent as the pom parent (red lines) and only the top level module actually points back to the main JBoss Tools parent module (blue line).
This has the following positive features:
* you can stand in the root of a module and run mvn clean install and it will build the whole module
* you can override/customize a build locally for a module or submodule
* maven tycho version plugin will be able to easily version this module on its own
The last optimization I did lately was that now that we have this +natural+ structure between parent and child setup we can remove the child modules redundant version info from the pom.xml’s. We unfortunately still have to list the full version info for the parent but with the Tycho versions plugin this becomes trivial to maintain.
h1. The Dirty Details
The essentials parts of the structure is as follows (using hibernatetools as reference):
Module pom:
<project ...>
...
<parent>
<!-- the *only reference* to root build parent from a module -->
<groupId>org.jboss.tools</groupId>
<artifactId>org.jboss.tools.parent.pom</artifactId>
<version>0.0.2-SNAPSHOT</version>
<relativePath>../build/parent/pom.xml</relativePath>
</parent>
<groupId>org.jboss.tools</groupId>
<artifactId>hibernatetools</artifactId>
<name>hibernatetools.all</name>
<!-- the only place the *module version number* needs to be in a pom.xml for a module -->
<version>3.4.0-SNAPSHOT</version>
<packaging>pom</packaging>
<modules>
<module>features</module>
<module>plugins</module>
<module>tests</module>
<module>site</module>
</modules>
</project>
Sub-Module pom:
<project ...>
...
<parent>
<!-- this section is *maintained by the versions plugin* --!>
<groupId>org.jboss.tools</groupId>
<artifactId>hibernatetools</artifactId>
<version>3.4.0-SNAPSHOT</version>
</parent>
<groupId>org.jboss.tools.hibernatetools</groupId>
<artifactId>plugins</artifactId>
<name>hibernatetools.plugins</name>
<packaging>pom</packaging>
<modules>
<module>org.hibernate.eclipse</module>
<module>org.hibernate.eclipse.console</module>
...
</modules>
…and finally the actual plugin/feature pom’s:
<project ... >
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.jboss.tools.hibernatetools</groupId>
<artifactId>plugins</artifactId>
<version>3.4.0-SNAPSHOT</version>
</parent>
<groupId>org.jboss.tools.hibernatetools.plugins</groupId>
<artifactId>org.hibernate.eclipse</artifactId>
<packaging>eclipse-plugin</packaging>
Notice how this setup makes the configuration at the plugin level very concise (or at least as concise as Maven allows them to be). Only if your plugin has custom build logic do they need to be different.
h1. Conclusion
With this setup we can now easily customize our builds at a module level and easily bump our versions number across all the osgi/p2 artifacts within the module.
Meaning if I use the Tycho versions plugin to bump a module to 3.5.0, by default +everything+ in that module gets bumped to 3.5.0, no matter if they have changed or not.
Purists of osgi might claim that is a bad practice and you should only bump the versions of the plugins that actually received changes and in principle I agree with them, but…
…JBoss Tools consists of about 202 plugins and 100 features each with their own feature.xml, MANIFEST.MF and when we included Tycho or rather Maven in the mix they also each have a pom.xml.
Add in the various updatesites, and other artifacts and just in the main source code tree of JBoss Tools it all adds up to us having at the current time of writing *628* versionable artifacts.
That is alot of versions to keep track of and ensure is uptodate.
Until now we have been maintaining the versions of these artifacts manually by hand and just as a precaution we (as many others in osgi/p2 land) do our builds with a .qualifier as the last part of the version number. This ensure the version number is always higher than the previous build. If we don’t, then p2 won’t install the newest build.
This actually means that if you don’t realize it then you can easily stay on version 1.0.0 for your plugins forever and ever - no users will complain since they can always get the the newest updated version.
The problem of being blind to versions of course show up when you start having multiple branches and even more so when you try to build up API plugins and want to ensure you are using the right compatible version - and here relying on the “random” qualifier string becomes unmanagable.
With a handful of plugins it’s “easy”, but with 628 artifacts it can become rather chaotic.
Thus I’ll argue its better to do it on the module level which reduces the versionable artifacts to 42 in our case - a much more managable number and much simpler to handle and understand for both developer and user IMO.
Notice, that if you are in a situation where you need to manually version specific plugins then you simply set the version explicitly for those plugins/features and Tycho versions plugin will not change them if they are not the same as the module pom.
That is another thing I like about this setup
- it allows you to do the most manageble thing easily, and if you need the full control you can do that for just the parts you wishes it for.
What do you think ?
Have you solved this problem differently/better/worse ?
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/community/tools/blog/2011/09/17/coping-with-ve...]
14 years, 7 months
[JBoss Tools] - Coping with versions in large multi-module osgi projects
by Max Rydahl Andersen
Max Rydahl Andersen [http://community.jboss.org/people/maxandersen] modified the blog post:
"Coping with versions in large multi-module osgi projects"
To view the blog post, visit: http://community.jboss.org/community/tools/blog/2011/09/17/coping-with-ve...
--------------------------------------------------------------
h1. Versions for large multi-module osgi projects
Recently I went through JBoss Tools main source code base and fixed a few long standing issues that had made it cumbersome to manage versions over the years. This blog tries to explain what we changed, why and how Tycho helped.
h1. Tycho Version Plugin
Maven has it’s own versions plugin but it only takes care of version references in pom.xml, it does not consider osgi/p2 related references. Tycho therefore has it’s own versions plugin.
Unfortunately there aren’t alot of documentation for this plugin, but by poking to Sonatype, follow the https://dev.eclipse.org/mailman/listinfo/tycho-user tycho mailing list and looking at a https://docs.sonatype.org/display/M2ECLIPSE/Staging+and+releasing+new+M2E... few hints out there I managed to get the it working. Here is my attempt to make the world more aware of the Tycho Version plugin.
h1. Usage
The core command for Tycho Versions plugin are executed in your Maven module that represents your plugin/features. The Tycho Version plugin command looks like this:
mvn org.eclipse.tycho:tycho-versions-plugin:set-version -DnewVersion=<version>
Here <version> is the version number you want for your plugins, i.e. 1.2.3.GA. If you use 1.2.3-SNAPSHOT the plugin will use 1.2.3.qualifier in the places necessary (i.e. in manifest.mf and feature.xml).
The beauty of this plugin is that with a single command you can update your plugin, features, product and updatesite references.
No manual tweaking required, except that to use it effectively your pom.xml’s should follow a few maven conventions.
That last part is what kept us in JBoss Tools to use this command until recently.
Why you ask ? Well, read on…
h1. Maven Parent/Child relationships
The reason we couldn’t use the tycho version plugin previously was that we had the following layout for each of our modules:
http://community.jboss.org/servlet/JiveServlet/showImage/38-4019-16990/mo... http://community.jboss.org/servlet/JiveServlet/downloadImage/38-4019-1699...
Each top level module has a set of submodules: plugins, tests, features and site (there are also a doc module but that is for another blog).
Each of these submodules can have children, for plugins that are all the individual plugins the main feature will include, tests are the plugin tests and so forth.
That parent represents the parent pom where the shared build configuration for JBoss Tools is stored - we use that to avoid repeating the build instructions in all 350+ buildable units.
But there is a big problem with this structure.
First of each artifact have a manual maintained version section, but do you notice all those thick red outlined lines going to the Parent from each leaf plugin, feature, etc. ?
Those red lines illustrates that each child leaf point directly to the main parent pom which makes it possible to have the build configuration in one central place but it also means that everytime we update the parent pom version we have to change it in each and every node (for us that is 605 locations).
It also have the consequence that even though we have this nice modular division of each +module+ into +tests+ and +plugins+ there is not a place to store module or submodule specific settings for our builds - that all have to take place in each leaf plugin instead of being just stated in one place.
Thus to make this sharing easier and to make it more explicit what structure is actually being versioned with the Tycho module Denis Golovin and I did a few pom refactorings.
http://community.jboss.org/servlet/JiveServlet/showImage/38-4019-16991/mo... http://community.jboss.org/servlet/JiveServlet/downloadImage/38-4019-1699...
Notice the difference ?
Each “sub-node” now uses their actual structural relative parent as the pom parent (red lines) and only the top level module actually points back to the main JBoss Tools parent module (blue line).
This has the following positive features:
* you can stand in the root of a module and run mvn clean install and it will build the whole module
* you can override/customize a build locally for a module or submodule
* maven tycho version plugin will be able to easily version this module on its own
The last optimization I did lately was that now that we have this +natural+ structure between parent and child setup we can remove the child modules redundant version info from the pom.xml’s. We unfortunately still have to list the full version info for the parent but with the Tycho versions plugin this becomes trivial to maintain.
h1. The Dirty Details
The essentials parts of the structure is as follows (using hibernatetools as reference):
Module pom:
<project ...>
...
<parent>
<!-- the *only reference* to root build parent from a module -->
<groupId>org.jboss.tools</groupId>
<artifactId>org.jboss.tools.parent.pom</artifactId>
<version>0.0.2-SNAPSHOT</version>
<relativePath>../build/parent/pom.xml</relativePath>
</parent>
<groupId>org.jboss.tools</groupId>
<artifactId>hibernatetools</artifactId>
<name>hibernatetools.all</name>
<!-- the only place the *module version number* needs to be in a pom.xml for a module -->
<version>3.4.0-SNAPSHOT</version>
<packaging>pom</packaging>
<modules>
<module>features</module>
<module>plugins</module>
<module>tests</module>
<module>site</module>
</modules>
</project>
Sub-Module pom:
<project ...>
...
<parent>
<!-- this section is *maintained by the versions plugin* --!>
<groupId>org.jboss.tools</groupId>
<artifactId>hibernatetools</artifactId>
<version>3.4.0-SNAPSHOT</version>
</parent>
<groupId>org.jboss.tools.hibernatetools</groupId>
<artifactId>plugins</artifactId>
<name>hibernatetools.plugins</name>
<packaging>pom</packaging>
<modules>
<module>org.hibernate.eclipse</module>
<module>org.hibernate.eclipse.console</module>
...
</modules>
…and finally the actual plugin/feature pom’s:
<project ... >
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.jboss.tools.hibernatetools</groupId>
<artifactId>plugins</artifactId>
<version>3.4.0-SNAPSHOT</version>
</parent>
<groupId>org.jboss.tools.hibernatetools.plugins</groupId>
<artifactId>org.hibernate.eclipse</artifactId>
<packaging>eclipse-plugin</packaging>
Notice how this setup makes the configuration at the plugin level very concise (or at least as concise as Maven allows them to be). Only if your plugin has custom build logic do they need to be different.
h1. Conclusion
With this setup we can now easily customize our builds at a module level and easily bump our versions number across all the osgi/p2 artifacts within the module.
Meaning if I use the Tycho versions plugin to bump a module to 3.5.0, by default +everything+ in that module gets bumped to 3.5.0, no matter if they have changed or not.
Purists of osgi might claim that is a bad practice and you should only bump the versions of the plugins that actually received changes and in principle I agree with them, but…
…JBoss Tools consists of about 202 plugins and 100 features each with their own feature.xml, MANIFEST.MF and when we included Tycho or rather Maven in the mix they also each have a pom.xml.
Add in the various updatesites, and other artifacts and just in the main source code tree of JBoss Tools it all adds up to us having at the current time of writing *628* versionable artifacts.
That is alot of versions to keep track of and ensure is uptodate.
Until now we have been maintaining the versions of these artifacts manually by hand and just as a precaution we (as many others in osgi/p2 land) do our builds with a .qualifier as the last part of the version number. This ensure the version number is always higher than the previous build. If we don’t, then p2 won’t install the newest build.
This actually means that if you don’t realize it then you can easily stay on version 1.0.0 for your plugins forever and ever - no users will complain since they can always get the the newest updated version.
The problem of being blind to versions of course show up when you start having multiple branches and even more so when you try to build up API plugins and want to ensure you are using the right compatible version - and here relying on the “random” qualifier string becomes unmanagable.
With a handful of plugins it’s “easy”, but with 628 artifacts it can become rather chaotic.
Thus I’ll argue its better to do it on the module level which reduces the versionable artifacts to 42 in our case - a much more managable number and much simpler to handle and understand for both developer and user IMO.
Notice, that if you are in a situation where you need to manually version specific plugins then you simply set the version explicitly for those plugins/features and Tycho versions plugin will not change them if they are not the same as the module pom.
That is another thing I like about this setup
- it allows you to do the most manageble thing easily, and if you need the full control you can do that for just the parts you wishes it for.
What do you think ?
Have you solved this problem differently/better/worse ?
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/community/tools/blog/2011/09/17/coping-with-ve...]
14 years, 7 months
[jBPM] - Oryx Issue Subprocesses
by Tobias Wittur
Tobias Wittur [http://community.jboss.org/people/tob1as] created the discussion
"Oryx Issue Subprocesses"
To view the discussion, visit: http://community.jboss.org/message/627019#627019
--------------------------------------------------------------
Hi,
I just tried to model a subprocess with oryx. When I saved it, the entire process model disappeared.
I then opened the jbpm example BPMN2-ErrorBoundaryEventInterrupting.
I simply opened and saved it, and here as well, the model was gone after saving it. (The xml was erased). http://community.jboss.org/servlet/JiveServlet/showImage/2-627019-16992/C... http://community.jboss.org/servlet/JiveServlet/downloadImage/2-627019-169...
This is the xml to it:
<?xml version="1.0" encoding="UTF-8"?>
<bpmn2:definitions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.omg.org/bpmn20" xmlns:bpmn2="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" xmlns:dc="http://www.omg.org/spec/DD/20100524/DC" xmlns:di="http://www.omg.org/spec/DD/20100524/DI" xmlns:drools="http://www.jboss.org/drools" id="Definition" xsi:schemaLocation="http://www.omg.org/spec/BPMN/20100524/MODEL BPMN20.xsd" expressionLanguage="http://www.mvel.org/2.0" name="Error Boundary Event Process" targetNamespace="http://www.omg.org/bpmn20" typeLanguage="http://www.java.com/javaTypes">
<bpmn2:process id="ErrorBoundaryEvent" name="Error Boundary Event Process" isExecutable="true">
<bpmn2:startEvent id="_1" name="StartProcess">
<bpmn2:outgoing>_1-_2</bpmn2:outgoing>
</bpmn2:startEvent>
<bpmn2:subProcess id="_2" name="Hello">
<bpmn2:incoming>_1-_2</bpmn2:incoming>
<bpmn2:outgoing>_2-_3</bpmn2:outgoing>
<bpmn2:startEvent id="_2-1" name="StartSubProcess">
<bpmn2:outgoing>_2-1-_2-2</bpmn2:outgoing>
</bpmn2:startEvent>
<bpmn2:parallelGateway id="_2-2" name="null">
<bpmn2:incoming>_2-1-_2-2</bpmn2:incoming>
<bpmn2:outgoing>_2-2-_2-3</bpmn2:outgoing>
<bpmn2:outgoing>_2-2-_2-4</bpmn2:outgoing>
</bpmn2:parallelGateway>
<bpmn2:endEvent id="_2-3" name="ErrorEvent">
<bpmn2:incoming>_2-2-_2-3</bpmn2:incoming>
<bpmn2:errorEventDefinition id="_VVD4gOEJEeCmFs5FZDDDYg" drools:erefname="MyError"/>
</bpmn2:endEvent>
<bpmn2:task id="_2-4" drools:taskName="MyTask" name="Task">
<bpmn2:incoming>_2-2-_2-4</bpmn2:incoming>
<bpmn2:outgoing>_2-4-_2-5</bpmn2:outgoing>
<bpmn2:ioSpecification id="_VVD4geEJEeCmFs5FZDDDYg">
<bpmn2:dataInput id="_2-4_TaskNameInput" name="TaskName"/>
<bpmn2:inputSet id="_VVD4guEJEeCmFs5FZDDDYg"/>
<bpmn2:outputSet id="_VVD4g-EJEeCmFs5FZDDDYg"/>
</bpmn2:ioSpecification>
<bpmn2:dataInputAssociation id="_VVD4hOEJEeCmFs5FZDDDYg">
<bpmn2:targetRef>_2-4_TaskNameInput</bpmn2:targetRef>
<bpmn2:assignment id="_VVD4heEJEeCmFs5FZDDDYg">
<bpmn2:from xsi:type="bpmn2:tFormalExpression" id="_VVD4huEJEeCmFs5FZDDDYg">MyTask</bpmn2:from>
<bpmn2:to xsi:type="bpmn2:tFormalExpression" id="_VVD4h-EJEeCmFs5FZDDDYg">_2-4_TaskNameInput</bpmn2:to>
</bpmn2:assignment>
</bpmn2:dataInputAssociation>
</bpmn2:task>
<bpmn2:endEvent id="_2-5" name="EndEvent">
<bpmn2:incoming>_2-4-_2-5</bpmn2:incoming>
</bpmn2:endEvent>
<bpmn2:sequenceFlow id="_2-1-_2-2" sourceRef="_2-1" targetRef="_2-2"/>
<bpmn2:sequenceFlow id="_2-2-_2-3" sourceRef="_2-2" targetRef="_2-3"/>
<bpmn2:sequenceFlow id="_2-2-_2-4" sourceRef="_2-2" targetRef="_2-4"/>
<bpmn2:sequenceFlow id="_2-4-_2-5" sourceRef="_2-4" targetRef="_2-5"/>
</bpmn2:subProcess>
<bpmn2:endEvent id="_3" name="EndProcess">
<bpmn2:incoming>_2-_3</bpmn2:incoming>
<bpmn2:terminateEventDefinition id="_VVD4iOEJEeCmFs5FZDDDYg"/>
</bpmn2:endEvent>
<bpmn2:intermediateCatchEvent id="_4" name="ErrorEvent">
<bpmn2:outgoing>_4-_5</bpmn2:outgoing>
<bpmn2:errorEventDefinition id="_VVD4ieEJEeCmFs5FZDDDYg" errorRef="_VVD4iuEJEeCmFs5FZDDDYg"/>
</bpmn2:intermediateCatchEvent>
<bpmn2:scriptTask id="_5" name="Goodbye" scriptFormat="null">
<bpmn2:incoming>_4-_5</bpmn2:incoming>
<bpmn2:outgoing>_5-_6</bpmn2:outgoing>
<bpmn2:script>System.out.println("Error handled");</bpmn2:script>
</bpmn2:scriptTask>
<bpmn2:endEvent id="_6" name="EndProcess">
<bpmn2:incoming>_5-_6</bpmn2:incoming>
</bpmn2:endEvent>
<bpmn2:sequenceFlow id="_1-_2" sourceRef="_1" targetRef="_2"/>
<bpmn2:sequenceFlow id="_2-_3" sourceRef="_2" targetRef="_3"/>
<bpmn2:sequenceFlow id="_4-_5" sourceRef="_4" targetRef="_5"/>
<bpmn2:sequenceFlow id="_5-_6" sourceRef="_5" targetRef="_6"/>
</bpmn2:process>
<bpmn2:error id="_VVD4iuEJEeCmFs5FZDDDYg"/>
<bpmndi:BPMNDiagram id="_VVD4i-EJEeCmFs5FZDDDYg">
<bpmndi:BPMNPlane id="_VVD4jOEJEeCmFs5FZDDDYg" bpmnElement="ErrorBoundaryEvent">
<bpmndi:BPMNShape id="_VVD4jeEJEeCmFs5FZDDDYg" bpmnElement="_1">
<dc:Bounds height="30.0" width="30.0" x="27.0" y="115.0"/>
</bpmndi:BPMNShape>
<bpmndi:BPMNShape id="_VVD4juEJEeCmFs5FZDDDYg" bpmnElement="_2">
<dc:Bounds height="221.0" width="349.0" x="97.0" y="15.0"/>
</bpmndi:BPMNShape>
<bpmndi:BPMNShape id="_VVD4j-EJEeCmFs5FZDDDYg" bpmnElement="_3">
<dc:Bounds height="28.0" width="28.0" x="489.0" y="113.0"/>
</bpmndi:BPMNShape>
<bpmndi:BPMNShape id="_VVD4kOEJEeCmFs5FZDDDYg" bpmnElement="_4">
<dc:Bounds height="30.0" width="30.0" x="380.0" y="224.0"/>
</bpmndi:BPMNShape>
<bpmndi:BPMNShape id="_VVD4keEJEeCmFs5FZDDDYg" bpmnElement="_5">
<dc:Bounds height="48.0" width="80.0" x="355.0" y="288.0"/>
</bpmndi:BPMNShape>
<bpmndi:BPMNShape id="_VVD4kuEJEeCmFs5FZDDDYg" bpmnElement="_6">
<dc:Bounds height="28.0" width="28.0" x="380.0" y="369.0"/>
</bpmndi:BPMNShape>
<bpmndi:BPMNEdge id="_VVD4k-EJEeCmFs5FZDDDYg" bpmnElement="_1-_2">
<di:waypoint xsi:type="dc:Point" x="42.0" y="130.0"/>
<di:waypoint xsi:type="dc:Point" x="271.5" y="125.5"/>
</bpmndi:BPMNEdge>
<bpmndi:BPMNEdge id="_VVD4lOEJEeCmFs5FZDDDYg" bpmnElement="_2-_3">
<di:waypoint xsi:type="dc:Point" x="271.5" y="125.5"/>
<di:waypoint xsi:type="dc:Point" x="503.0" y="127.0"/>
</bpmndi:BPMNEdge>
<bpmndi:BPMNEdge id="_VVD4leEJEeCmFs5FZDDDYg" bpmnElement="_4-_5">
<di:waypoint xsi:type="dc:Point" x="395.0" y="239.0"/>
<di:waypoint xsi:type="dc:Point" x="395.0" y="312.0"/>
</bpmndi:BPMNEdge>
<bpmndi:BPMNEdge id="_VVD4luEJEeCmFs5FZDDDYg" bpmnElement="_5-_6">
<di:waypoint xsi:type="dc:Point" x="395.0" y="312.0"/>
<di:waypoint xsi:type="dc:Point" x="394.0" y="383.0"/>
</bpmndi:BPMNEdge>
</bpmndi:BPMNPlane>
</bpmndi:BPMNDiagram>
</bpmn2:definitions>
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/627019#627019]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 7 months
[jBPM] - How to resume a persisted processInstance?
by Ryan Peterson
Ryan Peterson [http://community.jboss.org/people/rrpeterson] created the discussion
"How to resume a persisted processInstance?"
To view the discussion, visit: http://community.jboss.org/message/627001#627001
--------------------------------------------------------------
Hey guys,
I'm starting my ProcessInstance which consists of two service tasks seperated by a timer.
If I Thread.sleep() after creating my StatefulKnowledgeSession before calling ksession.dispose(), then the timer can complete and my 2nd task executes.
If I call ksession.dispose() without sleeping, and re-load my ksession via JPAKnowledgeService.loadStatefulKnowledgeSession(w, x, y, z), my processInstance gets stuck on the timer even though more time has elapsed than it's limit. Is there a method I need to call in order to get my processInstance to continue executing upon checking the timer status?
Ideally I'd like to be able to create and start my processInstance, then close out the ksession. Then periodically check on the status of the ksession to see if the timer's value has elapsed, and if so continue executing nodes.
Thanks for any suggestions/help!
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/627001#627001]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 7 months
