camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: Split using tokenize on header
Date Mon, 11 May 2009 04:12:23 GMT
On Mon, May 11, 2009 at 2:34 AM, Willem Jiang <willem.jiang@gmail.com> wrote:
> How about return a List<Message> from the POJO bean method?
> Then we can check the List Object in the Splitter's
> createProcessorExchangePairsList() and
> createProcessorExchangePairsIterable(), if the object in the list is
> Message, we can set the Exchange's InMessage
> with the Message object that we get from the list.
Willem

A very good idea. Glad you thought of this solution. Very concise and clean.
And leveraging the existing Camel API.

Do you mind updating the Splitter EIP wiki page with this new feature?


>
> Willem
>
> Claus Ibsen wrote:
>> On Fri, May 8, 2009 at 3:28 PM, rohitbrai <rohitbrai@gmail.com> wrote:
>>> Can't I achieve something similar using bean in the splitter as explained in
>>> Using a "Pojo to do the splitting" on http://camel.apache.org/splitter.html
>> Yeah I have thought of that one too, but I cannot see how you should
>> be able to alter the message for each of the individual splitted new
>> message.
>> As we only return the body as result.
>>
>> And in java we cannot return 2 types, 1 for the body, 1 for the headers
>>
>> We might be able to introduce some convention and let you return some
>> object holder the body and the header.
>> List<BodyAndHeaderHolder>
>>
>> But then I might get a bit ugly?
>>
>> Any thoughts?
>>
>>
>>
>>
>>> I was trying to understand the code, but am wondering how will I get back
>>> the whole message. The example there sends a arraylist of string, but I
>>> would want messages with the existing headers intact.
>>>
>>> Another solution I am thinking of is making the message a object and not a
>>> string and passing the to address string as part of it.
>> Yeah that works perfect. Or you can temporary return the To header in
>> the 1st line of the body response
>> and then fix it in a POJO afterwards
>>
>> from(x).split(MySplitterBean).bean(MyFixUpBean.class).to(z)
>>
>> And in your MyFixUpBean
>> you read the first line of the Body and set it back as To header
>> and remove it from the body.
>>
>>
>>
>>> I am making a reliable mass mailing solution with spam control based on
>>> ActiveMQ and camel, is it the right approach?
>> Yeah I see why not. However I have not personally build spam
>> protection software.
>>
>>
>>>
>>>
>>> Claus Ibsen-2 wrote:
>>>> On Fri, May 8, 2009 at 2:58 PM, rohitbrai <rohitbrai@gmail.com> wrote:
>>>>> I have a message which has -
>>>>> Header
>>>>>    "To" - "abc@sdf.com,xyz@dsfsdf.com,sdaf@serr.com"
>>>>> Body
>>>>>    Hello
>>>>>
>>>>> onthis message I tried -
>>>>>
>>>>> from("jms:queue:new.test1").splitter(header("To").tokenize(",")).to("jms:queue:new.test2");
>>>>>
>>>>> and I was expecting 3 entries on test2 queue
>>>>> Header
>>>>>    "To" - "abc@sdf.com"
>>>>> Body
>>>>>    Hello
>>>>>
>>>>> Header
>>>>>    "To" - "xyz@dsfsdf.com"
>>>>> Body
>>>>>    Hello
>>>>>
>>>>> Header
>>>>>    "To" - "sdaf@serr.com"
>>>>> Body
>>>>>    Hello
>>>>>
>>>>>
>>>>> But instead I got 3 messages on test2 queue like
>>>>> Header
>>>>>    "To" - "abc@sdf.com,xyz@dsfsdf.com,sdaf@serr.com"
>>>>> Body
>>>>>    abc@sdf.com
>>>>>
>>>>> Header
>>>>>    "To" - "abc@sdf.com,xyz@dsfsdf.com,sdaf@serr.com"
>>>>> Body
>>>>>    xyz@dsfsdf.com
>>>>>
>>>>> Header
>>>>>    "To" - "abc@sdf.com,xyz@dsfsdf.com,sdaf@serr.com"
>>>>> Body
>>>>>    sdaf@serr.com
>>>>>
>>>>> So I guess, I am doing it and even understanding it wrong.
>>>>>
>>>>> Can anyone here guide me how to handle this situation.
>>>> Hi
>>>>
>>>> Welcome on the Camel ride.
>>>>
>>>> The EIP patterns is about message routing where the message relies in
>>>> the BODY payload.
>>>> The header is just meta data about the message.
>>>>
>>>> So the splitter operates on splitting the BODY and not the headers,
>>>> hence why you get the email address in the body.
>>>>
>>>> So by default there EIP patterns dont really support your use case out
>>>> of the box, unless you do some manual fixup in Java code.
>>>>
>>>> You could use a POJO or the like where you create new messages to send
>>>> along.
>>>>
>>>> private ProducerTemplate producer
>>>>
>>>> public void sendSplittedMessages(String body, @Headers Map headers) {
>>>>   // loop the headers for each email adr
>>>>   for (...) {
>>>>      String email = ...
>>>>      producer.sendBodyAndHeader("jms:queue:new:test02", body, "To",
>>>> email);
>>>>    }
>>>>
>>>> And then have a route that is like
>>>> from("jms:queue:new.test1").bean(MySplitMessageClass.class,
>>>> "sendSplittedMessages");
>>>>
>>>> where we route to our bean that, will do the "split" manually and send
>>>> a new message to the JMS queue.
>>>>
>>>>
>>>>> Thanks and Regards,
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Split-using-tokenize-on-header-tp23445496p23445496.html
>>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> Apache Camel Committer
>>>>
>>>> Open Source Integration: http://fusesource.com
>>>> Blog: http://davsclaus.blogspot.com/
>>>> Twitter: http://twitter.com/davsclaus
>>>> Apache Camel Reference Card:
>>>> http://refcardz.dzone.com/refcardz/enterprise-integration
>>>> Interview with me:
>>>> http://architects.dzone.com/articles/interview-claus-ibsen-about?mz=7893-progress
>>>>
>>>>
>>> --
>>> View this message in context: http://www.nabble.com/Split-using-tokenize-on-header-tp23445496p23445999.html
>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
>
>



-- 
Claus Ibsen
Apache Camel Committer

Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Apache Camel Reference Card:
http://refcardz.dzone.com/refcardz/enterprise-integration
Interview with me:
http://architects.dzone.com/articles/interview-claus-ibsen-about?mz=7893-progress

Mime
View raw message