[jira] Created: (CAMEL-86) Unify the various POJO approaches in Camel (pojo + bean components, proxying, spring remoting, bean post processing etc)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] Created: (CAMEL-86) Unify the various POJO approaches in Camel (pojo + bean components, proxying, spring remoting, bean post processing etc)

JIRA jira@apache.org
Unify the various POJO approaches in Camel (pojo + bean components, proxying, spring remoting, bean post processing etc)
------------------------------------------------------------------------------------------------------------------------

                 Key: CAMEL-86
                 URL: https://issues.apache.org/activemq/browse/CAMEL-86
             Project: Apache Camel
          Issue Type: Improvement
          Components: camel-core
    Affects Versions: 1.0.0
            Reporter: James Strachan
             Fix For: 1.1.0


Currently we have various approaches to POJOs in Camel

* POJO component which provides a proxy to any interface; which creates a PojoInvocation as a message body which sends to a camel endpoint; then a server side which consumes the message and invokes the server
* a Bean component which binds messages to any bean in spring
* a bean post processor (spring) which can inject various Camel resources via annotations; plus allows a method on a POJO to consume messages by binding flexibly the method to a message exchange
* a spring remoting implementation

We need to rationalise the code and promote reuse across these integration points.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (CAMEL-86) Unify the various POJO approaches in Camel (pojo + bean components, proxying, spring remoting, bean post processing etc)

JIRA jira@apache.org

    [ https://issues.apache.org/activemq/browse/CAMEL-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_39827 ]

James Strachan commented on CAMEL-86:
-------------------------------------

The code now reuses the same common Processor (BeanProcessor) for invoking a bean from any Camel exchange however a bean is connected to a message exchange (bean post processor via annotations, or the bean component).

I've unified the POJO and Bean components together (there's now just the Bean component which has moved from Spring to camel-core). This also uses the Camel Registry to find the POJO - so we can use the bean component with JNDI to find the beans if the user is not using spring etc. The POJO component now really has turned into the ProxyHelper which allows a proxy to be created for any bean (which the implementation sends a message to Camel)

Finally the binding mechanism between a message exchange on the bean can now use the BeanInvocation body if the body can be converted to that (which defines exactly what the method is and its parameters) - or the message might include a header to describe the method, or the type of the body is used to figure out which method to invoke (if a single method call is unambiguous, otherwise its an error)

> Unify the various POJO approaches in Camel (pojo + bean components, proxying, spring remoting, bean post processing etc)
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-86
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-86
>             Project: Apache Camel
>          Issue Type: Improvement
>          Components: camel-core
>    Affects Versions: 1.0.0
>            Reporter: James Strachan
>             Fix For: 1.1.0
>
>
> Currently we have various approaches to POJOs in Camel
> * POJO component which provides a proxy to any interface; which creates a PojoInvocation as a message body which sends to a camel endpoint; then a server side which consumes the message and invokes the server
> * a Bean component which binds messages to any bean in spring
> * a bean post processor (spring) which can inject various Camel resources via annotations; plus allows a method on a POJO to consume messages by binding flexibly the method to a message exchange
> * a spring remoting implementation
> We need to rationalise the code and promote reuse across these integration points.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Resolved: (CAMEL-86) Unify the various POJO approaches in Camel (pojo + bean components, proxying, spring remoting, bean post processing etc)

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

     [ https://issues.apache.org/activemq/browse/CAMEL-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Strachan resolved CAMEL-86.
---------------------------------

    Resolution: Fixed

See the documentation here

http://cwiki.apache.org/CAMEL/bean-integration.html

> Unify the various POJO approaches in Camel (pojo + bean components, proxying, spring remoting, bean post processing etc)
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-86
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-86
>             Project: Apache Camel
>          Issue Type: Improvement
>          Components: camel-core
>    Affects Versions: 1.0.0
>            Reporter: James Strachan
>             Fix For: 1.1.0
>
>
> Currently we have various approaches to POJOs in Camel
> * POJO component which provides a proxy to any interface; which creates a PojoInvocation as a message body which sends to a camel endpoint; then a server side which consumes the message and invokes the server
> * a Bean component which binds messages to any bean in spring
> * a bean post processor (spring) which can inject various Camel resources via annotations; plus allows a method on a POJO to consume messages by binding flexibly the method to a message exchange
> * a spring remoting implementation
> We need to rationalise the code and promote reuse across these integration points.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.