[jira] [Created] (CAMEL-7745) Using @EndpointInject with ref does not enlist endpoint in JMX
Claus Ibsen created CAMEL-7745:
--
Summary: Using @EndpointInject with ref does not enlist endpoint
in JMX
Key: CAMEL-7745
URL: https://issues.apache.org/jira/browse/CAMEL-7745
Project: Camel
Issue Type: Bug
Components: camel-blueprint, camel-osgi
Reporter: Claus Ibsen
Fix For: 2.14.0
When using osgi such as blueprint/spring-dm.
When using
{code}
@EndpointInject(ref = sourceDirectoryXml)
Endpoint sourceUri;
{code}
In a RouteBuilder class then the endpoint is not enlisted in jmx. But if you
use uri instead of ref, then they are enlisted in JMX.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CAMEL-7745) Using @EndpointInject with ref does not enlist endpoint in JMX
[
https://issues.apache.org/jira/browse/CAMEL-7745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-7745.
Resolution: Fixed
Fix Version/s: 2.13.3
2.12.5
Assignee: Claus Ibsen
Using @EndpointInject with ref does not enlist endpoint in JMX
--
Key: CAMEL-7745
URL: https://issues.apache.org/jira/browse/CAMEL-7745
Project: Camel
Issue Type: Bug
Components: camel-blueprint, camel-osgi
Reporter: Claus Ibsen
Assignee: Claus Ibsen
Fix For: 2.12.5, 2.13.3, 2.14.0
When using osgi such as blueprint/spring-dm.
When using
{code}
@EndpointInject(ref = sourceDirectoryXml)
Endpoint sourceUri;
{code}
In a RouteBuilder class then the endpoint is not enlisted in jmx. But if you
use uri instead of ref, then they are enlisted in JMX.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Work started] (CAMEL-7742) Support grouping separtor for Camel Bindy (BigDecimal)
[
https://issues.apache.org/jira/browse/CAMEL-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-7742 started by Charles Moulliard.
Support grouping separtor for Camel Bindy (BigDecimal)
--
Key: CAMEL-7742
URL: https://issues.apache.org/jira/browse/CAMEL-7742
Project: Camel
Issue Type: Improvement
Components: camel-bindy
Affects Versions: 2.13.2
Reporter: Charles Moulliard
Assignee: Charles Moulliard
Issue
{code}
I currently have a problem concerning Camel Bindy. I have a csv file that
should be parsed with Camel Bindy using a given model class. This csv file
contains a number that should be parsed as a BigDecimal. The problem is that
this number contains a comma as a grouping separator and a point as the
decimal separator.
If I start the camel route the unmarshal process will throw a
NumberFormatException mentioning the invalid format of that number. So I
tried to add a pattern to the DataField annotation, but the error stays.
After digging throw the documentation (http://camel.apache.org/bindy.html)
and the source code of FormatFactory
(http://grepcode.com/file_/repo1.maven.org/maven2/org.apache.camel/camel-bindy/2.13.1/org/apache/camel/dataformat/bindy/FormatFactory.java/?v=source)
I'm a little bit confused, because the documentation mentions the ability to
specify a grouping separator, but the source code shows that the pattern is
ignored for BigDecimal data types.
Does anyone know how to specify that grouping separator? Or is this not
implemented yet?
{code}
Solution
{code}
public void parsePattern(String formattedString,
Locale locale,
String pattern,
char groupingSeparator,
char decimalSeparator) throws ParseException {
DecimalFormatSymbols symbols = new DecimalFormatSymbols(locale);
symbols.setGroupingSeparator(groupingSeparator);
symbols.setDecimalSeparator(decimalSeparator);
DecimalFormat decimalFormat = new DecimalFormat(pattern, symbols);
decimalFormat.setParseBigDecimal(true);
// parse the string
BigDecimal bigDecimal = (BigDecimal)
decimalFormat.parse(formattedString);
bigDecimal.setScale(precision);
System.out.println(bigDecimal);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CAMEL-7742) Support grouping separtor for Camel Bindy (BigDecimal)
[
https://issues.apache.org/jira/browse/CAMEL-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles Moulliard resolved CAMEL-7742.
--
Resolution: Fixed
Support grouping separtor for Camel Bindy (BigDecimal)
--
Key: CAMEL-7742
URL: https://issues.apache.org/jira/browse/CAMEL-7742
Project: Camel
Issue Type: Improvement
Components: camel-bindy
Affects Versions: 2.13.2
Reporter: Charles Moulliard
Assignee: Charles Moulliard
Issue
{code}
I currently have a problem concerning Camel Bindy. I have a csv file that
should be parsed with Camel Bindy using a given model class. This csv file
contains a number that should be parsed as a BigDecimal. The problem is that
this number contains a comma as a grouping separator and a point as the
decimal separator.
If I start the camel route the unmarshal process will throw a
NumberFormatException mentioning the invalid format of that number. So I
tried to add a pattern to the DataField annotation, but the error stays.
After digging throw the documentation (http://camel.apache.org/bindy.html)
and the source code of FormatFactory
(http://grepcode.com/file_/repo1.maven.org/maven2/org.apache.camel/camel-bindy/2.13.1/org/apache/camel/dataformat/bindy/FormatFactory.java/?v=source)
I'm a little bit confused, because the documentation mentions the ability to
specify a grouping separator, but the source code shows that the pattern is
ignored for BigDecimal data types.
Does anyone know how to specify that grouping separator? Or is this not
implemented yet?
{code}
Solution
{code}
public void parsePattern(String formattedString,
Locale locale,
String pattern,
char groupingSeparator,
char decimalSeparator) throws ParseException {
DecimalFormatSymbols symbols = new DecimalFormatSymbols(locale);
symbols.setGroupingSeparator(groupingSeparator);
symbols.setDecimalSeparator(decimalSeparator);
DecimalFormat decimalFormat = new DecimalFormat(pattern, symbols);
decimalFormat.setParseBigDecimal(true);
// parse the string
BigDecimal bigDecimal = (BigDecimal)
decimalFormat.parse(formattedString);
bigDecimal.setScale(precision);
System.out.println(bigDecimal);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CAMEL-7741) itest for sanitiycheck Camel running on Karaf 2.x and 3.x
[ https://issues.apache.org/jira/browse/CAMEL-7741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7741: --- Assignee: Willem Jiang itest for sanitiycheck Camel running on Karaf 2.x and 3.x - Key: CAMEL-7741 URL: https://issues.apache.org/jira/browse/CAMEL-7741 Project: Camel Issue Type: Test Components: osgi, tests Reporter: Claus Ibsen Assignee: Willem Jiang Fix For: 2.14.0 We should have a sanity check in itests that check that Camel can deploy and run on karaf 2.x / 3.0.x. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7741) itest for sanitiycheck Camel running on Karaf 2.x and 3.x
[ https://issues.apache.org/jira/browse/CAMEL-7741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14110492#comment-14110492 ] Claus Ibsen commented on CAMEL-7741: Thanks Willem. Do you mind creating a tests/camel-itest-karaf23 that just has a few unit tests and is forced to use karaf 2.3. Then its easy to run, like we do for spring32 testing etc. https://github.com/apache/camel/tree/master/tests/camel-itest-spring32 itest for sanitiycheck Camel running on Karaf 2.x and 3.x - Key: CAMEL-7741 URL: https://issues.apache.org/jira/browse/CAMEL-7741 Project: Camel Issue Type: Test Components: osgi, tests Reporter: Claus Ibsen Assignee: Willem Jiang Fix For: 2.14.0 We should have a sanity check in itests that check that Camel can deploy and run on karaf 2.x / 3.0.x. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7652) Rest DSL - Integrate with camel-cxfrs
[ https://issues.apache.org/jira/browse/CAMEL-7652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7652: --- Fix Version/s: (was: 2.14.0) 2.15.0 Rest DSL - Integrate with camel-cxfrs - Key: CAMEL-7652 URL: https://issues.apache.org/jira/browse/CAMEL-7652 Project: Camel Issue Type: Sub-task Components: camel-core Reporter: Claus Ibsen Fix For: 2.15.0 camel-cxfrs should be integrated with the new Rest DSL. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7448) throttle EIP - unchanged value
[ https://issues.apache.org/jira/browse/CAMEL-7448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14110493#comment-14110493 ] Claus Ibsen commented on CAMEL-7448: Ben do you have time to work on this? throttle EIP - unchanged value -- Key: CAMEL-7448 URL: https://issues.apache.org/jira/browse/CAMEL-7448 Project: Camel Issue Type: Bug Components: camel-core, eip Affects Versions: 2.13.1 Reporter: Elvio Caruana Assignee: Ben O'Day Priority: Minor Fix For: 2.13.3, 2.14.0 Throttler Documentation [1] states If the header is absent, then the Throttler uses the old value. So that allows you to only provide a header if the value is to be changed. however if the expression evaluates to null (header missing from message) the Throttler throws an exception (Throttler.java:108). The workaround is to ensure that all messages carry the value (if the value is the same no changes will take affect). Adding an option to turn this on and off (e.g. allowNullException) would make it much easier to use (as per camel-users thread [2]). [1] http://camel.apache.org/throttler.html [2] http://camel.465427.n5.nabble.com/throttle-EIP-unchanged-value-td5751300.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7420) Rest DSL - expose WADL for the new REST endpoint (and ideally other HTTP based camel endpoints too)
[ https://issues.apache.org/jira/browse/CAMEL-7420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7420: --- Fix Version/s: 2.15.0 Rest DSL - expose WADL for the new REST endpoint (and ideally other HTTP based camel endpoints too) --- Key: CAMEL-7420 URL: https://issues.apache.org/jira/browse/CAMEL-7420 Project: Camel Issue Type: Sub-task Components: camel-core Reporter: james strachan Fix For: 2.15.0 once CAMEL-7354 is implemented; it'd be great to provide a JMX API to be able to get the WADL of a camel endpoint/component/route/context so we can document and browse the available camel REST APIs like we can with CXF. Having a course grained API WADL would be better; e.g. at the component level; maybe with documentation/links to specific route ids / camel context ids etc? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CAMEL-7354) make it easier to define and expose clean RESTful APIs to back end services / endpoints via a new rest endpoint
[
https://issues.apache.org/jira/browse/CAMEL-7354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-7354.
Resolution: Fixed
We got the bulk of this done, improvements logged as sub tasks for next release.
make it easier to define and expose clean RESTful APIs to back end services /
endpoints via a new rest endpoint
-
Key: CAMEL-7354
URL: https://issues.apache.org/jira/browse/CAMEL-7354
Project: Camel
Issue Type: New Feature
Components: camel-core
Reporter: james strachan
Assignee: Claus Ibsen
Fix For: 2.14.0
All the current HTTP-like endpoints tend to have host/port in the URI and are
not that DRY; plus there's no easy way to view the API if the consumer of the
REST API is a REST developer (rather than Java/Camel developer).
It'd be nice to make things more DRY to have an easy way to define mappings
from restful operations and URI templates to camel routes.
Exposing camel routes and endpoints as nice clean RESTful APIs is going to
get more common (as an alternative to doing things by hand in pure Java with
JAX-RS for example). Particularly in the age of BaaS and API Management; its
going to be really handy to use Camel as a facade to wrap back end services
as clean RESTful APIs.
So it'd be nice to be able to do things like...
{code}
from(rest:get://customers).to(...);
from(rest:put://customer/{id}).to(...);
{code}
i.e. define a rest component which can be configured with a HTTP plugin to
use (e.g. use netty by default, or be able to reuse the servlet/http engine
in tomcat/karaf) along with configuring the host/port if not using the
current containers web connector.
Then the remaining URI format is HTTP method (GET/PUT/POST/DELETE/OPTION etc)
followed by a URI template. Optional parameters could be to set content type
and the like. The Camel DSL can be used to do content based routing and so
forth.
It might be even cooler to add a little RestRouteBuilder class which extends
RouteBuilder to add extra Java DSL operations
{code}
public class MyRouteBuilder extends RestRouteBuilder {
protected void configure() {
get(/customers).to(...);
put(/customers/{id}).to(...);
// the above is just a facade over from(get:/ + uriTemplate) etc
}
}
{code}
When using URI templates the values (such as 'id' in the examples above)
should be exposed as properties so they can be referred to in any expressions
and so forth in the camel DSL.
Extra brownie points if by default the REST component also exposed a WADL /
Swagger file listing all the RESTful operations defined on the endpoint; so
the API can be easily introspected.
Since JSON / XML are going to be the most common stuff; it might be good if
the REST endpoint defaulted to using those out of the box if nothing's
specified. Or at least if something like this were used in the Java DSL...
{code}
public class MyRouteBuilder extends RestRouteBuilder {
protected void configure() {
put(/customers/{id}, MyDTO.class).to(...);
}
}
{code}
it'd default to unmarshalling/marshalling using jackson / JSON by default
(the Binding could be configured on the REST component - or via the DSL on a
per endpoint basis; but doing JSON / jackson by default seems the most useful
out of the box)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CAMEL-7467) Spring-orm 4.x removed the support of ibatis
[ https://issues.apache.org/jira/browse/CAMEL-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14110497#comment-14110497 ] Claus Ibsen commented on CAMEL-7467: There is no iBatis3, that is called MyBatis. This is fine as is, camel-ibatis should only support spring 3.x. And the component should be deprecated and people should use MyBatis instead. Spring-orm 4.x removed the support of ibatis - Key: CAMEL-7467 URL: https://issues.apache.org/jira/browse/CAMEL-7467 Project: Camel Issue Type: Sub-task Components: tests Reporter: Willem Jiang Assignee: Willem Jiang Fix For: 2.14.0 Spring-orm 4.x removed the support of iBatis and suggest user to use iBatis spring support directly. But ibatis spring support only support iBatis 3, and current camel is using ibatis2. We need to update the camel-ibatis to use iBatis3 to address the upgrade issue. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CAMEL-7467) Spring-orm 4.x removed the support of ibatis
[ https://issues.apache.org/jira/browse/CAMEL-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7467. Resolution: Fixed camel-ibatis does not rely on spring at all. So people can use this without spring. Spring-orm 4.x removed the support of ibatis - Key: CAMEL-7467 URL: https://issues.apache.org/jira/browse/CAMEL-7467 Project: Camel Issue Type: Sub-task Components: tests Reporter: Willem Jiang Assignee: Willem Jiang Fix For: 2.14.0 Spring-orm 4.x removed the support of iBatis and suggest user to use iBatis spring support directly. But ibatis spring support only support iBatis 3, and current camel is using ibatis2. We need to update the camel-ibatis to use iBatis3 to address the upgrade issue. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7746) Use Spring 4.x as default
Claus Ibsen created CAMEL-7746: -- Summary: Use Spring 4.x as default Key: CAMEL-7746 URL: https://issues.apache.org/jira/browse/CAMEL-7746 Project: Camel Issue Type: Task Reporter: Claus Ibsen Fix For: 2.15.0 We should switch to use spring 4.x as the default in Camel 2.15 onwards. Spring 3.x is still supported by not the default version. For OSGi users on Karaf they can still use spring 3.x with Camel 2.15 etc. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7668) @Consume may restart during a shutdown event
[
https://issues.apache.org/jira/browse/CAMEL-7668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14110500#comment-14110500
]
Claus Ibsen commented on CAMEL-7668:
This is the pojo example btw that is shipped with Apache Camel.
@Consume may restart during a shutdown event
Key: CAMEL-7668
URL: https://issues.apache.org/jira/browse/CAMEL-7668
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: Claus Ibsen
Assignee: Claus Ibsen
Priority: Minor
Fix For: 2.14.0
When using POJO consuming and we shutdown CamelContext and if by chance
something hangs, such as the JMS shutdown (see other tickets) then the file
endpoint may be stopped but the POJO consumer is still running (not shutdown)
and this causes the idempotent repo to reset its state, and the POJO consumer
will then pickup the same files again.
eg as demonstrated by the pojo example
{code}
2014-08-07 14:17:49,909 [file://src/data] INFO SendFileRecordsToQueueBean
- Incoming file: message1.xml
2014-08-07 14:17:49,945 [file://src/data] INFO SendFileRecordsToQueueBean
- Incoming file: message2.xml
2014-08-07 14:17:49,950 [file://src/data] INFO SendFileRecordsToQueueBean
- Incoming file: message3.xml
2014-08-07 14:17:49,955 [sonnel.records]] INFO XPathBuilder
- Created default XPathFactory
com.sun.org.apache.xpath.internal.jaxp.XPathFactoryImpl@3e9037f9
2014-08-07 14:17:49,996 [sonnel.records]] INFO DistributeRecordsBean
- Person is from EMEA region
2014-08-07 14:17:50,008 [sonnel.records]] INFO DistributeRecordsBean
- Person is from AMER region
2014-08-07 14:17:50,014 [sonnel.records]] INFO DistributeRecordsBean
- Person is from AMER region
^C2014-08-07 14:17:52,237 [Thread-5 ] INFO
MainSupport$HangupInterceptor - Received hang up - stopping the main
instance.
2014-08-07 14:17:52,237 [Thread-5 ] INFO MainSupport
- Apache Camel 2.14-SNAPSHOT stopping
2014-08-07 14:17:52,237 [Thread-5 ] INFO
ClassPathXmlApplicationContext - Closing
org.springframework.context.support.ClassPathXmlApplicationContext@1f361707:
startup date [Thu Aug 07 14:17:46 CEST 2014]; root of context hierarchy
2014-08-07 14:17:52,238 [Thread-5 ] INFO SpringCamelContext
- Apache Camel 2.14-SNAPSHOT (CamelContext: camel-1) is shutting down
2014-08-07 14:17:52,242 [sonnel.records]] WARN
ultJmsMessageListenerContainer - Setup of JMS message listener invoker failed
for destination 'personnel.records' - trying to recover. Cause: The Session
is closed
2014-08-07 14:17:52,247 [sonnel.records]] ERROR
ultJmsMessageListenerContainer - Could not refresh JMS Connection for
destination 'personnel.records' - retrying in 5000 ms. Cause: null
2014-08-07 14:17:52,466 [file://src/data] INFO SendFileRecordsToQueueBean
- Incoming file: message1.xml
2014-08-07 14:17:52,467 [file://src/data] WARN GenericFileOnCompletion
- Rollback file strategy:
org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy@693a9769
for file: GenericFile[message1.xml]
2014-08-07 14:17:52,469 [file://src/data] INFO SendFileRecordsToQueueBean
- Incoming file: message2.xml
2014-08-07 14:17:52,469 [file://src/data] WARN GenericFileOnCompletion
- Rollback file strategy:
org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy@693a9769
for file: GenericFile[message2.xml]
2014-08-07 14:17:52,470 [file://src/data] INFO SendFileRecordsToQueueBean
- Incoming file: message3.xml
2014-08-07 14:17:52,470 [file://src/data] WARN GenericFileOnCompletion
- Rollback file strategy:
org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy@693a9769
for file: GenericFile[message3.xml]
2014-08-07 14:17:52,976 [file://src/data] INFO SendFileRecordsToQueueBean
- Incoming file: message1.xml
2014-08-07 14:17:52,977 [file://src/data] WARN GenericFileOnCompletion
- Rollback file strategy:
org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy@693a9769
for file: GenericFile[message1.xml]
2014-08-07 14:17:52,978 [file://src/data] INFO SendFileRecordsToQueueBean
- Incoming file: message2.xml
2014-08-07 14:17:52,979 [file://src/data] WARN GenericFileOnCompletion
- Rollback file strategy:
org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy@693a9769
for file: GenericFile[message2.xml]
2014-08-07 14:17:52,980 [file://src/data] INFO SendFileRecordsToQueueBean
- Incoming file: message3.xml
2014-08-07 14:17:52,980 [file://src/data] WARN GenericFileOnCompletion
- Rollback file strategy:
[jira] [Resolved] (CAMEL-7689) Rest DSL - Swagger module should have SPI plugin to integrate with blueprint or other ways to discover Camel in the app / JVM
[ https://issues.apache.org/jira/browse/CAMEL-7689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7689. Resolution: Fixed Rest DSL - Swagger module should have SPI plugin to integrate with blueprint or other ways to discover Camel in the app / JVM - Key: CAMEL-7689 URL: https://issues.apache.org/jira/browse/CAMEL-7689 Project: Camel Issue Type: Sub-task Components: camel-core Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.14.0 Currently the module uses spring. But we should allow to blueprint / cdi / servlet etc to discover the Camel in the WAR / JVM. We could try using JMX discovery. But a bit of trick is that swagger has a model processor that scan POJOs and generate a swagger model of those. And if those POJOs are in another classloader, we need to allow swagger to see these classes to scan 'en. Or offer a scanner in camel-core we can use and return the data over JMX. Then we can support any Camel in the JVM and have the swagger module separated from the Camel app. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7747) Support Karaf 3.0.1 which uses an older jline version
Claus Ibsen created CAMEL-7747: -- Summary: Support Karaf 3.0.1 which uses an older jline version Key: CAMEL-7747 URL: https://issues.apache.org/jira/browse/CAMEL-7747 Project: Camel Issue Type: Task Components: karaf Affects Versions: 2.14.0 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.14.0 We should use a broader jline import version so we can support jline 2.11 also. As that version is used by Karaf 3.0.x and newer Karaf releases may be using jline 2.12. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CAMEL-7747) Support Karaf 3.0.1 which uses an older jline version
[ https://issues.apache.org/jira/browse/CAMEL-7747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7747. Resolution: Fixed Support Karaf 3.0.1 which uses an older jline version - Key: CAMEL-7747 URL: https://issues.apache.org/jira/browse/CAMEL-7747 Project: Camel Issue Type: Task Components: karaf Affects Versions: 2.14.0 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.14.0 We should use a broader jline import version so we can support jline 2.11 also. As that version is used by Karaf 3.0.x and newer Karaf releases may be using jline 2.12. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7748) org.apache.camel.component.twitter.UriConfigurationTest is failing
Kevin Earls created CAMEL-7748: -- Summary: org.apache.camel.component.twitter.UriConfigurationTest is failing Key: CAMEL-7748 URL: https://issues.apache.org/jira/browse/CAMEL-7748 Project: Camel Issue Type: Test Components: camel-twitter Reporter: Kevin Earls Priority: Minor This test fails with the error below. I think Clause missed this on the fix for CAMEL-7495. java.lang.AssertionError: null at org.junit.Assert.fail(Assert.java:86) at org.junit.Assert.assertTrue(Assert.java:41) at org.junit.Assert.assertTrue(Assert.java:52) at org.apache.camel.component.twitter.UriConfigurationTest.testComponentConfiguration(UriConfigurationTest.java:77) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7748) org.apache.camel.component.twitter.UriConfigurationTest is failing
[ https://issues.apache.org/jira/browse/CAMEL-7748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14110680#comment-14110680 ] ASF GitHub Bot commented on CAMEL-7748: --- GitHub user kevinearls opened a pull request: https://github.com/apache/camel/pull/253 Fix for CAMEL-7748 Test was failing because of change in returning json ... ...schema object types. You can merge this pull request into a Git repository by running: $ git pull https://github.com/kevinearls/camel CAMEL-7748 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/253.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 #253 commit d70039b14e971654af9e13a080954ee46f233456 Author: Kevin Earls ke...@kevinearls.com Date: 2014-08-26T13:15:01Z Fix for CAMEL-7748 Test was failing because of change in returning json schema object types org.apache.camel.component.twitter.UriConfigurationTest is failing -- Key: CAMEL-7748 URL: https://issues.apache.org/jira/browse/CAMEL-7748 Project: Camel Issue Type: Test Components: camel-twitter Reporter: Kevin Earls Priority: Minor This test fails with the error below. I think Clause missed this on the fix for CAMEL-7495. java.lang.AssertionError: null at org.junit.Assert.fail(Assert.java:86) at org.junit.Assert.assertTrue(Assert.java:41) at org.junit.Assert.assertTrue(Assert.java:52) at org.apache.camel.component.twitter.UriConfigurationTest.testComponentConfiguration(UriConfigurationTest.java:77) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7748) org.apache.camel.component.twitter.UriConfigurationTest is failing
[ https://issues.apache.org/jira/browse/CAMEL-7748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14110712#comment-14110712 ] ASF GitHub Bot commented on CAMEL-7748: --- Github user asfgit closed the pull request at: https://github.com/apache/camel/pull/253 org.apache.camel.component.twitter.UriConfigurationTest is failing -- Key: CAMEL-7748 URL: https://issues.apache.org/jira/browse/CAMEL-7748 Project: Camel Issue Type: Test Components: camel-twitter Reporter: Kevin Earls Priority: Minor This test fails with the error below. I think Clause missed this on the fix for CAMEL-7495. java.lang.AssertionError: null at org.junit.Assert.fail(Assert.java:86) at org.junit.Assert.assertTrue(Assert.java:41) at org.junit.Assert.assertTrue(Assert.java:52) at org.apache.camel.component.twitter.UriConfigurationTest.testComponentConfiguration(UriConfigurationTest.java:77) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CAMEL-7576) camel-cache - Turn off ET phone home
[ https://issues.apache.org/jira/browse/CAMEL-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7576. Resolution: Fixed Fix Version/s: 2.12.5 Assignee: Claus Ibsen camel-cache - Turn off ET phone home Key: CAMEL-7576 URL: https://issues.apache.org/jira/browse/CAMEL-7576 Project: Camel Issue Type: Improvement Components: camel-cache Affects Versions: 2.13.1 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.12.5, 2.13.3, 2.14.0 See nabble http://camel.465427.n5.nabble.com/camel-cache-2-13-1-fails-on-UpdateChecker-tp5753294.html And some links https://issues.apache.org/jira/browse/SHINDIG-1617?jql=text%20~%20%22updatechecker%22 https://jira.terracotta.org/jira/browse/QTZ-29 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CAMEL-7748) org.apache.camel.component.twitter.UriConfigurationTest is failing
[ https://issues.apache.org/jira/browse/CAMEL-7748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7748. Resolution: Fixed Fix Version/s: 2.14.0 Assignee: Claus Ibsen Thanks org.apache.camel.component.twitter.UriConfigurationTest is failing -- Key: CAMEL-7748 URL: https://issues.apache.org/jira/browse/CAMEL-7748 Project: Camel Issue Type: Test Components: camel-twitter Reporter: Kevin Earls Assignee: Claus Ibsen Priority: Minor Fix For: 2.14.0 This test fails with the error below. I think Clause missed this on the fix for CAMEL-7495. java.lang.AssertionError: null at org.junit.Assert.fail(Assert.java:86) at org.junit.Assert.assertTrue(Assert.java:41) at org.junit.Assert.assertTrue(Assert.java:52) at org.apache.camel.component.twitter.UriConfigurationTest.testComponentConfiguration(UriConfigurationTest.java:77) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7749) JmsTXForceShutdownIssueTest#testTXForceShutdown should be ignored
Kevin Earls created CAMEL-7749: -- Summary: JmsTXForceShutdownIssueTest#testTXForceShutdown should be ignored Key: CAMEL-7749 URL: https://issues.apache.org/jira/browse/CAMEL-7749 Project: Camel Issue Type: Test Reporter: Kevin Earls Priority: Minor This test was previously ignored. It looks like the @Ignore was commented out by accident as part of another change. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7749) JmsTXForceShutdownIssueTest#testTXForceShutdown should be ignored
[ https://issues.apache.org/jira/browse/CAMEL-7749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14110716#comment-14110716 ] ASF GitHub Bot commented on CAMEL-7749: --- GitHub user kevinearls opened a pull request: https://github.com/apache/camel/pull/254 Fix for CAMEL-7749 restore @Ignore on testTXForceShutdown You can merge this pull request into a Git repository by running: $ git pull https://github.com/kevinearls/camel CAMEL-7749 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/254.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 #254 commit 99a76e70678b4a99ff7139fed7bd393dafaacf6f Author: Kevin Earls ke...@kevinearls.com Date: 2014-08-26T13:58:08Z Fix for CAMEL-7749 restore @Ignore on testTXForceShutdown JmsTXForceShutdownIssueTest#testTXForceShutdown should be ignored - Key: CAMEL-7749 URL: https://issues.apache.org/jira/browse/CAMEL-7749 Project: Camel Issue Type: Test Reporter: Kevin Earls Priority: Minor This test was previously ignored. It looks like the @Ignore was commented out by accident as part of another change. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7749) JmsTXForceShutdownIssueTest#testTXForceShutdown should be ignored
[ https://issues.apache.org/jira/browse/CAMEL-7749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7749: --- Component/s: tests JmsTXForceShutdownIssueTest#testTXForceShutdown should be ignored - Key: CAMEL-7749 URL: https://issues.apache.org/jira/browse/CAMEL-7749 Project: Camel Issue Type: Test Components: tests Reporter: Kevin Earls Assignee: Claus Ibsen Priority: Minor Fix For: 2.14.0 This test was previously ignored. It looks like the @Ignore was commented out by accident as part of another change. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CAMEL-7749) JmsTXForceShutdownIssueTest#testTXForceShutdown should be ignored
[ https://issues.apache.org/jira/browse/CAMEL-7749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7749. Resolution: Fixed Fix Version/s: 2.14.0 Assignee: Claus Ibsen Thanks again for spotting this. JmsTXForceShutdownIssueTest#testTXForceShutdown should be ignored - Key: CAMEL-7749 URL: https://issues.apache.org/jira/browse/CAMEL-7749 Project: Camel Issue Type: Test Components: tests Reporter: Kevin Earls Assignee: Claus Ibsen Priority: Minor Fix For: 2.14.0 This test was previously ignored. It looks like the @Ignore was commented out by accident as part of another change. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7749) JmsTXForceShutdownIssueTest#testTXForceShutdown should be ignored
[ https://issues.apache.org/jira/browse/CAMEL-7749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14110724#comment-14110724 ] ASF GitHub Bot commented on CAMEL-7749: --- Github user asfgit closed the pull request at: https://github.com/apache/camel/pull/254 JmsTXForceShutdownIssueTest#testTXForceShutdown should be ignored - Key: CAMEL-7749 URL: https://issues.apache.org/jira/browse/CAMEL-7749 Project: Camel Issue Type: Test Components: tests Reporter: Kevin Earls Assignee: Claus Ibsen Priority: Minor Fix For: 2.14.0 This test was previously ignored. It looks like the @Ignore was commented out by accident as part of another change. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7448) throttle EIP - unchanged value
[ https://issues.apache.org/jira/browse/CAMEL-7448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14110969#comment-14110969 ] Ben O'Day commented on CAMEL-7448: -- I can, I was just waiting for some feedback...does that approach sound alright? throttle EIP - unchanged value -- Key: CAMEL-7448 URL: https://issues.apache.org/jira/browse/CAMEL-7448 Project: Camel Issue Type: Bug Components: camel-core, eip Affects Versions: 2.13.1 Reporter: Elvio Caruana Assignee: Ben O'Day Priority: Minor Fix For: 2.13.3, 2.14.0 Throttler Documentation [1] states If the header is absent, then the Throttler uses the old value. So that allows you to only provide a header if the value is to be changed. however if the expression evaluates to null (header missing from message) the Throttler throws an exception (Throttler.java:108). The workaround is to ensure that all messages carry the value (if the value is the same no changes will take affect). Adding an option to turn this on and off (e.g. allowNullException) would make it much easier to use (as per camel-users thread [2]). [1] http://camel.apache.org/throttler.html [2] http://camel.465427.n5.nabble.com/throttle-EIP-unchanged-value-td5751300.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7434) Provide a way to force the completion of a aggregate exchange from an external event
[ https://issues.apache.org/jira/browse/CAMEL-7434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14110984#comment-14110984 ] Ben O'Day commented on CAMEL-7434: -- in the short term, I can add the support for a new marker header (AGGREGATION_COMPLETE_FOR_GROUP) which would invoke forceCompletionOfGroup(key)...if this is acceptable. then perhaps log a separate task to add an external controller as Claus suggested...thoughts? Provide a way to force the completion of a aggregate exchange from an external event Key: CAMEL-7434 URL: https://issues.apache.org/jira/browse/CAMEL-7434 Project: Camel Issue Type: New Feature Components: camel-core, eip Affects Versions: 2.13.0 Reporter: Susan Javurek Assignee: Ben O'Day Fix For: Future There is a way to do this by creating a trigger exchange that is handled in a special way by the aggregation strategy and a completion predicate. But this solution is quite intrusive and painful to write. It would actually be much easier if the AggregateProcessor would implement and expose the following methods: public void forceCompletionOfGroup(String key) public Expression getCorrelationExpression() This way, it becomes possible to control externally an aggregator without having to implement some intrusive logic. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7448) throttle EIP - unchanged value
[ https://issues.apache.org/jira/browse/CAMEL-7448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1421#comment-1421 ] Claus Ibsen commented on CAMEL-7448: Ben, yeah this sounds like a good idea. I think you should try this change. throttle EIP - unchanged value -- Key: CAMEL-7448 URL: https://issues.apache.org/jira/browse/CAMEL-7448 Project: Camel Issue Type: Bug Components: camel-core, eip Affects Versions: 2.13.1 Reporter: Elvio Caruana Assignee: Ben O'Day Priority: Minor Fix For: 2.13.3, 2.14.0 Throttler Documentation [1] states If the header is absent, then the Throttler uses the old value. So that allows you to only provide a header if the value is to be changed. however if the expression evaluates to null (header missing from message) the Throttler throws an exception (Throttler.java:108). The workaround is to ensure that all messages carry the value (if the value is the same no changes will take affect). Adding an option to turn this on and off (e.g. allowNullException) would make it much easier to use (as per camel-users thread [2]). [1] http://camel.apache.org/throttler.html [2] http://camel.465427.n5.nabble.com/throttle-EIP-unchanged-value-td5751300.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7434) Provide a way to force the completion of a aggregate exchange from an external event
[ https://issues.apache.org/jira/browse/CAMEL-7434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1424#comment-1424 ] Claus Ibsen commented on CAMEL-7434: I think its the external controller that is the most needed. As sometimes you need a way of management to force a completion etc. Or some external tooling to do that. Ben, I suggest you log a new ticket about that completion for group header, so we keep this about the external controller. Provide a way to force the completion of a aggregate exchange from an external event Key: CAMEL-7434 URL: https://issues.apache.org/jira/browse/CAMEL-7434 Project: Camel Issue Type: New Feature Components: camel-core, eip Affects Versions: 2.13.0 Reporter: Susan Javurek Assignee: Ben O'Day Fix For: Future There is a way to do this by creating a trigger exchange that is handled in a special way by the aggregation strategy and a completion predicate. But this solution is quite intrusive and painful to write. It would actually be much easier if the AggregateProcessor would implement and expose the following methods: public void forceCompletionOfGroup(String key) public Expression getCorrelationExpression() This way, it becomes possible to control externally an aggregator without having to implement some intrusive logic. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CAMEL-7733) Sending a CamelCacheDeleteAll does not actually delete anything
[ https://issues.apache.org/jira/browse/CAMEL-7733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7733. Resolution: Won't Fix Working as designed, we use the api of ehcache to remove all. Sending a CamelCacheDeleteAll does not actually delete anything --- Key: CAMEL-7733 URL: https://issues.apache.org/jira/browse/CAMEL-7733 Project: Camel Issue Type: Bug Components: camel-cache Affects Versions: 2.13.2 Environment: Karaf 3.0.1, CentOS 6 Reporter: Matt Sicker Priority: Minor Sending a CamelCacheOperation of CamelCacheDeleteAll doesn't actually delete anything from the cache. It might be clearing out the in-memory cache, but anything that's persisted to disk won't be cleared. This causes immense problems anytime a stray class gets serialized that had its serialization format updated. Constant exceptions from attempting to get items from the cache is not what should be happening here. If I delete the cache file EHCache is using, that obviously does nothing as it still has a file handle on it and will continue using it unless I completely restart Karaf. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CAMEL-7688) XPathBuilder initDefaultXPathFactory implementation incorrect
[ https://issues.apache.org/jira/browse/CAMEL-7688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-7688: -- Assignee: Claus Ibsen XPathBuilder initDefaultXPathFactory implementation incorrect - Key: CAMEL-7688 URL: https://issues.apache.org/jira/browse/CAMEL-7688 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.12.3 Reporter: Chris Watts Assignee: Claus Ibsen Priority: Minor Attachments: camel-core-xpathbuild.patch The implementation of initDefaultXPathFactory uses instance and static variables to initialize a static XPathFactory then overrides it anyway. Looks like so old code that was never removed plus a bug where it's not using the implementation specified on the command line. I've also added a function to allow the default to be passed in, this allows the jvm deafult to be different from the XPathBuilder (saves having to set it on every xpath factory created). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7688) XPathBuilder initDefaultXPathFactory implementation incorrect
[ https://issues.apache.org/jira/browse/CAMEL-7688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7688: --- Fix Version/s: 2.14.0 XPathBuilder initDefaultXPathFactory implementation incorrect - Key: CAMEL-7688 URL: https://issues.apache.org/jira/browse/CAMEL-7688 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.12.3 Reporter: Chris Watts Assignee: Claus Ibsen Priority: Minor Fix For: 2.14.0 Attachments: camel-core-xpathbuild.patch The implementation of initDefaultXPathFactory uses instance and static variables to initialize a static XPathFactory then overrides it anyway. Looks like so old code that was never removed plus a bug where it's not using the implementation specified on the command line. I've also added a function to allow the default to be passed in, this allows the jvm deafult to be different from the XPathBuilder (saves having to set it on every xpath factory created). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7688) XPathBuilder initDefaultXPathFactory implementation incorrect
[ https://issues.apache.org/jira/browse/CAMEL-7688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7688: --- Issue Type: Improvement (was: Bug) XPathBuilder initDefaultXPathFactory implementation incorrect - Key: CAMEL-7688 URL: https://issues.apache.org/jira/browse/CAMEL-7688 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.12.3 Reporter: Chris Watts Assignee: Claus Ibsen Priority: Minor Fix For: 2.14.0 Attachments: camel-core-xpathbuild.patch The implementation of initDefaultXPathFactory uses instance and static variables to initialize a static XPathFactory then overrides it anyway. Looks like so old code that was never removed plus a bug where it's not using the implementation specified on the command line. I've also added a function to allow the default to be passed in, this allows the jvm deafult to be different from the XPathBuilder (saves having to set it on every xpath factory created). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7628) Incorrect tests of quartz2 component
[ https://issues.apache.org/jira/browse/CAMEL-7628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7628: --- Priority: Minor (was: Major) Incorrect tests of quartz2 component Key: CAMEL-7628 URL: https://issues.apache.org/jira/browse/CAMEL-7628 Project: Camel Issue Type: Test Components: camel-quartz, camel-quartz2 Reporter: Nikolay Turpitko Priority: Minor Fix For: 2.14.0 Attachments: 0001-Fix-SpringQuartzPersistentStoreTest.patch, 0002-Fix-SpringQuartzPersistentStoreRestart-Test.patch There are errors in tests of quartz2 component with persistent store such as org.apache.camel.component.quartz2.SpringQuartzPersistentStoreTest. It's application context configuration resides in file org/apache/camel/component/quartz2/SpringQuartzPersistentStoreTest.xml. Which has a suspicious issue in it: scheduler bean, which is configured to use DB, further passed to bean with id quartz, but in the endpoint's uri in the route the bean with id quartz2 used. I'm afraid, this test ignores configured quartz bean, scheduler bean, datasource and database. I provided patches to fix incorrect tests. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7628) Incorrect tests of quartz2 component
[ https://issues.apache.org/jira/browse/CAMEL-7628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7628: --- Issue Type: Test (was: Bug) Incorrect tests of quartz2 component Key: CAMEL-7628 URL: https://issues.apache.org/jira/browse/CAMEL-7628 Project: Camel Issue Type: Test Components: camel-quartz, camel-quartz2 Reporter: Nikolay Turpitko Fix For: 2.14.0 Attachments: 0001-Fix-SpringQuartzPersistentStoreTest.patch, 0002-Fix-SpringQuartzPersistentStoreRestart-Test.patch There are errors in tests of quartz2 component with persistent store such as org.apache.camel.component.quartz2.SpringQuartzPersistentStoreTest. It's application context configuration resides in file org/apache/camel/component/quartz2/SpringQuartzPersistentStoreTest.xml. Which has a suspicious issue in it: scheduler bean, which is configured to use DB, further passed to bean with id quartz, but in the endpoint's uri in the route the bean with id quartz2 used. I'm afraid, this test ignores configured quartz bean, scheduler bean, datasource and database. I provided patches to fix incorrect tests. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7628) Incorrect tests of quartz2 component
[ https://issues.apache.org/jira/browse/CAMEL-7628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7628: --- Fix Version/s: 2.14.0 Incorrect tests of quartz2 component Key: CAMEL-7628 URL: https://issues.apache.org/jira/browse/CAMEL-7628 Project: Camel Issue Type: Test Components: camel-quartz, camel-quartz2 Reporter: Nikolay Turpitko Fix For: 2.14.0 Attachments: 0001-Fix-SpringQuartzPersistentStoreTest.patch, 0002-Fix-SpringQuartzPersistentStoreRestart-Test.patch There are errors in tests of quartz2 component with persistent store such as org.apache.camel.component.quartz2.SpringQuartzPersistentStoreTest. It's application context configuration resides in file org/apache/camel/component/quartz2/SpringQuartzPersistentStoreTest.xml. Which has a suspicious issue in it: scheduler bean, which is configured to use DB, further passed to bean with id quartz, but in the endpoint's uri in the route the bean with id quartz2 used. I'm afraid, this test ignores configured quartz bean, scheduler bean, datasource and database. I provided patches to fix incorrect tests. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7568) OnComplete does not work on transactioned route after rollback
[
https://issues.apache.org/jira/browse/CAMEL-7568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-7568:
---
Priority: Minor (was: Major)
OnComplete does not work on transactioned route after rollback
---
Key: CAMEL-7568
URL: https://issues.apache.org/jira/browse/CAMEL-7568
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.13.1
Reporter: André Ricardo da Silva Souza
Priority: Minor
Fix For: 2.14.0
Example:
{code:title=Route Sample|borderStyle=solid}
this.from(servlet:///test).routeId(CamelTestRoute)
.onCompletion()
.bean(this.logCompletionRoute)
.end()
.onException(Exception.class)
.log(LoggingLevel.ERROR, this.log, Error on processing message.
Sending Rollback command!)
.log(LoggingLevel.ERROR, this.log, ${exception.stacktrace})
.rollback()
.handled(true)
.end()
.transacted(RouteTransactionConfiguration.PROPAGATION_REQUIRED)
.process(new Processor() {
@Override
public void process(Exchange exchange) throws Exception {
throw new Exception();
}});
{code}
In this sample, the OnCompletion bean never is executed. But, if I remove the
rollback() call, it is executed properly.
thanks,
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (CAMEL-7568) OnComplete does not work on transactioned route after rollback
[
https://issues.apache.org/jira/browse/CAMEL-7568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-7568:
--
Assignee: Claus Ibsen
OnComplete does not work on transactioned route after rollback
---
Key: CAMEL-7568
URL: https://issues.apache.org/jira/browse/CAMEL-7568
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.13.1
Reporter: André Ricardo da Silva Souza
Assignee: Claus Ibsen
Priority: Minor
Fix For: 2.14.0
Example:
{code:title=Route Sample|borderStyle=solid}
this.from(servlet:///test).routeId(CamelTestRoute)
.onCompletion()
.bean(this.logCompletionRoute)
.end()
.onException(Exception.class)
.log(LoggingLevel.ERROR, this.log, Error on processing message.
Sending Rollback command!)
.log(LoggingLevel.ERROR, this.log, ${exception.stacktrace})
.rollback()
.handled(true)
.end()
.transacted(RouteTransactionConfiguration.PROPAGATION_REQUIRED)
.process(new Processor() {
@Override
public void process(Exchange exchange) throws Exception {
throw new Exception();
}});
{code}
In this sample, the OnCompletion bean never is executed. But, if I remove the
rollback() call, it is executed properly.
thanks,
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CAMEL-7503) PAYLOAD Producer select first available operation if OPERATION_NAME don't specified
[
https://issues.apache.org/jira/browse/CAMEL-7503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-7503.
Resolution: Not a Problem
PAYLOAD Producer select first available operation if OPERATION_NAME don't
specified
---
Key: CAMEL-7503
URL: https://issues.apache.org/jira/browse/CAMEL-7503
Project: Camel
Issue Type: Bug
Components: camel-cxf
Affects Versions: 2.13.0
Reporter: Alexey Markevich
Assignee: Willem Jiang
Fix For: 2.12.5, 2.13.3, 2.14.0
Webservice [1] contains two operations.
Following route works:
from(timer:cTimer_1?period=1repeatCount=1delay=1)
.setBody().constant(web:GetWeather
xmlns:web='http://www.webserviceX.NET'web:CityNameMinsk/web:CityName/web:GetWeather)
.to(cxf://http://www.webservicex.net/globalweather.asmx?wsdlURL=F:/globalweather.wsdldataFormat=PAYLOADserviceName={http://www.webserviceX.NET}GlobalWeatherendpointName={http://www.webserviceX.NET}GlobalWeatherSoap;)
.to(log:cLog_1?level=INFO)
But with body
web:GetCitiesByCountry
xmlns:web='http://www.webserviceX.NET'web:CountryNameBelarus/web:CountryName/web:GetCitiesByCountry
there is exception [2].
Looking into the sources [3] I found that first available opration used.
Expected that operation lookup is based on payload root element (which is
different for operations)
1. http://www.webservicex.net/globalweather.asmx?WSDL
2.
[WARN ]: org.apache.camel.component.timer.TimerConsumer - Error processing
exchange. Exchange[Message: web:GetCitiesByCountry
xmlns:web='http://www.webserviceX.NET'web:CountryNameBelarus/web:CountryName/web:GetCitiesByCountry].
Caused by: [java.lang.IllegalArgumentException - The PayLoad elements cannot
fit with the message parts of the BindingOperation. Please check the
BindingOperation and PayLoadMessage.]
java.lang.IllegalArgumentException: The PayLoad elements cannot fit with the
message parts of the BindingOperation. Please check the BindingOperation and
PayLoadMessage.
at
org.apache.camel.component.cxf.CxfEndpoint$CamelCxfClientImpl.setParameters(CxfEndpoint.java:1011)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:526)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:472)
at
org.apache.camel.component.cxf.CxfProducer.process(CxfProducer.java:112)
at
org.apache.camel.processor.SendProcessor.process(SendProcessor.java:113)
at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398)
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:118)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
at
org.apache.camel.component.timer.TimerConsumer.sendTimerExchange(TimerConsumer.java:139)
at
org.apache.camel.component.timer.TimerConsumer$1.run(TimerConsumer.java:64)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
3.
https://github.com/apache/camel/blob/master/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfProducer.java#L344
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CAMEL-7503) PAYLOAD Producer select first available operation if OPERATION_NAME don't specified
[
https://issues.apache.org/jira/browse/CAMEL-7503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-7503:
---
Fix Version/s: 2.14.0
2.13.3
2.12.5
PAYLOAD Producer select first available operation if OPERATION_NAME don't
specified
---
Key: CAMEL-7503
URL: https://issues.apache.org/jira/browse/CAMEL-7503
Project: Camel
Issue Type: Bug
Components: camel-cxf
Affects Versions: 2.13.0
Reporter: Alexey Markevich
Assignee: Willem Jiang
Fix For: 2.12.5, 2.13.3, 2.14.0
Webservice [1] contains two operations.
Following route works:
from(timer:cTimer_1?period=1repeatCount=1delay=1)
.setBody().constant(web:GetWeather
xmlns:web='http://www.webserviceX.NET'web:CityNameMinsk/web:CityName/web:GetWeather)
.to(cxf://http://www.webservicex.net/globalweather.asmx?wsdlURL=F:/globalweather.wsdldataFormat=PAYLOADserviceName={http://www.webserviceX.NET}GlobalWeatherendpointName={http://www.webserviceX.NET}GlobalWeatherSoap;)
.to(log:cLog_1?level=INFO)
But with body
web:GetCitiesByCountry
xmlns:web='http://www.webserviceX.NET'web:CountryNameBelarus/web:CountryName/web:GetCitiesByCountry
there is exception [2].
Looking into the sources [3] I found that first available opration used.
Expected that operation lookup is based on payload root element (which is
different for operations)
1. http://www.webservicex.net/globalweather.asmx?WSDL
2.
[WARN ]: org.apache.camel.component.timer.TimerConsumer - Error processing
exchange. Exchange[Message: web:GetCitiesByCountry
xmlns:web='http://www.webserviceX.NET'web:CountryNameBelarus/web:CountryName/web:GetCitiesByCountry].
Caused by: [java.lang.IllegalArgumentException - The PayLoad elements cannot
fit with the message parts of the BindingOperation. Please check the
BindingOperation and PayLoadMessage.]
java.lang.IllegalArgumentException: The PayLoad elements cannot fit with the
message parts of the BindingOperation. Please check the BindingOperation and
PayLoadMessage.
at
org.apache.camel.component.cxf.CxfEndpoint$CamelCxfClientImpl.setParameters(CxfEndpoint.java:1011)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:526)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:472)
at
org.apache.camel.component.cxf.CxfProducer.process(CxfProducer.java:112)
at
org.apache.camel.processor.SendProcessor.process(SendProcessor.java:113)
at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398)
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:118)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
at
org.apache.camel.component.timer.TimerConsumer.sendTimerExchange(TimerConsumer.java:139)
at
org.apache.camel.component.timer.TimerConsumer$1.run(TimerConsumer.java:64)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
3.
https://github.com/apache/camel/blob/master/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfProducer.java#L344
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CAMEL-7568) OnComplete does not work on transactioned route after rollback
[
https://issues.apache.org/jira/browse/CAMEL-7568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-7568:
---
Fix Version/s: 2.14.0
OnComplete does not work on transactioned route after rollback
---
Key: CAMEL-7568
URL: https://issues.apache.org/jira/browse/CAMEL-7568
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.13.1
Reporter: André Ricardo da Silva Souza
Priority: Minor
Fix For: 2.14.0
Example:
{code:title=Route Sample|borderStyle=solid}
this.from(servlet:///test).routeId(CamelTestRoute)
.onCompletion()
.bean(this.logCompletionRoute)
.end()
.onException(Exception.class)
.log(LoggingLevel.ERROR, this.log, Error on processing message.
Sending Rollback command!)
.log(LoggingLevel.ERROR, this.log, ${exception.stacktrace})
.rollback()
.handled(true)
.end()
.transacted(RouteTransactionConfiguration.PROPAGATION_REQUIRED)
.process(new Processor() {
@Override
public void process(Exchange exchange) throws Exception {
throw new Exception();
}});
{code}
In this sample, the OnCompletion bean never is executed. But, if I remove the
rollback() call, it is executed properly.
thanks,
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CAMEL-7501) Only one ZooKeeperRoutePolicy possible
[ https://issues.apache.org/jira/browse/CAMEL-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7501: --- Fix Version/s: Future Only one ZooKeeperRoutePolicy possible -- Key: CAMEL-7501 URL: https://issues.apache.org/jira/browse/CAMEL-7501 Project: Camel Issue Type: Improvement Components: camel-zookeeper Affects Versions: 2.12.3 Reporter: Scott Stults Fix For: Future If two ZooKeeperRoutePolicy's are created and used in separate routes, only one leader election route gets created. This effectively nullifies the route policy for the second route, meaning it works regardless of leadership status (even on the other route). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7501) Only one ZooKeeperRoutePolicy possible
[ https://issues.apache.org/jira/browse/CAMEL-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7501: --- Issue Type: Improvement (was: Bug) Only one ZooKeeperRoutePolicy possible -- Key: CAMEL-7501 URL: https://issues.apache.org/jira/browse/CAMEL-7501 Project: Camel Issue Type: Improvement Components: camel-zookeeper Affects Versions: 2.12.3 Reporter: Scott Stults Fix For: Future If two ZooKeeperRoutePolicy's are created and used in separate routes, only one leader election route gets created. This effectively nullifies the route policy for the second route, meaning it works regardless of leadership status (even on the other route). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7452) beanRef is caching instances - unwanted behavior
[ https://issues.apache.org/jira/browse/CAMEL-7452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7452: --- Fix Version/s: 2.14.0 beanRef is caching instances - unwanted behavior Key: CAMEL-7452 URL: https://issues.apache.org/jira/browse/CAMEL-7452 Project: Camel Issue Type: Bug Affects Versions: 2.13.0 Reporter: Christoph Giera Fix For: 2.14.0 After upgrading from 2.11.0 to 2.13.0 the behavior of beanRef has changed(unwanted behavior). Beans only get instanted once, even if the cache option is explicitly set to false. see http://camel.465427.n5.nabble.com/beanRef-is-caching-instances-in-camel-2-13-0-unwanted-behavior-td5751335.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CAMEL-7452) beanRef is caching instances - unwanted behavior
[ https://issues.apache.org/jira/browse/CAMEL-7452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-7452: -- Assignee: Claus Ibsen beanRef is caching instances - unwanted behavior Key: CAMEL-7452 URL: https://issues.apache.org/jira/browse/CAMEL-7452 Project: Camel Issue Type: Bug Affects Versions: 2.13.0 Reporter: Christoph Giera Assignee: Claus Ibsen Fix For: 2.14.0 After upgrading from 2.11.0 to 2.13.0 the behavior of beanRef has changed(unwanted behavior). Beans only get instanted once, even if the cache option is explicitly set to false. see http://camel.465427.n5.nabble.com/beanRef-is-caching-instances-in-camel-2-13-0-unwanted-behavior-td5751335.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7434) Provide a way to force the completion of a aggregate exchange from an external event
[ https://issues.apache.org/jira/browse/CAMEL-7434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14111248#comment-14111248 ] Sebastien Petrucci commented on CAMEL-7434: --- Hello, I tend to agree with Claus. Using a marker header would not help much in the scenario where you want to pre-complete a group to obey a maximum size limit. I started to prototype a sample code some time ago, I can share this with you if this may help. Regards, Sebastien. Provide a way to force the completion of a aggregate exchange from an external event Key: CAMEL-7434 URL: https://issues.apache.org/jira/browse/CAMEL-7434 Project: Camel Issue Type: New Feature Components: camel-core, eip Affects Versions: 2.13.0 Reporter: Susan Javurek Assignee: Ben O'Day Fix For: Future There is a way to do this by creating a trigger exchange that is handled in a special way by the aggregation strategy and a completion predicate. But this solution is quite intrusive and painful to write. It would actually be much easier if the AggregateProcessor would implement and expose the following methods: public void forceCompletionOfGroup(String key) public Expression getCorrelationExpression() This way, it becomes possible to control externally an aggregator without having to implement some intrusive logic. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7091) EventNotifiers don't work under Blueprint as a referenced service
[ https://issues.apache.org/jira/browse/CAMEL-7091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7091: --- Issue Type: Improvement (was: Bug) EventNotifiers don't work under Blueprint as a referenced service - Key: CAMEL-7091 URL: https://issues.apache.org/jira/browse/CAMEL-7091 Project: Camel Issue Type: Improvement Components: camel-blueprint, camel-core Affects Versions: 2.10.0 Environment: JBoss Fuse 6.0.0 / Karaf 2.3.0 Reporter: Henrique Viecili Assignee: Willem Jiang Labels: blueprint, events Fix For: Future I'm facing a similar issue to what is describer at CAMEL-5299, this time the same behaviour happen when using the EventNotifier from another bundle's exported service. Bundle 1 (exposes an EventNotifier): Export-Service = com.event.logger.CommonLogEventNotifier blueprint.xml: service id=commonLogEventNotifier interface=com.event.logger.CommonLogEventNotifier bean class=com.event.logger.CommonLogEventNotifierImpl /bean /service Bundle 2 (uses the EventNotifier) Import-Service = com.event.logger.CommonLogEventNotifier;multiple:=false blueprint.xml: reference id=commonLogEventNotifier interface=com.event.logger.CommonLogEventNotifier / The EventNotifier class definition is: public class CommonLogEventNotifierImpl extends EventNotifierSupport implements EventNotifier, com.event.logger.CommonLogEventNotifier -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-6950) camel-sjms: Lacks reconnection logic in case of exception
[ https://issues.apache.org/jira/browse/CAMEL-6950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6950: --- Fix Version/s: Future camel-sjms: Lacks reconnection logic in case of exception - Key: CAMEL-6950 URL: https://issues.apache.org/jira/browse/CAMEL-6950 Project: Camel Issue Type: Improvement Components: camel-sjms Affects Versions: 2.12.1 Reporter: Raúl Kripalani Assignee: Scott England-Sullivan Fix For: Future See this thread: http://camel.465427.n5.nabble.com/SJMS-failure-with-stale-reply-queue-tp5742833.html. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-6950) camel-sjms: Lacks reconnection logic in case of exception
[ https://issues.apache.org/jira/browse/CAMEL-6950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6950: --- Issue Type: Improvement (was: Bug) camel-sjms: Lacks reconnection logic in case of exception - Key: CAMEL-6950 URL: https://issues.apache.org/jira/browse/CAMEL-6950 Project: Camel Issue Type: Improvement Components: camel-sjms Affects Versions: 2.12.1 Reporter: Raúl Kripalani Assignee: Scott England-Sullivan Fix For: Future See this thread: http://camel.465427.n5.nabble.com/SJMS-failure-with-stale-reply-queue-tp5742833.html. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CAMEL-5400) Updating the websocket example at runtime causes the webpage to not refresh with new tweets
[ https://issues.apache.org/jira/browse/CAMEL-5400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-5400. Resolution: Unresolved Updating the websocket example at runtime causes the webpage to not refresh with new tweets --- Key: CAMEL-5400 URL: https://issues.apache.org/jira/browse/CAMEL-5400 Project: Camel Issue Type: Bug Components: camel-websocket, examples Affects Versions: 2.10.0 Reporter: Claus Ibsen Priority: Minor Fix For: Future The twitter websocket example used to allow dynamic updates of the tweet search word, so the website was updated in real time. Now this is broken, with the latest refactorings in the camel-websocket component. Twitter component works fine, as its updated and will poll new tweets. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-5719) ZooKeeper route policy should initialize using onInit to elect master
[ https://issues.apache.org/jira/browse/CAMEL-5719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-5719: --- Issue Type: Improvement (was: Bug) ZooKeeper route policy should initialize using onInit to elect master - Key: CAMEL-5719 URL: https://issues.apache.org/jira/browse/CAMEL-5719 Project: Camel Issue Type: Improvement Components: camel-zookeeper Affects Versions: 2.10.0 Reporter: Claus Ibsen Fix For: Future See nabble http://camel.465427.n5.nabble.com/Single-instance-of-running-route-in-the-cluster-tp5720846.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CAMEL-7688) XPathBuilder initDefaultXPathFactory implementation incorrect
[ https://issues.apache.org/jira/browse/CAMEL-7688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7688. Resolution: Fixed Thanks for the patch. XPathBuilder initDefaultXPathFactory implementation incorrect - Key: CAMEL-7688 URL: https://issues.apache.org/jira/browse/CAMEL-7688 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.12.3 Reporter: Chris Watts Assignee: Claus Ibsen Priority: Minor Fix For: 2.14.0 Attachments: camel-core-xpathbuild.patch The implementation of initDefaultXPathFactory uses instance and static variables to initialize a static XPathFactory then overrides it anyway. Looks like so old code that was never removed plus a bug where it's not using the implementation specified on the command line. I've also added a function to allow the default to be passed in, this allows the jvm deafult to be different from the XPathBuilder (saves having to set it on every xpath factory created). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7750) Enhance CXF RS Invoker to support AsyncResponse-enabled JAX-RS endpoints
Sergey Beryozkin created CAMEL-7750: --- Summary: Enhance CXF RS Invoker to support AsyncResponse-enabled JAX-RS endpoints Key: CAMEL-7750 URL: https://issues.apache.org/jira/browse/CAMEL-7750 Project: Camel Issue Type: Improvement Components: camel-cxf Reporter: Sergey Beryozkin It appears the invoker does not recognize the endpoints depending on a new suspended invocations feature of JAX-RS 2.0. We can tweak CXF JAXRSInvoker a bit if needed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7339) Transfer exchange in Camel-Kafka
[ https://issues.apache.org/jira/browse/CAMEL-7339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14111493#comment-14111493 ] Ioannis Polyzos commented on CAMEL-7339: OK, I will proceed with the changes Transfer exchange in Camel-Kafka - Key: CAMEL-7339 URL: https://issues.apache.org/jira/browse/CAMEL-7339 Project: Camel Issue Type: Improvement Components: camel-kafka Affects Versions: 2.13.0 Reporter: Ioannis Polyzos Fix For: Future Attachments: camel-kafka-patch-2.diff, camel-kafka.diff There is cases that need to transfer the whole exchange through kafka. I would like to share a patch for camel-kafka that support transfer exchange along with some more minor improvements such as more flexible configuration and default values preset. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7751) Trace interceptor use add instead of remove in removeTraceHandler
Ramon Rosa da Silva created CAMEL-7751:
--
Summary: Trace interceptor use add instead of remove in
removeTraceHandler
Key: CAMEL-7751
URL: https://issues.apache.org/jira/browse/CAMEL-7751
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.13.2
Reporter: Ramon Rosa da Silva
Priority: Trivial
Class
https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/processor/interceptor/Tracer.java
implements add instead of remove in method:
public void removeTraceHandler(TraceEventHandler traceHandler) {
this.traceHandlers.add(traceHandler);
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CAMEL-7448) throttle EIP - unchanged value
[ https://issues.apache.org/jira/browse/CAMEL-7448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben O'Day resolved CAMEL-7448. -- Resolution: Fixed throttle EIP - unchanged value -- Key: CAMEL-7448 URL: https://issues.apache.org/jira/browse/CAMEL-7448 Project: Camel Issue Type: Bug Components: camel-core, eip Affects Versions: 2.13.1 Reporter: Elvio Caruana Assignee: Ben O'Day Priority: Minor Fix For: 2.13.3, 2.14.0 Throttler Documentation [1] states If the header is absent, then the Throttler uses the old value. So that allows you to only provide a header if the value is to be changed. however if the expression evaluates to null (header missing from message) the Throttler throws an exception (Throttler.java:108). The workaround is to ensure that all messages carry the value (if the value is the same no changes will take affect). Adding an option to turn this on and off (e.g. allowNullException) would make it much easier to use (as per camel-users thread [2]). [1] http://camel.apache.org/throttler.html [2] http://camel.465427.n5.nabble.com/throttle-EIP-unchanged-value-td5751300.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7752) filter with camel sftp is returnin NullPointerException
Raghavan created CAMEL-7752:
---
Summary: filter with camel sftp is returnin NullPointerException
Key: CAMEL-7752
URL: https://issues.apache.org/jira/browse/CAMEL-7752
Project: Camel
Issue Type: Bug
Components: camel-ftp
Affects Versions: 2.10.0
Environment: Windows 7, RedHat Linux 5.x
Reporter: Raghavan
We are testing camel sftp with filter options to restrict the source files
using a pattern.
We get a NullPointerException when try to use a filter (CustomFilter)
Attached herewith the code snippet
[[CodeSnippet]]
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:camel=http://camel.apache.org/schema/spring;
xsi:schemaLocation=
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd;
camelContext xmlns=http://camel.apache.org/schema/spring;
camel:propertyPlaceholder id=ftpadapterProperty
location=classpath:ftpadapter.properties/
!-- The file filter is to be tested --
route
from
uri=sftp://{{ftp.user}}@{{ftp.host}}/{{ftp.remote.dir}}?password={{ftp.pwd}}amp;separator=UNIXamp;recursive={{ftp.dir.recursive}}amp;binary=trueamp;delete={{ftp.deletefiles}}amp;stepwise={{ftp.stepwise}}amp;delay={{ftp.pollinginterval}}amp;filter=#fileFilter/
to
uri=file://{{local.dir}}?fileName=${date:now:MMddhhmmss}_${file:onlyname.noext}.${file:ext}/
log message=Routing message from remote server to
target folder with data ${body} /
/route
/camelContext
bean id=fileFilter class=org.myapp.ftpadapter.FileFilter/
/beans
FileFilter src:
public class FileFilterT implements GenericFileFilterT {
private static Logger logger =
LoggerFactory.getLogger(FileFilter.class);
/* The purpose of this method is to apply a custom filter based on file
pattern
* This enables the ftp adapter to filter files based on the criteria
implemented here
* (non-Javadoc)
* @see
org.apache.camel.component.file.GenericFileFilter#accept(org.apache.camel.component.file.GenericFile)
*/
public boolean accept(GenericFileT file) {
if(logger.isDebugEnabled()) {
logger.debug(IsDirectory= + file.isDirectory());
logger.debug(FileName=+file.getFileName());
}
if(file !=null file.getFileName() != null) {
return file.getFileName().endsWith(.xml);
}
else {
return false;
}
}
}
[[/CodeSnippet]]
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CAMEL-7434) Provide a way to force the completion of a aggregate exchange from an external event
[ https://issues.apache.org/jira/browse/CAMEL-7434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14111808#comment-14111808 ] Ben O'Day commented on CAMEL-7434: -- [~spetrucci], if you have a potential patch for this, attach it and I'll try to work it in...thanks Provide a way to force the completion of a aggregate exchange from an external event Key: CAMEL-7434 URL: https://issues.apache.org/jira/browse/CAMEL-7434 Project: Camel Issue Type: New Feature Components: camel-core, eip Affects Versions: 2.13.0 Reporter: Susan Javurek Assignee: Ben O'Day Fix For: Future There is a way to do this by creating a trigger exchange that is handled in a special way by the aggregation strategy and a completion predicate. But this solution is quite intrusive and painful to write. It would actually be much easier if the AggregateProcessor would implement and expose the following methods: public void forceCompletionOfGroup(String key) public Expression getCorrelationExpression() This way, it becomes possible to control externally an aggregator without having to implement some intrusive logic. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CAMEL-7751) Trace interceptor use add instead of remove in removeTraceHandler
[
https://issues.apache.org/jira/browse/CAMEL-7751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang reassigned CAMEL-7751:
---
Assignee: Willem Jiang
Trace interceptor use add instead of remove in removeTraceHandler
-
Key: CAMEL-7751
URL: https://issues.apache.org/jira/browse/CAMEL-7751
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.13.2
Reporter: Ramon Rosa da Silva
Assignee: Willem Jiang
Priority: Trivial
Class
https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/processor/interceptor/Tracer.java
implements add instead of remove in method:
public void removeTraceHandler(TraceEventHandler traceHandler) {
this.traceHandlers.add(traceHandler);
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CAMEL-7751) Trace interceptor use add instead of remove in removeTraceHandler
[
https://issues.apache.org/jira/browse/CAMEL-7751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang resolved CAMEL-7751.
-
Resolution: Fixed
Fix Version/s: 2.14.0
2.13.3
2.12.5
Applied the patch to camel-2.12.x, camel-2.13.x and master branches with thanks
to Ramon.
Trace interceptor use add instead of remove in removeTraceHandler
-
Key: CAMEL-7751
URL: https://issues.apache.org/jira/browse/CAMEL-7751
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.13.2
Reporter: Ramon Rosa da Silva
Assignee: Willem Jiang
Priority: Trivial
Fix For: 2.12.5, 2.13.3, 2.14.0
Class
https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/processor/interceptor/Tracer.java
implements add instead of remove in method:
public void removeTraceHandler(TraceEventHandler traceHandler) {
this.traceHandlers.add(traceHandler);
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CAMEL-7500) Concurrent modification of exchange during retry after netty TCP failure leads to futher processing of failed messages
[ https://issues.apache.org/jira/browse/CAMEL-7500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang updated CAMEL-7500: Fix Version/s: Future Concurrent modification of exchange during retry after netty TCP failure leads to futher processing of failed messages -- Key: CAMEL-7500 URL: https://issues.apache.org/jira/browse/CAMEL-7500 Project: Camel Issue Type: Bug Components: camel-netty Affects Versions: 2.13.1 Reporter: Bob Browning Assignee: Willem Jiang Fix For: Future Attachments: NettyRedeliveryTest.java When a exception occurs on a netty TCP channel such as ChanelClosedException then there are two invocations of the producer callback. If there is a redelivery handler configured this causes either two threads to be added to the scheduled thread-pool which then compete or in the more common case the first invocation adds the redelivery thread but in doing so clears the exception from the exchange such that when the subsequent callback invocation occurs it see's the event as a success and continues routing of the exchange. Note this also seems to be a cause of negative inflight messages on the route. The first callback invocation occurs in the ChannelFutureListener which is the usual case. The second callback invocation which comes from the ClientChannelHandler registered in the DefaultClientPipelineFactory used by the NettyProducer. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7552) RabbitMQ Component: property to allow declare or not queue and exchange.
[ https://issues.apache.org/jira/browse/CAMEL-7552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14111902#comment-14111902 ] Willem Jiang commented on CAMEL-7552: - Applied the patch in camel master branch with thanks to Ramon. I also updated the wiki page for this new option. RabbitMQ Component: property to allow declare or not queue and exchange. Key: CAMEL-7552 URL: https://issues.apache.org/jira/browse/CAMEL-7552 Project: Camel Issue Type: Improvement Components: camel-rabbitmq Affects Versions: 2.13.1 Reporter: Ramon Rosa da Silva Assignee: Willem Jiang Labels: Camel Fix For: 2.14.0 Sometimes to consume a message from RabbitMQ the consumer doesn't konw its exchange. And to send message to exchange, it isn't necessary set queue name, because the destination queue is defined from a routingkey, but in camel-rabbitmq when queue is blank, is generated a random uuid, and this uuid is used to declare and bind with the exchange. I suggest that the getEndpoint().declareExchangeAndQueue(chanel) in Consumer and Producer can be optional. Like: boolean declare = true; -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CAMEL-7552) RabbitMQ Component: property to allow declare or not queue and exchange.
[ https://issues.apache.org/jira/browse/CAMEL-7552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-7552. - Resolution: Fixed RabbitMQ Component: property to allow declare or not queue and exchange. Key: CAMEL-7552 URL: https://issues.apache.org/jira/browse/CAMEL-7552 Project: Camel Issue Type: Improvement Components: camel-rabbitmq Affects Versions: 2.13.1 Reporter: Ramon Rosa da Silva Assignee: Willem Jiang Labels: Camel Fix For: 2.14.0 Sometimes to consume a message from RabbitMQ the consumer doesn't konw its exchange. And to send message to exchange, it isn't necessary set queue name, because the destination queue is defined from a routingkey, but in camel-rabbitmq when queue is blank, is generated a random uuid, and this uuid is used to declare and bind with the exchange. I suggest that the getEndpoint().declareExchangeAndQueue(chanel) in Consumer and Producer can be optional. Like: boolean declare = true; -- This message was sent by Atlassian JIRA (v6.2#6252)
