Hi,
On Thu, Mar 11, 2010 at 9:22 AM, Claus Ibsen <[email protected]> wrote:
> Now you change subject to sending an mail using camel-mail, and by
> which you want to send it as a javax.mail.MimeMessage.
> Is this correct?
sorry, no I need to consume an email and the camel-mail test cases are
what I'm using as a starting point to understand how to do this. I
apologize for not being clearer about this.
In testing the MimeMessage will be constructed programatically and
then I need some way of sending it to my processor (I guess using
direct:start and ProducerTemplate but again stand to be corrected)
In production the MimeMessage will be consumed via camel-mail from a
pop3 (I think) mailbox
I try to have a camel integration test using
resultEndpoint.expectedBodiesRecieved etc and a unit test which just
exercises the method. This allows me to test the snippet of routing
associated with the change as well as the method
ie:
@Test
public void testMailIntegration() throws Exception {
// camel stuff here
}
@Test
public void testMail() throws Exception {
// pure pojo testing here
}
This may be why my previous email was a little confused. I still
think that in both cases the body of the exchange should be a
MimeMessage as that is what should come out of the pop3 mailbox? It's
how this is interacts with camel exchanges I don't quite get. Reading
MailMessage in camel-mail source I understand how a camel message can
contain attachments and then how this would fit with some of the
suggestions so far
>
> If so why dont you just try to see if it works.
> template.send("smtp:xxx", myMimeMessage);
>
> I haven't checked the source code of camel-mail, but it could be very
> well that it can detect the MimeMessage type and use it as is.
>
>
>
> On Thu, Mar 11, 2010 at 10:16 AM, Kevin Jackson <[email protected]> wrote:
>> Hi,
>>
>>>> public void process(Exchange ex) throws Exception {
>>>> Map<String, DataHandler> attachments = ex.getIn().getAttachments();
>>>> if(attachments.size() > 0) {
>>>> //loop here but really only expect a single attachment
>>>> for(String name : attachments.keySet()) {
>>>> DataHandler dh = attachments.get(name);
>>>>
>>>> String filename = dh.getName();
>>>> byte[] data =
>>>> ex.getContext().getTypeConverter().convertTo(byte[].class,
>>>> dh.getInputStream());
>>>> FileOutputStream fos = new
>>>> FileOutputStream(getAttachmentPath()+filename);
>>>> fos.write(data);
>>>> fos.flush();
>>>> fos.close();
>>>> }
>>>> }
>>>> }
>>>>
>>> The bean parameter binding is what you would normally use to decouple
>>> a POJO from Camel Exchange.
>>> http://camel.apache.org/bean-binding.html
>>> http://camel.apache.org/parameter-binding-annotations.html
>>>
>>>
>>> But I can see it lacks a feature to binding attachements, so you can
>>> do something like
>>>
>>> public void foo(@Attachments Map<String, DataHandler> myAttachments) {
>>> ..
>>> }
>>>
>>> But it could probably also be done without the @Attachments annotation
>>> as it can detect the types in the Map and see if its <String,
>>> DataHandler> and then map that automatic to the attachments of the
>>> Exchange. Anyone see a problem with this?
>>
>> I'm not sure I follow you here.
>>
>> I can use bean-binding annotations to mark a method in my pojo as a
>> @Handler method, does this negate the need to use the marker interface
>> Processor?
>>
>> The method signature suggests that the POJO would process Map<String
>> DataHandler>, this would mean that some pre-processing would be
>> required upstream to take the mime message and convert it into this
>> format?
>>
>> If this is the case, then my route would become something like :
>>
>> from("direct:start").bean(MailProc.class).to("mock:result"), where MailProc
>> is :
>>
>> @Handler
>> public void proc(Map<String, DataHandler> attachments) throws Exception {
>>
>> }
>>
>> But when I kick this test off, I want to be using a programatically
>> created MimeMessage, so will that get converted from MimeMessage into
>> Map<String, DataHandler> attachments automatically due it being the
>> body of the Exchange?
>>
>> In the camel mail unit tests:
>>
>> @Test
>> public void testSendAndRecieveMailWithAttachments() throws Exception {
>> // START SNIPPET: e1
>>
>> // create an exchange with a normal body and attachment to be
>> produced as email
>> Endpoint endpoint =
>> context.getEndpoint("smtp://[email protected]?password=secret");
>>
>> // create the exchange with the mail message that is multipart
>> with a file and a Hello World text/plain message.
>> Exchange exchange = endpoint.createExchange();
>> Message in = exchange.getIn();
>> in.setBody("Hello World");
>> in.addAttachment("logo.jpeg", new DataHandler(new
>> FileDataSource("src/test/data/logo.jpeg")));
>>
>> // create a producer that can produce the exchange (= send the mail)
>> Producer producer = endpoint.createProducer();
>> // start the producer
>> producer.start();
>> // and let it go (processes the exchange by sending the email)
>> producer.process(exchange);
>>
>> // END SNIPPET: e1
>>
>> // need some time for the mail to arrive on the inbox
>> (consumed and sent to the mock)
>> Thread.sleep(2000);
>>
>> MockEndpoint mock = getMockEndpoint("mock:result");
>> mock.expectedMessageCount(1);
>> Exchange out = mock.assertExchangeReceived(0);
>> mock.assertIsSatisfied();
>>
>> // plain text
>> assertEquals("Hello World", out.getIn().getBody(String.class));
>>
>> // attachment
>> Map<String, DataHandler> attachments = out.getIn().getAttachments();
>> assertNotNull("Should have attachments", attachments);
>> assertEquals(1, attachments.size());
>>
>> DataHandler handler = out.getIn().getAttachment("logo.jpeg");
>> assertNotNull("The logo should be there", handler);
>>
>> assertEquals("image/jpeg; name=logo.jpeg", handler.getContentType());
>>
>> producer.stop();
>> }
>>
>> This relies on Camel test classes and I would just like to be able to
>> create a new MimeMessage and use direct:start to
>> template.sendBody(attachmentEmail) rather than rely on manually
>> creating Exchanges etc
>>
>> Sorry to bother you but this is an interesting investigation from my side
>> Kev
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
