[jira] [Commented] (CAMEL-8588) REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header
[
https://issues.apache.org/jira/browse/CAMEL-8588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14392326#comment-14392326
]
Claus Ibsen commented on CAMEL-8588:
You must use 'Location' with a capital L - this seems required by restlet itself
REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header
Key: CAMEL-8588
URL: https://issues.apache.org/jira/browse/CAMEL-8588
Project: Camel
Issue Type: Improvement
Components: camel-restlet
Affects Versions: 2.15.0
Reporter: Camel Guy
Priority: Minor
There doesn't seem to be a way to use the REST DSL in a provider-agnostic way
in order to produce a redirect.
Setting the location header generates a warning sent to the console:
{noformat}
Addition of the standard header location is not allowed. Please use the
equivalent property in the Restlet API.{noformat}
Very small example: http://pastebin.com/Zaq7p0Us
Also see linked JIRA.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-8588) REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header
[
https://issues.apache.org/jira/browse/CAMEL-8588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-8588.
Resolution: Cannot Reproduce
Assignee: Claus Ibsen
REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header
Key: CAMEL-8588
URL: https://issues.apache.org/jira/browse/CAMEL-8588
Project: Camel
Issue Type: Improvement
Components: camel-restlet
Affects Versions: 2.15.0
Reporter: Camel Guy
Assignee: Claus Ibsen
Priority: Minor
There doesn't seem to be a way to use the REST DSL in a provider-agnostic way
in order to produce a redirect.
Setting the location header generates a warning sent to the console:
{noformat}
Addition of the standard header location is not allowed. Please use the
equivalent property in the Restlet API.{noformat}
Very small example: http://pastebin.com/Zaq7p0Us
Also see linked JIRA.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8585) The lazy load option doesn't unlock the file
[
https://issues.apache.org/jira/browse/CAMEL-8585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14392362#comment-14392362
]
Claus Ibsen commented on CAMEL-8585:
This only affects windows users.
The lazy load option doesn't unlock the file
Key: CAMEL-8585
URL: https://issues.apache.org/jira/browse/CAMEL-8585
Project: Camel
Issue Type: Bug
Components: camel-csv
Affects Versions: 2.15.0
Reporter: Antoine Esnault
Priority: Minor
Fix For: 2.15.2, 2.16.0
Hi,
After to upgrade camel from 2.14.1 to 2.15.0, a
org.apache.camel.component.file.GenericFileOperationFailedException Exception
is thrown when camel move/delete the file at the end of process.
After some tests, I've notice that the issue appear when the lazy load option
is enabled. I think, the reader or parser used by the component Apache CSV
1.0 aren't closed at the end of file.
My stacktrace:
{code}
14:30:48,960 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source)
org.apache.camel.component.file.GenericFileOperationFailedException: Error
renaming file from C:\temp\import\source\file_20150304162756890.csv to
C:\temp\import\source\error\file_20150304162756890_20150401143044944.csv
14:30:48,964 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.FileOperations.renameFile(FileOperations.java:81)
14:30:48,966 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.strategy.GenericFileProcessStrategySupport.renameFile(GenericFileProcessStrategySupport.java:113)
14:30:48,973 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy.rollback(GenericFileRenameProcessStrategy.java:66)
14:30:48,976 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.GenericFileOnCompletion.processStrategyRollback(GenericFileOnCompletion.java:151)
14:30:48,977 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.GenericFileOnCompletion.onCompletion(GenericFileOnCompletion.java:86)
14:30:48,979 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.GenericFileOnCompletion.onFailure(GenericFileOnCompletion.java:58)
14:30:48,980 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.util.UnitOfWorkHelper.doneSynchronizations(UnitOfWorkHelper.java:101)
14:30:48,981 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.impl.DefaultUnitOfWork.done(DefaultUnitOfWork.java:229)
14:30:48,982 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.util.UnitOfWorkHelper.doneUow(UnitOfWorkHelper.java:65)
14:30:48,983 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.processor.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:650)
14:30:48,984 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.processor.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:618)
14:30:48,986 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.processor.CamelInternalProcessor$InternalCallback.done(CamelInternalProcessor.java:240)
14:30:48,987 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.impl.MDCUnitOfWork$MDCCallback.done(MDCUnitOfWork.java:231)
14:30:48,988 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.processor.Pipeline.process(Pipeline.java:106)
14:30:48,989 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
14:30:48,991 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.GenericFileConsumer.processExchange(GenericFileConsumer.java:433)
14:30:48,992 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.GenericFileConsumer.processBatch(GenericFileConsumer.java:211)
14:30:48,993 INFO [stdout] (Camel
[jira] [Updated] (CAMEL-8585) The lazy load option doesn't unlock the file
[
https://issues.apache.org/jira/browse/CAMEL-8585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-8585:
---
Fix Version/s: 2.16.0
2.15.2
The lazy load option doesn't unlock the file
Key: CAMEL-8585
URL: https://issues.apache.org/jira/browse/CAMEL-8585
Project: Camel
Issue Type: Bug
Components: camel-csv
Affects Versions: 2.15.0
Reporter: Antoine Esnault
Priority: Minor
Fix For: 2.15.2, 2.16.0
Hi,
After to upgrade camel from 2.14.1 to 2.15.0, a
org.apache.camel.component.file.GenericFileOperationFailedException Exception
is thrown when camel move/delete the file at the end of process.
After some tests, I've notice that the issue appear when the lazy load option
is enabled. I think, the reader or parser used by the component Apache CSV
1.0 aren't closed at the end of file.
My stacktrace:
{code}
14:30:48,960 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source)
org.apache.camel.component.file.GenericFileOperationFailedException: Error
renaming file from C:\temp\import\source\file_20150304162756890.csv to
C:\temp\import\source\error\file_20150304162756890_20150401143044944.csv
14:30:48,964 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.FileOperations.renameFile(FileOperations.java:81)
14:30:48,966 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.strategy.GenericFileProcessStrategySupport.renameFile(GenericFileProcessStrategySupport.java:113)
14:30:48,973 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy.rollback(GenericFileRenameProcessStrategy.java:66)
14:30:48,976 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.GenericFileOnCompletion.processStrategyRollback(GenericFileOnCompletion.java:151)
14:30:48,977 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.GenericFileOnCompletion.onCompletion(GenericFileOnCompletion.java:86)
14:30:48,979 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.GenericFileOnCompletion.onFailure(GenericFileOnCompletion.java:58)
14:30:48,980 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.util.UnitOfWorkHelper.doneSynchronizations(UnitOfWorkHelper.java:101)
14:30:48,981 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.impl.DefaultUnitOfWork.done(DefaultUnitOfWork.java:229)
14:30:48,982 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.util.UnitOfWorkHelper.doneUow(UnitOfWorkHelper.java:65)
14:30:48,983 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.processor.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:650)
14:30:48,984 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.processor.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:618)
14:30:48,986 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.processor.CamelInternalProcessor$InternalCallback.done(CamelInternalProcessor.java:240)
14:30:48,987 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.impl.MDCUnitOfWork$MDCCallback.done(MDCUnitOfWork.java:231)
14:30:48,988 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.processor.Pipeline.process(Pipeline.java:106)
14:30:48,989 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
14:30:48,991 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.GenericFileConsumer.processExchange(GenericFileConsumer.java:433)
14:30:48,992 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.GenericFileConsumer.processBatch(GenericFileConsumer.java:211)
14:30:48,993 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
[jira] [Updated] (CAMEL-8585) The lazy load option doesn't unlock the file
[
https://issues.apache.org/jira/browse/CAMEL-8585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-8585:
---
Priority: Minor (was: Critical)
The lazy load option doesn't unlock the file
Key: CAMEL-8585
URL: https://issues.apache.org/jira/browse/CAMEL-8585
Project: Camel
Issue Type: Bug
Components: camel-csv
Affects Versions: 2.15.0
Reporter: Antoine Esnault
Priority: Minor
Fix For: 2.15.2, 2.16.0
Hi,
After to upgrade camel from 2.14.1 to 2.15.0, a
org.apache.camel.component.file.GenericFileOperationFailedException Exception
is thrown when camel move/delete the file at the end of process.
After some tests, I've notice that the issue appear when the lazy load option
is enabled. I think, the reader or parser used by the component Apache CSV
1.0 aren't closed at the end of file.
My stacktrace:
{code}
14:30:48,960 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source)
org.apache.camel.component.file.GenericFileOperationFailedException: Error
renaming file from C:\temp\import\source\file_20150304162756890.csv to
C:\temp\import\source\error\file_20150304162756890_20150401143044944.csv
14:30:48,964 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.FileOperations.renameFile(FileOperations.java:81)
14:30:48,966 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.strategy.GenericFileProcessStrategySupport.renameFile(GenericFileProcessStrategySupport.java:113)
14:30:48,973 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy.rollback(GenericFileRenameProcessStrategy.java:66)
14:30:48,976 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.GenericFileOnCompletion.processStrategyRollback(GenericFileOnCompletion.java:151)
14:30:48,977 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.GenericFileOnCompletion.onCompletion(GenericFileOnCompletion.java:86)
14:30:48,979 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.GenericFileOnCompletion.onFailure(GenericFileOnCompletion.java:58)
14:30:48,980 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.util.UnitOfWorkHelper.doneSynchronizations(UnitOfWorkHelper.java:101)
14:30:48,981 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.impl.DefaultUnitOfWork.done(DefaultUnitOfWork.java:229)
14:30:48,982 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.util.UnitOfWorkHelper.doneUow(UnitOfWorkHelper.java:65)
14:30:48,983 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.processor.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:650)
14:30:48,984 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.processor.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:618)
14:30:48,986 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.processor.CamelInternalProcessor$InternalCallback.done(CamelInternalProcessor.java:240)
14:30:48,987 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.impl.MDCUnitOfWork$MDCCallback.done(MDCUnitOfWork.java:231)
14:30:48,988 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.processor.Pipeline.process(Pipeline.java:106)
14:30:48,989 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
14:30:48,991 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.GenericFileConsumer.processExchange(GenericFileConsumer.java:433)
14:30:48,992 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.GenericFileConsumer.processBatch(GenericFileConsumer.java:211)
14:30:48,993 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
[jira] [Commented] (CAMEL-8582) No way to specify a custom ModelJAXBContextFactory when using Spring DSL/XML Namespace
[ https://issues.apache.org/jira/browse/CAMEL-8582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14392395#comment-14392395 ] Claus Ibsen commented on CAMEL-8582: Can you remove the +private String modelJAXBContextFactoryRef; +@XmlAttribute(required = false) We dont want the camelContext to have these kind of refs for spi and uncommon used functionality. The spi for this should be the bean lookup style only. No way to specify a custom ModelJAXBContextFactory when using Spring DSL/XML Namespace -- Key: CAMEL-8582 URL: https://issues.apache.org/jira/browse/CAMEL-8582 Project: Camel Issue Type: Improvement Components: camel-spring Affects Versions: 2.15.0 Reporter: Aaron Whiteside Priority: Minor Fix For: 2.16.0 Attachments: CAMEL-8582.patch No way to specify a custom ModelJAXBContextFactory when using Spring DSL/Xml Namespace. The ModelJAXBContextFactory reference should be specifiable on the CamelContext Spring XML Namespace. And it should be searched via the spring bean registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8582) No way to specify a custom ModelJAXBContextFactory when using Spring DSL/XML Namespace
[ https://issues.apache.org/jira/browse/CAMEL-8582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-8582: --- Fix Version/s: 2.16.0 No way to specify a custom ModelJAXBContextFactory when using Spring DSL/XML Namespace -- Key: CAMEL-8582 URL: https://issues.apache.org/jira/browse/CAMEL-8582 Project: Camel Issue Type: Improvement Components: camel-spring Affects Versions: 2.15.0 Reporter: Aaron Whiteside Priority: Minor Fix For: 2.16.0 Attachments: CAMEL-8582.patch No way to specify a custom ModelJAXBContextFactory when using Spring DSL/Xml Namespace. The ModelJAXBContextFactory reference should be specifiable on the CamelContext Spring XML Namespace. And it should be searched via the spring bean registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8592) NPE in AbstractListAggregationStrategy if empty list
[ https://issues.apache.org/jira/browse/CAMEL-8592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-8592: --- Estimated Complexity: Novice (was: Unknown) NPE in AbstractListAggregationStrategy if empty list Key: CAMEL-8592 URL: https://issues.apache.org/jira/browse/CAMEL-8592 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.15.1 Reporter: Claus Ibsen Priority: Minor Fix For: 2.15.2, 2.16.0 See nabble http://camel.465427.n5.nabble.com/NullPointerException-on-empty-List-in-AbstractListAggregationStrategy-tp5764965.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7833) create an extension of the RX ObservableT to add more of the Camel DSL in there (e.g. to() or to go back to the general camel DSL)
[
https://issues.apache.org/jira/browse/CAMEL-7833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14392472#comment-14392472
]
ASF GitHub Bot commented on CAMEL-7833:
---
Github user yuruki closed the pull request at:
https://github.com/apache/camel/pull/459
create an extension of the RX ObservableT to add more of the Camel DSL in
there (e.g. to() or to go back to the general camel DSL)
Key: CAMEL-7833
URL: https://issues.apache.org/jira/browse/CAMEL-7833
Project: Camel
Issue Type: New Feature
Reporter: james strachan
Assignee: Willem Jiang
Fix For: 2.16.0
with Camel RX and java 8 we can do some nice lambdas and typesafe filtering
and transformation:
{code}
ReactiveCamel rx = new ReactiveCamel(camelContext);
ObservableOrder observable = rx.toObservable(seda:orders, Order.class);
// now lets filter and map using Java 8
ObservableString largeOrderIds = observable.
filter(order - order.getAmount() 100.0).
map(order - order.getId());
rx.sendTo(observable, activemq:MyQueue);
{code}
however the DSL isn't quite as nice as Camel's due to the lack of the camel
verbs like to(). It'd be nice to provide an extended ObservableT
interface which adds more of Camel's DSL in there too; so you can still use
things the RX way; but can also reuse the camel DSL too (in a typesafe way).
e.g. something like this
{code}
// Observable comes from RX; it'd be nice to have a camel extended version so
we can add camel DSL stuff in there like to() etc
CamelStreamOrder orders = rx.stream(seda:orders, Order.class);
// now lets filter and map using Java 8
orders.
filter(order - order.getAmount() 100.0).
map(order - order.getId()).
to(activemq:MyQueue);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8583) CamelContext.getEndpointRegistry() should return EndpointRegistryString, but returns DefaultEndpointRegistry which is EndpointRegistryEndpointKey
[ https://issues.apache.org/jira/browse/CAMEL-8583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14392332#comment-14392332 ] Willem Jiang commented on CAMEL-8583: - Why do you need to access the EndpointRegistry? It's an internal API and we don't want user to mess up with the Registry. CamelContext.getEndpointRegistry() should return EndpointRegistryString, but returns DefaultEndpointRegistry which is EndpointRegistryEndpointKey - Key: CAMEL-8583 URL: https://issues.apache.org/jira/browse/CAMEL-8583 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.15.0 Reporter: Iikku Mattila Priority: Blocker I have org.apache.camel.spring.javaconfig.CamelConfiguration -instance, in which I setup the camel context. In setupCamelContext(CamelContext camelContext) I'm trying camelContext.getEndpointRegistry().put(name, endpoint); which fails, because CamelContext.getEndpointRegistry() returns DefaultEndpointRegistry which is EndpointRegistryEndpointKey and thus only has method put(EndpointKey key, Endpoint endpoint) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-8585) The lazy load option doesn't unlock the file
[
https://issues.apache.org/jira/browse/CAMEL-8585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-8585:
--
Assignee: Claus Ibsen
The lazy load option doesn't unlock the file
Key: CAMEL-8585
URL: https://issues.apache.org/jira/browse/CAMEL-8585
Project: Camel
Issue Type: Bug
Components: camel-csv
Affects Versions: 2.15.0
Reporter: Antoine Esnault
Assignee: Claus Ibsen
Priority: Minor
Fix For: 2.15.2, 2.16.0
Hi,
After to upgrade camel from 2.14.1 to 2.15.0, a
org.apache.camel.component.file.GenericFileOperationFailedException Exception
is thrown when camel move/delete the file at the end of process.
After some tests, I've notice that the issue appear when the lazy load option
is enabled. I think, the reader or parser used by the component Apache CSV
1.0 aren't closed at the end of file.
My stacktrace:
{code}
14:30:48,960 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source)
org.apache.camel.component.file.GenericFileOperationFailedException: Error
renaming file from C:\temp\import\source\file_20150304162756890.csv to
C:\temp\import\source\error\file_20150304162756890_20150401143044944.csv
14:30:48,964 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.FileOperations.renameFile(FileOperations.java:81)
14:30:48,966 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.strategy.GenericFileProcessStrategySupport.renameFile(GenericFileProcessStrategySupport.java:113)
14:30:48,973 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy.rollback(GenericFileRenameProcessStrategy.java:66)
14:30:48,976 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.GenericFileOnCompletion.processStrategyRollback(GenericFileOnCompletion.java:151)
14:30:48,977 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.GenericFileOnCompletion.onCompletion(GenericFileOnCompletion.java:86)
14:30:48,979 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.GenericFileOnCompletion.onFailure(GenericFileOnCompletion.java:58)
14:30:48,980 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.util.UnitOfWorkHelper.doneSynchronizations(UnitOfWorkHelper.java:101)
14:30:48,981 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.impl.DefaultUnitOfWork.done(DefaultUnitOfWork.java:229)
14:30:48,982 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.util.UnitOfWorkHelper.doneUow(UnitOfWorkHelper.java:65)
14:30:48,983 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.processor.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:650)
14:30:48,984 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.processor.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:618)
14:30:48,986 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.processor.CamelInternalProcessor$InternalCallback.done(CamelInternalProcessor.java:240)
14:30:48,987 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.impl.MDCUnitOfWork$MDCCallback.done(MDCUnitOfWork.java:231)
14:30:48,988 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.processor.Pipeline.process(Pipeline.java:106)
14:30:48,989 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
14:30:48,991 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.GenericFileConsumer.processExchange(GenericFileConsumer.java:433)
14:30:48,992 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.GenericFileConsumer.processBatch(GenericFileConsumer.java:211)
14:30:48,993 INFO [stdout] (Camel (Socle-CamelContext)
[jira] [Commented] (CAMEL-8570) NullPointerException when using CXF-component in a spring-boot application with loglevel = INFO
[
https://issues.apache.org/jira/browse/CAMEL-8570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14392390#comment-14392390
]
Claus Ibsen commented on CAMEL-8570:
Can you build and try with latest 2.15-SNAPSHOT ?
NullPointerException when using CXF-component in a spring-boot application
with loglevel = INFO
Key: CAMEL-8570
URL: https://issues.apache.org/jira/browse/CAMEL-8570
Project: Camel
Issue Type: Bug
Components: camel-core, camel-cxf, camel-spring-boot
Affects Versions: 2.15.0, 2.15.1
Reporter: Jakob Thun
Fix For: 2.16.0
I get a NullPointerException when using log-level INFO or finer in a
spring-boot application with CXF.
The exception is thrown from DefaultCamelContext.java:2449, where it tries to
log how many routes have been started.
I have made an example project to reproduce it, it's available here:
https://github.com/jakobthun/spring-boot-camel-cxf-logging-bug
I have tried with camel version: 2.15.0 2.15-SNAPSHOT. Both have the same
behaviour.
+Andrew Block started som analysis:+
It is running into issues in this code block which is executed at logging
level = INFO
if (log.isInfoEnabled()) {
// count how many routes are actually started
int started = 0;
for (Route route : getRoutes()) {
if (getRouteStatus(route.getId()).isStarted()) {
started++;
}
}
log.info(Total + getRoutes().size() + routes, of which +
started + is started.);
log.info(Apache Camel + getVersion() + (CamelContext: +
getName() + ) started in + TimeUtils.printDuration(stopWatch.taken()));
}
The exception occurs when the status for the route is pulled from the route
service. It is null and the exception is thrown. The route is initially spun
up but then refreshes when the CXF consumer is initialized.
Swapping it to test with a direct consumer does not result in a similar
situation and startup succeeds at all logging level.
It appears the route is not being registered with the route service
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8570) NullPointerException when using CXF-component in a spring-boot application with loglevel = INFO
[
https://issues.apache.org/jira/browse/CAMEL-8570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-8570:
---
Fix Version/s: 2.16.0
NullPointerException when using CXF-component in a spring-boot application
with loglevel = INFO
Key: CAMEL-8570
URL: https://issues.apache.org/jira/browse/CAMEL-8570
Project: Camel
Issue Type: Bug
Components: camel-core, camel-cxf, camel-spring-boot
Affects Versions: 2.15.0, 2.15.1
Reporter: Jakob Thun
Priority: Minor
Fix For: 2.16.0
I get a NullPointerException when using log-level INFO or finer in a
spring-boot application with CXF.
The exception is thrown from DefaultCamelContext.java:2449, where it tries to
log how many routes have been started.
I have made an example project to reproduce it, it's available here:
https://github.com/jakobthun/spring-boot-camel-cxf-logging-bug
I have tried with camel version: 2.15.0 2.15-SNAPSHOT. Both have the same
behaviour.
+Andrew Block started som analysis:+
It is running into issues in this code block which is executed at logging
level = INFO
if (log.isInfoEnabled()) {
// count how many routes are actually started
int started = 0;
for (Route route : getRoutes()) {
if (getRouteStatus(route.getId()).isStarted()) {
started++;
}
}
log.info(Total + getRoutes().size() + routes, of which +
started + is started.);
log.info(Apache Camel + getVersion() + (CamelContext: +
getName() + ) started in + TimeUtils.printDuration(stopWatch.taken()));
}
The exception occurs when the status for the route is pulled from the route
service. It is null and the exception is thrown. The route is initially spun
up but then refreshes when the CXF consumer is initialized.
Swapping it to test with a direct consumer does not result in a similar
situation and startup succeeds at all logging level.
It appears the route is not being registered with the route service
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8570) NullPointerException when using CXF-component in a spring-boot application with loglevel = INFO
[
https://issues.apache.org/jira/browse/CAMEL-8570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-8570:
---
Priority: Minor (was: Major)
NullPointerException when using CXF-component in a spring-boot application
with loglevel = INFO
Key: CAMEL-8570
URL: https://issues.apache.org/jira/browse/CAMEL-8570
Project: Camel
Issue Type: Bug
Components: camel-core, camel-cxf, camel-spring-boot
Affects Versions: 2.15.0, 2.15.1
Reporter: Jakob Thun
Priority: Minor
Fix For: 2.16.0
I get a NullPointerException when using log-level INFO or finer in a
spring-boot application with CXF.
The exception is thrown from DefaultCamelContext.java:2449, where it tries to
log how many routes have been started.
I have made an example project to reproduce it, it's available here:
https://github.com/jakobthun/spring-boot-camel-cxf-logging-bug
I have tried with camel version: 2.15.0 2.15-SNAPSHOT. Both have the same
behaviour.
+Andrew Block started som analysis:+
It is running into issues in this code block which is executed at logging
level = INFO
if (log.isInfoEnabled()) {
// count how many routes are actually started
int started = 0;
for (Route route : getRoutes()) {
if (getRouteStatus(route.getId()).isStarted()) {
started++;
}
}
log.info(Total + getRoutes().size() + routes, of which +
started + is started.);
log.info(Apache Camel + getVersion() + (CamelContext: +
getName() + ) started in + TimeUtils.printDuration(stopWatch.taken()));
}
The exception occurs when the status for the route is pulled from the route
service. It is null and the exception is thrown. The route is initially spun
up but then refreshes when the CXF consumer is initialized.
Swapping it to test with a direct consumer does not result in a similar
situation and startup succeeds at all logging level.
It appears the route is not being registered with the route service
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-7833) create an extension of the RX ObservableT to add more of the Camel DSL in there (e.g. to() or to go back to the general camel DSL)
[
https://issues.apache.org/jira/browse/CAMEL-7833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang reassigned CAMEL-7833:
---
Assignee: Willem Jiang
create an extension of the RX ObservableT to add more of the Camel DSL in
there (e.g. to() or to go back to the general camel DSL)
Key: CAMEL-7833
URL: https://issues.apache.org/jira/browse/CAMEL-7833
Project: Camel
Issue Type: New Feature
Reporter: james strachan
Assignee: Willem Jiang
with Camel RX and java 8 we can do some nice lambdas and typesafe filtering
and transformation:
{code}
ReactiveCamel rx = new ReactiveCamel(camelContext);
ObservableOrder observable = rx.toObservable(seda:orders, Order.class);
// now lets filter and map using Java 8
ObservableString largeOrderIds = observable.
filter(order - order.getAmount() 100.0).
map(order - order.getId());
rx.sendTo(observable, activemq:MyQueue);
{code}
however the DSL isn't quite as nice as Camel's due to the lack of the camel
verbs like to(). It'd be nice to provide an extended ObservableT
interface which adds more of Camel's DSL in there too; so you can still use
things the RX way; but can also reuse the camel DSL too (in a typesafe way).
e.g. something like this
{code}
// Observable comes from RX; it'd be nice to have a camel extended version so
we can add camel DSL stuff in there like to() etc
CamelStreamOrder orders = rx.stream(seda:orders, Order.class);
// now lets filter and map using Java 8
orders.
filter(order - order.getAmount() 100.0).
map(order - order.getId()).
to(activemq:MyQueue);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-8584) Circuit breaker does not honour halfOpenAfter period
[ https://issues.apache.org/jira/browse/CAMEL-8584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-8584. Resolution: Fixed Thanks for the PR Circuit breaker does not honour halfOpenAfter period Key: CAMEL-8584 URL: https://issues.apache.org/jira/browse/CAMEL-8584 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.15.0, 2.15.1 Reporter: jack patwork Assignee: Claus Ibsen Fix For: 2.15.2, 2.16.0 The CircuitBreakerLoadBalancer will always switch to a half-open state immediately after the first rejected message instead of honouring the halfOpenAfter period. It's due to the failed message count getting reset in the rejectExchange method: https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/processor/loadbalancer/CircuitBreakerLoadBalancer.java#L207 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8572) Upgrade aws sdk java version and add support for DynamoDB v2
[ https://issues.apache.org/jira/browse/CAMEL-8572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14392448#comment-14392448 ] Claus Ibsen commented on CAMEL-8572: Getting karma to assign jira is unfortunately become harder - so ppl usually just add a comment they work on a ticket. Upgrade aws sdk java version and add support for DynamoDB v2 Key: CAMEL-8572 URL: https://issues.apache.org/jira/browse/CAMEL-8572 Project: Camel Issue Type: Improvement Components: camel-aws Reporter: Andrea Cosentino Priority: Minor Labels: aws, aws-ddb Fix For: 2.16.0 Hi, We should upgrade the AWS sdk version to something = 1.9. I've made some test on the code, and the DynamoDB part of the component is affected from this change. We need to support DynamoDB v2, if we want to use a newer version. I would like to study this improvement and work on this. Is possible to assign this JIRA to me? I would like to be able to assign JIRAs to myself. Is it possible? Bye, Andrea -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8584) Circuit breaker does not honour halfOpenAfter period
[ https://issues.apache.org/jira/browse/CAMEL-8584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-8584: --- Fix Version/s: 2.16.0 2.15.2 Circuit breaker does not honour halfOpenAfter period Key: CAMEL-8584 URL: https://issues.apache.org/jira/browse/CAMEL-8584 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.15.0, 2.15.1 Reporter: jack patwork Fix For: 2.15.2, 2.16.0 The CircuitBreakerLoadBalancer will always switch to a half-open state immediately after the first rejected message instead of honouring the halfOpenAfter period. It's due to the failed message count getting reset in the rejectExchange method: https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/processor/loadbalancer/CircuitBreakerLoadBalancer.java#L207 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-8584) Circuit breaker does not honour halfOpenAfter period
[ https://issues.apache.org/jira/browse/CAMEL-8584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-8584: -- Assignee: Claus Ibsen Circuit breaker does not honour halfOpenAfter period Key: CAMEL-8584 URL: https://issues.apache.org/jira/browse/CAMEL-8584 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.15.0, 2.15.1 Reporter: jack patwork Assignee: Claus Ibsen Fix For: 2.15.2, 2.16.0 The CircuitBreakerLoadBalancer will always switch to a half-open state immediately after the first rejected message instead of honouring the halfOpenAfter period. It's due to the failed message count getting reset in the rejectExchange method: https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/processor/loadbalancer/CircuitBreakerLoadBalancer.java#L207 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8585) The lazy load option doesn't unlock the file
[
https://issues.apache.org/jira/browse/CAMEL-8585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-8585.
Resolution: Fixed
Thanks for reporting.
The lazy load option doesn't unlock the file
Key: CAMEL-8585
URL: https://issues.apache.org/jira/browse/CAMEL-8585
Project: Camel
Issue Type: Bug
Components: camel-csv
Affects Versions: 2.15.0
Reporter: Antoine Esnault
Assignee: Claus Ibsen
Priority: Minor
Fix For: 2.15.2, 2.16.0
Hi,
After to upgrade camel from 2.14.1 to 2.15.0, a
org.apache.camel.component.file.GenericFileOperationFailedException Exception
is thrown when camel move/delete the file at the end of process.
After some tests, I've notice that the issue appear when the lazy load option
is enabled. I think, the reader or parser used by the component Apache CSV
1.0 aren't closed at the end of file.
My stacktrace:
{code}
14:30:48,960 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source)
org.apache.camel.component.file.GenericFileOperationFailedException: Error
renaming file from C:\temp\import\source\file_20150304162756890.csv to
C:\temp\import\source\error\file_20150304162756890_20150401143044944.csv
14:30:48,964 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.FileOperations.renameFile(FileOperations.java:81)
14:30:48,966 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.strategy.GenericFileProcessStrategySupport.renameFile(GenericFileProcessStrategySupport.java:113)
14:30:48,973 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy.rollback(GenericFileRenameProcessStrategy.java:66)
14:30:48,976 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.GenericFileOnCompletion.processStrategyRollback(GenericFileOnCompletion.java:151)
14:30:48,977 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.GenericFileOnCompletion.onCompletion(GenericFileOnCompletion.java:86)
14:30:48,979 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.GenericFileOnCompletion.onFailure(GenericFileOnCompletion.java:58)
14:30:48,980 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.util.UnitOfWorkHelper.doneSynchronizations(UnitOfWorkHelper.java:101)
14:30:48,981 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.impl.DefaultUnitOfWork.done(DefaultUnitOfWork.java:229)
14:30:48,982 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.util.UnitOfWorkHelper.doneUow(UnitOfWorkHelper.java:65)
14:30:48,983 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.processor.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:650)
14:30:48,984 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.processor.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:618)
14:30:48,986 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.processor.CamelInternalProcessor$InternalCallback.done(CamelInternalProcessor.java:240)
14:30:48,987 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.impl.MDCUnitOfWork$MDCCallback.done(MDCUnitOfWork.java:231)
14:30:48,988 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.processor.Pipeline.process(Pipeline.java:106)
14:30:48,989 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
14:30:48,991 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.GenericFileConsumer.processExchange(GenericFileConsumer.java:433)
14:30:48,992 INFO [stdout] (Camel (Socle-CamelContext) thread #3 -
file://C:/temp/import/source) at
org.apache.camel.component.file.GenericFileConsumer.processBatch(GenericFileConsumer.java:211)
14:30:48,993 INFO [stdout] (Camel
[jira] [Resolved] (CAMEL-8548) upgrade commons-codec version to 1.10
[ https://issues.apache.org/jira/browse/CAMEL-8548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-8548. Resolution: Fixed upgrade commons-codec version to 1.10 - Key: CAMEL-8548 URL: https://issues.apache.org/jira/browse/CAMEL-8548 Project: Camel Issue Type: Task Reporter: Freeman Fang Assignee: Willem Jiang Fix For: 2.16.0, 2.15.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8548) upgrade commons-codec version to 1.10
[ https://issues.apache.org/jira/browse/CAMEL-8548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-8548: --- Fix Version/s: 2.15.1 upgrade commons-codec version to 1.10 - Key: CAMEL-8548 URL: https://issues.apache.org/jira/browse/CAMEL-8548 Project: Camel Issue Type: Task Reporter: Freeman Fang Assignee: Willem Jiang Fix For: 2.15.1, 2.16.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8569) Ability to easily extract email attachments
[ https://issues.apache.org/jira/browse/CAMEL-8569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14392453#comment-14392453 ] Claus Ibsen commented on CAMEL-8569: I think its better to improve the existing? Can you not add an option to turn on reading the attachments as byte[]. Then ppl can turn this option on and get the behavior in your impl. Would you be able take a look at that? Ability to easily extract email attachments --- Key: CAMEL-8569 URL: https://issues.apache.org/jira/browse/CAMEL-8569 Project: Camel Issue Type: Improvement Components: camel-mail Affects Versions: 2.15.0 Reporter: Simon van der Sluis Labels: features Original Estimate: 2h Remaining Estimate: 2h The existing support for splitting an email by it's attachments (org.apache.camel.component.mail.SplitAttachmentsExpression) is limiting that the attachments are still mime encoded, and cannot be easily used by the next stage in a route. e.g. from(pop3://ja...@mymailserver.com?... .split(new SplitAttachmentsExpression()) .to(file:///myAttachmentsFolder) doesn't work An improved splitter that decodes the mime parts into byte arrays would be more useful -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8589) url.getPort returning -1, needs additional check
[
https://issues.apache.org/jira/browse/CAMEL-8589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang resolved CAMEL-8589.
-
Resolution: Fixed
Fix Version/s: 2.16.0
2.15.2
Applied the patch into camel master and camel-2.15.x branches with thanks to
Matthew.
url.getPort returning -1, needs additional check
Key: CAMEL-8589
URL: https://issues.apache.org/jira/browse/CAMEL-8589
Project: Camel
Issue Type: Bug
Components: camel-swagger
Affects Versions: 2.15.0
Reporter: Matthew Casperson
Assignee: Willem Jiang
Priority: Minor
Fix For: 2.15.2, 2.16.0
In our environment, the camel-swagger component is building relative urls
with a port of -1.
http://docs.oracle.com/javase/7/docs/api/java/net/URL.html#getPort() is what
is returning -1.
The fix is to change
if (url.getPort != 80) {
to
if (url.getPort != 80 url.getPort != -1) {
in RestSwaggerApiDeclarationServlet.scala. See
https://github.com/apache/camel/blob/camel-2.15.x/components/camel-swagger/src/main/scala/org/apache/camel/component/swagger/RestSwaggerApiDeclarationServlet.scala#L111
for the line of code that is affected.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8583) CamelContext.getEndpointRegistry() should return EndpointRegistryString, but returns DefaultEndpointRegistry which is EndpointRegistryEndpointKey
[ https://issues.apache.org/jira/browse/CAMEL-8583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14392350#comment-14392350 ] Claus Ibsen commented on CAMEL-8583: Yes its not currently intended for end users to put endpoints manually. CamelContext.getEndpointRegistry() should return EndpointRegistryString, but returns DefaultEndpointRegistry which is EndpointRegistryEndpointKey - Key: CAMEL-8583 URL: https://issues.apache.org/jira/browse/CAMEL-8583 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.15.0 Reporter: Iikku Mattila Priority: Minor I have org.apache.camel.spring.javaconfig.CamelConfiguration -instance, in which I setup the camel context. In setupCamelContext(CamelContext camelContext) I'm trying camelContext.getEndpointRegistry().put(name, endpoint); which fails, because CamelContext.getEndpointRegistry() returns DefaultEndpointRegistry which is EndpointRegistryEndpointKey and thus only has method put(EndpointKey key, Endpoint endpoint) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-8583) CamelContext.getEndpointRegistry() should return EndpointRegistryString, but returns DefaultEndpointRegistry which is EndpointRegistryEndpointKey
[ https://issues.apache.org/jira/browse/CAMEL-8583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-8583: -- Assignee: Claus Ibsen CamelContext.getEndpointRegistry() should return EndpointRegistryString, but returns DefaultEndpointRegistry which is EndpointRegistryEndpointKey - Key: CAMEL-8583 URL: https://issues.apache.org/jira/browse/CAMEL-8583 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.15.0 Reporter: Iikku Mattila Assignee: Claus Ibsen Priority: Minor I have org.apache.camel.spring.javaconfig.CamelConfiguration -instance, in which I setup the camel context. In setupCamelContext(CamelContext camelContext) I'm trying camelContext.getEndpointRegistry().put(name, endpoint); which fails, because CamelContext.getEndpointRegistry() returns DefaultEndpointRegistry which is EndpointRegistryEndpointKey and thus only has method put(EndpointKey key, Endpoint endpoint) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8588) REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header
[
https://issues.apache.org/jira/browse/CAMEL-8588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-8588:
---
Assignee: (was: Claus Ibsen)
REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header
Key: CAMEL-8588
URL: https://issues.apache.org/jira/browse/CAMEL-8588
Project: Camel
Issue Type: Improvement
Components: camel-restlet
Affects Versions: 2.15.0
Reporter: Camel Guy
Priority: Minor
There doesn't seem to be a way to use the REST DSL in a provider-agnostic way
in order to produce a redirect.
Setting the location header generates a warning sent to the console:
{noformat}
Addition of the standard header location is not allowed. Please use the
equivalent property in the Restlet API.{noformat}
Very small example: http://pastebin.com/Zaq7p0Us
Also see linked JIRA.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8565) Support for camel-gson to handle generic types
[ https://issues.apache.org/jira/browse/CAMEL-8565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-8565: --- Fix Version/s: 2.16.0 Support for camel-gson to handle generic types -- Key: CAMEL-8565 URL: https://issues.apache.org/jira/browse/CAMEL-8565 Project: Camel Issue Type: New Feature Components: camel-gson Reporter: Andrew Block Priority: Minor Fix For: 2.16.0 Currently camel-gson only supports the ability to marshal or unmarshall a concrete class. It should provide the functionality handle generic types such as collections. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8590) camel-bindy - Add option keepQuotes to allow to keep the quote charachters
Claus Ibsen created CAMEL-8590: -- Summary: camel-bindy - Add option keepQuotes to allow to keep the quote charachters Key: CAMEL-8590 URL: https://issues.apache.org/jira/browse/CAMEL-8590 Project: Camel Issue Type: Improvement Components: camel-bindy Affects Versions: 2.15.1 Reporter: Claus Ibsen See nabble http://camel.465427.n5.nabble.com/Marshal-with-quote-in-CSV-tp5765160.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7833) create an extension of the RX ObservableT to add more of the Camel DSL in there (e.g. to() or to go back to the general camel DSL)
[
https://issues.apache.org/jira/browse/CAMEL-7833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang resolved CAMEL-7833.
-
Resolution: Fixed
Fix Version/s: 2.16.0
Applied the patch into camel master branch with thanks to Jyrki, I also did
some change on the CamelOperation to use ProducerTemplate and handler the
exception which is thrown from to processing.
create an extension of the RX ObservableT to add more of the Camel DSL in
there (e.g. to() or to go back to the general camel DSL)
Key: CAMEL-7833
URL: https://issues.apache.org/jira/browse/CAMEL-7833
Project: Camel
Issue Type: New Feature
Reporter: james strachan
Assignee: Willem Jiang
Fix For: 2.16.0
with Camel RX and java 8 we can do some nice lambdas and typesafe filtering
and transformation:
{code}
ReactiveCamel rx = new ReactiveCamel(camelContext);
ObservableOrder observable = rx.toObservable(seda:orders, Order.class);
// now lets filter and map using Java 8
ObservableString largeOrderIds = observable.
filter(order - order.getAmount() 100.0).
map(order - order.getId());
rx.sendTo(observable, activemq:MyQueue);
{code}
however the DSL isn't quite as nice as Camel's due to the lack of the camel
verbs like to(). It'd be nice to provide an extended ObservableT
interface which adds more of Camel's DSL in there too; so you can still use
things the RX way; but can also reuse the camel DSL too (in a typesafe way).
e.g. something like this
{code}
// Observable comes from RX; it'd be nice to have a camel extended version so
we can add camel DSL stuff in there like to() etc
CamelStreamOrder orders = rx.stream(seda:orders, Order.class);
// now lets filter and map using Java 8
orders.
filter(order - order.getAmount() 100.0).
map(order - order.getId()).
to(activemq:MyQueue);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8588) REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header
[
https://issues.apache.org/jira/browse/CAMEL-8588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14392323#comment-14392323
]
Claus Ibsen commented on CAMEL-8588:
See this FAQ
http://camel.apache.org/using-getin-or-getout-methods-on-exchange.html
And this test works fine setting a location header
org.apache.camel.component.restlet.RestletRedirectTest
REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header
Key: CAMEL-8588
URL: https://issues.apache.org/jira/browse/CAMEL-8588
Project: Camel
Issue Type: Improvement
Components: camel-restlet
Affects Versions: 2.15.0
Reporter: Camel Guy
Priority: Minor
There doesn't seem to be a way to use the REST DSL in a provider-agnostic way
in order to produce a redirect.
Setting the location header generates a warning sent to the console:
{noformat}
Addition of the standard header location is not allowed. Please use the
equivalent property in the Restlet API.{noformat}
Very small example: http://pastebin.com/Zaq7p0Us
Also see linked JIRA.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-8591) Upgrade to restlet 2.3.x
Claus Ibsen created CAMEL-8591: -- Summary: Upgrade to restlet 2.3.x Key: CAMEL-8591 URL: https://issues.apache.org/jira/browse/CAMEL-8591 Project: Camel Issue Type: Task Components: camel-restlet Reporter: Claus Ibsen Assignee: Claus Ibsen Priority: Minor Fix For: 2.16.0 Its not API compatible a code change was needed in camel-restlet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8586) File component optimization required for file response body
[
https://issues.apache.org/jira/browse/CAMEL-8586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-8586:
---
Fix Version/s: 2.16.0
File component optimization required for file response body
---
Key: CAMEL-8586
URL: https://issues.apache.org/jira/browse/CAMEL-8586
Project: Camel
Issue Type: Improvement
Components: camel-core
Affects Versions: 2.14.1
Reporter: Sergey Zolotaryov
Priority: Minor
Fix For: 2.16.0
I have a producer which makes files (writes data to a temp file) and sets it
as output message body. I was expecting Camel file component to just rename
the resulting file. But instead it copies the file leaving the temporary file
intact. Here's a snippet from the FileOperations class which raised my
concern:
{code}
// we can optimize and use file based if no charset must be used,
and the input body is a file
File source = null;
boolean fileBased = false;
if (charset == null) {
// if no charset, then we can try using file directly
(optimized)
Object body = exchange.getIn().getBody();
if (body instanceof WrappedFile) {
body = ((WrappedFile?) body).getFile();
fileBased = true;
}
if (body instanceof File) {
source = (File) body;
}
}
if (fileBased) {
// okay we know the body is a file based
{code}
So the fileBased is only assumed if we are using a proprietary WrappedFile
body, whereas normal file is not considered a fileBased body. Am I missing
something?
We could just treat files the same way as WrappedFile, or have an endpoint
option to treat them as such, what do you think?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8586) File component optimization required for file response body
[
https://issues.apache.org/jira/browse/CAMEL-8586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14392388#comment-14392388
]
Claus Ibsen commented on CAMEL-8586:
Yeah we can allow for custom components to set the body as a plain java.io.File.
You are welcome to provide a patch.
File component optimization required for file response body
---
Key: CAMEL-8586
URL: https://issues.apache.org/jira/browse/CAMEL-8586
Project: Camel
Issue Type: Improvement
Components: camel-core
Affects Versions: 2.14.1
Reporter: Sergey Zolotaryov
I have a producer which makes files (writes data to a temp file) and sets it
as output message body. I was expecting Camel file component to just rename
the resulting file. But instead it copies the file leaving the temporary file
intact. Here's a snippet from the FileOperations class which raised my
concern:
{code}
// we can optimize and use file based if no charset must be used,
and the input body is a file
File source = null;
boolean fileBased = false;
if (charset == null) {
// if no charset, then we can try using file directly
(optimized)
Object body = exchange.getIn().getBody();
if (body instanceof WrappedFile) {
body = ((WrappedFile?) body).getFile();
fileBased = true;
}
if (body instanceof File) {
source = (File) body;
}
}
if (fileBased) {
// okay we know the body is a file based
{code}
So the fileBased is only assumed if we are using a proprietary WrappedFile
body, whereas normal file is not considered a fileBased body. Am I missing
something?
We could just treat files the same way as WrappedFile, or have an endpoint
option to treat them as such, what do you think?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8586) File component optimization required for file response body
[
https://issues.apache.org/jira/browse/CAMEL-8586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-8586:
---
Priority: Minor (was: Major)
File component optimization required for file response body
---
Key: CAMEL-8586
URL: https://issues.apache.org/jira/browse/CAMEL-8586
Project: Camel
Issue Type: Improvement
Components: camel-core
Affects Versions: 2.14.1
Reporter: Sergey Zolotaryov
Priority: Minor
I have a producer which makes files (writes data to a temp file) and sets it
as output message body. I was expecting Camel file component to just rename
the resulting file. But instead it copies the file leaving the temporary file
intact. Here's a snippet from the FileOperations class which raised my
concern:
{code}
// we can optimize and use file based if no charset must be used,
and the input body is a file
File source = null;
boolean fileBased = false;
if (charset == null) {
// if no charset, then we can try using file directly
(optimized)
Object body = exchange.getIn().getBody();
if (body instanceof WrappedFile) {
body = ((WrappedFile?) body).getFile();
fileBased = true;
}
if (body instanceof File) {
source = (File) body;
}
}
if (fileBased) {
// okay we know the body is a file based
{code}
So the fileBased is only assumed if we are using a proprietary WrappedFile
body, whereas normal file is not considered a fileBased body. Am I missing
something?
We could just treat files the same way as WrappedFile, or have an endpoint
option to treat them as such, what do you think?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8572) Upgrade aws sdk java version and add support for DynamoDB v2
[ https://issues.apache.org/jira/browse/CAMEL-8572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14392447#comment-14392447 ] Claus Ibsen commented on CAMEL-8572: Thanks Andrea for working on this. Upgrade aws sdk java version and add support for DynamoDB v2 Key: CAMEL-8572 URL: https://issues.apache.org/jira/browse/CAMEL-8572 Project: Camel Issue Type: Improvement Components: camel-aws Reporter: Andrea Cosentino Priority: Minor Labels: aws, aws-ddb Fix For: 2.16.0 Hi, We should upgrade the AWS sdk version to something = 1.9. I've made some test on the code, and the DynamoDB part of the component is affected from this change. We need to support DynamoDB v2, if we want to use a newer version. I would like to study this improvement and work on this. Is possible to assign this JIRA to me? I would like to be able to assign JIRAs to myself. Is it possible? Bye, Andrea -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8565) Support for camel-gson to handle generic types
[ https://issues.apache.org/jira/browse/CAMEL-8565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-8565. Resolution: Fixed Assignee: Willem Jiang Support for camel-gson to handle generic types -- Key: CAMEL-8565 URL: https://issues.apache.org/jira/browse/CAMEL-8565 Project: Camel Issue Type: New Feature Components: camel-gson Reporter: Andrew Block Assignee: Willem Jiang Priority: Minor Fix For: 2.16.0 Currently camel-gson only supports the ability to marshal or unmarshall a concrete class. It should provide the functionality handle generic types such as collections. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8591) Upgrade to restlet 2.3.x
[ https://issues.apache.org/jira/browse/CAMEL-8591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-8591. Resolution: Fixed Upgrade to restlet 2.3.x Key: CAMEL-8591 URL: https://issues.apache.org/jira/browse/CAMEL-8591 Project: Camel Issue Type: Task Components: camel-restlet Reporter: Claus Ibsen Assignee: Claus Ibsen Priority: Minor Fix For: 2.16.0 Its not API compatible a code change was needed in camel-restlet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8583) CamelContext.getEndpointRegistry() should return EndpointRegistryString, but returns DefaultEndpointRegistry which is EndpointRegistryEndpointKey
[ https://issues.apache.org/jira/browse/CAMEL-8583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-8583: --- Priority: Minor (was: Blocker) CamelContext.getEndpointRegistry() should return EndpointRegistryString, but returns DefaultEndpointRegistry which is EndpointRegistryEndpointKey - Key: CAMEL-8583 URL: https://issues.apache.org/jira/browse/CAMEL-8583 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.15.0 Reporter: Iikku Mattila Priority: Minor I have org.apache.camel.spring.javaconfig.CamelConfiguration -instance, in which I setup the camel context. In setupCamelContext(CamelContext camelContext) I'm trying camelContext.getEndpointRegistry().put(name, endpoint); which fails, because CamelContext.getEndpointRegistry() returns DefaultEndpointRegistry which is EndpointRegistryEndpointKey and thus only has method put(EndpointKey key, Endpoint endpoint) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8582) No way to specify a custom ModelJAXBContextFactory when using Spring DSL/XML Namespace
[ https://issues.apache.org/jira/browse/CAMEL-8582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Whiteside updated CAMEL-8582: --- Attachment: CAMEL-8582v2.patch Added unit test and removed changes to XML schema. No way to specify a custom ModelJAXBContextFactory when using Spring DSL/XML Namespace -- Key: CAMEL-8582 URL: https://issues.apache.org/jira/browse/CAMEL-8582 Project: Camel Issue Type: Improvement Components: camel-spring Affects Versions: 2.15.0 Reporter: Aaron Whiteside Priority: Minor Fix For: 2.16.0 Attachments: CAMEL-8582.patch, CAMEL-8582v2.patch No way to specify a custom ModelJAXBContextFactory when using Spring DSL/Xml Namespace. The ModelJAXBContextFactory reference should be specifiable on the CamelContext Spring XML Namespace. And it should be searched via the spring bean registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8572) Upgrade aws sdk java version and add support for DynamoDB v2
[ https://issues.apache.org/jira/browse/CAMEL-8572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14393449#comment-14393449 ] Andrea Cosentino commented on CAMEL-8572: - PR submitted: https://github.com/apache/camel/pull/463/ For information purpose I report the most important changes (from PR on github): There are some new feature to consider: - The package is different: from com.amazonaws.services.dynamodb to com.amazonaws.services.dynamodbv2 - Key class is gone (among other changes) and it's been replaced by MapString, AttributeValue The most important changes: - from com.amazonaws.services.dynamodb.model.Key to MapString, AttributeValue - from com.amazonaws.services.dynamodb.model.BatchResponse to ListMapString, AttributeValue - from com.amazonaws.services.dynamodb.model.KeySchema to ListKeySchemaElement - QueryRequest methods withHashKeyValue(AttributeValue) and withRangeKeyCondition(Condition) now are merged into withKeyConditions(MapString,Condition) - QueryRequest method withCount(Boolean) doesn't exist anymore So we will even need to make some changes on documentation (I've deleted some constant from DdbConstants.java class). Andrea Upgrade aws sdk java version and add support for DynamoDB v2 Key: CAMEL-8572 URL: https://issues.apache.org/jira/browse/CAMEL-8572 Project: Camel Issue Type: Improvement Components: camel-aws Reporter: Andrea Cosentino Priority: Minor Labels: aws, aws-ddb Fix For: 2.16.0 Hi, We should upgrade the AWS sdk version to something = 1.9. I've made some test on the code, and the DynamoDB part of the component is affected from this change. We need to support DynamoDB v2, if we want to use a newer version. I would like to study this improvement and work on this. Is possible to assign this JIRA to me? I would like to be able to assign JIRAs to myself. Is it possible? Bye, Andrea -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8572) Upgrade aws sdk java version and add support for DynamoDB v2
[ https://issues.apache.org/jira/browse/CAMEL-8572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14393439#comment-14393439 ] ASF GitHub Bot commented on CAMEL-8572: --- GitHub user oscerd opened a pull request: https://github.com/apache/camel/pull/463 CAMEL-8572 Upgrade AWS SDK java version and add support for DynamoDB v2 Hi all, This PR is related to: Upgrade aws sdk java version and add support for DynamoDB v2 There are some new feature to consider: - The package is different: from com.amazonaws.services.dynamodb to com.amazonaws.services.dynamodbv2 - Key class is gone (among other changes) and it's been replaced by MapString, AttributeValue The most important changes: - from com.amazonaws.services.dynamodb.model.Key to MapString, AttributeValue - from com.amazonaws.services.dynamodb.model.BatchResponse to ListMapString, AttributeValue - from com.amazonaws.services.dynamodb.model.KeySchema to ListKeySchemaElement - QueryRequest methods withHashKeyValue(AttributeValue) and withRangeKeyCondition(Condition) now are merged into withKeyConditions(MapString,Condition) - QueryRequest method withCount(Boolean) doesn't exist anymore So we will even need to make some changes on documentation (I've deleted some constant from DdbConstants.java class). Andrea You can merge this pull request into a Git repository by running: $ git pull https://github.com/oscerd/camel update-aws-sdk-version Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/463.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #463 commit fa80c497583b455aa74b4f129d12e398772bbdee Author: ancosen anco...@gmail.com Date: 2015-04-02T20:02:13Z CAMEL-8572 Updated version of AWS Java SDK from 1.8.9.1 to 1.9.17 commit 8844979a2d0f7e791e1afade00a8dde71488940a Author: ancosen anco...@gmail.com Date: 2015-04-02T20:19:30Z CAMEL-8572 - Upgrade aws sdk java version and add support for DynamoDB v2 commit cee8291e1c8c1c2de92e626c3ca071b77268dfc6 Author: ancosen anco...@gmail.com Date: 2015-04-02T21:06:31Z CAMEL-8572 Fixed CS Upgrade aws sdk java version and add support for DynamoDB v2 Key: CAMEL-8572 URL: https://issues.apache.org/jira/browse/CAMEL-8572 Project: Camel Issue Type: Improvement Components: camel-aws Reporter: Andrea Cosentino Priority: Minor Labels: aws, aws-ddb Fix For: 2.16.0 Hi, We should upgrade the AWS sdk version to something = 1.9. I've made some test on the code, and the DynamoDB part of the component is affected from this change. We need to support DynamoDB v2, if we want to use a newer version. I would like to study this improvement and work on this. Is possible to assign this JIRA to me? I would like to be able to assign JIRAs to myself. Is it possible? Bye, Andrea -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8588) REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header
[
https://issues.apache.org/jira/browse/CAMEL-8588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14393541#comment-14393541
]
Camel Guy commented on CAMEL-8588:
--
Thanks for your help. Stupid me, I didn't try an uppercase L. And I don't have
to use out any more either. After 18 months of Cameling, I still don't
understand MEP.
REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header
Key: CAMEL-8588
URL: https://issues.apache.org/jira/browse/CAMEL-8588
Project: Camel
Issue Type: Improvement
Components: camel-restlet
Affects Versions: 2.15.0
Reporter: Camel Guy
Assignee: Claus Ibsen
Priority: Minor
There doesn't seem to be a way to use the REST DSL in a provider-agnostic way
in order to produce a redirect.
Setting the location header generates a warning sent to the console:
{noformat}
Addition of the standard header location is not allowed. Please use the
equivalent property in the Restlet API.{noformat}
Very small example: http://pastebin.com/Zaq7p0Us
Also see linked JIRA.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-8592) NPE in AbstractListAggregationStrategy if empty list
[ https://issues.apache.org/jira/browse/CAMEL-8592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang reassigned CAMEL-8592: --- Assignee: Willem Jiang NPE in AbstractListAggregationStrategy if empty list Key: CAMEL-8592 URL: https://issues.apache.org/jira/browse/CAMEL-8592 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.15.1 Reporter: Claus Ibsen Assignee: Willem Jiang Priority: Minor Fix For: 2.15.2, 2.16.0 See nabble http://camel.465427.n5.nabble.com/NullPointerException-on-empty-List-in-AbstractListAggregationStrategy-tp5764965.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8592) NPE in AbstractListAggregationStrategy if empty list
[ https://issues.apache.org/jira/browse/CAMEL-8592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-8592. - Resolution: Fixed Fix Version/s: 2.14.3 The NPE is caused the result exchange could be null, I just fixed it by adding a null check there. NPE in AbstractListAggregationStrategy if empty list Key: CAMEL-8592 URL: https://issues.apache.org/jira/browse/CAMEL-8592 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.15.1 Reporter: Claus Ibsen Assignee: Willem Jiang Priority: Minor Fix For: 2.14.3, 2.15.2, 2.16.0 See nabble http://camel.465427.n5.nabble.com/NullPointerException-on-empty-List-in-AbstractListAggregationStrategy-tp5764965.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-8572) Upgrade aws sdk java version and add support for DynamoDB v2
[ https://issues.apache.org/jira/browse/CAMEL-8572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang reassigned CAMEL-8572: --- Assignee: Willem Jiang Upgrade aws sdk java version and add support for DynamoDB v2 Key: CAMEL-8572 URL: https://issues.apache.org/jira/browse/CAMEL-8572 Project: Camel Issue Type: Improvement Components: camel-aws Reporter: Andrea Cosentino Assignee: Willem Jiang Priority: Minor Labels: aws, aws-ddb Fix For: 2.16.0 Hi, We should upgrade the AWS sdk version to something = 1.9. I've made some test on the code, and the DynamoDB part of the component is affected from this change. We need to support DynamoDB v2, if we want to use a newer version. I would like to study this improvement and work on this. Is possible to assign this JIRA to me? I would like to be able to assign JIRAs to myself. Is it possible? Bye, Andrea -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-8593) JmsEndpoint.configureListenerContainer() some debug logs miss {}
[
https://issues.apache.org/jira/browse/CAMEL-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang reassigned CAMEL-8593:
---
Assignee: Willem Jiang
JmsEndpoint.configureListenerContainer() some debug logs miss {}
Key: CAMEL-8593
URL: https://issues.apache.org/jira/browse/CAMEL-8593
Project: Camel
Issue Type: Improvement
Affects Versions: 2.13.3
Reporter: Martin Lichtin
Assignee: Willem Jiang
Priority: Trivial
In method JmsEndpoint.configureListenerContainer()
there are a few debug logs that miss the second {}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7833) create an extension of the RX ObservableT to add more of the Camel DSL in there (e.g. to() or to go back to the general camel DSL)
[
https://issues.apache.org/jira/browse/CAMEL-7833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14393958#comment-14393958
]
Willem Jiang commented on CAMEL-7833:
-
Merged the patch into camel master branch with thanks to Jyrki.
create an extension of the RX ObservableT to add more of the Camel DSL in
there (e.g. to() or to go back to the general camel DSL)
Key: CAMEL-7833
URL: https://issues.apache.org/jira/browse/CAMEL-7833
Project: Camel
Issue Type: New Feature
Reporter: james strachan
Assignee: Willem Jiang
Fix For: 2.16.0
with Camel RX and java 8 we can do some nice lambdas and typesafe filtering
and transformation:
{code}
ReactiveCamel rx = new ReactiveCamel(camelContext);
ObservableOrder observable = rx.toObservable(seda:orders, Order.class);
// now lets filter and map using Java 8
ObservableString largeOrderIds = observable.
filter(order - order.getAmount() 100.0).
map(order - order.getId());
rx.sendTo(observable, activemq:MyQueue);
{code}
however the DSL isn't quite as nice as Camel's due to the lack of the camel
verbs like to(). It'd be nice to provide an extended ObservableT
interface which adds more of Camel's DSL in there too; so you can still use
things the RX way; but can also reuse the camel DSL too (in a typesafe way).
e.g. something like this
{code}
// Observable comes from RX; it'd be nice to have a camel extended version so
we can add camel DSL stuff in there like to() etc
CamelStreamOrder orders = rx.stream(seda:orders, Order.class);
// now lets filter and map using Java 8
orders.
filter(order - order.getAmount() 100.0).
map(order - order.getId()).
to(activemq:MyQueue);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-8593) JmsEndpoint.configureListenerContainer() some debug logs miss {}
[
https://issues.apache.org/jira/browse/CAMEL-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang resolved CAMEL-8593.
-
Resolution: Fixed
Fix Version/s: 2.16.0
2.15.2
2.14.3
Applied the patch into camel master, camel-2.15.x and camel-2.14.x branches.
JmsEndpoint.configureListenerContainer() some debug logs miss {}
Key: CAMEL-8593
URL: https://issues.apache.org/jira/browse/CAMEL-8593
Project: Camel
Issue Type: Improvement
Affects Versions: 2.13.3
Reporter: Martin Lichtin
Assignee: Willem Jiang
Priority: Trivial
Fix For: 2.14.3, 2.15.2, 2.16.0
In method JmsEndpoint.configureListenerContainer()
there are a few debug logs that miss the second {}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7833) create an extension of the RX ObservableT to add more of the Camel DSL in there (e.g. to() or to go back to the general camel DSL)
[
https://issues.apache.org/jira/browse/CAMEL-7833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14394099#comment-14394099
]
ASF GitHub Bot commented on CAMEL-7833:
---
Github user yuruki closed the pull request at:
https://github.com/apache/camel/pull/462
create an extension of the RX ObservableT to add more of the Camel DSL in
there (e.g. to() or to go back to the general camel DSL)
Key: CAMEL-7833
URL: https://issues.apache.org/jira/browse/CAMEL-7833
Project: Camel
Issue Type: New Feature
Reporter: james strachan
Assignee: Willem Jiang
Fix For: 2.16.0
with Camel RX and java 8 we can do some nice lambdas and typesafe filtering
and transformation:
{code}
ReactiveCamel rx = new ReactiveCamel(camelContext);
ObservableOrder observable = rx.toObservable(seda:orders, Order.class);
// now lets filter and map using Java 8
ObservableString largeOrderIds = observable.
filter(order - order.getAmount() 100.0).
map(order - order.getId());
rx.sendTo(observable, activemq:MyQueue);
{code}
however the DSL isn't quite as nice as Camel's due to the lack of the camel
verbs like to(). It'd be nice to provide an extended ObservableT
interface which adds more of Camel's DSL in there too; so you can still use
things the RX way; but can also reuse the camel DSL too (in a typesafe way).
e.g. something like this
{code}
// Observable comes from RX; it'd be nice to have a camel extended version so
we can add camel DSL stuff in there like to() etc
CamelStreamOrder orders = rx.stream(seda:orders, Order.class);
// now lets filter and map using Java 8
orders.
filter(order - order.getAmount() 100.0).
map(order - order.getId()).
to(activemq:MyQueue);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8588) REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header
[
https://issues.apache.org/jira/browse/CAMEL-8588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14392879#comment-14392879
]
Camel Guy commented on CAMEL-8588:
--
Regarding the MEP, it took me an hour to figure out that I should use
exchange.out.
headers.'Content-Type' =
Had no effect.
REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header
Key: CAMEL-8588
URL: https://issues.apache.org/jira/browse/CAMEL-8588
Project: Camel
Issue Type: Improvement
Components: camel-restlet
Affects Versions: 2.15.0
Reporter: Camel Guy
Assignee: Claus Ibsen
Priority: Minor
There doesn't seem to be a way to use the REST DSL in a provider-agnostic way
in order to produce a redirect.
Setting the location header generates a warning sent to the console:
{noformat}
Addition of the standard header location is not allowed. Please use the
equivalent property in the Restlet API.{noformat}
Very small example: http://pastebin.com/Zaq7p0Us
Also see linked JIRA.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8584) Circuit breaker does not honour halfOpenAfter period
[ https://issues.apache.org/jira/browse/CAMEL-8584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14392664#comment-14392664 ] ASF GitHub Bot commented on CAMEL-8584: --- Github user kapowie closed the pull request at: https://github.com/apache/camel/pull/458 Circuit breaker does not honour halfOpenAfter period Key: CAMEL-8584 URL: https://issues.apache.org/jira/browse/CAMEL-8584 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.15.0, 2.15.1 Reporter: jack patwork Assignee: Claus Ibsen Fix For: 2.15.2, 2.16.0 The CircuitBreakerLoadBalancer will always switch to a half-open state immediately after the first rejected message instead of honouring the halfOpenAfter period. It's due to the failed message count getting reset in the rejectExchange method: https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/processor/loadbalancer/CircuitBreakerLoadBalancer.java#L207 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8593) JmsEndpoint.configureListenerContainer() some debug logs miss {}
Martin Lichtin created CAMEL-8593:
-
Summary: JmsEndpoint.configureListenerContainer() some debug logs
miss {}
Key: CAMEL-8593
URL: https://issues.apache.org/jira/browse/CAMEL-8593
Project: Camel
Issue Type: Improvement
Affects Versions: 2.13.3
Reporter: Martin Lichtin
Priority: Trivial
In method JmsEndpoint.configureListenerContainer()
there are a few debug logs that miss the second {}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7877) json DataFormat: provide the prettyPrint option by all the supported JSON libraries
[
https://issues.apache.org/jira/browse/CAMEL-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Babak Vahdat updated CAMEL-7877:
Description:
See:
http://camel.465427.n5.nabble.com/Problems-prettyPrinting-JSON-after-camel-2-14-0-upgrade-td5756738.html
It would be nice to have support for the {{prettyPrint}} option no matter if
the XStream, Jackson or GSon library is in use.
was:
See:
http://camel.465427.n5.nabble.com/Problems-prettyPrinting-JSON-after-camel-2-14-0-upgrade-td5756738.html
It would be nice to have support for the {{prettyPrint}} option no matter if
the XStream, Jettsion, Jackson or GSon library is in use.
json DataFormat: provide the prettyPrint option by all the supported JSON
libraries
---
Key: CAMEL-7877
URL: https://issues.apache.org/jira/browse/CAMEL-7877
Project: Camel
Issue Type: New Feature
Reporter: Babak Vahdat
Assignee: Babak Vahdat
Priority: Minor
Fix For: 2.16.0
See:
http://camel.465427.n5.nabble.com/Problems-prettyPrinting-JSON-after-camel-2-14-0-upgrade-td5756738.html
It would be nice to have support for the {{prettyPrint}} option no matter if
the XStream, Jackson or GSon library is in use.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8582) No way to specify a custom ModelJAXBContextFactory when using Spring DSL/XML Namespace
[ https://issues.apache.org/jira/browse/CAMEL-8582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14392997#comment-14392997 ] Aaron Whiteside commented on CAMEL-8582: Understood. Any chance of getting this into a 2.15.x branch? No way to specify a custom ModelJAXBContextFactory when using Spring DSL/XML Namespace -- Key: CAMEL-8582 URL: https://issues.apache.org/jira/browse/CAMEL-8582 Project: Camel Issue Type: Improvement Components: camel-spring Affects Versions: 2.15.0 Reporter: Aaron Whiteside Priority: Minor Fix For: 2.16.0 Attachments: CAMEL-8582.patch No way to specify a custom ModelJAXBContextFactory when using Spring DSL/Xml Namespace. The ModelJAXBContextFactory reference should be specifiable on the CamelContext Spring XML Namespace. And it should be searched via the spring bean registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-7877) json DataFormat: provide the prettyPrint option by all the supported JSON libraries
[
https://issues.apache.org/jira/browse/CAMEL-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Babak Vahdat reassigned CAMEL-7877:
---
Assignee: Babak Vahdat
json DataFormat: provide the prettyPrint option by all the supported JSON
libraries
---
Key: CAMEL-7877
URL: https://issues.apache.org/jira/browse/CAMEL-7877
Project: Camel
Issue Type: New Feature
Reporter: Babak Vahdat
Assignee: Babak Vahdat
Priority: Minor
Fix For: 2.16.0
See:
http://camel.465427.n5.nabble.com/Problems-prettyPrinting-JSON-after-camel-2-14-0-upgrade-td5756738.html
It would be nice to have support for the {{prettyPrint}} option no matter if
the XStream, Jettsion, Jackson or GSon library is in use.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7877) json DataFormat: support the prettyPrint option by all the supported JSON libraries
[
https://issues.apache.org/jira/browse/CAMEL-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Babak Vahdat updated CAMEL-7877:
Summary: json DataFormat: support the prettyPrint option by all the
supported JSON libraries (was: json DataFormat: provide the prettyPrint option
by all the supported JSON libraries)
json DataFormat: support the prettyPrint option by all the supported JSON
libraries
---
Key: CAMEL-7877
URL: https://issues.apache.org/jira/browse/CAMEL-7877
Project: Camel
Issue Type: New Feature
Reporter: Babak Vahdat
Assignee: Babak Vahdat
Priority: Minor
Fix For: 2.16.0
See:
http://camel.465427.n5.nabble.com/Problems-prettyPrinting-JSON-after-camel-2-14-0-upgrade-td5756738.html
It would be nice to have support for the {{prettyPrint}} option no matter if
the XStream, Jackson or GSon library is in use.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8582) No way to specify a custom ModelJAXBContextFactory when using Spring DSL/XML Namespace
[ https://issues.apache.org/jira/browse/CAMEL-8582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14393067#comment-14393067 ] Claus Ibsen commented on CAMEL-8582: Yeah sure if its only the lookup of the bean the spi style, then that should not cause issues for existing users. And since the code is in the core-xml module then it should work out of the box for blueprint too. No way to specify a custom ModelJAXBContextFactory when using Spring DSL/XML Namespace -- Key: CAMEL-8582 URL: https://issues.apache.org/jira/browse/CAMEL-8582 Project: Camel Issue Type: Improvement Components: camel-spring Affects Versions: 2.15.0 Reporter: Aaron Whiteside Priority: Minor Fix For: 2.16.0 Attachments: CAMEL-8582.patch No way to specify a custom ModelJAXBContextFactory when using Spring DSL/Xml Namespace. The ModelJAXBContextFactory reference should be specifiable on the CamelContext Spring XML Namespace. And it should be searched via the spring bean registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
