[Design of JBoss jBPM] - Re: Start process with form
by tom.baeyens＠jboss.com
here's the example usage (ProcessDefinitionStartFormTest):
public void testFormInUnnamedStartActivity() {
| String deploymentDbid =
| repositoryService.createDeployment()
| .addResourceFromString("xmlstring.jpdl.xml",
| "<process name='make print'>" +
| " <start form='org/jbpm/test/process/ProcessDefinitionStartForm.form' />" +
| "</process>"
| )
| .addResourceFromClasspath("org/jbpm/test/process/ProcessDefinitionStartForm.form")
| .deploy();
|
| registerDeployment(deploymentDbid);
|
| ProcessDefinition processDefinition =
| repositoryService
| .createProcessDefinitionQuery()
| .processDefinitionName("make print")
| .uniqueResult();
|
| String processDefinitionId = processDefinition.getId();
|
| List<String> startActivityNames = repositoryService.getStartActivityNames(processDefinitionId );
| List<String> expectedStartActivityNames = new ArrayList<String>();
| expectedStartActivityNames.add(null);
|
| assertEquals(expectedStartActivityNames, startActivityNames);
|
| String startFormResourceName = repositoryService.getStartFormResourceName(processDefinitionId, null);
|
| assertEquals("org/jbpm/test/process/ProcessDefinitionStartForm.form", startFormResourceName);
|
| InputStream formInputStream = repositoryService.getResourceAsStream(processDefinition.getDeploymentId(), startFormResourceName);
|
| String formContents = new String(IoUtil.readBytes(formInputStream));
| assertEquals("start task form", formContents);
| }
|
| public void testFormInNamedStartActivity() {
| String deploymentDbid =
| repositoryService.createDeployment()
| .addResourceFromString("xmlstring.jpdl.xml",
| "<process name='make print'>" +
| " <start name='start' form='org/jbpm/test/process/ProcessDefinitionStartForm.form' />" +
| "</process>"
| )
| .addResourceFromClasspath("org/jbpm/test/process/ProcessDefinitionStartForm.form")
| .deploy();
|
| registerDeployment(deploymentDbid);
|
| ProcessDefinition processDefinition =
| repositoryService
| .createProcessDefinitionQuery()
| .processDefinitionName("make print")
| .uniqueResult();
|
| String processDefinitionId = processDefinition.getId();
|
| List<String> startActivityNames = repositoryService.getStartActivityNames(processDefinitionId );
| List<String> expectedStartActivityNames = new ArrayList<String>();
| expectedStartActivityNames.add("start");
|
| assertEquals(expectedStartActivityNames, startActivityNames);
|
| String startFormResourceName = repositoryService.getStartFormResourceName(processDefinitionId, "start");
|
| assertEquals("org/jbpm/test/process/ProcessDefinitionStartForm.form", startFormResourceName);
|
| InputStream formInputStream = repositoryService.getResourceAsStream(processDefinition.getDeploymentId(), startFormResourceName);
|
| String formContents = new String(IoUtil.readBytes(formInputStream));
| assertEquals("start task form", formContents);
| }
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240511#4240511
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240511
14 years, 11 months
[Design of JBoss jBPM] - Re: Start process with form
by tom.baeyens＠jboss.com
i'm adding these two to the repository service:
/** find all the activity names of the start activities for a given
| * process definition. Only top level activities are scanned.
| * Every activity that doesn't have incoming transitions is considered
| * a start activity. For the moment, jPDL only supports one
| * start activity. Start activity names can be null. */
| List<String> getStartActivityNames(String processDefinitionId);
|
| /** the resource name for the given start activity. It is assumed that
| * the ProcessDefinition is already retrieved. From the ProcessDefinition,
| * the {@link ProcessDefinition#getId()} and the {@link ProcessDefinition#getDeploymentId()}
| * can be retrieved. The activityName can be obtained via {@link #getStartActivityNames(String)}.
| * An InputStream for the resource can be obtained with {@link #getResourceAsStream(String, String)} */
| String getStartFormResourceName(String processDefinitionId, String activityName);
|
task forms are exposed through Task.getForm(). In order to make that method name consistent, I'll be refactoring it to Task.getFormResourceName()
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240505#4240505
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240505
14 years, 11 months
[Design of JBoss ESB] - Re: Supporting entry-point
by jeffdelong
Bernd,
Fusion allows for events to come from different "event streams". In the example I posed (similar to the quickstart business_ruleservice_stateful) one object stream is of customers, the other is orders. Fusion does not really care how these events come in (e.g. JMS queues, etc.), but it does allow rules to be written against events from both streams. For example, the rules could calculate discounts based on order totals for a specific customer over some time period. So far this is just Drools CEP capabilities.
Now we want to add the ESB to the architecture to help manage the input streams, and deploy these rules as a service. So in what I described previously there could be three services, one that actually implements the business rules. and the other two to manage the input streams>
Your question is why does each service not have its own working memory? The answer is that we want both streams of objects in a single working memory so the rules operate against the combined set of facts. That is not the same as putting all the customers into one working memory and all the orders into a second working memory. If you did that with rules testing for the existence of both types of facts (like the rules in the quickstart), no rules would ever fire.
Internal optimizations should not be visible to the outside? Implementation details should not be visible outside of a service, but the functionality of a service is visible and why one service has one set of capabilities and another service has another set of capabilities would certainly be influenced by the desire to "optimize" services (i.e., it may not perform well if given too many tasks to perform). In this sense the allocation of capabilities to services is an "optimization"s.
So in this spirit, I proposed we provide the capabilities to create individual services, some whose capabilities are based on a managing the input stream of events of a certain type, and another to manage the actual rules execution. Perhaps these services could be better named the CustomerEventHandlingService and the OrderEventHandlingService, and the third service is the DiscountService. Yes this design is the result of an "optimization". But it might be a very reasonable optimization to make.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240478#4240478
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240478
14 years, 11 months
[Design of EJB 3.0] - EJBTHREE-1823 - handling of res-type in resource-ref
by Wolfgang Knauf
In https://jira.jboss.org/jira/browse/EJBTHREE-1823 a warning message was introduced if a "resource-ref" in ejb-jar.xml lacks the element "res-type".
19:56:41,171 WARN [ResourceHandler] EJBTHREE-1823 : <res-type> not specified for the <resource-ref> ... in bean ...Bean
I think this warn message is a slight violation of the spec (chapter 16.7.1.3 of EJB3 spec and 5.6.2 of JavaEE5 spec):
"The resource-ref element consists of ... the optional res-type .... The res-type element is optional if an injection target is specified for the
resource; in this case, the res-type defaults to the type of the injection target."
And:
"The resource manager connection factory type must be compatible with the type declared in the res-type element"
So I think that JBoss should warn only if no "injection-target" is specified (though it can handle this case, too).
The content of the res-type element does not seem to be checked by JBoss. Even if I don't enter an injection target and have no or an invalid res-type value, a lookup works. That's quite gentle of JBoss. But according to the spec, I would at least expect an error if the type of the object bound to the mapped-name does not match the "res-type".
By the way: the "resource-ref" element seems to be only valid for a "Resource Manager Connection Factory", but I could use it for injection of a javax.ejb.SessionContext from "java:comp/EJBContext". While digging through the spec for writing this post, I found that I should have used a "resource-env-ref" element....
Any comments from the gurus on my crude theories ;-)?
Wolfgang
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240434#4240434
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240434
14 years, 11 months