Re: Camel JAXB DataFormat is not thread safe

Because both are parsing and this part of process is statefull, so somehow they are more like builders not factories ;). -- View this message in context: http://camel.465427.n5.nabble.com/Camel-JAXB-DataFormat-is-not-thread-safe-tp5737748p5737883.html Sent from the Camel - Users mailing list

Camel JAXB DataFormat is not thread safe

Hello! Recently, I've encountered an issue (I suppose) connected with Camel's DataFormat implementation - the JAXB one. Due to exhausting tests, which we currently perform we've noticed that Camel's implementation uses JAXB's instances correctly (context is thread safe but products of context are

CxfPayload and streamCache

Hello! I've encountered unexpected behaviour while modelling some routes. When simplified it can be described as follows: camel:routeContext id=channel-routes xmlns=http://camel.apache.org/schema/spring; camel:route id=xyz streamCache=true from

Re: Enricher - coping strategy

Hi! Claus Ibsen-2 wrote This is working as designed. When using the enricher EIPs then the idea is that having the original message and the new message to combine these into a original message that is enriched with information from the new message. I see. Any idea how would you handle

Re: Enricher - coping strategy

Willem.Jiang wrote The enricher is just a common EIP implementation, we don't care much about the implementation of message. That's right, so implementation of exchange creation should be injectable. Willem.Jiang wrote I think we can enhance the enrich DSL by providing the plugin parameter

Enricher - coping strategy

Hello! After few route implementations which use enricher I've found it quite inconvenient to copy whole exchange. The concept is quite brilliant, but could anyone explain why, instead of implementing some ExchangeCreateStrategt (like AggregationStrategy for aggregation), the whole exchange is

Custom HTTP binding

Hello. According to http://camel.apache.org/jetty.html it is possible to easily override http binding. Unfortunately, default constructor of DefaultHttpBinding is annotated as @Deprecated, so this tutorial is outdated I think. Any way, looks like there is only a single point of usage of new

Re: Camel converters chaining.

Claus Ibsen-2 wrote What version of Camel are you using? It's 2.9 enhanced by Fuse. Unfortunately I cannot upgrade to 2.10, because it's evaluation of Fuse product in term of finding strong and weak points. You seems involved - I'm very interested in Fuses future under new wings :). Claus

Camel converters chaining.

Hello, Imagine situation when we have two converters ready to load. The case is that any of them can alone do desired conversion but chaining them is going to make it a day. For example: Converter X can convert type A to B. Converter Y can convert type B to C. Currently if we, for example, send

Re: Camel converters chaining.

Claus Ibsen-2 wrote Chained converters can be tricky as they can become non optimal, if the intermediate conversion takes time/memory etc. It would instead often be better to have A - C directly as converter. True! Claus Ibsen-2 wrote Also if there is multiple choices for the chain,

Re: Issue with ApnsServiceFactory

Here we go - https://issues.apache.org/jira/browse/CAMEL-5536 -- View this message in context: http://camel.465427.n5.nabble.com/Issue-with-ApnsServiceFactory-tp5717573p5719069.html Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Issue with ApnsServiceFactory

Hi, If we stick to examples in term of feedback and gateway configuration as an optional then I understand if ParamUtils.checkDestination(...) returns false then default values should still be used. Right now configureApnsCertificate(...) always overrides destinations (with default values) and