[Design of JBoss jBPM] - GroupId or (groupName & GroupType)
by jeff.yuchang
Just found out that we've used the groupId in the jPDL file, for example, in the TaskCandidateTest.class, we've had following jpdl file.
| <?xml version="1.0" encoding="UTF-8"?>
|
| <process name="TaskCandidates">
|
| <start g="20,20,48,48">
| <transition to="review" />
| </start>
|
| <task name="review"
| candidate-groups="jbpid_group_id_._._unit_._._sales-dept"
| g="96,16,127,52">
|
| <transition to="wait" />
| </task>
|
| <state name="wait" g="255,16,88,52"/>
|
| </process>
|
For the candiate-groups, we need to specify the groupId, because the groupId is identity component specific, which means it might differ in different identity implementation. So I don't think it is good to use the id in this case.
Because in the process of doing jboss identity integration, I've found if I want to make the test suite passed, I need to update the jpdl file. And if I want to switch to use the jbpm-built-in identity, then need to update the jpdl file again due to the change of groupId difference.
My suggestion is: for groups, we used:
| candidate-groups = "groupName/groupType"
|
if the groupType == null or a default jBPM groupType (unit), it can be just specified as only groupName, like:
| candidate-groups="groupName"
|
While, for the users, we've used username as the value.
| user="username"
|
Got any thoughts??
thanks
Jeff
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237698#4237698
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237698
16 years, 9 months
[Design of JBoss ESB] - Http Gateway - requirements please...
by tfennelly
The HttpGateway added in v4.5 was based on an embedded tomcat, which has proven to be troublesome due to the sheer complexity of embedding tomcat. Because of this, we have decided to go to a model similar to that of EBWS, where we generate an actual war and deploy it as a sub deployment of the containing esb deployment.
>From a usability point of view, what would people like to see in a new HttpGateway? What I mean is ... what would they like to be able to configure, and how? What do we want to inherit from the existing HttpGateway config?
>From an implementation point of view, what would people like to see? Exactly the same as EBWS again, or should we try and create a new mechanism that abstracts this type of thing (creating sub deployments) away from the deployer and then use this as an opportunity to start evolving the EBWS specific code out of the deployer (where I would think it doesn't belong)? Do we want to merge deployments of the same type as in this case, where the EBWS and the new HttpGateway both require war deployments? What would that gain and would the added complexity be worth it?
Apart from potential implementation similarities, what else should the new HttpGateway have in common with the EBWS functionality?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237696#4237696
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237696
16 years, 9 months