[
https://issues.apache.org/jira/browse/CAMEL-3468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976624#action_12976624
]
Claus Ibsen edited comment on CAMEL-3468 at 1/3/11 1:18 AM:
------------------------------------------------------------
Code review
==========
1)
Prefer to throw IllegalArgumentException instead of CamelException for invalid
configuration.
eg: throw new CamelException("Queue name not specified.");
2)
There is a <a/> in the javadoc of SqsConfiguration
3)
Why do you use Integer and not int for the properties in SqsConfiguration? You
use boolean. Maybe use Boolean so they are all non primitive types, or use int,
so they are all primitive.
4)
The consumer is scheduled poll based - and it polls X number of messages. Maybe
it can be a {{BatchConsumer}} as well?
See the camel-mail component for an example.
5)
The logic to delete message after read in the consumer, should preferred to be
in a on completion. This ensures it works well with the asynchronous routing
engine. See MailConsumer for an example.
6)
Prefer to use {{handleException(e);}} instead of logging exceptions which was
thrown. This allows to re-use logic to handle this. See MailConsumer for
example.
7)
In the producer you don't propagate headers if its a InOut MEP, in the
getMessageForResponse method. You most likely want to copy the headers from the
IN message to OUT to preserve those. If you dont do this, then end users will
suffer from the "where the f*** is my headers." issue.
was (Author: davsclaus):
Code review
==========
1)
Prefer to throw IllegalArgumentException instead of CamelException for invalid
configuration.
eg: throw new CamelException("Queue name not specified.");
2)
There is a <a/> in the javadoc of SqsConfiguration
3)
Why do you use Integer and not int for the properties in SqsConfiguration? You
use boolean. Maybe use Boolean so they are all non primitive types, or use int,
so they are all primitive.
4)
The consumer is scheduled poll based? And it polls X number of messages. Maybe
it can be a {{BatchConsumer}} as well?
See the camel-mail component for an example.
5)
The logic to delete message after read in the consumer, should preferred to be
in a on completion. This ensures it works well with the asynchronous routing
engine. See MailConsumer for an example.
6)
Prefer to use {{handleException(e);}} instead of logging exceptions which was
thrown. This allows to re-use logic to handle this. See MailConsumer for
example.
7)
In the producer you don't propagate headers if its a InOut MEP, in the
getMessageForResponse method. You most likely want to copy the headers from the
IN message to OUT to preserve those. If you dont do this, then end users will
suffer from the "where the f*** is my headers." issue.
> New camel-aws component
> -----------------------
>
> Key: CAMEL-3468
> URL: https://issues.apache.org/jira/browse/CAMEL-3468
> Project: Camel
> Issue Type: New Feature
> Reporter: Tracy Snell
> Assignee: Christian Müller
> Fix For: 2.7.0
>
> Attachments: CAMEL-3468.patch, patchfile.txt
>
>
> I've started a new component to interface with Amazon Web Services. This
> first pass includes just a Simple Queue Service component. Additional
> services will be added soon. I used the Amazon AWS SDK for Java to interface
> with AWS. Uses Apache 2.0 as it's license.
> Let me know if I need to change things or any thoughts/suggestions and I'll
> be glad to make the adjustments.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
