FAQ
Is there any chance that support for bean method invocations on the event
dispatch thread could be added?

The URI might look something like:

bean:foo?methodName=addBar&EDT=true

Some way to tell @MessageDriven that it should dispatch on the EDT would be
really nice too...

I'm new to camel, but so far the refactoring of our project where we try out
using camel, spring, spring-javaconfig, and maven, is going very well. There
has been a large reduction and simplification of the code, and a new clarity
in the architecture... thanks!

Steven Marcus


--
View this message in context: http://www.nabble.com/bean-method-invocations-on-EDT-tf4329507s22882.html#a12330693
Sent from the Camel - Users mailing list archive at Nabble.com.

Search Discussions

  • James Strachan at Aug 26, 2007 at 1:34 pm

    On 8/26/07, steven.marcus wrote:
    Is there any chance that support for bean method invocations on the event
    dispatch thread could be added?

    The URI might look something like:

    bean:foo?methodName=addBar&EDT=true

    Some way to tell @MessageDriven that it should dispatch on the EDT would be
    really nice too...
    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

    I'm new to camel, but so far the refactoring of our project where we try out
    using camel, spring, spring-javaconfig, and maven, is going very well. There
    has been a large reduction and simplification of the code, and a new clarity
    in the architecture... thanks!
    Great, thats good to know!
  • Steven.marcus at Aug 26, 2007 at 10:44 pm

    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.

    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.

    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?

    thanks again!
    Steven Marcus

    ps. there is an SWT thread which is analogous but incompatible with the EDT,
    so SWT users may ask for an SWT component...

    --
    View this message in context: http://www.nabble.com/bean-method-invocations-on-EDT-tf4329507s22882.html#a12339298
    Sent from the Camel - Users mailing list archive at Nabble.com.
  • James Strachan at Aug 27, 2007 at 7:24 am

    On 8/26/07, steven.marcus 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!

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupusers @
categoriescamel
postedAug 25, '07 at 11:35p
activeAug 27, '07 at 7:24a
posts4
users2
websitecamel.apache.org

2 users in discussion

Steven.marcus: 2 posts James Strachan: 2 posts

People

Translate

site design / logo © 2022 Grokbase