On 8/26/07, steven.marcus <[EMAIL PROTECTED]> wrote: > > > James.Strachan 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 > > > > edt:beanName?methodName=foo > > > > 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: > > SwingUtilities.invokeAndWait > SwingUtilities.invokeLater > > If there is a need to participate in transactions invokeAndWait needs to be > supported too... > 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 other thread. > 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! -- James ------- http://macstrac.blogspot.com/
