[jira] [Created] (CAMEL-7837) Support json2json data transformation
Charles Moulliard created CAMEL-7837: Summary: Support json2json data transformation Key: CAMEL-7837 URL: https://issues.apache.org/jira/browse/CAMEL-7837 Project: Camel Issue Type: New Feature Affects Versions: 2.14.0 Reporter: Charles Moulliard We should support json2json data transformation. A good candidate project exists which is Apache Licensed 2 : - http://chunqishi.github.io/json2json/ - https://github.com/chunqishi/json2json -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7787) Multicast - Should defer UoW done until after the aggregate has been done
[ https://issues.apache.org/jira/browse/CAMEL-7787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer updated CAMEL-7787: Attachment: (was: 0001-stream-caching-in-sub-routes-of-splitter-and-multi-c.patch) Multicast - Should defer UoW done until after the aggregate has been done - Key: CAMEL-7787 URL: https://issues.apache.org/jira/browse/CAMEL-7787 Project: Camel Issue Type: Improvement Components: camel-core, eip Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.15.0 See nabble http://camel.465427.n5.nabble.com/Stream-Cache-spool-file-deletion-before-aggregation-in-Multicast-involving-huge-data-tp5756092.html In the multicast/splitter we should defer the UoW done to *after* the aggregate has been called, as in the nabble example, the stream cache overflow to disk would have deleted the file etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7787) Multicast - Should defer UoW done until after the aggregate has been done
[ https://issues.apache.org/jira/browse/CAMEL-7787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer updated CAMEL-7787: Attachment: 0001-stream-caching-in-sub-routes-of-splitter-and-multi-c.patch We found an additional case where a problem can occur: nesting of splitter/mulitcast where the aggregation strategy returns a stream cache. We fixed this also in the new uploaded patch. Multicast - Should defer UoW done until after the aggregate has been done - Key: CAMEL-7787 URL: https://issues.apache.org/jira/browse/CAMEL-7787 Project: Camel Issue Type: Improvement Components: camel-core, eip Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.15.0 Attachments: 0001-stream-caching-in-sub-routes-of-splitter-and-multi-c.patch See nabble http://camel.465427.n5.nabble.com/Stream-Cache-spool-file-deletion-before-aggregation-in-Multicast-involving-huge-data-tp5756092.html In the multicast/splitter we should defer the UoW done to *after* the aggregate has been called, as in the nabble example, the stream cache overflow to disk would have deleted the file etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7838) Aggregator - Using groupExchanges should store them on body mid-processing
Marc Carter created CAMEL-7838:
--
Summary: Aggregator - Using groupExchanges should store them on
body mid-processing
Key: CAMEL-7838
URL: https://issues.apache.org/jira/browse/CAMEL-7838
Project: Camel
Issue Type: Improvement
Components: camel-core
Affects Versions: 2.13.2
Reporter: Marc Carter
Priority: Minor
CAMEL-6744 encompassed setting the ListV into the body {{onCompletion}} only
when using anything based on {{AbstractListAggregationStrategy}}
However any strategies based on this class cannot be used with a persistent
repository because the GROUPED_EXCHANGE property appears not to be serialised
so keeps being reset to the latest message only.
(I spotted this by checking properties in the completion predicate and
AGGREGATED_SIZE != GROUPED_EXCHANGE.size())
Given this limitation, it doesn't seem sensible to only promote to the body on
completion. The only reason I can think of is to limit regression to existing
completionPredicates that expect the first message in {{body}} instead of
{{body.get(0)}}. That said, CAMEL-6744 already introduced this change to the
subsequent route.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-7839) Xpath is not namespace aware in choice
Oliver Holzmann created CAMEL-7839: -- Summary: Xpath is not namespace aware in choice Key: CAMEL-7839 URL: https://issues.apache.org/jira/browse/CAMEL-7839 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.14.0 Reporter: Oliver Holzmann I have a route (XML definition) containing a choice based on xpath expressions. The xpath expressions are using custom namespaces. After migration from camel 2.13.2 to camel 2.14.0 the namespaces are not registered to the XpathExpression and XPathBuilder anymore. XPath in setProperty definitions referencing the same namespaces still work fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7802) XML Signature: parameter for output character encoding and parent node via XPath
[ https://issues.apache.org/jira/browse/CAMEL-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-7802. - Resolution: Fixed XML Signature: parameter for output character encoding and parent node via XPath Key: CAMEL-7802 URL: https://issues.apache.org/jira/browse/CAMEL-7802 Project: Camel Issue Type: Improvement Components: camel-xmlsecurity Reporter: Franz Forsthofer Assignee: Willem Jiang Fix For: 2.15.0 Attachments: 0001-xml-signature-output-encoding-and-parent-XPath.patch Two improvements for the xmlsec component concerning the XML Signature signer and verifier: - The output character encoding for the signer and verifier (if no character encoding is specified UTF-8 will be used as before) can be specified via the configuration parameter 'outputXmlEncoding'. - In the Enveloped XML Signature case, the parent node can be now specified via an XPATH expression (new parameter 'parentXpath'). This allows selecting the parent node in a more flexible way as before where the parent node was specified via local name and namespace. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7827) When using CXFRS with simple HTTP api, variable replacement should be available
[
https://issues.apache.org/jira/browse/CAMEL-7827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang updated CAMEL-7827:
Summary: When using CXFRS with simple HTTP api, variable replacement should
be available (was: Wen using CXFRS with simple HTTP api, variable replacement
should be available)
When using CXFRS with simple HTTP api, variable replacement should be
available
---
Key: CAMEL-7827
URL: https://issues.apache.org/jira/browse/CAMEL-7827
Project: Camel
Issue Type: Improvement
Components: camel-cxf
Reporter: François LAROCHE
Assignee: Willem Jiang
Priority: Minor
Fix For: 2.15.0
I am calling an endpoint using cxfrs client with the http api. So I have
something like that in the DSL :
.setHeader(CxfConstants.CAMEL_CXF_RS_USING_HTTP_API, constant(true))
.setHeader(Exchange.HTTP_PATH, simple(/endpoint/${header.myHeader}))
.setHeader(Exchange.HTTP_METHOD, constant(POST))
.to(cxfrs:bean:myClient)
This usually works fine.
I had a somewhat nasty error when someone did a copy paste of my server,
with the variable substitution style (something like /endpoint/{myVariable})
at that point, ${header.myHeader} resolved to {myVariable}, thus the url the
client will try to resolve is /endpoint/{myVariable}. When trying to parse
this URL, CXF will not be happy, since there is no value to replace what it
thinks to be a variable, and will throw an IllegalArgumentException with
message Unresolved variables; only 0 value(s) given for 1 unique
variable(s).
After looking a bit in the code, I understood better what happens.
In order to avoid that, it would be nice to use the mechanism of CXF to
replace variables in URI.
In the DSL, we would have something like :
.setHeader(CxfConstants.CAMEL_CXF_RS_USING_HTTP_API, constant(true))
.setHeader(CxfConstants.CAMEL_CXF_RS_VAR_VALUES,
simple([${header.myHeader}]))
.setHeader(Exchange.HTTP_PATH, constant(/endpoint/{myVariable}))
.setHeader(Exchange.HTTP_METHOD, constant(POST))
.to(cxfrs:bean:myClient)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-7824) Camel manual throws some errors by opening in Safari or Firefox
[ https://issues.apache.org/jira/browse/CAMEL-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-7824. - Resolution: Fixed I just checked the generated html file, the error is gone. Camel manual throws some errors by opening in Safari or Firefox --- Key: CAMEL-7824 URL: https://issues.apache.org/jira/browse/CAMEL-7824 Project: Camel Issue Type: Bug Components: website Affects Versions: 2.14.0 Reporter: Christian Müller Assignee: Willem Jiang Fix For: 2.14.1, 2.15.0 In Safari and Firefox, I got some errors by opening the Camel manual: SyntaxHighlighter: Can't find brush for: py -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7827) When using CXFRS with simple HTTP api, variable replacement should be available
[
https://issues.apache.org/jira/browse/CAMEL-7827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang resolved CAMEL-7827.
-
Resolution: Fixed
Applied the patch into camel master branch with thanks to François.
When using CXFRS with simple HTTP api, variable replacement should be
available
---
Key: CAMEL-7827
URL: https://issues.apache.org/jira/browse/CAMEL-7827
Project: Camel
Issue Type: Improvement
Components: camel-cxf
Reporter: François LAROCHE
Assignee: Willem Jiang
Priority: Minor
Fix For: 2.15.0
I am calling an endpoint using cxfrs client with the http api. So I have
something like that in the DSL :
.setHeader(CxfConstants.CAMEL_CXF_RS_USING_HTTP_API, constant(true))
.setHeader(Exchange.HTTP_PATH, simple(/endpoint/${header.myHeader}))
.setHeader(Exchange.HTTP_METHOD, constant(POST))
.to(cxfrs:bean:myClient)
This usually works fine.
I had a somewhat nasty error when someone did a copy paste of my server,
with the variable substitution style (something like /endpoint/{myVariable})
at that point, ${header.myHeader} resolved to {myVariable}, thus the url the
client will try to resolve is /endpoint/{myVariable}. When trying to parse
this URL, CXF will not be happy, since there is no value to replace what it
thinks to be a variable, and will throw an IllegalArgumentException with
message Unresolved variables; only 0 value(s) given for 1 unique
variable(s).
After looking a bit in the code, I understood better what happens.
In order to avoid that, it would be nice to use the mechanism of CXF to
replace variables in URI.
In the DSL, we would have something like :
.setHeader(CxfConstants.CAMEL_CXF_RS_USING_HTTP_API, constant(true))
.setHeader(CxfConstants.CAMEL_CXF_RS_VAR_VALUES,
simple([${header.myHeader}]))
.setHeader(Exchange.HTTP_PATH, constant(/endpoint/{myVariable}))
.setHeader(Exchange.HTTP_METHOD, constant(POST))
.to(cxfrs:bean:myClient)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-7792) JIRA component
[ https://issues.apache.org/jira/browse/CAMEL-7792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang reassigned CAMEL-7792: --- Assignee: Willem Jiang JIRA component -- Key: CAMEL-7792 URL: https://issues.apache.org/jira/browse/CAMEL-7792 Project: Camel Issue Type: New Feature Reporter: Brett E. Meyer Assignee: Willem Jiang Fix For: 2.15.0 For Overlord (http://projectoverlord.io), we need to consume events from JIRA, as well as produce actions. We're moving towards using Camel as a backbone for various capabilities, and as such are writing the endpoint functionality as new Camel components. I'd love to see this incorporated as another mainline Camel component. Work in progress: https://github.com/brmeyer/camel-jira Consumer ideas: jira://newIssue (new tickets) jira://newComment (new comments on tickets) Producer ideas: jira://newComment (add comment to a ticket) Obviously, that's only a small portion of the capabilities. The JIRA API is extensive and opens a large variety of possibilities. It uses the Atlassian's jira-rest-java-client SDK (https://marketplace.atlassian.com/plugins/com.atlassian.jira.jira-rest-java-client), released under an Apache V2 license. Similar to what I did for camel-twitter, the Exchange payloads would be the SDK-provided objects themselves (Issue, Comment, etc.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7364) JpaMessageIdRepository uses EntityManager non thread-safe
[ https://issues.apache.org/jira/browse/CAMEL-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14140456#comment-14140456 ] Olivier Sambourg commented on CAMEL-7364: - Will this fix be backported to Camel 2.13.x ? 2.14.x dropped Java 1.6 support so we're currently stuck with 2.10 (as 2.11/2.12/2.13 are impacted) Thanks! JpaMessageIdRepository uses EntityManager non thread-safe - Key: CAMEL-7364 URL: https://issues.apache.org/jira/browse/CAMEL-7364 Project: Camel Issue Type: Bug Components: camel-jpa Affects Versions: 2.12.3 Environment: tomcat 7.0.32, hibernate 4.1.4.Final, spring 3.1.4.RELEASE Reporter: Denis Galkin Assignee: Claus Ibsen Fix For: 2.14.0 In our product we have found strange behavior of JpaMessageIdRepository when change version 2.9.2 to 2.12.3. The reason for this was that EntityManager assigned in the constructor org.apache.camel.processor.idempotent.jpa.JpaMessageIdRepository, but EntityManager not required to be thread safe. http://download.oracle.com/otn-pub/jcp/persistence-2.0-fr-oth-JSpec/persistence-2_0-final-spec.pdf page 286. I think need assign the EntityManager in each method separately. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7840) Upgrade to metrics 3.1
Claus Ibsen created CAMEL-7840: -- Summary: Upgrade to metrics 3.1 Key: CAMEL-7840 URL: https://issues.apache.org/jira/browse/CAMEL-7840 Project: Camel Issue Type: Task Components: camel-metrics Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.15.0 There is a new release and they changed the mvn group id to dropwizard. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7840) Upgrade to metrics 3.1
[ https://issues.apache.org/jira/browse/CAMEL-7840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7840. Resolution: Fixed Upgrade to metrics 3.1 -- Key: CAMEL-7840 URL: https://issues.apache.org/jira/browse/CAMEL-7840 Project: Camel Issue Type: Task Components: camel-metrics Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.15.0 There is a new release and they changed the mvn group id to dropwizard. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7841) Allow SpEL inside Camel {{properties}}
Marc Carter created CAMEL-7841:
--
Summary: Allow SpEL inside Camel {{properties}}
Key: CAMEL-7841
URL: https://issues.apache.org/jira/browse/CAMEL-7841
Project: Camel
Issue Type: Improvement
Components: camel-spring
Affects Versions: 2.14.0
Reporter: Marc Carter
The test for {{BridgePropertyPlaceholderConfigurer}} shows a very unrealistic
example of putting some SpEL into a camel variable. This requires pre-declaring
every such spel expression as you instantiate the bridge. Essentaily the SpEL
is only evaluated when directly in the Spring context refresh.
This bridge class can be ugraded to parse SpEL expressions dynamically as Camel
requests properties allowing the usecases like:
{code}
.from(direct:dostuff)
.wireTap( file:#{@runtime.dataPath}?fileName=${date:now:MMdd}.txt )
{code}
In today's code the first part of URI cannot be paramterised.
I'll submit a PR via github with my solution and example tests.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7841) Allow SpEL inside Camel URIs
[
https://issues.apache.org/jira/browse/CAMEL-7841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marc Carter updated CAMEL-7841:
---
Summary: Allow SpEL inside Camel URIs (was: Allow SpEL inside Camel
{{properties}})
Allow SpEL inside Camel URIs
Key: CAMEL-7841
URL: https://issues.apache.org/jira/browse/CAMEL-7841
Project: Camel
Issue Type: Improvement
Components: camel-spring
Affects Versions: 2.14.0
Reporter: Marc Carter
The test for {{BridgePropertyPlaceholderConfigurer}} shows a very unrealistic
example of putting some SpEL into a camel variable. This requires
pre-declaring every such spel expression as you instantiate the bridge.
Essentaily the SpEL is only evaluated when directly in the Spring context
refresh.
This bridge class can be ugraded to parse SpEL expressions dynamically as
Camel requests properties allowing the usecases like:
{code}
.from(direct:dostuff)
.wireTap( file:#{@runtime.dataPath}?fileName=${date:now:MMdd}.txt )
{code}
In today's code the first part of URI cannot be paramterised.
I'll submit a PR via github with my solution and example tests.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
