camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raul Kripalani (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CAMEL-6648) Create a Fluent ProducerTemplate
Date Sun, 25 Aug 2013 23:15:51 GMT

    [ https://issues.apache.org/jira/browse/CAMEL-6648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749763#comment-13749763
] 

Raul Kripalani edited comment on CAMEL-6648 at 8/25/13 11:15 PM:
-----------------------------------------------------------------

Hi [~jhm],

I checked out the implementation and IMHO we should go for a second iteration with a slightly
different approach.

A ProducerTemplate instance is designed to be a long-term, thread-safe object: created once
in the application lifetime and reused thereon. However, if I understood properly, this implementation
relies on creating a new ProducerTemplate for each Exchange sent, which may cause unnecessary
overhead.

Rather than creating a builder pattern for the ProducerTemplate (PT), I'd rather us focus
on providing "fluency" for creating and dispatching new interactions around an existing PT:


- New FluentProducerTemplate class which wraps a ProducerTemplate inside.
- The implementation is stateless => the newExchange() method is a factory for new FluentProducerTemplateInteractionBuilder
objects extending ExchangeBuilder. The state is maintained in this separate object.
- asyncStyle, dispatchInOut, dispatchInOnly, etc. methods conclude the building by invoking
the appropriate send/request/sendAsync methods in the wrapped PT, passing in the generated
Exchange.

What do you think? I already started working on this, but please do let me know if you'd like
to give it a go yourself.

Regards,
Raúl.
                
      was (Author: raulvk):
    Hi [~jhm],

I checked out the implementation and IMHO we should go for a second iteration with a slightly
different approach.

A ProducerTemplate instance is designed to be a long-term, thread-safe object: created once
in the application lifetime and reused thereon. However, if I understood properly, this implementation
relies on creating a new ProducerTemplate for each Exchange sent, which may cause unnecessary
overhead.

Rather than creating a builder pattern for the ProducerTemplate (PT), I'd rather us focus
on providing "fluency" for creating and dispatching new interactions around an existing PT:


- New FluentProducerTemplate class which wraps a ProducerTemplate inside.
- The implementation is stateless => the newExchange() method returns a new FluentProducerTemplateInteractionBuilder
object extending ExchangeBuilder. 
- asyncStyle, dispatchInOut, dispatchInOnly, etc. methods invoke the appropriate send/request/sendAsync
methods in the wrapped PT.

What do you think? I already started working on this, but please do let me know if you'd like
to give it a go yourself.

Regards,
Raúl.
                  
> Create a Fluent ProducerTemplate
> --------------------------------
>
>                 Key: CAMEL-6648
>                 URL: https://issues.apache.org/jira/browse/CAMEL-6648
>             Project: Camel
>          Issue Type: New Feature
>          Components: camel-core
>            Reporter: Raul Kripalani
>            Assignee: Raul Kripalani
>         Attachments: ProducerTemplateBuilder.java, ProducerTemplateBuilderTest.java
>
>
> Create a Fluent ProducerTemplate so that users can use it in the following manner:
> \\
> \\
> {code}
> // initialize ProducerTemplate with a default endpoint
> FluentProducerTemplate template = new FluentProducerTemplate("activemq:queue:foo"); 
> MyResponse response = 
>     template.newExchange().toDefaultEndpoint()
>             .withBody("this is slick")
>             .withHeader("MyHeader1", "HeaderValue")
>             .withHeader("MyHeader2", "HeaderValue2")
>             .resultAs(MyResponse.class)
>             .dispatchInOut();                 // or inOnly(), asyncInOut()
> {code}
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message