Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Date: Sat, 22 Oct 2011 07:00:32 +0000 (UTC)
From: "Christian Schneider (Commented) (JIRA)" <jira@apache.org>
To: dev@camel.apache.org
Message-ID: 
 <1907947606.4564.1319266832890.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <2065433586.16182.1319130310787.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (CAMEL-4565) Allow to send messages using a user
 supplied pojo interface
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CAMEL-4565?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1313=
3282#comment-13133282 ]=20

Christian Schneider commented on CAMEL-4565:
--------------------------------------------

The ProxyHelper seems to always create a BeanInvocation. So I think we are =
not already there. I now work out a prototype of a InvocationHandler for
pojo messaging.
               =20
> Allow to send messages using a user supplied pojo interface
> -----------------------------------------------------------
>
>                 Key: CAMEL-4565
>                 URL: https://issues.apache.org/jira/browse/CAMEL-4565
>             Project: Camel
>          Issue Type: Improvement
>            Reporter: Christian Schneider
>
> The basic requirement is that we want to send a user defined object to a =
camel endpoint. The user code for sending the object should not contain any=
 camel code.
> So imagine a simple DTO like Person with properties name and age. I would=
 like to use an interface like
> interface PersonSender {
>   void send(Person person);
> }
> So in the use code I code get an implementation injected that I simply co=
uld call with=20
> sender.send(person);
> So this is quite similar to our Pojo Messaging @Produce but I don=C2=B4t =
want to send a BeanInvocation. Instead I would like to just have the Person=
 object in the body. Ideally this should also support request / response if=
 there is a return type.
> Additionally it should be configurable if it should send aynschronously o=
r synchronously.
> Optionally we may also support a handler or Future for the response.
> To get the interface implementation we should support up to three variant=
s.
> 1) Create the dynamic proxy programmatically
> 2) Define the proxy thiough a spring bean
> 3) Create and inject the proxy using the @Produce annotation (we will nee=
d a flag to switch behaviour or use a second annotation)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira