[Design of JBoss jBPM] - Re: task assignee vs owner
by tom.baeyens＠jboss.com
"KrisVerlaenen" wrote : Tom, what about working together on a shared task component with the Drools team? Our human task component already supports use cases like this (and many more).
|
| Kris
i had a quick look at the drools task component before. model looked too simplistic for the use cases that we have. and it also didn't look appropriate to support the human interaction management features that we also want to incorporate. and it would be harder to make the drools task component fit into our architecture.
on the other hand, what would be the requirements for drools to collaborate with our task component ?
we have pluggable task lifecycle to allow for the human task lifecycle as well as a much simpler default lifecycle.
we also have hierarchical subtasks, comments and roles
i've also integrated jbpm with the jboss identity component. so all of our task component will be based on that integration as well.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210341#4210341
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210341
17 years, 1 month
[Design the new POJO MicroContainer] - Redeploy is done wrong
by alesj
or VFS needs a re-deploy notion.
WRT:
- https://jira.jboss.org/jira/browse/JBAS-6504
What goes on and where does it go wrong?
* some ProfileService part finds modified deployment
* it returns list of Modifications to HDScanner
* HDScanner for MODIFIED deployment does this:
| mainDeployer::addDeployment(deployment)
|
* MainDeployer::addDeployment <-- (W)
* HDScanned invokes mainDeployer::process()
* MainDeployer --> DeployersImpl::process(undeploy, deploy)
* DeployerImpl::process --> undeploys modifed deployment, (re-)deploys modifed deployment
The wrong part is this:
In (W) we find existing deployment context, hence this means that addition is actually a re-deploy.
We add existing deployment context to undeploy, and then we create/recognize new one to be deployed.
And this is what's wrong --> we are actually doing new structure recognition on a deployment that's about to be undeployed --> its temp are gonna be cleared.
This already reads some VirtualFile refs into the DeploymentContext.
This refs can point to ZipEntryHandlers (VirtualFileHandler impl) whos underlying temp file is about to be deleted.
But the actual temp deletion only happens in DeployersImpl:process, its undeploy part.
So, we end up with parts from old VirtualFile refs and a few new ones.
e.g. from my test, the classpath was and old ref
In VFS on VirtualFile::clear I delete possible temps and reset jar VirtualFileHandlers (actually it's its contexts).
This reset enables that owning jar handlers are gonna re-initialize its contents, hence re-creating nested temp jars.
That this clearly works I added the following change to HDScanner:
| case MODIFIED:
| mainDeployer.removeDeployment(ctx); // change
| mainDeployer.process(); // change
| mainDeployer.addDeployment(ctx);
| break;
|
But this is not the right solution, since it's MainDeployer that should transparently handle re-deploys.
What would be the right way to do this?
We're probably have to break existing 2 phase deployment for re-deploys.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210271#4210271
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210271
17 years, 1 month