[jira] [Resolved] (CAMEL-6826) Use Mock Objects Instead of Live HazelcastInstances to Speed Up Testing
[ https://issues.apache.org/jira/browse/CAMEL-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman resolved CAMEL-6826. - Resolution: Fixed > Use Mock Objects Instead of Live HazelcastInstances to Speed Up Testing > --- > > Key: CAMEL-6826 > URL: https://issues.apache.org/jira/browse/CAMEL-6826 > Project: Camel > Issue Type: Improvement > Components: camel-hazelcast >Reporter: James Carman >Assignee: James Carman > > The unit tests for the camel-hazelcast component use real HazelcastInstance > objects, which is very slow. We should use mock objects instead to speed up > testing. Testing the integration can be done with a few, select tests, but > the majority of the logic can be tested with mocks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CAMEL-6826) Use Mock Objects Instead of Live HazelcastInstances to Speed Up Testing
[ https://issues.apache.org/jira/browse/CAMEL-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman reopened CAMEL-6826: - Assignee: James Carman > Use Mock Objects Instead of Live HazelcastInstances to Speed Up Testing > --- > > Key: CAMEL-6826 > URL: https://issues.apache.org/jira/browse/CAMEL-6826 > Project: Camel > Issue Type: Improvement > Components: camel-hazelcast >Reporter: James Carman >Assignee: James Carman > > The unit tests for the camel-hazelcast component use real HazelcastInstance > objects, which is very slow. We should use mock objects instead to speed up > testing. Testing the integration can be done with a few, select tests, but > the majority of the logic can be tested with mocks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CAMEL-6826) Use Mock Objects Instead of Live HazelcastInstances to Speed Up Testing
[ https://issues.apache.org/jira/browse/CAMEL-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman closed CAMEL-6826. --- Estimated Complexity: Moderate (was: Unknown) > Use Mock Objects Instead of Live HazelcastInstances to Speed Up Testing > --- > > Key: CAMEL-6826 > URL: https://issues.apache.org/jira/browse/CAMEL-6826 > Project: Camel > Issue Type: Improvement > Components: camel-hazelcast >Reporter: James Carman >Assignee: James Carman > > The unit tests for the camel-hazelcast component use real HazelcastInstance > objects, which is very slow. We should use mock objects instead to speed up > testing. Testing the integration can be done with a few, select tests, but > the majority of the logic can be tested with mocks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-6826) Use Mock Objects Instead of Live HazelcastInstances to Speed Up Testing
[ https://issues.apache.org/jira/browse/CAMEL-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14623512#comment-14623512 ] James Carman commented on CAMEL-6826: - You mean it's fast enough after the changes made? Sorry didn't realize this was the one with work already done. If we like how it works now, I'm cool with closing this, but it should be marked as "fixed" since something was actually done. > Use Mock Objects Instead of Live HazelcastInstances to Speed Up Testing > --- > > Key: CAMEL-6826 > URL: https://issues.apache.org/jira/browse/CAMEL-6826 > Project: Camel > Issue Type: Improvement > Components: camel-hazelcast >Reporter: James Carman > > The unit tests for the camel-hazelcast component use real HazelcastInstance > objects, which is very slow. We should use mock objects instead to speed up > testing. Testing the integration can be done with a few, select tests, but > the majority of the logic can be tested with mocks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-6826) Use Mock Objects Instead of Live HazelcastInstances to Speed Up Testing
[ https://issues.apache.org/jira/browse/CAMEL-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14623511#comment-14623511 ] James Carman commented on CAMEL-6826: - So you are the sole person who can make this determination? > Use Mock Objects Instead of Live HazelcastInstances to Speed Up Testing > --- > > Key: CAMEL-6826 > URL: https://issues.apache.org/jira/browse/CAMEL-6826 > Project: Camel > Issue Type: Improvement > Components: camel-hazelcast >Reporter: James Carman > > The unit tests for the camel-hazelcast component use real HazelcastInstance > objects, which is very slow. We should use mock objects instead to speed up > testing. Testing the integration can be done with a few, select tests, but > the majority of the logic can be tested with mocks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7023) Add hawtio goal to camel plugin
[ https://issues.apache.org/jira/browse/CAMEL-7023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837989#comment-13837989 ] James Carman commented on CAMEL-7023: - That's "James Carman", btw. :) > Add hawtio goal to camel plugin > --- > > Key: CAMEL-7023 > URL: https://issues.apache.org/jira/browse/CAMEL-7023 > Project: Camel > Issue Type: New Feature > Components: tooling >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.12.3, 2.13.0 > > Attachments: Screen Shot 2013-11-30 at 11.10.54.png, > camel-routes.png, camel-tree.png > > > This allows end users to start Camel applications and examples as they would > do with mvn camel:run, but using mvn camel:hawtio instead, it also bootup the > hawtio web console. > This allows end users to use the console to see what happens, visualize the > Camel routes, debug the routes, profile the routes, and whatnot. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CAMEL-6927) Bean Transformer throwing org.apache.camel.TypeConversionException: Error during type conversion from type: due argument type mismatch
[
https://issues.apache.org/jira/browse/CAMEL-6927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815065#comment-13815065
]
James Carman commented on CAMEL-6927:
-
Thanks for closing, Sree. I haven't had time to dig in to see why this works,
yet. If I get a chance, I'll put a comment on here.
> Bean Transformer throwing org.apache.camel.TypeConversionException: Error
> during type conversion from type: due argument type mismatch
> --
>
> Key: CAMEL-6927
> URL: https://issues.apache.org/jira/browse/CAMEL-6927
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.9.3, 2.9.4, 2.9.5, 2.10.0, 2.10.1, 2.10.2, 2.10.3,
> 2.10.4, 2.10.5, 2.10.6, 2.10.7, 2.11.2
> Environment: Windows 7
>Reporter: Sree Panchajanyam D
>Assignee: James Carman
>Priority: Blocker
> Labels: features
> Attachments: EventToPayloadExtracter.java, StackTrace.txt
>
>
> Same piece of camel.xml and POJO working in camel 2.9.2.
> Issue encountered in camel 2.9.3 and all above versions.
> When trying to start apache camel embedded inside activemq (or camel starting
> as standalone on Jetty container), I encountered the following exception :
> Caused by: org.apache.camel.TypeConversionException: Error during type
> conversion from type: com.messagetransformers.StringAppenderBean to the
> required type: org.apache.camel.Processor with value
> com.messagetransformers.StringAppenderBean@77b407 due argument type mismatch
>at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:126)
>at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:98)
>at
> org.apache.camel.util.CamelContextHelper.convertTo(CamelContextHelper.java:72)
> Extract from my camel.xml
> class="com.messagetransformers.StringAppenderBean"/>
> http://camel.apache.org/schema/spring";>
>
> Transformer Route
>
>
>
>
>
> Code snippet from that is causing this issue
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.java(doConvertTo
> method)
> Object rc;
> if (tryConvert) {
> rc = tc.tryConvertTo(type, exchange, value);
> } else {
> rc = tc.convertTo(type, exchange, value);
> }
> The else part is not there in Camel 2.9.2 and is introduced from Camel 2.9.3.
> This code seems to force a normal bean to register as a
> FallbackTypeConverter which is causing the issue.
> Removing the else condition from camel 2.10.3 solved the issue.
> My question is, is it expected that normal bean definitions should fail from
> upwards of camel 2.9.3? Documentation seems to say nothing about it. Please
> help
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (CAMEL-6927) Bean Transformer throwing org.apache.camel.TypeConversionException: Error during type conversion from type: due argument type mismatch
[
https://issues.apache.org/jira/browse/CAMEL-6927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman resolved CAMEL-6927.
-
Resolution: Not A Problem
Looks like the user was unknowingly capitalizing on a bug in the oder code.
The user has fixed the issue on their end.
> Bean Transformer throwing org.apache.camel.TypeConversionException: Error
> during type conversion from type: due argument type mismatch
> --
>
> Key: CAMEL-6927
> URL: https://issues.apache.org/jira/browse/CAMEL-6927
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.9.3, 2.9.4, 2.9.5, 2.10.0, 2.10.1, 2.10.2, 2.10.3,
> 2.10.4, 2.10.5, 2.10.6, 2.10.7, 2.11.2
> Environment: Windows 7
>Reporter: Sree Panchajanyam D
>Assignee: James Carman
>Priority: Blocker
> Labels: features
> Attachments: EventToPayloadExtracter.java, StackTrace.txt
>
>
> Same piece of camel.xml and POJO working in camel 2.9.2.
> Issue encountered in camel 2.9.3 and all above versions.
> When trying to start apache camel embedded inside activemq (or camel starting
> as standalone on Jetty container), I encountered the following exception :
> Caused by: org.apache.camel.TypeConversionException: Error during type
> conversion from type: com.messagetransformers.StringAppenderBean to the
> required type: org.apache.camel.Processor with value
> com.messagetransformers.StringAppenderBean@77b407 due argument type mismatch
>at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:126)
>at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:98)
>at
> org.apache.camel.util.CamelContextHelper.convertTo(CamelContextHelper.java:72)
> Extract from my camel.xml
> class="com.messagetransformers.StringAppenderBean"/>
> http://camel.apache.org/schema/spring";>
>
> Transformer Route
>
>
>
>
>
> Code snippet from that is causing this issue
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.java(doConvertTo
> method)
> Object rc;
> if (tryConvert) {
> rc = tc.tryConvertTo(type, exchange, value);
> } else {
> rc = tc.convertTo(type, exchange, value);
> }
> The else part is not there in Camel 2.9.2 and is introduced from Camel 2.9.3.
> This code seems to force a normal bean to register as a
> FallbackTypeConverter which is causing the issue.
> Removing the else condition from camel 2.10.3 solved the issue.
> My question is, is it expected that normal bean definitions should fail from
> upwards of camel 2.9.3? Documentation seems to say nothing about it. Please
> help
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CAMEL-6927) Bean Transformer throwing org.apache.camel.TypeConversionException: Error during type conversion from type: due argument type mismatch
[
https://issues.apache.org/jira/browse/CAMEL-6927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13812874#comment-13812874
]
James Carman commented on CAMEL-6927:
-
Event is your class, right?
> Bean Transformer throwing org.apache.camel.TypeConversionException: Error
> during type conversion from type: due argument type mismatch
> --
>
> Key: CAMEL-6927
> URL: https://issues.apache.org/jira/browse/CAMEL-6927
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.9.3, 2.9.4, 2.9.5, 2.10.0, 2.10.1, 2.10.2, 2.10.3,
> 2.10.4, 2.10.5, 2.10.6, 2.10.7, 2.11.2
> Environment: Windows 7
>Reporter: Sree Panchajanyam D
>Assignee: James Carman
>Priority: Blocker
> Labels: features
> Attachments: EventToPayloadExtracter.java, StackTrace.txt
>
>
> Same piece of camel.xml and POJO working in camel 2.9.2.
> Issue encountered in camel 2.9.3 and all above versions.
> When trying to start apache camel embedded inside activemq (or camel starting
> as standalone on Jetty container), I encountered the following exception :
> Caused by: org.apache.camel.TypeConversionException: Error during type
> conversion from type: com.messagetransformers.StringAppenderBean to the
> required type: org.apache.camel.Processor with value
> com.messagetransformers.StringAppenderBean@77b407 due argument type mismatch
>at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:126)
>at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:98)
>at
> org.apache.camel.util.CamelContextHelper.convertTo(CamelContextHelper.java:72)
> Extract from my camel.xml
> class="com.messagetransformers.StringAppenderBean"/>
> http://camel.apache.org/schema/spring";>
>
> Transformer Route
>
>
>
>
>
> Code snippet from that is causing this issue
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.java(doConvertTo
> method)
> Object rc;
> if (tryConvert) {
> rc = tc.tryConvertTo(type, exchange, value);
> } else {
> rc = tc.convertTo(type, exchange, value);
> }
> The else part is not there in Camel 2.9.2 and is introduced from Camel 2.9.3.
> This code seems to force a normal bean to register as a
> FallbackTypeConverter which is causing the issue.
> Removing the else condition from camel 2.10.3 solved the issue.
> My question is, is it expected that normal bean definitions should fail from
> upwards of camel 2.9.3? Documentation seems to say nothing about it. Please
> help
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (CAMEL-6927) Bean Transformer throwing org.apache.camel.TypeConversionException: Error during type conversion from type: due argument type mismatch
[
https://issues.apache.org/jira/browse/CAMEL-6927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13812874#comment-13812874
]
James Carman edited comment on CAMEL-6927 at 11/4/13 2:52 PM:
--
Event is your class, right?
According to the documentation here:
http://camel.apache.org/type-converter.html
The method signature should be:
{code}
public static T convertTo(Class type, Exchange exchange, Object value,
TypeConverterRegistry registry);
{code}
So, using Event as the parameter type wasn't supposed to work (would have to
dig to find out why it did), necessarily in the first place. You'll probably
need to do an instanceof or isAssignableFrom check on the parameter in order to
implement your @FallbackConverter method. Hope that helps.
was (Author: jwcarman):
Event is your class, right?
According to the documentation here:
http://camel.apache.org/type-converter.html
The method signature should be:
public static T convertTo(Class type, Exchange exchange, Object value,
TypeConverterRegistry registry);
So, using Event as the parameter type wasn't supposed to work (would have to
dig to find out why it did), necessarily in the first place. You'll probably
need to do an instanceof or isAssignableFrom check on the parameter in order to
implement your @FallbackConverter method. Hope that helps.
> Bean Transformer throwing org.apache.camel.TypeConversionException: Error
> during type conversion from type: due argument type mismatch
> --
>
> Key: CAMEL-6927
> URL: https://issues.apache.org/jira/browse/CAMEL-6927
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.9.3, 2.9.4, 2.9.5, 2.10.0, 2.10.1, 2.10.2, 2.10.3,
> 2.10.4, 2.10.5, 2.10.6, 2.10.7, 2.11.2
> Environment: Windows 7
>Reporter: Sree Panchajanyam D
>Assignee: James Carman
>Priority: Blocker
> Labels: features
> Attachments: EventToPayloadExtracter.java, StackTrace.txt
>
>
> Same piece of camel.xml and POJO working in camel 2.9.2.
> Issue encountered in camel 2.9.3 and all above versions.
> When trying to start apache camel embedded inside activemq (or camel starting
> as standalone on Jetty container), I encountered the following exception :
> Caused by: org.apache.camel.TypeConversionException: Error during type
> conversion from type: com.messagetransformers.StringAppenderBean to the
> required type: org.apache.camel.Processor with value
> com.messagetransformers.StringAppenderBean@77b407 due argument type mismatch
>at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:126)
>at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:98)
>at
> org.apache.camel.util.CamelContextHelper.convertTo(CamelContextHelper.java:72)
> Extract from my camel.xml
> class="com.messagetransformers.StringAppenderBean"/>
> http://camel.apache.org/schema/spring";>
>
> Transformer Route
>
>
>
>
>
> Code snippet from that is causing this issue
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.java(doConvertTo
> method)
> Object rc;
> if (tryConvert) {
> rc = tc.tryConvertTo(type, exchange, value);
> } else {
> rc = tc.convertTo(type, exchange, value);
> }
> The else part is not there in Camel 2.9.2 and is introduced from Camel 2.9.3.
> This code seems to force a normal bean to register as a
> FallbackTypeConverter which is causing the issue.
> Removing the else condition from camel 2.10.3 solved the issue.
> My question is, is it expected that normal bean definitions should fail from
> upwards of camel 2.9.3? Documentation seems to say nothing about it. Please
> help
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (CAMEL-6927) Bean Transformer throwing org.apache.camel.TypeConversionException: Error during type conversion from type: due argument type mismatch
[
https://issues.apache.org/jira/browse/CAMEL-6927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13812874#comment-13812874
]
James Carman edited comment on CAMEL-6927 at 11/4/13 2:52 PM:
--
Event is your class, right?
According to the documentation here:
http://camel.apache.org/type-converter.html
The method signature should be:
public static T convertTo(Class type, Exchange exchange, Object value,
TypeConverterRegistry registry);
So, using Event as the parameter type wasn't supposed to work (would have to
dig to find out why it did), necessarily in the first place. You'll probably
need to do an instanceof or isAssignableFrom check on the parameter in order to
implement your @FallbackConverter method. Hope that helps.
was (Author: jwcarman):
Event is your class, right?
> Bean Transformer throwing org.apache.camel.TypeConversionException: Error
> during type conversion from type: due argument type mismatch
> --
>
> Key: CAMEL-6927
> URL: https://issues.apache.org/jira/browse/CAMEL-6927
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.9.3, 2.9.4, 2.9.5, 2.10.0, 2.10.1, 2.10.2, 2.10.3,
> 2.10.4, 2.10.5, 2.10.6, 2.10.7, 2.11.2
> Environment: Windows 7
>Reporter: Sree Panchajanyam D
>Assignee: James Carman
>Priority: Blocker
> Labels: features
> Attachments: EventToPayloadExtracter.java, StackTrace.txt
>
>
> Same piece of camel.xml and POJO working in camel 2.9.2.
> Issue encountered in camel 2.9.3 and all above versions.
> When trying to start apache camel embedded inside activemq (or camel starting
> as standalone on Jetty container), I encountered the following exception :
> Caused by: org.apache.camel.TypeConversionException: Error during type
> conversion from type: com.messagetransformers.StringAppenderBean to the
> required type: org.apache.camel.Processor with value
> com.messagetransformers.StringAppenderBean@77b407 due argument type mismatch
>at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:126)
>at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:98)
>at
> org.apache.camel.util.CamelContextHelper.convertTo(CamelContextHelper.java:72)
> Extract from my camel.xml
> class="com.messagetransformers.StringAppenderBean"/>
> http://camel.apache.org/schema/spring";>
>
> Transformer Route
>
>
>
>
>
> Code snippet from that is causing this issue
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.java(doConvertTo
> method)
> Object rc;
> if (tryConvert) {
> rc = tc.tryConvertTo(type, exchange, value);
> } else {
> rc = tc.convertTo(type, exchange, value);
> }
> The else part is not there in Camel 2.9.2 and is introduced from Camel 2.9.3.
> This code seems to force a normal bean to register as a
> FallbackTypeConverter which is causing the issue.
> Removing the else condition from camel 2.10.3 solved the issue.
> My question is, is it expected that normal bean definitions should fail from
> upwards of camel 2.9.3? Documentation seems to say nothing about it. Please
> help
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Assigned] (CAMEL-6927) Bean Transformer throwing org.apache.camel.TypeConversionException: Error during type conversion from type: due argument type mismatch
[
https://issues.apache.org/jira/browse/CAMEL-6927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman reassigned CAMEL-6927:
---
Assignee: James Carman
> Bean Transformer throwing org.apache.camel.TypeConversionException: Error
> during type conversion from type: due argument type mismatch
> --
>
> Key: CAMEL-6927
> URL: https://issues.apache.org/jira/browse/CAMEL-6927
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.9.3, 2.9.4, 2.9.5, 2.10.0, 2.10.1, 2.10.2, 2.10.3,
> 2.10.4, 2.10.5, 2.10.6, 2.10.7, 2.11.2
> Environment: Windows 7
>Reporter: Sree Panchajanyam D
>Assignee: James Carman
>Priority: Blocker
> Labels: features
> Attachments: EventToPayloadExtracter.java, StackTrace.txt
>
>
> Same piece of camel.xml and POJO working in camel 2.9.2.
> Issue encountered in camel 2.9.3 and all above versions.
> When trying to start apache camel embedded inside activemq (or camel starting
> as standalone on Jetty container), I encountered the following exception :
> Caused by: org.apache.camel.TypeConversionException: Error during type
> conversion from type: com.messagetransformers.StringAppenderBean to the
> required type: org.apache.camel.Processor with value
> com.messagetransformers.StringAppenderBean@77b407 due argument type mismatch
>at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:126)
>at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:98)
>at
> org.apache.camel.util.CamelContextHelper.convertTo(CamelContextHelper.java:72)
> Extract from my camel.xml
> class="com.messagetransformers.StringAppenderBean"/>
> http://camel.apache.org/schema/spring";>
>
> Transformer Route
>
>
>
>
>
> Code snippet from that is causing this issue
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.java(doConvertTo
> method)
> Object rc;
> if (tryConvert) {
> rc = tc.tryConvertTo(type, exchange, value);
> } else {
> rc = tc.convertTo(type, exchange, value);
> }
> The else part is not there in Camel 2.9.2 and is introduced from Camel 2.9.3.
> This code seems to force a normal bean to register as a
> FallbackTypeConverter which is causing the issue.
> Removing the else condition from camel 2.10.3 solved the issue.
> My question is, is it expected that normal bean definitions should fail from
> upwards of camel 2.9.3? Documentation seems to say nothing about it. Please
> help
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CAMEL-6927) Bean Transformer throwing org.apache.camel.TypeConversionException: Error during type conversion from type: due argument type mismatch
[
https://issues.apache.org/jira/browse/CAMEL-6927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13812018#comment-13812018
]
James Carman commented on CAMEL-6927:
-
Sree, take a look at this example:
https://github.com/jwcarman/camel-sandbox/blob/master/src/test/java/com/carmanconsulting/sandbox/camel/BeanTransformTest.java
Can you get this example to illustrate the issue you're seeing?
> Bean Transformer throwing org.apache.camel.TypeConversionException: Error
> during type conversion from type: due argument type mismatch
> --
>
> Key: CAMEL-6927
> URL: https://issues.apache.org/jira/browse/CAMEL-6927
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.9.3, 2.9.4, 2.9.5, 2.10.0, 2.10.1, 2.10.2, 2.10.3,
> 2.10.4, 2.10.5, 2.10.6, 2.10.7, 2.11.2
> Environment: Windows 7
>Reporter: Sree Panchajanyam D
>Priority: Blocker
> Labels: features
> Attachments: EventToPayloadExtracter.java, StackTrace.txt
>
>
> Same piece of camel.xml and POJO working in camel 2.9.2.
> Issue encountered in camel 2.9.3 and all above versions.
> When trying to start apache camel embedded inside activemq (or camel starting
> as standalone on Jetty container), I encountered the following exception :
> Caused by: org.apache.camel.TypeConversionException: Error during type
> conversion from type: com.messagetransformers.StringAppenderBean to the
> required type: org.apache.camel.Processor with value
> com.messagetransformers.StringAppenderBean@77b407 due argument type mismatch
>at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:126)
>at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:98)
>at
> org.apache.camel.util.CamelContextHelper.convertTo(CamelContextHelper.java:72)
> Extract from my camel.xml
> class="com.messagetransformers.StringAppenderBean"/>
> http://camel.apache.org/schema/spring";>
>
> Transformer Route
>
>
>
>
>
> Code snippet from that is causing this issue
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.java(doConvertTo
> method)
> Object rc;
> if (tryConvert) {
> rc = tc.tryConvertTo(type, exchange, value);
> } else {
> rc = tc.convertTo(type, exchange, value);
> }
> The else part is not there in Camel 2.9.2 and is introduced from Camel 2.9.3.
> This code seems to force a normal bean to register as a
> FallbackTypeConverter which is causing the issue.
> Removing the else condition from camel 2.10.3 solved the issue.
> My question is, is it expected that normal bean definitions should fail from
> upwards of camel 2.9.3? Documentation seems to say nothing about it. Please
> help
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CAMEL-6927) Bean Transformer throwing org.apache.camel.TypeConversionException: Error during type conversion from type: due argument type mismatch
[
https://issues.apache.org/jira/browse/CAMEL-6927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13811642#comment-13811642
]
James Carman commented on CAMEL-6927:
-
It looks like the code in question was introduced when fixing this issue.
> Bean Transformer throwing org.apache.camel.TypeConversionException: Error
> during type conversion from type: due argument type mismatch
> --
>
> Key: CAMEL-6927
> URL: https://issues.apache.org/jira/browse/CAMEL-6927
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.9.3, 2.9.4, 2.9.5, 2.10.0, 2.10.1, 2.10.2, 2.10.3,
> 2.10.4, 2.10.5, 2.10.6, 2.10.7, 2.11.2
> Environment: Windows 7
>Reporter: Sree Panchajanyam D
>Priority: Blocker
> Labels: features
>
> Same piece of camel.xml and POJO working in camel 2.9.2.
> Issue encountered in camel 2.9.3 and all above versions.
> When trying to start apache camel embedded inside activemq (or camel starting
> as standalone on Jetty container), I encountered the following exception :
> Caused by: org.apache.camel.TypeConversionException: Error during type
> conversion from type: com.messagetransformers.StringAppenderBean to the
> required type: org.apache.camel.Processor with value
> com.messagetransformers.StringAppenderBean@77b407 due argument type mismatch
>at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:126)
>at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:98)
>at
> org.apache.camel.util.CamelContextHelper.convertTo(CamelContextHelper.java:72)
> Extract from my camel.xml
> class="com.messagetransformers.StringAppenderBean"/>
> http://camel.apache.org/schema/spring";>
>
> Transformer Route
>
>
>
>
>
> Code snippet from that is causing this issue
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.java(doConvertTo
> method)
> Object rc;
> if (tryConvert) {
> rc = tc.tryConvertTo(type, exchange, value);
> } else {
> rc = tc.convertTo(type, exchange, value);
> }
> The else part is not there in Camel 2.9.2 and is introduced from Camel 2.9.3.
> This code seems to force a normal bean to register as a
> FallbackTypeConverter which is causing the issue.
> Removing the else condition from camel 2.10.3 solved the issue.
> My question is, is it expected that normal bean definitions should fail from
> upwards of camel 2.9.3? Documentation seems to say nothing about it. Please
> help
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CAMEL-6826) Use Mock Objects Instead of Live HazelcastInstances to Speed Up Testing
[ https://issues.apache.org/jira/browse/CAMEL-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800770#comment-13800770 ] James Carman commented on CAMEL-6826: - This is still in-progress, unless you just want to start a new one for taking care of the seda tests. I believe that's all that's left. > Use Mock Objects Instead of Live HazelcastInstances to Speed Up Testing > --- > > Key: CAMEL-6826 > URL: https://issues.apache.org/jira/browse/CAMEL-6826 > Project: Camel > Issue Type: Improvement > Components: camel-hazelcast >Reporter: James Carman >Assignee: James Carman > > The unit tests for the camel-hazelcast component use real HazelcastInstance > objects, which is very slow. We should use mock objects instead to speed up > testing. Testing the integration can be done with a few, select tests, but > the majority of the logic can be tested with mocks. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CAMEL-6843) Hazelcast Map Support Uses Wrong Verb "Envict"
[ https://issues.apache.org/jira/browse/CAMEL-6843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman resolved CAMEL-6843. - Resolution: Fixed Now using new constant EVICTED. > Hazelcast Map Support Uses Wrong Verb "Envict" > -- > > Key: CAMEL-6843 > URL: https://issues.apache.org/jira/browse/CAMEL-6843 > Project: Camel > Issue Type: Bug > Components: camel-hazelcast >Reporter: James Carman >Assignee: James Carman > > The event type is "evicted" not "envicted." Our code has a constant called > HazelcastConstants.ENVICTED which has the value "envicted." We need to fix > this, but it will cause a compatibility break. We could introduce the > correct values and support both, with the incorrect ones being deprecated. > Would that work? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Work started] (CAMEL-6843) Hazelcast Map Support Uses Wrong Verb "Envict"
[ https://issues.apache.org/jira/browse/CAMEL-6843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-6843 started by James Carman. > Hazelcast Map Support Uses Wrong Verb "Envict" > -- > > Key: CAMEL-6843 > URL: https://issues.apache.org/jira/browse/CAMEL-6843 > Project: Camel > Issue Type: Bug > Components: camel-hazelcast >Reporter: James Carman >Assignee: James Carman > > The event type is "evicted" not "envicted." Our code has a constant called > HazelcastConstants.ENVICTED which has the value "envicted." We need to fix > this, but it will cause a compatibility break. We could introduce the > correct values and support both, with the incorrect ones being deprecated. > Would that work? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CAMEL-6833) Atomic Number Producer Uses Wrong Name
[ https://issues.apache.org/jira/browse/CAMEL-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated CAMEL-6833: Summary: Atomic Number Producer Uses Wrong Name (was: Atomic Number Producer Uses Wrong Cache Name) > Atomic Number Producer Uses Wrong Name > -- > > Key: CAMEL-6833 > URL: https://issues.apache.org/jira/browse/CAMEL-6833 > Project: Camel > Issue Type: Bug > Components: camel-hazelcast >Reporter: James Carman >Assignee: James Carman > Fix For: 2.13.0 > > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > When redesigning the tests to use mock objects, I noticed that the atomic > number producer actually uses the incorrect atomic number name. If you try > to update an atomic number named "foo", it actually updates one named > "ue:foo". This is because it uses the wrong constant (the one for instances) > when it picks apart the URI. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CAMEL-6826) Use Mock Objects Instead of Live HazelcastInstances to Speed Up Testing
[ https://issues.apache.org/jira/browse/CAMEL-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791141#comment-13791141 ] James Carman commented on CAMEL-6826: - Spring tests have been updated as well as the error messages tests. > Use Mock Objects Instead of Live HazelcastInstances to Speed Up Testing > --- > > Key: CAMEL-6826 > URL: https://issues.apache.org/jira/browse/CAMEL-6826 > Project: Camel > Issue Type: Improvement > Components: camel-hazelcast >Reporter: James Carman >Assignee: James Carman > > The unit tests for the camel-hazelcast component use real HazelcastInstance > objects, which is very slow. We should use mock objects instead to speed up > testing. Testing the integration can be done with a few, select tests, but > the majority of the logic can be tested with mocks. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CAMEL-4015) camel-hazelcast - Allow to specify operation in uri instead of just as a header
[
https://issues.apache.org/jira/browse/CAMEL-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman resolved CAMEL-4015.
-
Resolution: Fixed
Romain, please let us know if this addresses your need. Great suggestion! I
would also like to see the capability to specify the operation in the URI:
"hazelcast:queue:foo:put"
> camel-hazelcast - Allow to specify operation in uri instead of just as a
> header
> ---
>
> Key: CAMEL-4015
> URL: https://issues.apache.org/jira/browse/CAMEL-4015
> Project: Camel
> Issue Type: Improvement
> Components: camel-hazelcast
>Reporter: Romain Manni-Bucau
>Assignee: James Carman
>Priority: Minor
> Fix For: 2.13.0
>
>
> It could be nice to be able to specify type operation (and maybe the key for
> map) in the uri instead of headers:
> from("hazelcast:map:foo?operation=get&id=myStringId").to("log:display");
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CAMEL-4015) camel-hazelcast - Allow to specify operation in uri instead of just as a header
[
https://issues.apache.org/jira/browse/CAMEL-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman updated CAMEL-4015:
Attachment: (was: CAMEL-4015-2.patch)
> camel-hazelcast - Allow to specify operation in uri instead of just as a
> header
> ---
>
> Key: CAMEL-4015
> URL: https://issues.apache.org/jira/browse/CAMEL-4015
> Project: Camel
> Issue Type: Improvement
> Components: camel-hazelcast
>Reporter: Romain Manni-Bucau
>Assignee: James Carman
>Priority: Minor
> Fix For: 2.13.0
>
>
> It could be nice to be able to specify type operation (and maybe the key for
> map) in the uri instead of headers:
> from("hazelcast:map:foo?operation=get&id=myStringId").to("log:display");
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CAMEL-4015) camel-hazelcast - Allow to specify operation in uri instead of just as a header
[
https://issues.apache.org/jira/browse/CAMEL-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman updated CAMEL-4015:
Attachment: (was: 0001-CAMEL-4015-camel-hazelcast-uri-format.patch)
> camel-hazelcast - Allow to specify operation in uri instead of just as a
> header
> ---
>
> Key: CAMEL-4015
> URL: https://issues.apache.org/jira/browse/CAMEL-4015
> Project: Camel
> Issue Type: Improvement
> Components: camel-hazelcast
>Reporter: Romain Manni-Bucau
>Assignee: James Carman
>Priority: Minor
> Fix For: 2.13.0
>
> Attachments: CAMEL-4015-2.patch, CAMEL-4015.patch
>
>
> It could be nice to be able to specify type operation (and maybe the key for
> map) in the uri instead of headers:
> from("hazelcast:map:foo?operation=get&id=myStringId").to("log:display");
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CAMEL-4015) camel-hazelcast - Allow to specify operation in uri instead of just as a header
[
https://issues.apache.org/jira/browse/CAMEL-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman updated CAMEL-4015:
Attachment: (was: CAMEL-4015.patch)
> camel-hazelcast - Allow to specify operation in uri instead of just as a
> header
> ---
>
> Key: CAMEL-4015
> URL: https://issues.apache.org/jira/browse/CAMEL-4015
> Project: Camel
> Issue Type: Improvement
> Components: camel-hazelcast
>Reporter: Romain Manni-Bucau
>Assignee: James Carman
>Priority: Minor
> Fix For: 2.13.0
>
>
> It could be nice to be able to specify type operation (and maybe the key for
> map) in the uri instead of headers:
> from("hazelcast:map:foo?operation=get&id=myStringId").to("log:display");
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CAMEL-4596) enrich and pollEnrich should accept an expression for dynamic uris
[
https://issues.apache.org/jira/browse/CAMEL-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790317#comment-13790317
]
James Carman commented on CAMEL-4596:
-
What if we added a pollEnrich(Expression) and enrich(Expression) overloaded
method as opposed to treating the String argument as an expression?
> enrich and pollEnrich should accept an expression for dynamic uris
> --
>
> Key: CAMEL-4596
> URL: https://issues.apache.org/jira/browse/CAMEL-4596
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Claus Ibsen
>Priority: Minor
> Fix For: 3.0.0
>
>
> We should consider using an expression for uri's for the enrich and
> pollEnrich EIP's so we can poll from a dynamic computed endpoint.
> However it will break API as currently the uri is mandatory.
> It's a bit the same problem with to EIP which is also static uri. However for
> to EIP we have recipientList which is the dynamic to.
> So we need a similar dynamic for enrich and pollEnrich.
> This also solves the problem with that people wan't to provide details from
> the current exchange in the endpoint uri. We have a ticket for that.
> eg enrich("file:inbox?fileName=${header.nameToPickUp}")
> So if we can do it using an expression it could be
> .enrich().simple("file:inbox?fileName=${header.nameToPickUp}")
> See nabble
> http://camel.465427.n5.nabble.com/pollEnrich-consumer-with-selector-tp4939908p4939908.html
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CAMEL-6826) Use Mock Objects Instead of Live HazelcastInstances to Speed Up Testing
[ https://issues.apache.org/jira/browse/CAMEL-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790034#comment-13790034 ] James Carman commented on CAMEL-6826: - I have implemented mocks for the consumer tests. The spring-based tests still need to be mocked out as well as the seda tests. It is much faster now, though. > Use Mock Objects Instead of Live HazelcastInstances to Speed Up Testing > --- > > Key: CAMEL-6826 > URL: https://issues.apache.org/jira/browse/CAMEL-6826 > Project: Camel > Issue Type: Improvement > Components: camel-hazelcast >Reporter: James Carman >Assignee: James Carman > > The unit tests for the camel-hazelcast component use real HazelcastInstance > objects, which is very slow. We should use mock objects instead to speed up > testing. Testing the integration can be done with a few, select tests, but > the majority of the logic can be tested with mocks. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CAMEL-6843) Hazelcast Map Support Uses Wrong Verb "Envict"
James Carman created CAMEL-6843: --- Summary: Hazelcast Map Support Uses Wrong Verb "Envict" Key: CAMEL-6843 URL: https://issues.apache.org/jira/browse/CAMEL-6843 Project: Camel Issue Type: Bug Components: camel-hazelcast Reporter: James Carman Assignee: James Carman The event type is "evicted" not "envicted." Our code has a constant called HazelcastConstants.ENVICTED which has the value "envicted." We need to fix this, but it will cause a compatibility break. We could introduce the correct values and support both, with the incorrect ones being deprecated. Would that work? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CAMEL-6826) Use Mock Objects Instead of Live HazelcastInstances to Speed Up Testing
[ https://issues.apache.org/jira/browse/CAMEL-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13789643#comment-13789643 ] James Carman commented on CAMEL-6826: - I have been able to successfully speed up the producer tests. However, the consumer tests are a bit tricky. They use a callback API to do their work. I don't know if it's worth mocking all of that out or not, but I'll play with it. I'm committing what I have, though. > Use Mock Objects Instead of Live HazelcastInstances to Speed Up Testing > --- > > Key: CAMEL-6826 > URL: https://issues.apache.org/jira/browse/CAMEL-6826 > Project: Camel > Issue Type: Improvement > Components: camel-hazelcast >Reporter: James Carman >Assignee: James Carman > > The unit tests for the camel-hazelcast component use real HazelcastInstance > objects, which is very slow. We should use mock objects instead to speed up > testing. Testing the integration can be done with a few, select tests, but > the majority of the logic can be tested with mocks. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Work started] (CAMEL-6833) Atomic Number Producer Uses Wrong Cache Name
[ https://issues.apache.org/jira/browse/CAMEL-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-6833 started by James Carman. > Atomic Number Producer Uses Wrong Cache Name > > > Key: CAMEL-6833 > URL: https://issues.apache.org/jira/browse/CAMEL-6833 > Project: Camel > Issue Type: Bug > Components: camel-hazelcast >Reporter: James Carman >Assignee: James Carman > Fix For: 2.13.0 > > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > When redesigning the tests to use mock objects, I noticed that the atomic > number producer actually uses the incorrect atomic number name. If you try > to update an atomic number named "foo", it actually updates one named > "ue:foo". This is because it uses the wrong constant (the one for instances) > when it picks apart the URI. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Work started] (CAMEL-6833) Atomic Number Producer Uses Wrong Cache Name
[ https://issues.apache.org/jira/browse/CAMEL-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-6833 started by James Carman. > Atomic Number Producer Uses Wrong Cache Name > > > Key: CAMEL-6833 > URL: https://issues.apache.org/jira/browse/CAMEL-6833 > Project: Camel > Issue Type: Bug > Components: camel-hazelcast >Reporter: James Carman >Assignee: James Carman > Fix For: 2.13.0 > > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > When redesigning the tests to use mock objects, I noticed that the atomic > number producer actually uses the incorrect atomic number name. If you try > to update an atomic number named "foo", it actually updates one named > "ue:foo". This is because it uses the wrong constant (the one for instances) > when it picks apart the URI. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CAMEL-6833) Atomic Number Producer Uses Wrong Cache Name
[ https://issues.apache.org/jira/browse/CAMEL-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman resolved CAMEL-6833. - Resolution: Fixed > Atomic Number Producer Uses Wrong Cache Name > > > Key: CAMEL-6833 > URL: https://issues.apache.org/jira/browse/CAMEL-6833 > Project: Camel > Issue Type: Bug > Components: camel-hazelcast >Reporter: James Carman >Assignee: James Carman > Fix For: 2.13.0 > > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > When redesigning the tests to use mock objects, I noticed that the atomic > number producer actually uses the incorrect atomic number name. If you try > to update an atomic number named "foo", it actually updates one named > "ue:foo". This is because it uses the wrong constant (the one for instances) > when it picks apart the URI. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CAMEL-6833) Atomic Number Producer Uses Wrong Cache Name
James Carman created CAMEL-6833: --- Summary: Atomic Number Producer Uses Wrong Cache Name Key: CAMEL-6833 URL: https://issues.apache.org/jira/browse/CAMEL-6833 Project: Camel Issue Type: Bug Components: camel-hazelcast Reporter: James Carman Assignee: James Carman Fix For: 2.13.0 When redesigning the tests to use mock objects, I noticed that the atomic number producer actually uses the incorrect atomic number name. If you try to update an atomic number named "foo", it actually updates one named "ue:foo". This is because it uses the wrong constant (the one for instances) when it picks apart the URI. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CAMEL-6826) Use Mock Objects Instead of Live HazelcastInstances to Speed Up Testing
[ https://issues.apache.org/jira/browse/CAMEL-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman reassigned CAMEL-6826: --- Assignee: James Carman > Use Mock Objects Instead of Live HazelcastInstances to Speed Up Testing > --- > > Key: CAMEL-6826 > URL: https://issues.apache.org/jira/browse/CAMEL-6826 > Project: Camel > Issue Type: Improvement > Components: camel-hazelcast >Reporter: James Carman >Assignee: James Carman > > The unit tests for the camel-hazelcast component use real HazelcastInstance > objects, which is very slow. We should use mock objects instead to speed up > testing. Testing the integration can be done with a few, select tests, but > the majority of the logic can be tested with mocks. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CAMEL-4015) camel-hazelcast - Allow to specify operation in uri instead of just as a header
[
https://issues.apache.org/jira/browse/CAMEL-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman reassigned CAMEL-4015:
---
Assignee: James Carman
> camel-hazelcast - Allow to specify operation in uri instead of just as a
> header
> ---
>
> Key: CAMEL-4015
> URL: https://issues.apache.org/jira/browse/CAMEL-4015
> Project: Camel
> Issue Type: Improvement
> Components: camel-hazelcast
>Reporter: Romain Manni-Bucau
>Assignee: James Carman
>Priority: Minor
> Fix For: 2.13.0
>
> Attachments: 0001-CAMEL-4015-camel-hazelcast-uri-format.patch,
> CAMEL-4015-2.patch, CAMEL-4015.patch
>
>
> It could be nice to be able to specify type operation (and maybe the key for
> map) in the uri instead of headers:
> from("hazelcast:map:foo?operation=get&id=myStringId").to("log:display");
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (CAMEL-6826) Use Mock Objects Instead of Live HazelcastInstances to Speed Up Testing
James Carman created CAMEL-6826: --- Summary: Use Mock Objects Instead of Live HazelcastInstances to Speed Up Testing Key: CAMEL-6826 URL: https://issues.apache.org/jira/browse/CAMEL-6826 Project: Camel Issue Type: Improvement Components: camel-hazelcast Reporter: James Carman The unit tests for the camel-hazelcast component use real HazelcastInstance objects, which is very slow. We should use mock objects instead to speed up testing. Testing the integration can be done with a few, select tests, but the majority of the logic can be tested with mocks. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Issue Comment Deleted] (CAMEL-6768) @Header @Body @Property bean parameter binding - add mandatory option
[ https://issues.apache.org/jira/browse/CAMEL-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated CAMEL-6768: Comment: was deleted (was: I don't mean we would have two different attributes on each annotation. I mean we would use a different attribute name for these specific cases. For instance, since the @Header is optional already, perhaps it gets a new attribute named "required" and you would set that to true to change the default behavior. For @Body, the attribute name would be called "optional" and you would again set that to true to change the default behavior. Just a thought. ) > @Header @Body @Property bean parameter binding - add mandatory option > - > > Key: CAMEL-6768 > URL: https://issues.apache.org/jira/browse/CAMEL-6768 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Priority: Minor > Fix For: Future > > > See > http://stackoverflow.com/questions/18874641/add-string-to-camel-exchange-header-from-route?noredirect=1#comment27863978_18874641 > We could have an attribute mandatory = true, which is default true for these > bean parameter annotations. Then people can set it to false, if a @Header is > not mandatory (eg do not fail if the header is not present). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CAMEL-6768) @Header @Body @Property bean parameter binding - add mandatory option
[ https://issues.apache.org/jira/browse/CAMEL-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13783703#comment-13783703 ] James Carman commented on CAMEL-6768: - I don't mean we would have two different attributes on each annotation. I mean we would use a different attribute name for these specific cases. For instance, since the @Header is optional already, perhaps it gets a new attribute named "required" and you would set that to true to change the default behavior. For @Body, the attribute name would be called "optional" and you would again set that to true to change the default behavior. Just a thought. > @Header @Body @Property bean parameter binding - add mandatory option > - > > Key: CAMEL-6768 > URL: https://issues.apache.org/jira/browse/CAMEL-6768 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Priority: Minor > Fix For: Future > > > See > http://stackoverflow.com/questions/18874641/add-string-to-camel-exchange-header-from-route?noredirect=1#comment27863978_18874641 > We could have an attribute mandatory = true, which is default true for these > bean parameter annotations. Then people can set it to false, if a @Header is > not mandatory (eg do not fail if the header is not present). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CAMEL-6768) @Header @Body @Property bean parameter binding - add mandatory option
[ https://issues.apache.org/jira/browse/CAMEL-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13783704#comment-13783704 ] James Carman commented on CAMEL-6768: - I don't mean we would have two different attributes on each annotation. I mean we would use a different attribute name for these specific cases. For instance, since the @Header is optional already, perhaps it gets a new attribute named "required" and you would set that to true to change the default behavior. For @Body, the attribute name would be called "optional" and you would again set that to true to change the default behavior. Just a thought. > @Header @Body @Property bean parameter binding - add mandatory option > - > > Key: CAMEL-6768 > URL: https://issues.apache.org/jira/browse/CAMEL-6768 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Priority: Minor > Fix For: Future > > > See > http://stackoverflow.com/questions/18874641/add-string-to-camel-exchange-header-from-route?noredirect=1#comment27863978_18874641 > We could have an attribute mandatory = true, which is default true for these > bean parameter annotations. Then people can set it to false, if a @Header is > not mandatory (eg do not fail if the header is not present). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CAMEL-6768) @Header @Body @Property bean parameter binding - add mandatory option
[ https://issues.apache.org/jira/browse/CAMEL-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13783380#comment-13783380 ] James Carman commented on CAMEL-6768: - We should probably change the attribute name, depending on the default case? > @Header @Body @Property bean parameter binding - add mandatory option > - > > Key: CAMEL-6768 > URL: https://issues.apache.org/jira/browse/CAMEL-6768 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Priority: Minor > Fix For: Future > > > See > http://stackoverflow.com/questions/18874641/add-string-to-camel-exchange-header-from-route?noredirect=1#comment27863978_18874641 > We could have an attribute mandatory = true, which is default true for these > bean parameter annotations. Then people can set it to false, if a @Header is > not mandatory (eg do not fail if the header is not present). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CAMEL-4015) camel-hazelcast - Allow to specify operation in uri instead of just as a header
[
https://issues.apache.org/jira/browse/CAMEL-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman updated CAMEL-4015:
Attachment: 0001-CAMEL-4015-camel-hazelcast-uri-format.patch
Claus, try this patch instead. You'll need the original patch I attached and
this one, I believe.
> camel-hazelcast - Allow to specify operation in uri instead of just as a
> header
> ---
>
> Key: CAMEL-4015
> URL: https://issues.apache.org/jira/browse/CAMEL-4015
> Project: Camel
> Issue Type: Improvement
> Components: camel-hazelcast
>Reporter: Romain Manni-Bucau
>Priority: Minor
> Fix For: 2.13.0
>
> Attachments: 0001-CAMEL-4015-camel-hazelcast-uri-format.patch,
> CAMEL-4015-2.patch, CAMEL-4015.patch
>
>
> It could be nice to be able to specify type operation (and maybe the key for
> map) in the uri instead of headers:
> from("hazelcast:map:foo?operation=get&id=myStringId").to("log:display");
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (CAMEL-6783) getFeatures() method of CxfEndpoint only accept AbstractFeature but Feature
[
https://issues.apache.org/jira/browse/CAMEL-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13781935#comment-13781935
]
James Carman edited comment on CAMEL-6783 at 9/30/13 3:34 PM:
--
It's okay to take List on the input because you know all the
things in the input collection are Feature objects. However, returning List doesn't work well at all, because you can't add stuff to it.
Consider the following case:
{code:java}
List list = ...;
list.add("Hello");
{code}
You can't do it, because "list" is a list of some type of things that extend
Serializable. You don't *know* that the type is String, you just know it's
some type extending from Serializable.
was (Author: jwcarman):
It's okay to take List doesn't work well at all, because you can't add stuff to it.
Consider the following case:
{code:java}
List list = ...;
list.add("Hello");
{code}
You can't do it, because "list" is a list of some type of things that extend
Serializable. You don't *know* that the type is String, you just know it's
some type extending from Serializable.
> getFeatures() method of CxfEndpoint only accept AbstractFeature but Feature
> ---
>
> Key: CAMEL-6783
> URL: https://issues.apache.org/jira/browse/CAMEL-6783
> Project: Camel
> Issue Type: Bug
> Components: camel-cxf
>Affects Versions: 2.12.0
>Reporter: liugang
> Attachments: CAMEL-6783.patch
>
>
> the *getFeatures()* method of *CxfEndpoint* only accept an instance of
> *AbstractFeature*, but the original *ClientFactoryBean* accept *Feature*
> instance.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CAMEL-6783) getFeatures() method of CxfEndpoint only accept AbstractFeature but Feature
[
https://issues.apache.org/jira/browse/CAMEL-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13781935#comment-13781935
]
James Carman commented on CAMEL-6783:
-
It's okay to take List doesn't work well at all, because you can't add stuff to it.
Consider the following case:
{code:java}
List list = ...;
list.add("Hello");
{code}
You can't do it, because "list" is a list of some type of things that extend
Serializable. You don't *know* that the type is String, you just know it's
some type extending from Serializable.
> getFeatures() method of CxfEndpoint only accept AbstractFeature but Feature
> ---
>
> Key: CAMEL-6783
> URL: https://issues.apache.org/jira/browse/CAMEL-6783
> Project: Camel
> Issue Type: Bug
> Components: camel-cxf
>Affects Versions: 2.12.0
>Reporter: liugang
> Attachments: CAMEL-6783.patch
>
>
> the *getFeatures()* method of *CxfEndpoint* only accept an instance of
> *AbstractFeature*, but the original *ClientFactoryBean* accept *Feature*
> instance.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CAMEL-4015) camel hazelcast uri format
[
https://issues.apache.org/jira/browse/CAMEL-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13781349#comment-13781349
]
James Carman commented on CAMEL-4015:
-
Sorry about the first patch. Forgot that we're normally in OSGi-land. Turns
out it's only used in one place anyway, so the INSTANCE wasn't really necessary.
> camel hazelcast uri format
> --
>
> Key: CAMEL-4015
> URL: https://issues.apache.org/jira/browse/CAMEL-4015
> Project: Camel
> Issue Type: Improvement
> Components: camel-hazelcast
>Reporter: Romain Manni-Bucau
>Priority: Trivial
> Attachments: CAMEL-4015-2.patch, CAMEL-4015.patch
>
>
> It could be nice to be able to specify type operation (and maybe the key for
> map) in the uri instead of headers:
> from("hazelcast:map:foo?operation=get&id=myStringId").to("log:display");
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CAMEL-6783) getFeatures() method of CxfEndpoint only accept AbstractFeature but Feature
[ https://issues.apache.org/jira/browse/CAMEL-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13781348#comment-13781348 ] James Carman commented on CAMEL-6783: - That would make things worse, because then the collection is virtually useless if anyone wants to modify it. > getFeatures() method of CxfEndpoint only accept AbstractFeature but Feature > --- > > Key: CAMEL-6783 > URL: https://issues.apache.org/jira/browse/CAMEL-6783 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Affects Versions: 2.12.0 >Reporter: liugang > Attachments: CAMEL-6783.patch > > > the *getFeatures()* method of *CxfEndpoint* only accept an instance of > *AbstractFeature*, but the original *ClientFactoryBean* accept *Feature* > instance. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CAMEL-4015) camel hazelcast uri format
[
https://issues.apache.org/jira/browse/CAMEL-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman updated CAMEL-4015:
Attachment: CAMEL-4015-2.patch
Sure, Claus. Can you just apply this patch file over top of the other one?
That should do it.
> camel hazelcast uri format
> --
>
> Key: CAMEL-4015
> URL: https://issues.apache.org/jira/browse/CAMEL-4015
> Project: Camel
> Issue Type: Improvement
> Components: camel-hazelcast
>Reporter: Romain Manni-Bucau
>Priority: Trivial
> Attachments: CAMEL-4015-2.patch, CAMEL-4015.patch
>
>
> It could be nice to be able to specify type operation (and maybe the key for
> map) in the uri instead of headers:
> from("hazelcast:map:foo?operation=get&id=myStringId").to("log:display");
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CAMEL-6771) ConcurrentModificationException thrown from inside camel splitter
[
https://issues.apache.org/jira/browse/CAMEL-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman updated CAMEL-6771:
Attachment: CAMEL-6771.patch
This should fix the problem. I was having trouble creating a unit test that
reliably reproduces the issue, so I didn't include it in this patch.
Basically, instead of using a HashMap, I'm using a ConcurrentHashMap to store
the MulticastProcessor -> AggreationStrategy map.
> ConcurrentModificationException thrown from inside camel splitter
> -
>
> Key: CAMEL-6771
> URL: https://issues.apache.org/jira/browse/CAMEL-6771
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.11.1
> Environment: Amazon Linux, oracle jdk 1.7
>Reporter: Joshua Groom
> Attachments: CAMEL-6771.patch
>
>
> We use camel 2.11.1 running on the oracle 1.7 jvm for linux.
> I have a route that looks like this. It reads in files and puts them on a
> seda queue with 8 concurrent consumers.
> - The SpatialInterpolationPojo reads each file is read and split into two
> messages X and Y.
> - The MyAggregator uses X and Y together and outputs a combined message A.B
> - The MySplitterPojo splits A.B into two messages A and B
> {code}
> from("file://somefile")
> .to("seda:filteraccept?concurrentConsumers=8");
> from("seda:filteraccept?concurrentConsumers=8")
> .split()
> .method(new SpatialInterpolationPojo(), "split")
> .to("direct:wind-aggregator");
> from("direct:wind-aggregator")
> .aggregate(packageCorrelationId(), new MyAggregator())
> .completionPredicate(header(FIELD_AGGREGATION_COMPLETE).isNotNull())
> .split()
> .method(new MySplitterPojo())
> .to("seda:output");
> {code}
> The MySplitterPojo simply returns List containing two messages that
> come from data in the input message body. We copy the body headers to the
> result messages.
> It is thread safe, it has no state, ie there are no object fields that are
> modified.
> The method is like this it is edited for clarity/privacy:
> {code}
> public class MySplitterPojo {
> public List splitMessage(
> @Headers Map headers,
> @Body CombinedObject body) {
>
> DefaultMessage a = new DefaultMessage();
> a.setBody(body.getA());
> a.setHeaders(new HashMap(headers));
>
> DefaultMessage b = new DefaultMessage();
> b.setBody(body.getB());
> b.setHeaders(new HashMap(headers));
>
> ArrayList result = new ArrayList(2);
> result.add(a);
> result.add(b);
>
> return result;
> }
> }
> {code}
> When we run this route we very occasionally get the exception below. You can
> see that it is entirely within camel, it appears to be trying to copy the map
> stored under the exchange property Exchange.AGGREGATION_STRATEGY which is a
> camel internal property key.
> By inspection of the message I can see that Exchange has just come out of the
> WindVectorAggregator.
> This seems like it must be a camel bug to me. Any ideas?
> {code}
> 15 Sep 2013 23:06:47,140[Camel (camel-1) thread #21 - seda://filteraccept]
> WARN AggregateProcessor Error processing aggregated exchange.
> Exchange[Message: { Trondheim, NO=WindVector [u=-5.92894983291626,
> v=7.060009002685547], ... }]. Caused by:
> [java.util.ConcurrentModificationException - null]
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(Unknown Source)
> at java.util.HashMap$EntryIterator.next(Unknown Source)
> at java.util.HashMap$EntryIterator.next(Unknown Source)
> at java.util.HashMap.putAllForCreate(Unknown Source)
> at java.util.HashMap.(Unknown Source)
> at
> org.apache.camel.processor.MulticastProcessor.setAggregationStrategyOnExchange(MulticastProcessor.java:1011)
>
> at org.apache.camel.processor.Splitter.process(Splitter.java:95)
> at
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>
> at
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
>
> at
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
>
> at
> org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
>
> at
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>
> at
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
>
> at
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
>
> at
> org.apache.camel.processor.interceptor.BacklogTracerInterce
[jira] [Commented] (CAMEL-4015) camel hazelcast uri format
[
https://issues.apache.org/jira/browse/CAMEL-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13780890#comment-13780890
]
James Carman commented on CAMEL-4015:
-
Romain, it actually allows you to either use the "name" of the operation or the
number, so that you can use the constants when constructing your URI. The unit
tests exhibit that behavior. Enjoy!
> camel hazelcast uri format
> --
>
> Key: CAMEL-4015
> URL: https://issues.apache.org/jira/browse/CAMEL-4015
> Project: Camel
> Issue Type: Improvement
> Components: camel-hazelcast
>Reporter: Romain Manni-Bucau
>Priority: Trivial
> Attachments: CAMEL-4015.patch
>
>
> It could be nice to be able to specify type operation (and maybe the key for
> map) in the uri instead of headers:
> from("hazelcast:map:foo?operation=get&id=myStringId").to("log:display");
--
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
[jira] [Updated] (CAMEL-6783) getFeatures() method of CxfEndpoint only accept AbstractFeature but Feature
[ https://issues.apache.org/jira/browse/CAMEL-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated CAMEL-6783: Attachment: CAMEL-6783.patch In case we decide to accept the regression risk of this change, I'm attaching a patch. > getFeatures() method of CxfEndpoint only accept AbstractFeature but Feature > --- > > Key: CAMEL-6783 > URL: https://issues.apache.org/jira/browse/CAMEL-6783 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Affects Versions: 2.12.0 >Reporter: liugang > Attachments: CAMEL-6783.patch > > > the *getFeatures()* method of *CxfEndpoint* only accept an instance of > *AbstractFeature*, but the original *ClientFactoryBean* accept *Feature* > instance. -- 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
[jira] [Commented] (CAMEL-6783) getFeatures() method of CxfEndpoint only accept AbstractFeature but Feature
[ https://issues.apache.org/jira/browse/CAMEL-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13780887#comment-13780887 ] James Carman commented on CAMEL-6783: - This change could cause a regression. Are we sure we want this? > getFeatures() method of CxfEndpoint only accept AbstractFeature but Feature > --- > > Key: CAMEL-6783 > URL: https://issues.apache.org/jira/browse/CAMEL-6783 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Affects Versions: 2.12.0 >Reporter: liugang > > the *getFeatures()* method of *CxfEndpoint* only accept an instance of > *AbstractFeature*, but the original *ClientFactoryBean* accept *Feature* > instance. -- 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
[jira] [Updated] (CAMEL-6792) Camel Test Support needs a new Method
[
https://issues.apache.org/jira/browse/CAMEL-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman updated CAMEL-6792:
Attachment: CAMEL-6792.patch
I believe this takes care of it.
> Camel Test Support needs a new Method
> -
>
> Key: CAMEL-6792
> URL: https://issues.apache.org/jira/browse/CAMEL-6792
> Project: Camel
> Issue Type: Wish
> Components: camel-test
>Affects Versions: 2.11.1
> Environment: ALL
>Reporter: Robert E. Simmons Jr. MSc.
>Priority: Minor
> Attachments: CAMEL-6792.patch
>
>
> There is a problem with the CamelTestSupport class in that if you call
> getMockEndpoint on an endpoint that doesnt exist, it blithely returns you an
> endpoint connected to nothing. The problem is you end up chasing endless test
> failures when the fact is your endpoint is not even there. So I suggest a
> method I added to my subclass of CamelTestSupport which is:
> protected MockEndpoint assertAndGetMockEndpoint(final String uri) {
> assertNotNull(context.hasEndpoint(uri));
> return getMockEndpoint(uri);
> }
> This method will make sure that the endpoint is there before returning it and
> it will make tests easier to write.
--
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
[jira] [Commented] (CAMEL-6670) Throttler EIP - Add JMX attribute to know if hit limit currently (eg its throttling state)
[ https://issues.apache.org/jira/browse/CAMEL-6670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13780877#comment-13780877 ] James Carman commented on CAMEL-6670: - I have an idea how to fix this, but I don't know about the implementation as it currently stands. The access to the timePeriodMillis isn't synchronized, but it's allowed to be modified via JMX, so it probably should be. Perhaps changing it to AtomicLong? > Throttler EIP - Add JMX attribute to know if hit limit currently (eg its > throttling state) > -- > > Key: CAMEL-6670 > URL: https://issues.apache.org/jira/browse/CAMEL-6670 > Project: Camel > Issue Type: Improvement > Components: camel-core, eip >Reporter: Claus Ibsen >Priority: Minor > Fix For: Future > > > See SO > http://stackoverflow.com/questions/18446689/how-to-get-the-information-that-throttling-limit-has-been-reached > We would need to extend the org.apache.camel.processor.Throttler so it keeps > state whether its holding back exchanges due hit limit, or not. Wonder what a > name should be. It could be a simple boolean to indicate that. And/or a > counter that counts the number of exchanges being hold back. Then ppl can > have a graph with the counter. > This data should be exposed in JMX with > org.apache.camel.api.management.mbean.ManagedThrottlerMBean -- 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
[jira] [Commented] (CAMEL-6768) @Header @Body @Property bean parameter binding - add mandatory option
[ https://issues.apache.org/jira/browse/CAMEL-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13780866#comment-13780866 ] James Carman commented on CAMEL-6768: - We don't want to change the existing behavior, correct? I believe the current behavior for @Header would be equivalent to the mandatory = false case. > @Header @Body @Property bean parameter binding - add mandatory option > - > > Key: CAMEL-6768 > URL: https://issues.apache.org/jira/browse/CAMEL-6768 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Priority: Minor > Fix For: Future > > > See > http://stackoverflow.com/questions/18874641/add-string-to-camel-exchange-header-from-route?noredirect=1#comment27863978_18874641 > We could have an attribute mandatory = true, which is default true for these > bean parameter annotations. Then people can set it to false, if a @Header is > not mandatory (eg do not fail if the header is not present). -- 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
[jira] [Updated] (CAMEL-4015) camel hazelcast uri format
[
https://issues.apache.org/jira/browse/CAMEL-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman updated CAMEL-4015:
Attachment: CAMEL-4015.patch
This patch implements the feature as I understand the request.
> camel hazelcast uri format
> --
>
> Key: CAMEL-4015
> URL: https://issues.apache.org/jira/browse/CAMEL-4015
> Project: Camel
> Issue Type: Improvement
> Components: camel-hazelcast
>Reporter: Romain Manni-Bucau
>Priority: Trivial
> Attachments: CAMEL-4015.patch
>
>
> It could be nice to be able to specify type operation (and maybe the key for
> map) in the uri instead of headers:
> from("hazelcast:map:foo?operation=get&id=myStringId").to("log:display");
--
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
[jira] [Commented] (CAMEL-4015) camel hazelcast uri format
[
https://issues.apache.org/jira/browse/CAMEL-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13780815#comment-13780815
]
James Carman commented on CAMEL-4015:
-
I'm implementing this now.
> camel hazelcast uri format
> --
>
> Key: CAMEL-4015
> URL: https://issues.apache.org/jira/browse/CAMEL-4015
> Project: Camel
> Issue Type: Improvement
> Components: camel-hazelcast
>Reporter: Romain Manni-Bucau
>Priority: Trivial
>
> It could be nice to be able to specify type operation (and maybe the key for
> map) in the uri instead of headers:
> from("hazelcast:map:foo?operation=get&id=myStringId").to("log:display");
--
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
[jira] [Updated] (CAMEL-6748) Optimize File Producers by Skipping Header Evaluation
[ https://issues.apache.org/jira/browse/CAMEL-6748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated CAMEL-6748: Attachment: CAMEL-6748.patch This patch implements the improvement and includes a WARN-level message to warn the user about the regression, pointing to this issue. > Optimize File Producers by Skipping Header Evaluation > - > > Key: CAMEL-6748 > URL: https://issues.apache.org/jira/browse/CAMEL-6748 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: James Carman >Priority: Minor > Attachments: CAMEL-6748.patch > > > The current file producer code will evaluate CamelFileName headers as simple > expressions if they start with "$simple". There are other ways to achieve > this same thing and this functionality is unnecessary. -- 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
[jira] [Updated] (CAMEL-6734) Introduce CamelFileNameConsumed Header
[ https://issues.apache.org/jira/browse/CAMEL-6734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated CAMEL-6734: Description: On the producing side, we have CamelFileNameProduced. It would be nice if we had access to the original consumed file name in a similar fashion.(was: On the producing side, we have CamelProducedFileName. It would be nice if we had access to the original consumed file name in a similar fashion. ) > Introduce CamelFileNameConsumed Header > -- > > Key: CAMEL-6734 > URL: https://issues.apache.org/jira/browse/CAMEL-6734 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: James Carman >Assignee: Claus Ibsen > Fix For: 2.10.7, 2.11.2, 2.12.1, 2.13.0 > > Attachments: CAMEL-6734.patch > > Original Estimate: 4h > Remaining Estimate: 4h > > On the producing side, we have CamelFileNameProduced. It would be nice if we > had access to the original consumed file name in a similar fashion. -- 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
[jira] [Updated] (CAMEL-6734) Introduce CamelFileNameConsumed Header
[ https://issues.apache.org/jira/browse/CAMEL-6734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated CAMEL-6734: Summary: Introduce CamelFileNameConsumed Header (was: Introduce CamelConsumedFileName Header) > Introduce CamelFileNameConsumed Header > -- > > Key: CAMEL-6734 > URL: https://issues.apache.org/jira/browse/CAMEL-6734 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: James Carman >Assignee: Claus Ibsen > Fix For: 2.10.7, 2.11.2, 2.12.1, 2.13.0 > > Attachments: CAMEL-6734.patch > > Original Estimate: 4h > Remaining Estimate: 4h > > On the producing side, we have CamelProducedFileName. It would be nice if we > had access to the original consumed file name in a similar fashion. -- 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
[jira] [Created] (CAMEL-6748) Optimize File Producers by Skipping Header Evaluation
James Carman created CAMEL-6748: --- Summary: Optimize File Producers by Skipping Header Evaluation Key: CAMEL-6748 URL: https://issues.apache.org/jira/browse/CAMEL-6748 Project: Camel Issue Type: Improvement Components: camel-core Reporter: James Carman Priority: Minor The current file producer code will evaluate CamelFileName headers as simple expressions if they start with "$simple". There are other ways to achieve this same thing and this functionality is unnecessary. -- 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
[jira] [Commented] (CAMEL-6734) Introduce CamelConsumedFileName Header
[ https://issues.apache.org/jira/browse/CAMEL-6734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13765324#comment-13765324 ] James Carman commented on CAMEL-6734: - Thanks for the tip, Claus. I was having an awful time with the full build on my machine. I'll try to work through those issues and get started on more patches. Glad I could help out! > Introduce CamelConsumedFileName Header > -- > > Key: CAMEL-6734 > URL: https://issues.apache.org/jira/browse/CAMEL-6734 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: James Carman >Assignee: Claus Ibsen > Fix For: 2.10.7, 2.11.2, 2.12.1, 2.13.0 > > Attachments: CAMEL-6734.patch > > Original Estimate: 4h > Remaining Estimate: 4h > > On the producing side, we have CamelProducedFileName. It would be nice if we > had access to the original consumed file name in a similar fashion. -- 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
[jira] [Updated] (CAMEL-6734) Introduce CamelConsumedFileName Header
[ https://issues.apache.org/jira/browse/CAMEL-6734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated CAMEL-6734: Attachment: CAMEL-6734.patch Here's a patch implementing the improvement. > Introduce CamelConsumedFileName Header > -- > > Key: CAMEL-6734 > URL: https://issues.apache.org/jira/browse/CAMEL-6734 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: James Carman > Attachments: CAMEL-6734.patch > > Original Estimate: 4h > Remaining Estimate: 4h > > On the producing side, we have CamelProducedFileName. It would be nice if we > had access to the original consumed file name in a similar fashion. -- 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
[jira] [Created] (CAMEL-6734) Introduce CamelConsumedFileName Header
James Carman created CAMEL-6734: --- Summary: Introduce CamelConsumedFileName Header Key: CAMEL-6734 URL: https://issues.apache.org/jira/browse/CAMEL-6734 Project: Camel Issue Type: Improvement Components: camel-core Reporter: James Carman On the producing side, we have CamelProducedFileName. It would be nice if we had access to the original consumed file name in a similar fashion. -- 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
[jira] [Commented] (CAMEL-5668) camel-jetty - A soap fault should trigger http response code 500
[ https://issues.apache.org/jira/browse/CAMEL-5668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13467024#comment-13467024 ] James Carman commented on CAMEL-5668: - Sorry about introducing the test failure. I saw that late last night and didn't have time to fix it. > camel-jetty - A soap fault should trigger http response code 500 > > > Key: CAMEL-5668 > URL: https://issues.apache.org/jira/browse/CAMEL-5668 > Project: Camel > Issue Type: Bug > Components: camel-jetty >Affects Versions: 2.9.0, 2.10.0 >Reporter: Claus Ibsen >Assignee: Willem Jiang >Priority: Minor > Fix For: 2.9.4, 2.11.0, 2.10.2 > > Attachments: CAMEL-5668.patch > > > See nabble > http://camel.465427.n5.nabble.com/Help-with-nmr-cxf-endpoints-and-fault-handling-tp5719720.html > If a response is fault=true, then we should force the http response code to > be 500. Which is what the SOAP 1.1 spec mandates. > See section 6.2 at: http://www.w3.org/TR/soap11/#_Ref477795996 -- 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
[jira] [Commented] (CAMEL-5668) camel-jetty - A soap fault should trigger http response code 500
[ https://issues.apache.org/jira/browse/CAMEL-5668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13466616#comment-13466616 ] James Carman commented on CAMEL-5668: - We should really think about consolidating this code. There are some value-adds in the http component that aren't in the http4 component. They're virtually the same exact code. There has to be a way to extract a superclass from this and create some abstract supermodule that they can both reference. > camel-jetty - A soap fault should trigger http response code 500 > > > Key: CAMEL-5668 > URL: https://issues.apache.org/jira/browse/CAMEL-5668 > Project: Camel > Issue Type: Bug > Components: camel-jetty >Affects Versions: 2.9.0, 2.10.0 >Reporter: Claus Ibsen >Assignee: Willem Jiang >Priority: Minor > Fix For: 2.9.4, 2.11.0, 2.10.2 > > Attachments: CAMEL-5668.patch > > > See nabble > http://camel.465427.n5.nabble.com/Help-with-nmr-cxf-endpoints-and-fault-handling-tp5719720.html > If a response is fault=true, then we should force the http response code to > be 500. Which is what the SOAP 1.1 spec mandates. > See section 6.2 at: http://www.w3.org/TR/soap11/#_Ref477795996 -- 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
[jira] [Updated] (CAMEL-5668) camel-jetty - A soap fault should trigger http response code 500
[ https://issues.apache.org/jira/browse/CAMEL-5668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated CAMEL-5668: Attachment: CAMEL-5668.patch Here's another patch that patches both the http and http4 components. > camel-jetty - A soap fault should trigger http response code 500 > > > Key: CAMEL-5668 > URL: https://issues.apache.org/jira/browse/CAMEL-5668 > Project: Camel > Issue Type: Bug > Components: camel-jetty >Affects Versions: 2.9.0, 2.10.0 >Reporter: Claus Ibsen >Assignee: Willem Jiang >Priority: Minor > Fix For: 2.9.4, 2.11.0, 2.10.2 > > Attachments: CAMEL-5668.patch > > > See nabble > http://camel.465427.n5.nabble.com/Help-with-nmr-cxf-endpoints-and-fault-handling-tp5719720.html > If a response is fault=true, then we should force the http response code to > be 500. Which is what the SOAP 1.1 spec mandates. > See section 6.2 at: http://www.w3.org/TR/soap11/#_Ref477795996 -- 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
[jira] [Updated] (CAMEL-5668) camel-jetty - A soap fault should trigger http response code 500
[ https://issues.apache.org/jira/browse/CAMEL-5668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated CAMEL-5668: Attachment: (was: CAMEL-5668.patch) > camel-jetty - A soap fault should trigger http response code 500 > > > Key: CAMEL-5668 > URL: https://issues.apache.org/jira/browse/CAMEL-5668 > Project: Camel > Issue Type: Bug > Components: camel-jetty >Affects Versions: 2.9.0, 2.10.0 >Reporter: Claus Ibsen >Assignee: Willem Jiang >Priority: Minor > Fix For: 2.9.4, 2.11.0, 2.10.2 > > Attachments: CAMEL-5668.patch > > > See nabble > http://camel.465427.n5.nabble.com/Help-with-nmr-cxf-endpoints-and-fault-handling-tp5719720.html > If a response is fault=true, then we should force the http response code to > be 500. Which is what the SOAP 1.1 spec mandates. > See section 6.2 at: http://www.w3.org/TR/soap11/#_Ref477795996 -- 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
[jira] [Updated] (CAMEL-5668) camel-jetty - A soap fault should trigger http response code 500
[ https://issues.apache.org/jira/browse/CAMEL-5668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated CAMEL-5668: Attachment: CAMEL-5668.patch Here's a patch that implements what I think you're looking for. I should probably add a test in the http component also, since that's where the actual code change takes place. > camel-jetty - A soap fault should trigger http response code 500 > > > Key: CAMEL-5668 > URL: https://issues.apache.org/jira/browse/CAMEL-5668 > Project: Camel > Issue Type: Bug > Components: camel-jetty >Affects Versions: 2.9.0, 2.10.0 >Reporter: Claus Ibsen >Assignee: Willem Jiang >Priority: Minor > Fix For: 2.9.4, 2.11.0, 2.10.2 > > Attachments: CAMEL-5668.patch > > > See nabble > http://camel.465427.n5.nabble.com/Help-with-nmr-cxf-endpoints-and-fault-handling-tp5719720.html > If a response is fault=true, then we should force the http response code to > be 500. Which is what the SOAP 1.1 spec mandates. > See section 6.2 at: http://www.w3.org/TR/soap11/#_Ref477795996 -- 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
[jira] [Commented] (CAMEL-5668) camel-jetty - A soap fault should trigger http response code 500
[ https://issues.apache.org/jira/browse/CAMEL-5668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13466609#comment-13466609 ] James Carman commented on CAMEL-5668: - I believe this is reported against the wrong component. The issue actually lies within the HTTP component in the DefaultHttpBinding class. > camel-jetty - A soap fault should trigger http response code 500 > > > Key: CAMEL-5668 > URL: https://issues.apache.org/jira/browse/CAMEL-5668 > Project: Camel > Issue Type: Bug > Components: camel-jetty >Affects Versions: 2.9.0, 2.10.0 >Reporter: Claus Ibsen >Assignee: Willem Jiang >Priority: Minor > Fix For: 2.9.4, 2.11.0, 2.10.2 > > > See nabble > http://camel.465427.n5.nabble.com/Help-with-nmr-cxf-endpoints-and-fault-handling-tp5719720.html > If a response is fault=true, then we should force the http response code to > be 500. Which is what the SOAP 1.1 spec mandates. > See section 6.2 at: http://www.w3.org/TR/soap11/#_Ref477795996 -- 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
[jira] [Commented] (CAMEL-5557) Camel-ZeroMQ Component
[ https://issues.apache.org/jira/browse/CAMEL-5557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13462763#comment-13462763 ] James Carman commented on CAMEL-5557: - What's wrong with just leaving this in "extras" for now while the licensing issues are investigated? > Camel-ZeroMQ Component > -- > > Key: CAMEL-5557 > URL: https://issues.apache.org/jira/browse/CAMEL-5557 > Project: Camel > Issue Type: New Feature >Reporter: stephen samuel >Priority: Minor > Fix For: 2.11.0 > > Attachments: camel-zeromq-inital.patch > > > Contribution of Camel-ZeroMQ component. > I've taken the liberty of adding documentation here: > https://cwiki.apache.org/confluence/display/CAMEL/ZeroMQ > 90% test coverage. -- 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
[jira] [Commented] (CAMEL-5641) JmsBinding Does Not Handle BigInteger and BigDecimal Properly
[
https://issues.apache.org/jira/browse/CAMEL-5641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461229#comment-13461229
]
James Carman commented on CAMEL-5641:
-
I'm going to run the build in my local Jenkins server. I'll grab the snapshot
once it's done. Thanks!
> JmsBinding Does Not Handle BigInteger and BigDecimal Properly
> -
>
> Key: CAMEL-5641
> URL: https://issues.apache.org/jira/browse/CAMEL-5641
> Project: Camel
> Issue Type: Bug
> Components: camel-jms
>Affects Versions: 2.9.3, 2.10.1
> Environment: java version "1.6.0_35"
> Java(TM) SE Runtime Environment (build 1.6.0_35-b10-428-11M3811)
> Java HotSpot(TM) 64-Bit Server VM (build 20.10-b01-428, mixed mode)
>Reporter: James Carman
>Assignee: Christian Müller
>Priority: Minor
> Labels: patch
> Fix For: 2.9.4, 2.11.0, 2.10.2
>
> Attachments: CAMEL-5641.patch
>
>
> According to the documentation:
> "The values must be primitives or their counter objects (such as
> Integer, Long, Character). The types, String, CharSequence, Date,
> BigDecimal and BigInteger are all converted to their toString()
> representation. All other types are dropped."
> So, it would seem that BigInteger should be toString()ed. However, in
> the JmsBinding class, we see the following code:
> {code}
> protected Object getValidJMSHeaderValue(String headerName, Object
> headerValue) {
> if (headerValue instanceof String) {
> return headerValue;
> } else if (headerValue instanceof Number) {
> return headerValue;
> } else if (headerValue instanceof Character) {
> return headerValue;
> } else if (headerValue instanceof CharSequence) {
> return headerValue.toString();
> } else if (headerValue instanceof Boolean) {
> return headerValue;
> } else if (headerValue instanceof Date) {
> return headerValue.toString();
> }
> return null;
> }
> {code}
> Since BigInteger extends Number, it will merely return the instance
> itself.
--
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
[jira] [Updated] (CAMEL-5641) JmsBinding Does Not Handle BigInteger and BigDecimal Properly
[
https://issues.apache.org/jira/browse/CAMEL-5641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman updated CAMEL-5641:
Attachment: CAMEL-5641.patch
Fix with test case.
> JmsBinding Does Not Handle BigInteger and BigDecimal Properly
> -
>
> Key: CAMEL-5641
> URL: https://issues.apache.org/jira/browse/CAMEL-5641
> Project: Camel
> Issue Type: Bug
> Components: camel-jms
> Environment: java version "1.6.0_35"
> Java(TM) SE Runtime Environment (build 1.6.0_35-b10-428-11M3811)
> Java HotSpot(TM) 64-Bit Server VM (build 20.10-b01-428, mixed mode)
>Reporter: James Carman
> Labels: patch
> Attachments: CAMEL-5641.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> According to the documentation:
> "The values must be primitives or their counter objects (such as
> Integer, Long, Character). The types, String, CharSequence, Date,
> BigDecimal and BigInteger are all converted to their toString()
> representation. All other types are dropped."
> So, it would seem that BigInteger should be toString()ed. However, in
> the JmsBinding class, we see the following code:
> {code}
> protected Object getValidJMSHeaderValue(String headerName, Object
> headerValue) {
> if (headerValue instanceof String) {
> return headerValue;
> } else if (headerValue instanceof Number) {
> return headerValue;
> } else if (headerValue instanceof Character) {
> return headerValue;
> } else if (headerValue instanceof CharSequence) {
> return headerValue.toString();
> } else if (headerValue instanceof Boolean) {
> return headerValue;
> } else if (headerValue instanceof Date) {
> return headerValue.toString();
> }
> return null;
> }
> {code}
> Since BigInteger extends Number, it will merely return the instance
> itself.
--
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
[jira] [Created] (CAMEL-5641) JmsBinding Does Not Handle BigInteger and BigDecimal Properly
James Carman created CAMEL-5641:
---
Summary: JmsBinding Does Not Handle BigInteger and BigDecimal
Properly
Key: CAMEL-5641
URL: https://issues.apache.org/jira/browse/CAMEL-5641
Project: Camel
Issue Type: Bug
Components: camel-jms
Environment: java version "1.6.0_35"
Java(TM) SE Runtime Environment (build 1.6.0_35-b10-428-11M3811)
Java HotSpot(TM) 64-Bit Server VM (build 20.10-b01-428, mixed mode)
Reporter: James Carman
According to the documentation:
"The values must be primitives or their counter objects (such as
Integer, Long, Character). The types, String, CharSequence, Date,
BigDecimal and BigInteger are all converted to their toString()
representation. All other types are dropped."
So, it would seem that BigInteger should be toString()ed. However, in
the JmsBinding class, we see the following code:
{code}
protected Object getValidJMSHeaderValue(String headerName, Object headerValue) {
if (headerValue instanceof String) {
return headerValue;
} else if (headerValue instanceof Number) {
return headerValue;
} else if (headerValue instanceof Character) {
return headerValue;
} else if (headerValue instanceof CharSequence) {
return headerValue.toString();
} else if (headerValue instanceof Boolean) {
return headerValue;
} else if (headerValue instanceof Date) {
return headerValue.toString();
}
return null;
}
{code}
Since BigInteger extends Number, it will merely return the instance
itself.
--
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
[jira] [Comment Edited] (CAMEL-5464) camel-jms consumer doesn't send back a reply in all cases
[
https://issues.apache.org/jira/browse/CAMEL-5464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13445928#comment-13445928
]
James Carman edited comment on CAMEL-5464 at 9/1/12 3:30 AM:
-
Okay, cool! Sorry about the regression. I was (and still am) having a
terrible time getting the build to run locally on my machine. I'll keep
tinkering. This is my first Mac laptop, so getting used to Java development on
here is somewhat of a chore. Perhaps I'll just switch to a VM or something
Are we going to update the fix versions/status?
was (Author: jwcarman):
Okay, cool! Sorry about the regression. I was (and still am) having a
terrible time getting the build to run locally on my machine. I'll keep
tinkering. This is my first Mac laptop, so getting used to Java development on
here is somewhat of a chore. Perhaps I'll just switch to a VM or something
> camel-jms consumer doesn't send back a reply in all cases
> -
>
> Key: CAMEL-5464
> URL: https://issues.apache.org/jira/browse/CAMEL-5464
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-jms
>Affects Versions: 2.8.6, 2.9.2, 2.10.0
>Reporter: Raul Kripalani
>Assignee: Willem Jiang
> Attachments: CAMEL-5464.patch
>
>
> In a very simple route consuming from a Camel JMS endpoint receiving InOut
> exchanges (i.e. JMSReplyTo header present), the endpoint will not send back
> replies.
> This happens because Camel JMS only returns a reply if the OUT message is
> set. But if the route looks like: consumer => processor, and Camel doesn't
> find the need to "weave in" an implicit Pipeline processor, no one will
> implicitly take care of mapping the IN message to an OUT message (unless the
> user knows about these internal aspects - but we shouldn't expect them too).
> As a result, these routes DON'T WORK...
> {code}
>
>
>Hello Raul
>
>
>
>
>
>
>
>
>
> {code}
> ... but just by adding an additional log endpoint to the second route (or any
> other thing, for that matter), it starts to work because Camel weaves in the
> Pipeline processor.
> Other workarounds that work:
> * -explicitly wrapping the log endpoint in a DSL-
> * ${in.body}
> Or simply introducing anything that will force Camel to insert a Pipeline
> processor.
> IMHO, there are two solutions to avoid this issue:
> # Always weave in a Pipeline processor (adds overhead in simple routes and
> may cause regressions)
> # Adapt EndpointMessageListener to pick the IN message when the exchange is
> out capable and expectation of a reply exists
> I'm happy to work on a patch for Camel 2.10.1.
> *EDIT:* Just wrapping the single endpoint in doesn't function as
> a workaround.
--
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
[jira] [Commented] (CAMEL-5464) camel-jms consumer doesn't send back a reply in all cases
[
https://issues.apache.org/jira/browse/CAMEL-5464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13445928#comment-13445928
]
James Carman commented on CAMEL-5464:
-
Okay, cool! Sorry about the regression. I was (and still am) having a
terrible time getting the build to run locally on my machine. I'll keep
tinkering. This is my first Mac laptop, so getting used to Java development on
here is somewhat of a chore. Perhaps I'll just switch to a VM or something
> camel-jms consumer doesn't send back a reply in all cases
> -
>
> Key: CAMEL-5464
> URL: https://issues.apache.org/jira/browse/CAMEL-5464
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-jms
>Affects Versions: 2.8.6, 2.9.2, 2.10.0
>Reporter: Raul Kripalani
>Assignee: Willem Jiang
> Attachments: CAMEL-5464.patch
>
>
> In a very simple route consuming from a Camel JMS endpoint receiving InOut
> exchanges (i.e. JMSReplyTo header present), the endpoint will not send back
> replies.
> This happens because Camel JMS only returns a reply if the OUT message is
> set. But if the route looks like: consumer => processor, and Camel doesn't
> find the need to "weave in" an implicit Pipeline processor, no one will
> implicitly take care of mapping the IN message to an OUT message (unless the
> user knows about these internal aspects - but we shouldn't expect them too).
> As a result, these routes DON'T WORK...
> {code}
>
>
>Hello Raul
>
>
>
>
>
>
>
>
>
> {code}
> ... but just by adding an additional log endpoint to the second route (or any
> other thing, for that matter), it starts to work because Camel weaves in the
> Pipeline processor.
> Other workarounds that work:
> * -explicitly wrapping the log endpoint in a DSL-
> * ${in.body}
> Or simply introducing anything that will force Camel to insert a Pipeline
> processor.
> IMHO, there are two solutions to avoid this issue:
> # Always weave in a Pipeline processor (adds overhead in simple routes and
> may cause regressions)
> # Adapt EndpointMessageListener to pick the IN message when the exchange is
> out capable and expectation of a reply exists
> I'm happy to work on a patch for Camel 2.10.1.
> *EDIT:* Just wrapping the single endpoint in doesn't function as
> a workaround.
--
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
[jira] [Updated] (CAMEL-5464) camel-jms consumer doesn't send back a reply in all cases
[
https://issues.apache.org/jira/browse/CAMEL-5464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman updated CAMEL-5464:
Attachment: CAMEL-5464.patch
Here's a patch that implements option #2. Let me know if you see any
regressions. I can't get the full Maven build working on my computer right now.
> camel-jms consumer doesn't send back a reply in all cases
> -
>
> Key: CAMEL-5464
> URL: https://issues.apache.org/jira/browse/CAMEL-5464
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-jms
>Affects Versions: 2.8.6, 2.9.2, 2.10.0
>Reporter: Raul Kripalani
> Attachments: CAMEL-5464.patch
>
>
> In a very simple route consuming from a Camel JMS endpoint receiving InOut
> exchanges (i.e. JMSReplyTo header present), the endpoint will not send back
> replies.
> This happens because Camel JMS only returns a reply if the OUT message is
> set. But if the route looks like: consumer => processor, and Camel doesn't
> find the need to "weave in" an implicit Pipeline processor, no one will
> implicitly take care of mapping the IN message to an OUT message (unless the
> user knows about these internal aspects - but we shouldn't expect them too).
> As a result, these routes DON'T WORK...
> {code}
>
>
>Hello Raul
>
>
>
>
>
>
>
>
>
> {code}
> ... but just by adding an additional log endpoint to the second route (or any
> other thing, for that matter), it starts to work because Camel weaves in the
> Pipeline processor.
> Other workarounds that work:
> * -explicitly wrapping the log endpoint in a DSL-
> * ${in.body}
> Or simply introducing anything that will force Camel to insert a Pipeline
> processor.
> IMHO, there are two solutions to avoid this issue:
> # Always weave in a Pipeline processor (adds overhead in simple routes and
> may cause regressions)
> # Adapt EndpointMessageListener to pick the IN message when the exchange is
> out capable and expectation of a reply exists
> I'm happy to work on a patch for Camel 2.10.1.
> *EDIT:* Just wrapping the single endpoint in doesn't function as
> a workaround.
--
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
[jira] [Commented] (CAMEL-4725) Add support for Callable statements
[ https://issues.apache.org/jira/browse/CAMEL-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13442885#comment-13442885 ] James Carman commented on CAMEL-4725: - You could also switch to H2. I have used that to do SPROC testing. > Add support for Callable statements > --- > > Key: CAMEL-4725 > URL: https://issues.apache.org/jira/browse/CAMEL-4725 > Project: Camel > Issue Type: New Feature > Components: camel-sql >Affects Versions: 2.8.3 >Reporter: Christian Müller >Assignee: Christian Müller > > See > [Nabble|http://camel.465427.n5.nabble.com/call-Oracle-Package-procedure-td5032133.html] > for details. -- 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
[jira] [Commented] (CAMEL-5293) Sending map that contains a serialized object that is not a primitive type causes an exception to be thrown.
[ https://issues.apache.org/jira/browse/CAMEL-5293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13280669#comment-13280669 ] James Carman commented on CAMEL-5293: - You can also do jmsMessageType=Object to force Camel to use a javax.jms.ObjectMessage. > Sending map that contains a serialized object that is not a primitive type > causes an exception to be thrown. > > > Key: CAMEL-5293 > URL: https://issues.apache.org/jira/browse/CAMEL-5293 > Project: Camel > Issue Type: Bug >Affects Versions: 2.9.0 >Reporter: BJ Peter DeLaCruz > Attachments: TestCamelJmsWithMap.java > > > I created a serialized object and put it in a map. I put the map in the body > of a message, and when I tried to send the message, an exception was thrown. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-5293) Sending map that contains a serialized object that is not a primitive type causes an exception to be thrown.
[ https://issues.apache.org/jira/browse/CAMEL-5293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13280668#comment-13280668 ] James Carman commented on CAMEL-5293: - You can try setting transferExchange=true on your URI to just have it transfer the entire exchange. ActiveMQ doesn't allow serializable objects (other than lists and maps) as the "value" of a MapMessage, apparently. > Sending map that contains a serialized object that is not a primitive type > causes an exception to be thrown. > > > Key: CAMEL-5293 > URL: https://issues.apache.org/jira/browse/CAMEL-5293 > Project: Camel > Issue Type: Bug >Affects Versions: 2.9.0 >Reporter: BJ Peter DeLaCruz > Attachments: TestCamelJmsWithMap.java > > > I created a serialized object and put it in a map. I put the map in the body > of a message, and when I tried to send the message, an exception was thrown. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
