[Design of JBoss jBPM] - Re: Register EventListener on JbppmContext
by camunda
Damn it, submitted too early, now in the train (with a bit of fresh air in between) I had two additional thoughts:
1.) I think the single listener would enough. If we want to have something like a dispatcher it can be configured as Listener knowing a list of other listener it notifies.
2.) The EventListener is maybe really not important at the moment. I think the same thing is already supported by hook in an own LoggingService. This LoggingService gets all important events as Log as well, right? Or does anybody already dived deeper into it and knows something which is missing there?
So I can extend the LoggingService to serve as EventListener... I think for my purposes at the moment it should be sufficient. I will check that out on Monday morning....
So I think I started an unnecessary discussion, sorry for that! But finally it helped at least me to come to a solution ;-) Keep you posted about how I meet our BAM requirements...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191376#4191376
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191376
17 years, 4 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Large message code review
by timfox
Here are the results of the large message code review:
1. Need some tests that show pre-commit acks working with large messages
2. Need some tests show in large messages failover.
3. We should use SessionSendMessage for sending both large and normal messages. We should then have a new packet called SessionSendMessageContinuation for sending extra chunks.
4. We should use SessionReceiveMessage for receiving both large and normal messages, with continuations in a different packet.
5. Chunk messages are currently always sent blocking. Instead only the last chunk should be sent blocking, and then, only if sendBlocking = true
6. Replication for large messages needs to be implemented
7. ClientConsumeImpl::handleChunk should be synchronized and have closing check like handleMessage()
8.ClientConsumerImpl shouldn't use instanceof to determine FileMessage, instead use isFileConsiumer()
9.Flow control - for large message flow control should be called before adding adding to buffer APART from last chunk which should have flow control called before consumption, otherwise could flood the buffer.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191362#4191362
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191362
17 years, 4 months
[Design of POJO Server] - Re: xml persistent format for attachments
by emuckenhuber
"scott.stark(a)jboss.org" wrote :
| I'm not really following. You have the marshalled form of the ManagedObject and build it back up, to apply to the deployment attachment or are you talking about something else?
|
Basically what i meant is that if we do something like:
| ManagedObject mo = managedObjectFactory.createManagedObject(SomeClass.class, null);
| ManagedProperty p = result.getProperty("objectName");
| p.setValue(SimpleValueSupport.wrap("jboss:service=Hypersonic,database=profileserviceTestDB"));
|
| SomeClass object = mo.getAttachment();
|
So if SomeClass is properly annotated and we persist actually everything needed, we could use this as predetermined attachment;
as those changes are already updated in the metadata model through the WritethroughManagedPropertyImpl.
If we want to just update the delta then the ManagedComponent from the ManagementView should actually only contain the changed values.
We then would need to merge those changes with the xml (if it already contains some previous values), and apply this during deployment to the metadata itself.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191361#4191361
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191361
17 years, 4 months
[Design of JBoss jBPM] - Re: Register EventListener on JbppmContext
by camunda
Okay, here my proposal.
Add to GraphElement:
| /**
| * notify configured external event listeners of fired event.
| *
| * The notification is done BEFORE the event gets processed by jbpm
| * internally (meaning actions are executed), so it is visible
| * to the listeners even if exceptions occur inside of the actions
| * causing the stacktrace to abort
| */
| private void notifyListenerOfEvent(String eventType, ExecutionContext executionContext) {
| EventListenerUtil.notifyListenerOfEvent(eventType, executionContext);
| }
|
and call this method inside of the "fireAndPropagateEvent" method.
Now my first thought was, that the EventListenerUtil looks up jbpm.cfg.xnml via JbpmConfiguration to see if there is a bean "jbpm.event.listener" configured, e.g.
| <bean name="jbpm.event.listener" class="MyEventListener">
|
Or to create some kind of jbpm event dispatcher to support a list of listeners:
| <bean name="jbpm.event.dispatcher" class="org.jbpm.NN">
| <field name="listeners">
| <list>
| <bean class="MyEventListener1" />
| <bean class="MyEventListener2" />
| </list>
| </field>
| </bean>
|
The code isn't hard there, just check in the JbpmConfiguration if the listener is/the listeners are set and if then call the listener.
What do you guys think? What would you prefer, simple one listener (so people with multiple listeners have to implement that themselvers) or multiple listeners?
This is a really powerfull machnism to hook into jbpm and to develop generic solutions around it, e.g. for BAM.... And it is not a big deal. I would like to start on this next week, hopefully we can come to some conclusions here. When finished I can also blog about how I use this to generate the BAM events we need in the project...
Cheers and have a nice weekend
Bernd
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191350#4191350
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191350
17 years, 4 months