|| at Aug 27, 2007 at 7:24 am
On 8/26/07, steven.marcus wrote:
Whats the event driven thread? Are you talking Swing/UI stuff?
If so we could maybe have a component/endpoint to process messages in
the EDT. e.g. like the SEDA component, but the messages would be
processed in the EDT...http://activemq.apache.org/camel/seda.html
Then the beans could be bound to URIs "edt:someName" then some route
could go from whatever the input is to the EDT uri?
Or maybe we just have an EDT component which invokes beans? So binding to
Yes, EDT=event dispatch thread, used by AWT and Swing and defines a "thread
compartment" for all gui objects.
Ah cool, thanks
As you say, implementing an edt component, like seda, makes more sense.
I'll look at the seda component and cobble together an edt component.
Great! We love contributions...http://activemq.apache.org/camel/contributing.html
Let us know if you need any help getting started etc.
Note that there are two ways to dispatch, synchronously and asynchronously:
If there is a need to participate in transactions invokeAndWait needs to be
Can seda processors participate in transactions?
Currently not I'm afraid; as we're using the default threaded
transactions in Spring. Though it could work if we supported
transaction suspend & resume when switching threads. So those async
components (of which there's not many so far - just seda and the new
edt component) they could see if there's a current transaction,
suspend it & attach it to the Exchange so it can be resumed in the
ps. there is an SWT thread which is analogous but incompatible with the EDT,
so SWT users may ask for an SWT component...
Thanks for the heads up!