[Design of JBoss jBPM] - Re: task and swimlane roles
by heiko.braun＠jboss.com
Recent chat between tom and heiko
anonymous wrote :
| Tom
| ----------------
| or can that property of the stakeholder be called role ?
|
| then we do not have the same confusion as we had before
|
| Heiko Braun
| ----------------
| right, we are looking fot the property of a stakeholder
|
| that's what I call the verb
|
| a user or group may be a stakeholder
|
| but it doesn't specify their involvement
|
| Tom Baeyens
| ----------------
| what about just keeping the term role for that property ?
|
| Heiko Braun
| ----------------
| participant and participation is not too bad
|
| USER johndoe PARTCIPATES as CANDIATE
|
| i like this:
|
| taskService.addParticipant(taskDbid, new User("johndoe"), Participation.CANDIDATE);
|
| Tom Baeyens
| ----------------
| yes
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210644#4210644
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210644
17 years, 1 month
[Design the new POJO MicroContainer] - Re: Redeploy is done wrong
by adrian＠jboss.org
"alesj" wrote :
| >> ps: seen then redeploy issue? :-(
| >
| > Yes, but what's the point in repeating the "hack to a hack" comment. :-(
|
| What's the hack there?
|
"alesj" wrote :
| 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.
|
"alesj" wrote :
| 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?
|
Let's fix it so the two have the same semantics and stop trying to hack around
problems when you already know the correct solution.
i.e. the structure determination is not done until the "deploy" stage of process()
after the "undeploy" stage has been done.
I know why you don't want to do that, but its obviously the correct solution to
the problem identified and will always be cleaner than trying to workaround the
issue at a level (the vfs) that doesn't understand the deployment lifecycle.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210636#4210636
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210636
17 years, 1 month
[Design of JBoss jBPM] - Re: task and swimlane roles
by tom.baeyens＠jboss.com
so the 2 options are:
long taskDbid = ...;
|
| taskService.addTaskRole(taskDbid, IdentityType.USER, "johndoe", Role.ROLENAME_CANDIDATE_USER);
|
or
long taskDbid = ...;
|
| taskService.addTaskRole(taskDbid, new User("johndoe"), Role.ROLENAME_CANDIDATE_USER);
|
where
public interface Identity {
| getId();
| }
|
| public class User implements Identity {
| public User(String userId) {...}
| ...
| }
|
| public class Group implements Identity {
| public Group(String groupId) {...}
| ...
| }
both are acceptable to me. but working with objects in a session facade can lead to confusion. so i am leaning a bit more towards first option with identityType = IdentityType.USER and identityId = "johndoe"
WDYT ?
do these 2 options reflect the choice correctly ? or do you see other diffs as well ?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210628#4210628
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210628
17 years, 1 month
[Design of JBoss jBPM] - Re: process definition as a resource
by heiko.braun＠jboss.com
anonymous wrote :
| so if we assume that versioning is done by the client in the process file, then this would really fit the jboss deployer architecture. (finally !)
|
yes, that's what bernd did with the AS 4 deployer as well. let's start with explicit versioning inside the process description, at least for AS deployments. It sounds reasonable to me.
anonymous wrote :
| if a user deploys a new version of a process...
|
we'd need to be more precise here. I can actually see three use cases:
1) a changed pdl file, but classes remain the same
2) same pdl, but classes changed
3) changed pdl and classes changed
IMO 1) and 3) should lead to a new version of that process, i.e. demanding an explicit version increment in the pdl, whereas 2) simply associated a different resource set to with process (i think bernd called it patching/bug fixes)
In general all those cases where the pdl is changed, we can encounter two situations: the user explicitly changed the version within the pdl or he didn't. IMO the later case indicates "replacement" of a process definition.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210626#4210626
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210626
17 years, 1 month