[jira] [Commented] (CAMEL-6797) camel-quartz2 - The clustering test SpringQuartzConsumerTwoAppsClusteredFailoverTest doesn't work although the same test works for camel-quartz
[
https://issues.apache.org/jira/browse/CAMEL-6797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13781268#comment-13781268
]
Babak Vahdat commented on CAMEL-6797:
-
On the other hand the other clustering test
{{SpringQuartzTwoAppsClusteredFailoverTest}} works well for both
{{camel-quartz}} as well as {{camel-quartz2}} components. However that test
makes use of {{CronScheduledRoutePolicy}} instead of {{QuartzConsumer}} to
trigger the routes.
> camel-quartz2 - The clustering test
> SpringQuartzConsumerTwoAppsClusteredFailoverTest doesn't work although the
> same test works for camel-quartz
> ---
>
> Key: CAMEL-6797
> URL: https://issues.apache.org/jira/browse/CAMEL-6797
> Project: Camel
> Issue Type: Bug
> Components: camel-quartz2
>Affects Versions: 2.12.0
>Reporter: Babak Vahdat
>Priority: Minor
>
> There seems to be a divergence in the behaviour of the {{camel-quartz}} and
> {{camel-quartz2}} components regarding this test.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (CAMEL-6797) camel-quartz2 - The clustering test SpringQuartzConsumerTwoAppsClusteredFailoverTest doesn't work although the same test works for camel-quartz
Babak Vahdat created CAMEL-6797:
---
Summary: camel-quartz2 - The clustering test
SpringQuartzConsumerTwoAppsClusteredFailoverTest doesn't work although the same
test works for camel-quartz
Key: CAMEL-6797
URL: https://issues.apache.org/jira/browse/CAMEL-6797
Project: Camel
Issue Type: Bug
Components: camel-quartz2
Affects Versions: 2.12.0
Reporter: Babak Vahdat
Priority: Minor
There seems to be a divergence in the behaviour of the {{camel-quartz}} and
{{camel-quartz2}} components regarding this test.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CAMEL-6783) getFeatures() method of CxfEndpoint only accept AbstractFeature but Feature
[ https://issues.apache.org/jira/browse/CAMEL-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13781209#comment-13781209 ] liugang commented on CAMEL-6783: How it works if change from *List* to *List* ? Thanks. > getFeatures() method of CxfEndpoint only accept AbstractFeature but Feature > --- > > Key: CAMEL-6783 > URL: https://issues.apache.org/jira/browse/CAMEL-6783 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Affects Versions: 2.12.0 >Reporter: liugang > Attachments: CAMEL-6783.patch > > > the *getFeatures()* method of *CxfEndpoint* only accept an instance of > *AbstractFeature*, but the original *ClientFactoryBean* accept *Feature* > instance. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CAMEL-6771) ConcurrentModificationException thrown from inside camel splitter
[
https://issues.apache.org/jira/browse/CAMEL-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman updated CAMEL-6771:
Attachment: CAMEL-6771.patch
This should fix the problem. I was having trouble creating a unit test that
reliably reproduces the issue, so I didn't include it in this patch.
Basically, instead of using a HashMap, I'm using a ConcurrentHashMap to store
the MulticastProcessor -> AggreationStrategy map.
> ConcurrentModificationException thrown from inside camel splitter
> -
>
> Key: CAMEL-6771
> URL: https://issues.apache.org/jira/browse/CAMEL-6771
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.11.1
> Environment: Amazon Linux, oracle jdk 1.7
>Reporter: Joshua Groom
> Attachments: CAMEL-6771.patch
>
>
> We use camel 2.11.1 running on the oracle 1.7 jvm for linux.
> I have a route that looks like this. It reads in files and puts them on a
> seda queue with 8 concurrent consumers.
> - The SpatialInterpolationPojo reads each file is read and split into two
> messages X and Y.
> - The MyAggregator uses X and Y together and outputs a combined message A.B
> - The MySplitterPojo splits A.B into two messages A and B
> {code}
> from("file://somefile")
> .to("seda:filteraccept?concurrentConsumers=8");
> from("seda:filteraccept?concurrentConsumers=8")
> .split()
> .method(new SpatialInterpolationPojo(), "split")
> .to("direct:wind-aggregator");
> from("direct:wind-aggregator")
> .aggregate(packageCorrelationId(), new MyAggregator())
> .completionPredicate(header(FIELD_AGGREGATION_COMPLETE).isNotNull())
> .split()
> .method(new MySplitterPojo())
> .to("seda:output");
> {code}
> The MySplitterPojo simply returns List containing two messages that
> come from data in the input message body. We copy the body headers to the
> result messages.
> It is thread safe, it has no state, ie there are no object fields that are
> modified.
> The method is like this it is edited for clarity/privacy:
> {code}
> public class MySplitterPojo {
> public List splitMessage(
> @Headers Map headers,
> @Body CombinedObject body) {
>
> DefaultMessage a = new DefaultMessage();
> a.setBody(body.getA());
> a.setHeaders(new HashMap(headers));
>
> DefaultMessage b = new DefaultMessage();
> b.setBody(body.getB());
> b.setHeaders(new HashMap(headers));
>
> ArrayList result = new ArrayList(2);
> result.add(a);
> result.add(b);
>
> return result;
> }
> }
> {code}
> When we run this route we very occasionally get the exception below. You can
> see that it is entirely within camel, it appears to be trying to copy the map
> stored under the exchange property Exchange.AGGREGATION_STRATEGY which is a
> camel internal property key.
> By inspection of the message I can see that Exchange has just come out of the
> WindVectorAggregator.
> This seems like it must be a camel bug to me. Any ideas?
> {code}
> 15 Sep 2013 23:06:47,140[Camel (camel-1) thread #21 - seda://filteraccept]
> WARN AggregateProcessor Error processing aggregated exchange.
> Exchange[Message: { Trondheim, NO=WindVector [u=-5.92894983291626,
> v=7.060009002685547], ... }]. Caused by:
> [java.util.ConcurrentModificationException - null]
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(Unknown Source)
> at java.util.HashMap$EntryIterator.next(Unknown Source)
> at java.util.HashMap$EntryIterator.next(Unknown Source)
> at java.util.HashMap.putAllForCreate(Unknown Source)
> at java.util.HashMap.(Unknown Source)
> at
> org.apache.camel.processor.MulticastProcessor.setAggregationStrategyOnExchange(MulticastProcessor.java:1011)
>
> at org.apache.camel.processor.Splitter.process(Splitter.java:95)
> at
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>
> at
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
>
> at
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
>
> at
> org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
>
> at
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>
> at
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
>
> at
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
>
> at
> org.apache.camel.processor.interceptor.BacklogTracerInterce
[jira] [Commented] (CAMEL-4015) camel hazelcast uri format
[
https://issues.apache.org/jira/browse/CAMEL-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13780890#comment-13780890
]
James Carman commented on CAMEL-4015:
-
Romain, it actually allows you to either use the "name" of the operation or the
number, so that you can use the constants when constructing your URI. The unit
tests exhibit that behavior. Enjoy!
> camel hazelcast uri format
> --
>
> Key: CAMEL-4015
> URL: https://issues.apache.org/jira/browse/CAMEL-4015
> Project: Camel
> Issue Type: Improvement
> Components: camel-hazelcast
>Reporter: Romain Manni-Bucau
>Priority: Trivial
> Attachments: CAMEL-4015.patch
>
>
> It could be nice to be able to specify type operation (and maybe the key for
> map) in the uri instead of headers:
> from("hazelcast:map:foo?operation=get&id=myStringId").to("log:display");
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4015) camel hazelcast uri format
[
https://issues.apache.org/jira/browse/CAMEL-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13780889#comment-13780889
]
Romain Manni-Bucau commented on CAMEL-4015:
---
Yes the patch matches the need. Thks
> camel hazelcast uri format
> --
>
> Key: CAMEL-4015
> URL: https://issues.apache.org/jira/browse/CAMEL-4015
> Project: Camel
> Issue Type: Improvement
> Components: camel-hazelcast
>Reporter: Romain Manni-Bucau
>Priority: Trivial
> Attachments: CAMEL-4015.patch
>
>
> It could be nice to be able to specify type operation (and maybe the key for
> map) in the uri instead of headers:
> from("hazelcast:map:foo?operation=get&id=myStringId").to("log:display");
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6783) getFeatures() method of CxfEndpoint only accept AbstractFeature but Feature
[ https://issues.apache.org/jira/browse/CAMEL-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated CAMEL-6783: Attachment: CAMEL-6783.patch In case we decide to accept the regression risk of this change, I'm attaching a patch. > getFeatures() method of CxfEndpoint only accept AbstractFeature but Feature > --- > > Key: CAMEL-6783 > URL: https://issues.apache.org/jira/browse/CAMEL-6783 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Affects Versions: 2.12.0 >Reporter: liugang > Attachments: CAMEL-6783.patch > > > the *getFeatures()* method of *CxfEndpoint* only accept an instance of > *AbstractFeature*, but the original *ClientFactoryBean* accept *Feature* > instance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6783) getFeatures() method of CxfEndpoint only accept AbstractFeature but Feature
[ https://issues.apache.org/jira/browse/CAMEL-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13780887#comment-13780887 ] James Carman commented on CAMEL-6783: - This change could cause a regression. Are we sure we want this? > getFeatures() method of CxfEndpoint only accept AbstractFeature but Feature > --- > > Key: CAMEL-6783 > URL: https://issues.apache.org/jira/browse/CAMEL-6783 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Affects Versions: 2.12.0 >Reporter: liugang > > the *getFeatures()* method of *CxfEndpoint* only accept an instance of > *AbstractFeature*, but the original *ClientFactoryBean* accept *Feature* > instance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6792) Camel Test Support needs a new Method
[
https://issues.apache.org/jira/browse/CAMEL-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman updated CAMEL-6792:
Attachment: CAMEL-6792.patch
I believe this takes care of it.
> Camel Test Support needs a new Method
> -
>
> Key: CAMEL-6792
> URL: https://issues.apache.org/jira/browse/CAMEL-6792
> Project: Camel
> Issue Type: Wish
> Components: camel-test
>Affects Versions: 2.11.1
> Environment: ALL
>Reporter: Robert E. Simmons Jr. MSc.
>Priority: Minor
> Attachments: CAMEL-6792.patch
>
>
> There is a problem with the CamelTestSupport class in that if you call
> getMockEndpoint on an endpoint that doesnt exist, it blithely returns you an
> endpoint connected to nothing. The problem is you end up chasing endless test
> failures when the fact is your endpoint is not even there. So I suggest a
> method I added to my subclass of CamelTestSupport which is:
> protected MockEndpoint assertAndGetMockEndpoint(final String uri) {
> assertNotNull(context.hasEndpoint(uri));
> return getMockEndpoint(uri);
> }
> This method will make sure that the endpoint is there before returning it and
> it will make tests easier to write.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6670) Throttler EIP - Add JMX attribute to know if hit limit currently (eg its throttling state)
[ https://issues.apache.org/jira/browse/CAMEL-6670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13780877#comment-13780877 ] James Carman commented on CAMEL-6670: - I have an idea how to fix this, but I don't know about the implementation as it currently stands. The access to the timePeriodMillis isn't synchronized, but it's allowed to be modified via JMX, so it probably should be. Perhaps changing it to AtomicLong? > Throttler EIP - Add JMX attribute to know if hit limit currently (eg its > throttling state) > -- > > Key: CAMEL-6670 > URL: https://issues.apache.org/jira/browse/CAMEL-6670 > Project: Camel > Issue Type: Improvement > Components: camel-core, eip >Reporter: Claus Ibsen >Priority: Minor > Fix For: Future > > > See SO > http://stackoverflow.com/questions/18446689/how-to-get-the-information-that-throttling-limit-has-been-reached > We would need to extend the org.apache.camel.processor.Throttler so it keeps > state whether its holding back exchanges due hit limit, or not. Wonder what a > name should be. It could be a simple boolean to indicate that. And/or a > counter that counts the number of exchanges being hold back. Then ppl can > have a graph with the counter. > This data should be exposed in JMX with > org.apache.camel.api.management.mbean.ManagedThrottlerMBean -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6768) @Header @Body @Property bean parameter binding - add mandatory option
[ https://issues.apache.org/jira/browse/CAMEL-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13780866#comment-13780866 ] James Carman commented on CAMEL-6768: - We don't want to change the existing behavior, correct? I believe the current behavior for @Header would be equivalent to the mandatory = false case. > @Header @Body @Property bean parameter binding - add mandatory option > - > > Key: CAMEL-6768 > URL: https://issues.apache.org/jira/browse/CAMEL-6768 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Priority: Minor > Fix For: Future > > > See > http://stackoverflow.com/questions/18874641/add-string-to-camel-exchange-header-from-route?noredirect=1#comment27863978_18874641 > We could have an attribute mandatory = true, which is default true for these > bean parameter annotations. Then people can set it to false, if a @Header is > not mandatory (eg do not fail if the header is not present). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6746) vm component - Should keep track of active consumers on static level
[ https://issues.apache.org/jira/browse/CAMEL-6746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta updated CAMEL-6746: --- Attachment: CAMEL-6746.patch Fix + tests attached. > vm component - Should keep track of active consumers on static level > > > Key: CAMEL-6746 > URL: https://issues.apache.org/jira/browse/CAMEL-6746 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen > Fix For: Future > > Attachments: CAMEL-6746.patch > > > See nabble > http://camel.465427.n5.nabble.com/MultipleConsumer-on-a-vm-endpoint-tp5738664.html > We need to keep track of the consumer per static level instead, so using > concurrent consumers will work accross deployment units. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4015) camel hazelcast uri format
[
https://issues.apache.org/jira/browse/CAMEL-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman updated CAMEL-4015:
Attachment: CAMEL-4015.patch
This patch implements the feature as I understand the request.
> camel hazelcast uri format
> --
>
> Key: CAMEL-4015
> URL: https://issues.apache.org/jira/browse/CAMEL-4015
> Project: Camel
> Issue Type: Improvement
> Components: camel-hazelcast
>Reporter: Romain Manni-Bucau
>Priority: Trivial
> Attachments: CAMEL-4015.patch
>
>
> It could be nice to be able to specify type operation (and maybe the key for
> map) in the uri instead of headers:
> from("hazelcast:map:foo?operation=get&id=myStringId").to("log:display");
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4015) camel hazelcast uri format
[
https://issues.apache.org/jira/browse/CAMEL-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13780815#comment-13780815
]
James Carman commented on CAMEL-4015:
-
I'm implementing this now.
> camel hazelcast uri format
> --
>
> Key: CAMEL-4015
> URL: https://issues.apache.org/jira/browse/CAMEL-4015
> Project: Camel
> Issue Type: Improvement
> Components: camel-hazelcast
>Reporter: Romain Manni-Bucau
>Priority: Trivial
>
> It could be nice to be able to specify type operation (and maybe the key for
> map) in the uri instead of headers:
> from("hazelcast:map:foo?operation=get&id=myStringId").to("log:display");
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-6790) Resuming a bundle that uses blueprint+camel fails if it was suspended externally
[ https://issues.apache.org/jira/browse/CAMEL-6790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-6790. Resolution: Fixed Thanks for reporting. > Resuming a bundle that uses blueprint+camel fails if it was suspended > externally > > > Key: CAMEL-6790 > URL: https://issues.apache.org/jira/browse/CAMEL-6790 > Project: Camel > Issue Type: Bug > Components: camel-blueprint >Affects Versions: 2.12.1 >Reporter: Eugene Tarasov >Assignee: Claus Ibsen > Fix For: 2.11.3, 2.12.2, 2.13.0 > > > There is a problem in this scenario: > # Karaf is running. > # Start some bundle that uses blueprint+camel. For convenience will call it > . > # Cause this bundle to be suspended by container, by refreshing a bundle that > provides some namespace used by bundle. For example, by > refreshing camel-cxf (assuming that uses also blueprint/cxf > namespace). In logs one can see something like this: > bq. Bundle is waiting for namespace handlers > [http://camel.apache.org/schema/blueprint/cxf] > In this case after the missing namespace becomes available again the bundle > will fail to resume with exception like: > bq. Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The > matching wildcard is strict, but no declaration can be found for element > 'camelContext'. > The problem is in CamelNamespaceHandler class which is a part of > camel-blueprint. When it parses incoming dom it changes namespace of all > elements from http://camel.apache.org/schema/blueprint to > http://camel.apache.org/schema/spring. So when a bundle that uses > blueprint+camel needs to validate its blueprint context again (like if it was > waiting for some namespace) the new validation will fail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6790) Resuming a bundle that uses blueprint+camel fails if it was suspended externally
[ https://issues.apache.org/jira/browse/CAMEL-6790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6790: --- Fix Version/s: 2.13.0 2.12.2 2.11.3 > Resuming a bundle that uses blueprint+camel fails if it was suspended > externally > > > Key: CAMEL-6790 > URL: https://issues.apache.org/jira/browse/CAMEL-6790 > Project: Camel > Issue Type: Bug > Components: camel-blueprint >Affects Versions: 2.12.1 >Reporter: Eugene Tarasov >Assignee: Claus Ibsen > Fix For: 2.11.3, 2.12.2, 2.13.0 > > > There is a problem in this scenario: > # Karaf is running. > # Start some bundle that uses blueprint+camel. For convenience will call it > . > # Cause this bundle to be suspended by container, by refreshing a bundle that > provides some namespace used by bundle. For example, by > refreshing camel-cxf (assuming that uses also blueprint/cxf > namespace). In logs one can see something like this: > bq. Bundle is waiting for namespace handlers > [http://camel.apache.org/schema/blueprint/cxf] > In this case after the missing namespace becomes available again the bundle > will fail to resume with exception like: > bq. Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The > matching wildcard is strict, but no declaration can be found for element > 'camelContext'. > The problem is in CamelNamespaceHandler class which is a part of > camel-blueprint. When it parses incoming dom it changes namespace of all > elements from http://camel.apache.org/schema/blueprint to > http://camel.apache.org/schema/spring. So when a bundle that uses > blueprint+camel needs to validate its blueprint context again (like if it was > waiting for some namespace) the new validation will fail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-6790) Resuming a bundle that uses blueprint+camel fails if it was suspended externally
[ https://issues.apache.org/jira/browse/CAMEL-6790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-6790: -- Assignee: Claus Ibsen > Resuming a bundle that uses blueprint+camel fails if it was suspended > externally > > > Key: CAMEL-6790 > URL: https://issues.apache.org/jira/browse/CAMEL-6790 > Project: Camel > Issue Type: Bug > Components: camel-blueprint >Affects Versions: 2.12.1 >Reporter: Eugene Tarasov >Assignee: Claus Ibsen > > There is a problem in this scenario: > # Karaf is running. > # Start some bundle that uses blueprint+camel. For convenience will call it > . > # Cause this bundle to be suspended by container, by refreshing a bundle that > provides some namespace used by bundle. For example, by > refreshing camel-cxf (assuming that uses also blueprint/cxf > namespace). In logs one can see something like this: > bq. Bundle is waiting for namespace handlers > [http://camel.apache.org/schema/blueprint/cxf] > In this case after the missing namespace becomes available again the bundle > will fail to resume with exception like: > bq. Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The > matching wildcard is strict, but no declaration can be found for element > 'camelContext'. > The problem is in CamelNamespaceHandler class which is a part of > camel-blueprint. When it parses incoming dom it changes namespace of all > elements from http://camel.apache.org/schema/blueprint to > http://camel.apache.org/schema/spring. So when a bundle that uses > blueprint+camel needs to validate its blueprint context again (like if it was > waiting for some namespace) the new validation will fail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6785) Provide patch for CAMEL-6769
[ https://issues.apache.org/jira/browse/CAMEL-6785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13780805#comment-13780805 ] Marios Trivizas commented on CAMEL-6785: Thank you! > Provide patch for CAMEL-6769 > > > Key: CAMEL-6785 > URL: https://issues.apache.org/jira/browse/CAMEL-6785 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.11.1 >Reporter: Marios Trivizas >Assignee: Claus Ibsen > Fix For: 2.11.3, 2.12.2, 2.13.0 > > Attachments: JndiRegistry.java.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CAMEL-6785) Provide patch for CAMEL-6769
[ https://issues.apache.org/jira/browse/CAMEL-6785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marios Trivizas closed CAMEL-6785. -- > Provide patch for CAMEL-6769 > > > Key: CAMEL-6785 > URL: https://issues.apache.org/jira/browse/CAMEL-6785 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.11.1 >Reporter: Marios Trivizas >Assignee: Claus Ibsen > Fix For: 2.11.3, 2.12.2, 2.13.0 > > Attachments: JndiRegistry.java.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6796) camel-xmlsecurity - Some options is not exposed as getter/setters
[ https://issues.apache.org/jira/browse/CAMEL-6796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6796: --- Affects Version/s: (was: 2.11.1) 2.12.0 Fix Version/s: (was: 2.11.3) > camel-xmlsecurity - Some options is not exposed as getter/setters > - > > Key: CAMEL-6796 > URL: https://issues.apache.org/jira/browse/CAMEL-6796 > Project: Camel > Issue Type: Bug >Affects Versions: 2.12.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.12.2, 2.13.0 > > > See nabble > http://camel.465427.n5.nabble.com/contentObjectId-in-XML-Security-camel-xmlsecurity-tp5740265p5740348.html > Some options has not been exposed as getter/setters so they can be fully > configured. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-5771) IOHelper.getCharsetName() should lookup CHARSET_NAME in headers if exchange property is not set
[ https://issues.apache.org/jira/browse/CAMEL-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-5771. Resolution: Fixed > IOHelper.getCharsetName() should lookup CHARSET_NAME in headers if exchange > property is not set > --- > > Key: CAMEL-5771 > URL: https://issues.apache.org/jira/browse/CAMEL-5771 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.10.2 >Reporter: Marco Zapletal >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.11.3, 2.12.2, 2.13.0 > > > The CHARSET_NAME is currently set as an exchange property. When the exchange > is sent over JMS, the properties are lost, which may result in inconveniences > in case conversion of the payload is required. > In order to tackle this problem, I suggest that IOHelper.getCharsetName() > looks up the CHARSET_NAME in the headers of the IN message in case the > property is not set on the exchange. > If this change is accepted, I am happy to provide a patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-6796) camel-xmlsecurity - Some options is not exposed as getter/setters
[ https://issues.apache.org/jira/browse/CAMEL-6796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-6796. Resolution: Fixed > camel-xmlsecurity - Some options is not exposed as getter/setters > - > > Key: CAMEL-6796 > URL: https://issues.apache.org/jira/browse/CAMEL-6796 > Project: Camel > Issue Type: Bug >Affects Versions: 2.12.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.12.2, 2.13.0 > > > See nabble > http://camel.465427.n5.nabble.com/contentObjectId-in-XML-Security-camel-xmlsecurity-tp5740265p5740348.html > Some options has not been exposed as getter/setters so they can be fully > configured. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6796) camel-xmlsecurity - Some options is not exposed as getter/setters
Claus Ibsen created CAMEL-6796: -- Summary: camel-xmlsecurity - Some options is not exposed as getter/setters Key: CAMEL-6796 URL: https://issues.apache.org/jira/browse/CAMEL-6796 Project: Camel Issue Type: Bug Affects Versions: 2.11.1 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.11.3, 2.12.2, 2.13.0 See nabble http://camel.465427.n5.nabble.com/contentObjectId-in-XML-Security-camel-xmlsecurity-tp5740265p5740348.html Some options has not been exposed as getter/setters so they can be fully configured. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CAMEL-5771) IOHelper.getCharsetName() should lookup CHARSET_NAME in headers if exchange property is not set
[ https://issues.apache.org/jira/browse/CAMEL-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reopened CAMEL-5771: > IOHelper.getCharsetName() should lookup CHARSET_NAME in headers if exchange > property is not set > --- > > Key: CAMEL-5771 > URL: https://issues.apache.org/jira/browse/CAMEL-5771 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.10.2 >Reporter: Marco Zapletal >Assignee: Claus Ibsen >Priority: Minor > Fix For: Future > > > The CHARSET_NAME is currently set as an exchange property. When the exchange > is sent over JMS, the properties are lost, which may result in inconveniences > in case conversion of the payload is required. > In order to tackle this problem, I suggest that IOHelper.getCharsetName() > looks up the CHARSET_NAME in the headers of the IN message in case the > property is not set on the exchange. > If this change is accepted, I am happy to provide a patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-5771) IOHelper.getCharsetName() should lookup CHARSET_NAME in headers if exchange property is not set
[ https://issues.apache.org/jira/browse/CAMEL-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-5771: --- Fix Version/s: (was: Future) 2.13.0 2.12.2 2.11.3 As we are only reading this is less harmful, and the header() in the DSL does a fallback to property, so we could allow to lookup the header as well. > IOHelper.getCharsetName() should lookup CHARSET_NAME in headers if exchange > property is not set > --- > > Key: CAMEL-5771 > URL: https://issues.apache.org/jira/browse/CAMEL-5771 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.10.2 >Reporter: Marco Zapletal >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.11.3, 2.12.2, 2.13.0 > > > The CHARSET_NAME is currently set as an exchange property. When the exchange > is sent over JMS, the properties are lost, which may result in inconveniences > in case conversion of the payload is required. > In order to tackle this problem, I suggest that IOHelper.getCharsetName() > looks up the CHARSET_NAME in the headers of the IN message in case the > property is not set on the exchange. > If this change is accepted, I am happy to provide a patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-6769) JndiRegistry - Implement the methods that return empty set
[ https://issues.apache.org/jira/browse/CAMEL-6769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-6769. Resolution: Fixed Fix Version/s: (was: Future) 2.13.0 2.12.2 2.11.3 > JndiRegistry - Implement the methods that return empty set > -- > > Key: CAMEL-6769 > URL: https://issues.apache.org/jira/browse/CAMEL-6769 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.11.3, 2.12.2, 2.13.0 > > > See nabble > http://camel.465427.n5.nabble.com/Proper-way-to-initialize-Transaction-management-for-Camel-in-an-Application-Server-tp5739760.html > We should implement the methods that return empty set. So it would work in > the situation from the link -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CAMEL-6785) Provide patch for CAMEL-6769
[ https://issues.apache.org/jira/browse/CAMEL-6785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reopened CAMEL-6785: Thanks for the patch. I made sure to return empty map instead of null as that is what the javadoc contract says. > Provide patch for CAMEL-6769 > > > Key: CAMEL-6785 > URL: https://issues.apache.org/jira/browse/CAMEL-6785 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.11.1 >Reporter: Marios Trivizas >Assignee: Claus Ibsen > Fix For: 2.11.3, 2.12.2, 2.13.0 > > Attachments: JndiRegistry.java.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-6785) Provide patch for CAMEL-6769
[ https://issues.apache.org/jira/browse/CAMEL-6785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-6785. Resolution: Fixed > Provide patch for CAMEL-6769 > > > Key: CAMEL-6785 > URL: https://issues.apache.org/jira/browse/CAMEL-6785 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.11.1 >Reporter: Marios Trivizas >Assignee: Claus Ibsen > Fix For: 2.11.3, 2.12.2, 2.13.0 > > Attachments: JndiRegistry.java.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-6769) JndiRegistry - Implement the methods that return empty set
[ https://issues.apache.org/jira/browse/CAMEL-6769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-6769: -- Assignee: Claus Ibsen > JndiRegistry - Implement the methods that return empty set > -- > > Key: CAMEL-6769 > URL: https://issues.apache.org/jira/browse/CAMEL-6769 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: Future > > > See nabble > http://camel.465427.n5.nabble.com/Proper-way-to-initialize-Transaction-management-for-Camel-in-an-Application-Server-tp5739760.html > We should implement the methods that return empty set. So it would work in > the situation from the link -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6785) Provide patch for CAMEL-6769
[ https://issues.apache.org/jira/browse/CAMEL-6785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6785: --- Fix Version/s: (was: Future) 2.13.0 2.12.2 2.11.3 > Provide patch for CAMEL-6769 > > > Key: CAMEL-6785 > URL: https://issues.apache.org/jira/browse/CAMEL-6785 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.11.1 >Reporter: Marios Trivizas >Assignee: Claus Ibsen > Fix For: 2.11.3, 2.12.2, 2.13.0 > > Attachments: JndiRegistry.java.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-6785) Provide patch for CAMEL-6769
[ https://issues.apache.org/jira/browse/CAMEL-6785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-6785: -- Assignee: Claus Ibsen > Provide patch for CAMEL-6769 > > > Key: CAMEL-6785 > URL: https://issues.apache.org/jira/browse/CAMEL-6785 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.11.1 >Reporter: Marios Trivizas >Assignee: Claus Ibsen > Fix For: Future > > Attachments: JndiRegistry.java.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-5771) IOHelper.getCharsetName() should lookup CHARSET_NAME in headers if exchange property is not set
[ https://issues.apache.org/jira/browse/CAMEL-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-5771. Resolution: Won't Fix Assignee: Claus Ibsen > IOHelper.getCharsetName() should lookup CHARSET_NAME in headers if exchange > property is not set > --- > > Key: CAMEL-5771 > URL: https://issues.apache.org/jira/browse/CAMEL-5771 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.10.2 >Reporter: Marco Zapletal >Assignee: Claus Ibsen >Priority: Minor > Fix For: Future > > > The CHARSET_NAME is currently set as an exchange property. When the exchange > is sent over JMS, the properties are lost, which may result in inconveniences > in case conversion of the payload is required. > In order to tackle this problem, I suggest that IOHelper.getCharsetName() > looks up the CHARSET_NAME in the headers of the IN message in case the > property is not set on the exchange. > If this change is accepted, I am happy to provide a patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-5771) IOHelper.getCharsetName() should lookup CHARSET_NAME in headers if exchange property is not set
[ https://issues.apache.org/jira/browse/CAMEL-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13780769#comment-13780769 ] Claus Ibsen commented on CAMEL-5771: CHARSET_NAME is an internal property on the Exchange. We do not want to expose this in a header. > IOHelper.getCharsetName() should lookup CHARSET_NAME in headers if exchange > property is not set > --- > > Key: CAMEL-5771 > URL: https://issues.apache.org/jira/browse/CAMEL-5771 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.10.2 >Reporter: Marco Zapletal >Priority: Minor > Fix For: Future > > > The CHARSET_NAME is currently set as an exchange property. When the exchange > is sent over JMS, the properties are lost, which may result in inconveniences > in case conversion of the payload is required. > In order to tackle this problem, I suggest that IOHelper.getCharsetName() > looks up the CHARSET_NAME in the headers of the IN message in case the > property is not set on the exchange. > If this change is accepted, I am happy to provide a patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6792) Camel Test Support needs a new Method
[
https://issues.apache.org/jira/browse/CAMEL-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-6792:
---
Estimated Complexity: Novice (was: Unknown)
The existing getMockEndpoint method should have an overloaded method with a
boolean create option, so people can do
getMockEndpoint("mock:foo", false)
To not auto create the mock endpoint if not existing, and throw a
NoSuchEndpoint exception if missing.
> Camel Test Support needs a new Method
> -
>
> Key: CAMEL-6792
> URL: https://issues.apache.org/jira/browse/CAMEL-6792
> Project: Camel
> Issue Type: Wish
> Components: camel-test
>Affects Versions: 2.11.1
> Environment: ALL
>Reporter: Robert E. Simmons Jr. MSc.
>Priority: Minor
>
> There is a problem with the CamelTestSupport class in that if you call
> getMockEndpoint on an endpoint that doesnt exist, it blithely returns you an
> endpoint connected to nothing. The problem is you end up chasing endless test
> failures when the fact is your endpoint is not even there. So I suggest a
> method I added to my subclass of CamelTestSupport which is:
> protected MockEndpoint assertAndGetMockEndpoint(final String uri) {
> assertNotNull(context.hasEndpoint(uri));
> return getMockEndpoint(uri);
> }
> This method will make sure that the endpoint is there before returning it and
> it will make tests easier to write.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6792) Camel Test Support needs a new Method
[
https://issues.apache.org/jira/browse/CAMEL-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-6792:
---
Patch Info: (was: Patch Available)
> Camel Test Support needs a new Method
> -
>
> Key: CAMEL-6792
> URL: https://issues.apache.org/jira/browse/CAMEL-6792
> Project: Camel
> Issue Type: Wish
> Components: camel-test
>Affects Versions: 2.11.1
> Environment: ALL
>Reporter: Robert E. Simmons Jr. MSc.
>Priority: Minor
>
> There is a problem with the CamelTestSupport class in that if you call
> getMockEndpoint on an endpoint that doesnt exist, it blithely returns you an
> endpoint connected to nothing. The problem is you end up chasing endless test
> failures when the fact is your endpoint is not even there. So I suggest a
> method I added to my subclass of CamelTestSupport which is:
> protected MockEndpoint assertAndGetMockEndpoint(final String uri) {
> assertNotNull(context.hasEndpoint(uri));
> return getMockEndpoint(uri);
> }
> This method will make sure that the endpoint is there before returning it and
> it will make tests easier to write.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6792) Camel Test Support needs a new Method
[
https://issues.apache.org/jira/browse/CAMEL-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13780755#comment-13780755
]
Claus Ibsen commented on CAMEL-6792:
Discussed at Camel user forum for a better solution.
> Camel Test Support needs a new Method
> -
>
> Key: CAMEL-6792
> URL: https://issues.apache.org/jira/browse/CAMEL-6792
> Project: Camel
> Issue Type: Wish
> Components: camel-test
>Affects Versions: 2.11.1
> Environment: ALL
>Reporter: Robert E. Simmons Jr. MSc.
>Priority: Minor
>
> There is a problem with the CamelTestSupport class in that if you call
> getMockEndpoint on an endpoint that doesnt exist, it blithely returns you an
> endpoint connected to nothing. The problem is you end up chasing endless test
> failures when the fact is your endpoint is not even there. So I suggest a
> method I added to my subclass of CamelTestSupport which is:
> protected MockEndpoint assertAndGetMockEndpoint(final String uri) {
> assertNotNull(context.hasEndpoint(uri));
> return getMockEndpoint(uri);
> }
> This method will make sure that the endpoint is there before returning it and
> it will make tests easier to write.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6792) Camel Test Support needs a new Method
[
https://issues.apache.org/jira/browse/CAMEL-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-6792:
---
Component/s: (was: tests)
camel-test
Priority: Minor (was: Major)
Issue Type: Wish (was: Bug)
> Camel Test Support needs a new Method
> -
>
> Key: CAMEL-6792
> URL: https://issues.apache.org/jira/browse/CAMEL-6792
> Project: Camel
> Issue Type: Wish
> Components: camel-test
>Affects Versions: 2.11.1
> Environment: ALL
>Reporter: Robert E. Simmons Jr. MSc.
>Priority: Minor
>
> There is a problem with the CamelTestSupport class in that if you call
> getMockEndpoint on an endpoint that doesnt exist, it blithely returns you an
> endpoint connected to nothing. The problem is you end up chasing endless test
> failures when the fact is your endpoint is not even there. So I suggest a
> method I added to my subclass of CamelTestSupport which is:
> protected MockEndpoint assertAndGetMockEndpoint(final String uri) {
> assertNotNull(context.hasEndpoint(uri));
> return getMockEndpoint(uri);
> }
> This method will make sure that the endpoint is there before returning it and
> it will make tests easier to write.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-6795) default spool directory in DefaultStreamCachingStrategy should be in a camel sub dir
[ https://issues.apache.org/jira/browse/CAMEL-6795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-6795. Resolution: Fixed > default spool directory in DefaultStreamCachingStrategy should be in a camel > sub dir > > > Key: CAMEL-6795 > URL: https://issues.apache.org/jira/browse/CAMEL-6795 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.12.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.12.2, 2.13.0 > > > The default spool directory in DefaultStreamCachingStrategy should be in a > camel sub directory. > This can avoid issues if the user does not have permission to write in the > tmp directory, but only in sub dirs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6795) default spool directory in DefaultStreamCachingStrategy should be in a camel sub dir
Claus Ibsen created CAMEL-6795: -- Summary: default spool directory in DefaultStreamCachingStrategy should be in a camel sub dir Key: CAMEL-6795 URL: https://issues.apache.org/jira/browse/CAMEL-6795 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.12.0 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.12.2, 2.13.0 The default spool directory in DefaultStreamCachingStrategy should be in a camel sub directory. This can avoid issues if the user does not have permission to write in the tmp directory, but only in sub dirs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6756) File consumer cannot rename a file consumed but failed due to AmbiguousMethodCallException - resulting infinite failure loop
[ https://issues.apache.org/jira/browse/CAMEL-6756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13780748#comment-13780748 ] Willem Jiang commented on CAMEL-6756: - Can you submit a simple test case to the JIRA? I will dig the issue when I get some time. > File consumer cannot rename a file consumed but failed due to > AmbiguousMethodCallException - resulting infinite failure loop > > > Key: CAMEL-6756 > URL: https://issues.apache.org/jira/browse/CAMEL-6756 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.12.0 > Environment: Windows 8 Pro, JDK 1.7 >Reporter: John Yin >Assignee: Willem Jiang > > When the following route encounters an AmbiguousMethodCallException in > calling bean:converter, the file that causing this problem cannot be > renamed/deleted by the File consumer. The same file would then be processed > and result the same error over and over again. > > > > > org.apache.camel.component.bean.AmbiguousMethodCallException > true > > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
