[Design of JBoss jBPM] - Re: task assignee vs owner
by KrisVerlaenen
anonymous wrote : In my opinion: Drools = BRM + CEP -> Yes, cool! But BPM? I think there is a lot of stuff around in BPM which makes it a sperate topic which should be targeted by a BPM software (like BPMN -> technical Model mapping, Simulation, BAM & Reporting, Persistence with the different kind of flavours, ...).
I disagree !
I agree on the fact that rules and processes are based on different paradigms (constraint evaluation vs state charts). And in that sense they could be considered separate topics. But in reality, if you try to model a business problem, you are confronted with logic that could best be represented using a business process and other logic where you would like to use rules. So in that sense it makes sense to integrate them.
And why would concepts like simulation, BAM and reporting, persistence,etc. only be applicable to BPM? They matter for BRM as well, hence the need for a unified platform ! And that's why Drools supports _integrated_ simulation, reporting, persistence, etc.
Kris
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210437#4210437
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210437
17 years, 1 month
[Design of POJO Server] - Re: Clustered DeploymentRepository for 5.1
by bstansberry＠jboss.com
"emuckenhuber" wrote : Hmm is the DeploymentManager enough for you then?
Not sure about the overall scope of this question, so I'll reply separately. ;)
anonymous wrote :
| just wondering what we should do with https://jira.jboss.org/jira/browse/JBAS-5682
|
| IMO profile.addDeployment should not automatically deploy the deployment.
| We could consider it on modifiedDeployments, but then you don't have any control about the lifecycle.
| It will just get deployed when HDScanner runs the next time, which does not really makes sense to me.
Yes, re-reading the JBAS-5682 forum thread (http://www.jboss.org/index.html?module=bb&op=viewtopic&t=138120) I don't see why anything needs to be done. I agree that adding a deployment to the profile and telling the server to deploy it are distinct things and should be controlled by the client that calls the DeploymentManager, and not be made random by the HDScanner thread. The 5.0.x HASingletonDeploymentScanner works fine that way, by calling DeploymentManager.distribute(name, phase, url, true) and then DeploymentManager.start().
In terms of the SPI, things are a bit confusing to me. Or perhaps I should say in terms of the implementation. Specifically, DeploymentManagerImpl.distribute(...). If you pass "true" as the copyContent param, on the server side DeployHandler.handleStream() gets called, which call DeploymentRepository.addDeploymentContent(). Simple enough. The client then calls DeploymentManager.start() which calls DeployHandler.start() which passes the deployment to the MainDeployer.
It's more confused if you pass "false" to the copyContent param. In that case DeployHandler.distribute() gets called, which calls DeploymentRepository.addDeployment() and then passes the deployment to the MainDeployer. A call to DeploymentManager.start() then seems redundant.
Passing a deployment to MainDeployer in two different places seems wrong.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210436#4210436
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210436
17 years, 1 month
[Design of JBoss jBPM] - Re: task assignee vs owner
by camunda
Hi Kris,
I know about DroolsFlow and such but to be honest: I am still a bit scared about some of the stuff integrated in Drools today ;-) But maybe this is just because of the lack of time to have a deeper look into the source code.
In my opinion: Drools = BRM + CEP -> Yes, cool! But BPM? I think there is a lot of stuff around in BPM which makes it a sperate topic which should be targeted by a BPM software (like BPMN -> technical Model mapping, Simulation, BAM & Reporting, Persistence with the different kind of flavours, ...).
With the Human Task Component I agree with you that effort should not be duplicated! But I don't see the value of drools developing the second BPM solution as well. And I really would like to see "one JBoss answer" to this, meaning a clear distinction when to use Drools and when to use jbpm. And how to combine.
Kris wrote :
| Do we want to work an a shared human task component or not, and if so, what are the requirements / restrictions? Then we can decide what would be the best way to move forward?
|
+1 for the shared task component supporting WS-HT (but not being tied to it, means having a pluggable life cycle). Kris, is there an easy example using your task component and how to change life cycle?
Kris wrote :
| I'm talking about collaboration
|
Would make sense to me, but I still think exactly one project (or lets say one project manager) must be responsible to enable this.
Hopefully this doesn't get to political? But it is indeed a topic which is in my mind for some time already, as being someone who likes both projects very much in their respective fields! So I would like to see some progress in this area....
Cheers
Bernd
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210427#4210427
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210427
17 years, 1 month
[Design of POJO Server] - Getting hold of the real cause of a DeploymentException
by pete.muir＠jboss.org
I'm trying to get hold of the real cause of a deployment failure (example shown below, I need to get the javax.inject.DefinitonException). I've tried deploying via JBossTestServices, and via the ProfileService. Both return a DeploymentException whose root cause is an IncompleteDeploymentException. I've drilled down into the IncompleteDeploymentException to look at the IncompleteDeployments, which has one context in error, due to a DeploymentException. This DeploymentException has no cause, and just the deployment that failed as an error message, so no help there.
Any suggestions how to get the real error?
16:17:03,011 ERROR [TooManyDeploymentTypesTest]] Exception sending context initialized event to listener instance of class org.jboss.webbeans.servlet.WebBeansListener
| javax.inject.DefinitionException: At most one scope may be specified
| at org.jboss.webbeans.bean.AbstractClassBean.initDeploymentType(AbstractClassBean.java:241)
| at org.jboss.webbeans.bean.AbstractBean.init(AbstractBean.java:147)
| at org.jboss.webbeans.bean.AbstractClassBean.init(AbstractClassBean.java:86)
| at org.jboss.webbeans.bean.SimpleBean.init(SimpleBean.java:294)
| at org.jboss.webbeans.bean.SimpleBean.<init>(SimpleBean.java:115)
| at org.jboss.webbeans.bean.SimpleBean.of(SimpleBean.java:103)
| at org.jboss.webbeans.bootstrap.BeanDeployer.createSimpleBean(BeanDeployer.java:198)
| at org.jboss.webbeans.bootstrap.BeanDeployer.deploy(BeanDeployer.java:90)
| at org.jboss.webbeans.bootstrap.WebBeansBootstrap.registerBeans(WebBeansBootstrap.java:111)
| at org.jboss.webbeans.bootstrap.WebBeansBootstrap.boot(WebBeansBootstrap.java:139)
| at org.jboss.webbeans.servlet.ServletLifecycle.beginApplication(ServletLifecycle.java:55)
| at org.jboss.webbeans.servlet.WebBeansListener.contextInitialized(WebBeansListener.java:48)
| at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910)
| at org.apache.catalina.core.StandardContext.start(StandardContext.java:4393)
| at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:367)
| at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:146)
| at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:460)
| at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118)
| at org.jboss.web.deployers.WebModule.start(WebModule.java:96)
| at sun.reflect.GeneratedMethodAccessor335.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
| at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
| at $Proxy36.start(Unknown Source)
| at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
| at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
| at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
| at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
| at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:286)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
| at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
| at org.jboss.system.ServiceController.start(ServiceController.java:460)
| at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:146)
| at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:104)
| at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:45)
| at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
| at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
| at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
| at org.jboss.profileservice.management.upload.remoting.DeployHandler.start(DeployHandler.java:224)
| at org.jboss.profileservice.management.upload.remoting.DeployHandler.invoke(DeployHandler.java:149)
| at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
| at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
| at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
| at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
| at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
| 16:17:03,012 ERROR [StandardContext] Error listenerStart
| 16:17:03,012 ERROR [StandardContext] Context [/org.jboss.jsr299.tck.unit.definition.deployment.broken.tooMany.TooManyDeploymentTypesTest] startup failed due to previous errors
| 16:17:03,014 ERROR [AbstractKernelController] Error installing to Start: name=jboss.web.deployment:war=/org.jboss.jsr299.tck.unit.definition.deployment.broken.tooMany.TooManyDeploymentTypesTest state=Create mode=Manual requiredState=Installed
| org.jboss.deployers.spi.DeploymentException: URL file:/Applications/jboss-5.0.0.GA/server/default/tmp/deploy/org.jboss.jsr299.tck.unit.definition.deployment.broken.tooMany.TooManyDeploymentTypesTest34311-exp.war/ deployment failed
| at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:388)
| at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:146)
| at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:460)
| at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118)
| at org.jboss.web.deployers.WebModule.start(WebModule.java:96)
| at sun.reflect.GeneratedMethodAccessor335.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
| at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
| at $Proxy36.start(Unknown Source)
| at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
| at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
| at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
| at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
| at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:286)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
| at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
| at org.jboss.system.ServiceController.start(ServiceController.java:460)
| at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:146)
| at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:104)
| at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:45)
| at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
| at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
| at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
| at org.jboss.profileservice.management.upload.remoting.DeployHandler.start(DeployHandler.java:224)
| at org.jboss.profileservice.management.upload.remoting.DeployHandler.invoke(DeployHandler.java:149)
| at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
| at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
| at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
| at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
| at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210416#4210416
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210416
17 years, 1 month
[Design of JBoss jBPM] - Re: task assignee vs owner
by KrisVerlaenen
anonymous wrote : i think for most use cases their lifecycle model is actually overly complex. that's why we made our lifecycle pluggable.
First it was too simplistic and now it's too complex? ;)
The basic simple life cycle is:
- someone creates a task for an actor
- actor that needs to execute the task starts the task when he starts executing it
- actor completes the task once he's done
Doesn't sound that complex to me?
And if you really want to change the life cycle (out of the scope of the WS-HT spec), you can do as well in our component (we use MVEL configuration to define possible state transitions and their effect).
anonymous wrote : You're always welcome to take our task component, leverage it and help to build any use cases that it might not yet support.
I'm talking about collaboration, not this one-way you can use and improve whatever we have. Do we want to work an a shared human task component or not, and if so, what are the requirements / restrictions? Then we can decide what would be the best way to move forward?
Kris
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210412#4210412
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210412
17 years, 1 month
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Journal Clean up / Compactor
by clebert.suconic＠jboss.com
This is a summary of the main changes:
- JournalFile..
I have added:
| void addCleanupInfo(long id, JournalFile deleteFile);
| JournalFile getCleanupInfo(long id);
|
I need to know what records are possibly bad. If a delete happened on a different file, I need that information to later perform a delete. The cleanupInfo will give me that List.
On JournalImpl, when a record is deleted, if the record is on a different file, I add the Information on that list:
| inner class PosFiles:
| ...
|
| void addDelete(final long id, final JournalFile deleteFile)
| {
| if (addFile != deleteFile)
| {
| addFile.addCleanupInfo(id, deleteFile);
| }
|
| deleteFile.incNegCount(addFile);
|
| if (updateFiles != null)
| {
| for (JournalFile updateF : updateFiles)
| {
| if (addFile != updateF)
| {
|
| // ... (some comments suppressed here)
| updateF.addCleanupInfo(id, deleteFile);
| }
|
| deleteFile.incNegCount(updateF);
| }
| }
| }
|
During the cleanup, if a record is on that list, I change the field-type for that record as CLEARED.
readJournalFile(journalFile, new JournalReader()
| {
|
| public void addRecord(final int recordPos, final RecordInfo recordInfo) throws Exception
| {
| JournalFile cleanupFile = journalFile.getCleanupInfo(recordInfo.id);
| if (cleanupFile != null)
| {
| if (trace)
| {
| trace("Cleaning addRecord id = " + recordInfo.id);
| }
|
| ByteBufferWrapper buffer = generateAddRecord(false,
| fileID,
| recordInfo.id,
| recordInfo.userRecordType,
| new ByteArrayEncoding(recordInfo.data));
|
| buffer.rewind();
|
| sf.position(recordPos);
| sf.write(buffer.getBuffer(), false);
|
| // Eliminating the dependency between a and b
|
| cleanupFile.decNegCount(journalFile);
| journalFile.decPosCount();
| }
|
| }
|
And to support reading JournalFiles for different purposes other than loading, I have created a method readJournalFile, that will be used by both load, cleaning, and compacting (in the future). The logic of reading the file is kept on a single place:
| // Used by both load, cleanup, and compact (in future)
| private int readJournalFile(final JournalFile file, final JournalReader reader) throws Exception
| {
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210400#4210400
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210400
17 years, 1 month
[Design of JBoss jBPM] - Re: task assignee vs owner
by camunda
Two quick remarks:
1) Supporting WS-HumanTask would be a interesting improvement for jbpm! But I also agree with Tom, that it doesn't fit in any case, so having a pluggable life cycle is the best option. And to model that lifecycle with jpdl itself would be a natural fit in the jbpm infrastructure I guess.
And yes, I faced that requirements at least a couple of times, some customers did really advanced human task management ;-)
2.) Having a joined Human Task Management component of jbpm and drools would be a very good thing! I think it doesn't make too much sense to develop that twice in JBoss. And it would be much better to have one user interface as well (for every component creating Human Tasks in the JBoss SOA ;-)).
And having two components always provokes the question why the both implementations are there.
But maybe this involves politics which team is responsible for it?
And personally I don't know the Drools Human Task Management component yet, so I cannot really judge how good it fits for the jbpm requirements. And I get the feeling that Human task Management is more in the direction of BPM than BRM, so I see jBPM responsible for it. And Drools shouldn't even need persistence in the most common use cases for a Rule Engine, different to jbpm.
Just my two cents
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210373#4210373
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210373
17 years, 1 month
[Design of JBoss jBPM] - Re: task assignee vs owner
by kukeltje
Tom,
Yes, this usecase is useful.
But I have another one. In many of the processes in the companiy I worked for, it is required to send out an xml message to the party that performed a task which lead to this specific task. e.g.:
- You ask me (or someone if the systems decides who it gets assigned to) to repair a car
- I accept to do it, or reject it
In case there is no other wait-state in between (one task directly leads to the next task after a 'signal'), you can set some variable on the next task with the role/actor/... value of this former task. When other waitstates are in between (e.g. an external service has to be called async) it does not work. So I added my own tag to the task in the processdefinition without customizing the taskInstance (I just read the xml from the process archive). This tag is a reference to the swimlane that had the previous task. It is kind of like a business transaction then in ebBP.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210369#4210369
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210369
17 years, 1 month