[Design of Messaging on JBoss (Messaging/JBoss)] - XML configuration changes
by jmesnil
I've fixed https://jira.jboss.org/jira/browse/JBMESSAGING-1596 in the trunk.
The intent was to simplify our XML configuration files.
We have a lot of unrelated properties (e.g. address settings, cf settings, etc.) which needed to be in a given order to be valid (e.g. "foo" must be before "bar", etc.)
This would make it very difficult for our users to configure JBM: they'd have to look at the XSD schema to know how to order the XML elements... not very user-friendly (XSD errors are cryptic) and plain ugly!
Now, our configuration files are "bags" of XML elements, they can be in any order.
However, there were a few structure changes to allow that: elements which could appear multiple times must now be inside a container XML element.
For example, all the "connector" definitions must be in a "connectors" elements. The same goes for "acceptor", "broadcast-group", "discovery-group", "bridge", "queue", "divert", "cluster-connection" in jbm-configuration.xml.
Similarly, the "entry" elements of jbm-jms.xml's "connection-factory" must be put inside a "entries" container.
I've updated all the source configuration files we have (src + tests + examples).
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225845#4225845
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225845
16 years, 11 months
[Design of JBoss jBPM] - Re: introducing process instance ?
by jbarrez
Tom,
I agree that it makes the executionService more user-friendly.
After all, when you signal an execution and he forks in 5 paths, the following 5 waitstates should be returned to make the code more easier to understand.
The only alternative for the ProcessInstance I'm seeing is a Set/Map/... of curent wait states of the 'root execution'. (or return nothing and let the user make a query ... but then we're back at jbpm 3, which was flawed in that perspective)
But I don't agree that the ProcessInstance should be an interface.
Why not make it an extension of the ExecutionImpl? After all, the ProcessInstance is just another name of a very specific execution (ie the root execution). You could add some specifc stuff to the process instance (eg business key? as it was in jbpm3 or getAllWaitStates())
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225824#4225824
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225824
16 years, 11 months
[Design of Messaging on JBoss (Messaging/JBoss)] - message group example -- not working
by gaohoward
Hi, I wrote a simple message grouping example to illustrate the effect of 'JMSXGroupID', but it doesn't always work as expected. All I do is create two consumers and send out 10 messages with JMSXGroupID set, and inspect that all the messages will went to only one of the consumers. But the result is random: sometimes all messages went to consumer1, sometimes consumer2 and sometimes both. I don't know what's wrong?
The code :
| MessageConsumer consumer1 = session.createConsumer(queue);
| consumer1.setMessageListener(new SimpleMessageListener("consumer-1"));
| MessageConsumer consumer2 = session.createConsumer(queue);
| consumer2.setMessageListener(new SimpleMessageListener("consumer-2"));
|
| //Step 8. Create and send 10 text messages with group id 'Group-0'
| int msgCount = 10;
| TextMessage[] groupMessages = new TextMessage[msgCount];
| for (int i = 0; i < msgCount; i++)
| {
| groupMessages = session.createTextMessage("Group-0 message " + i);
| groupMessages.setStringProperty(JBossMessage.JMSXGROUPID, "Group-0");
| producer.send(groupMessages);
| System.out.println("Sent message: " + groupMessages.getText());
| }
|
And I added the config
|
| <address-settings match="jms.queue.exampleQueue">
| <distribution-policy-class>org.jboss.messaging.core.server.impl.GroupingRoundRobinDistributor</distribution-policy-class>
| </address-settings>
|
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225809#4225809
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225809
16 years, 11 months
[Design of JBoss jBPM] - Re: schema for mail template and activity
by tom.baeyens＠jboss.com
"alex.guizar(a)jboss.com" wrote : Examples cannot be produced at this point because the syntax and the design have not been agreed upon.
|
i'm pushing for examples in the example test code exactly because that improves the discussion on the syntax. you work out examples from simple to complex. then we can review.
"alex.guizar(a)jboss.com" wrote : Unlike other activities email has more complex setup and more moving parts. Let us focus on making the design decisions first.
|
ok. but i think that should be trivial :-)
"alex.guizar(a)jboss.com" wrote : There are two concepts in play.
| * mail template describes the contents of an email
| * mail producer takes a template as input and produces a template as output
|
i think that is already too complex. this is splitting up our implementation to introduce some kind of user pluggability in the middle of our implementation.
check out my alternative MailSession:
interface MailSession {
| Mail createMail();
| Mail createMail(String templateName);
| }
|
| interface Mail {
| Mail setTo(String to);
| Mail setCC(String cc);
| Mail setBCC(String bcc);
| Mail setSubject(String subject);
| Mail setBody(String subject);
| Mail addAttachment(String name, InputStream attachment, String mimeType);
|
| void send();
| }
building that implementation should be the basis. this exposes all the functionality that we want to build on top of JavaMail. this implementation can be leveraged by 1) our mail activity and event-listener 2) task notify and reminder 3) users that want to build custom mail activities programatically.
i don't think it needs to be more complex then that.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225802#4225802
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225802
16 years, 11 months
[Design of JBoss jBPM] - introducing process instance ?
by tom.baeyens＠jboss.com
i'm thinking to introduce ProcessInstance:
interface ProcessInstance extends Execution {
| }
|
advantage is that with this interface we can indicate more precisely what the ExecutionService methods are returning: a real ProcessInstance (one execution of a full process) or an Execution (one path of execution in a process instance)
sidenote: in the PVM implementation class, we cannot make that distinction. cause if concrete process languages like jPDL want to introduce JpdlProcessInstance as a concrete subclass, that would lead to multiple inheritence.
disadvantage is that the ProcessInstance interface doesn't contain any extra methods. that might be strange. but i don't think it will cause confusion. and it will reduce the confusion in understanding the ExecutionService
public interface ExecutionService {
|
| ProcessInstance startProcessInstanceById(String processDefinitionId);
|
| ProcessInstance startProcessInstanceById(String processDefinitionId, String processInstanceKey);
|
| ProcessInstance startProcessInstanceById(String processDefinitionId, Map<String, Object> variables);
|
| ProcessInstance startProcessInstanceById(String processDefinitionId, Map<String, Object> variables, String processInstanceKey);
|
| ProcessInstance startProcessInstanceByKey(String processDefinitionKey);
|
| ProcessInstance startProcessInstanceByKey(String processDefinitionKey, String processInstanceKey);
|
| ProcessInstance startProcessInstanceByKey(String processDefinitionKey, Map<String, Object> variables);
|
| ProcessInstance startProcessInstanceByKey(String processDefinitionKey, Map<String, Object> variables, String processInstanceKey);
|
| Execution findExecutionById(String executionId);
|
| List<Execution> findExecutionsById(String processDefinitionId);
|
| ProcessInstance signalExecutionById(String executionId);
|
| ProcessInstance signalExecutionById(String executionId, String signalName);
|
| ProcessInstance signalExecutionById(String executionId, String signalName, Map<String, Object> parameters);
|
| ProcessInstance signalExecutionById(String executionId, Map<String, Object> parameters);
|
|
| ExecutionQuery createExecutionQuery();
|
| ExecutionQuery createProcessInstanceQuery();
|
| void setVariable(String executionId, String name, Object value);
|
| void setVariables(String executionId, Map<String, Object> variables);
|
| Object getVariable(String executionId, String variableName);
|
| Set<String> getVariableNames(String executionId);
|
| Map<String, Object> getVariables(String executionId, Set<String> variableNames);
|
| void endProcessInstance(String processInstanceId, String state);
|
| void deleteProcessInstance(String processInstanceId);
| }
|
i also think that the return value for signal should be the process instance and not the execution on which the signal occurs. that will force users to use the right way of getting the executionId's that are in a wait state. in the context of timers, each activity is potentially a scope, resulting in a child-execution and hence you cannot assume that it is the same execution that will be waiting in the wait state. that is why users will have to do something like this in case of a wait state:
Execution processInstance = executionService.startProcessInstanceByKey("TimerTransition");
|
| String executionId = processInstance.findActiveExecutionIn("guardedWait").getId();
|
| executionService.signalExecutionById(executionId, "go on");
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225801#4225801
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225801
16 years, 11 months
[Design of PVM (Process Virtual Machine)] - Composite execution problem
by beeke
hello,
| public void testSequence(){
| ClientProcessDefinition processDefinition = ProcessDefinitionBuilder
| .startProcess("propagate")
| .startActivity("sequence", new Sequence())
| .initial().needsPrevious().transition("end")
| .startActivity("one", new WaitState())
| .endActivity()
| .startActivity("two", new WaitState())
| .endActivity()
| .startActivity("three", new WaitState())
| .endActivity()
| .endActivity()
| .startActivity("end", new WaitState())
| .endActivity()
| .endProcess();
|
| ClientExecution execution = processDefinition.startProcessInstance();
| execution.signal();
| execution.signal();
| execution.signal();
| }
|
Notice the line:.initial().needsPrevious().transition("end")
I want it execute like this:
(sequence(one -> two -> three)) -> end
In fact is sequence->end
I saw the source code, while activityImpl.createOutgoingTransition, the activity "end" is set to be a defaultTransition: defaultTransition = transition;
While executionImpl.proceed(), the "sequence" activity has defaultActivity, and will never executed as a block structed node.
How can PVM support block structed like this?
http://docs.jboss.org/jbpm/pvm/manual/html_single/images/ch02.transition....
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225782#4225782
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225782
16 years, 11 months
