SQS - possible thread handling confusion with transactions

[James Green]

Hi,

I am looking at Spring Boot app that has been extended to include an
@SqsListener that uses ProducerTemplate to forward messages into a Camel
route.

An integration test was hooked up with ElasticMQ and all _appears_ correct
except assertions that the database records are correct - they in fact
appear to have been rolled back.

Logs indicate one thing - the SQS Listener is in one thread, camel another.

The camel route includes:

.transacted("springTransactionPolicyRequiresNew") // Start a new transaction

This works fine with Camel receiving messages from an ActiveMQ, however
clearly inadequate for SQS purposes.

Can anyone point me in the right direction?

Incidentally, the sqs component claims existance since Camel 2.6 yet I
cannot find it before 3.0. Am i missing something?

Thanks,

James

Spring Boot Testing & @DirtiesContext

[James Green]

I have an itch to scratch. Why does my test class require @DirtiesContext
to avoid a stack trace telling me that ActiveMQ was never started and so it
cannot be stopped after my test completes?

Context:

@RunWith(CamelSpringBootRunner.class)
@SpringBootTest
@MockEndpoints
@DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_EACH_TEST_METHOD)
public class FooTest {
...
}

Thanks,

James

Re: Spring Boot 2

[James Green]

Bah, 2.22, YKWIM!

On 2 March 2018 at 14:43, James Green  wrote:

> Thanks for the quick replies - we'll hold fire for 2.21.
>
> On 2 March 2018 at 14:33, Andrea Cosentino  wrote:
>
>> Actually there is a branch boot2 in apache camel repo, based on
>> camel-2.21.0-SNAPSHOT, with some work about Spring Boot 2.
>>
>> The target release for fully support Spring Boot 2 is 2.22.0
>>
>> --
>> Andrea Cosentino
>> --
>> Apache Camel PMC Member
>> Apache Karaf Committer
>> Apache Servicemix PMC Member
>> Email: ancosen1...@yahoo.com
>> Twitter: @oscerd2
>> Github: oscerd
>>
>>
>>
>>
>>
>>
>> On Friday, March 2, 2018, 3:30:50 PM GMT+1, James Green <
>> james.mk.gr...@gmail.com> wrote:
>>
>>
>>
>>
>>
>> I'm guessing that the current Camel release just won't do...
>>
>> Caused by: java.lang.NoClassDefFoundError:
>> org/springframework/boot/bind/RelaxedPropertyResolver
>> at
>> org.apache.camel.spring.boot.security.CamelSSLAutoConfigurat
>> ion$Condition.getMatchOutcome(CamelSSLAutoConfiguration.java:51)
>> at
>> org.springframework.boot.autoconfigure.condition.SpringBootC
>> ondition.matches(SpringBootCondition.java:47)
>> ... 41 more
>> Caused by: java.lang.ClassNotFoundException:
>> org.springframework.boot.bind.RelaxedPropertyResolver
>> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>> ... 43 more
>>
>> I noted a line in the 2.20 release notes talking about upcoming
>> compatibility. Would I be right to abandon this upgrade in my project
>> until
>> the next minor release of Camel?
>>
>> Thanks,
>>
>> James
>>
>
>

Re: Spring Boot 2

[James Green]

Thanks for the quick replies - we'll hold fire for 2.21.

On 2 March 2018 at 14:33, Andrea Cosentino  wrote:

> Actually there is a branch boot2 in apache camel repo, based on
> camel-2.21.0-SNAPSHOT, with some work about Spring Boot 2.
>
> The target release for fully support Spring Boot 2 is 2.22.0
>
> --
> Andrea Cosentino
> --
> Apache Camel PMC Member
> Apache Karaf Committer
> Apache Servicemix PMC Member
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
>
>
>
> On Friday, March 2, 2018, 3:30:50 PM GMT+1, James Green <
> james.mk.gr...@gmail.com> wrote:
>
>
>
>
>
> I'm guessing that the current Camel release just won't do...
>
> Caused by: java.lang.NoClassDefFoundError:
> org/springframework/boot/bind/RelaxedPropertyResolver
> at
> org.apache.camel.spring.boot.security.CamelSSLAutoConfiguration$
> Condition.getMatchOutcome(CamelSSLAutoConfiguration.java:51)
> at
> org.springframework.boot.autoconfigure.condition.
> SpringBootCondition.matches(SpringBootCondition.java:47)
> ... 41 more
> Caused by: java.lang.ClassNotFoundException:
> org.springframework.boot.bind.RelaxedPropertyResolver
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 43 more
>
> I noted a line in the 2.20 release notes talking about upcoming
> compatibility. Would I be right to abandon this upgrade in my project until
> the next minor release of Camel?
>
> Thanks,
>
> James
>

Spring Boot 2

[James Green]

I'm guessing that the current Camel release just won't do...

Caused by: java.lang.NoClassDefFoundError:
org/springframework/boot/bind/RelaxedPropertyResolver
at
org.apache.camel.spring.boot.security.CamelSSLAutoConfiguration$Condition.getMatchOutcome(CamelSSLAutoConfiguration.java:51)
at
org.springframework.boot.autoconfigure.condition.SpringBootCondition.matches(SpringBootCondition.java:47)
... 41 more
Caused by: java.lang.ClassNotFoundException:
org.springframework.boot.bind.RelaxedPropertyResolver
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 43 more

I noted a line in the 2.20 release notes talking about upcoming
compatibility. Would I be right to abandon this upgrade in my project until
the next minor release of Camel?

Thanks,

James

Re: Application halts for 30 minutes or until restart

[James Green]

We deployed changes Thursday evening that fixed the HTTP endpoint the
wiretap sends payloads to, and it's been running without incident since.

Feels like something may be wrong with error handling there.

On 27 July 2017 at 10:34, James Green  wrote:

> I have a thread dump with it hung - uploaded to fastthread.io and
> received a smiley face - there's nothing wrong!
>
> Here's the gist if anyone can spot something obvious: https://gist.github.
> com/jmkgreen/a293ace71678a1ae2a5aac7b6408876e
>
> The notable thing is that wiretap is being used and features - could there
> be a starvation problem due to this not completing?
>
> James
>
>
> On 27 July 2017 at 09:24, Zoran Regvart  wrote:
>
>> Hi James,
>> besides the obvious garbage collector pauses, one thing that might reveal
>> the problem is to do periodic thread dumps and look if there are any
>> locking issues. And perhaps increasing the verbosity of the logs can give
>> you more clues,
>>
>> zoran
>>
>> On Thu, Jul 27, 2017 at 9:58 AM, James Green 
>> wrote:
>>
>> > This is a Spring Boot 1.3 application that was recently re-imaged
>> (Docker)
>> > and rebooted after several months of loyal service. We are unaware of
>> any
>> > major changes beyond going from java:8 to openjdk:8.
>> >
>> > It receives payloads from ActiveMQ, works against Mongo, and spits out
>> > payloads to HTTP and SMTP endpoints. Since deployment, each morning
>> during
>> > "rush hour" the application has ceased operating seconds - the JVM is
>> alive
>> > yet the logs and data processing have all halted. A restart resumes
>> things.
>> >
>> > So what's in the logs? It seems we have a loading problem contacting the
>> > HTTP endpoint (NoHttpResponseException), which we will fix. There are
>> also
>> > warnings about ActiveMQ Inactivity Monitor exceeding 30s and will
>> reconnect
>> > which we don't have any obvious clue about.
>> >
>> > But I'm surprised either of these should (eventually) completely halt
>> the
>> > system!
>> >
>> > The very last log lines are absolutely normal behaviour indicating that
>> it
>> > has completed processing the message, indicating at least one thread has
>> > finished.
>> >
>> > Can anyone suggest what could cause what we're seeing? My next step is
>> to
>> > capture a heap dump but we're down to dark magic levels.
>> >
>> > We're trying hawt.io to get some visibility but it's a real pain
>> within a
>> > docker-compose launched set of containers due to some security
>> restrictions
>> > recently introduced and apparent bugs within.
>> >
>> > Appreciate the help in advance.
>> >
>> > Thanks,
>> >
>> > James
>> >
>>
>>
>>
>> --
>> Zoran Regvart
>>
>
>

Re: Application halts for 30 minutes or until restart

[James Green]

I have a thread dump with it hung - uploaded to fastthread.io and received
a smiley face - there's nothing wrong!

Here's the gist if anyone can spot something obvious:
https://gist.github.com/jmkgreen/a293ace71678a1ae2a5aac7b6408876e

The notable thing is that wiretap is being used and features - could there
be a starvation problem due to this not completing?

James


On 27 July 2017 at 09:24, Zoran Regvart  wrote:

> Hi James,
> besides the obvious garbage collector pauses, one thing that might reveal
> the problem is to do periodic thread dumps and look if there are any
> locking issues. And perhaps increasing the verbosity of the logs can give
> you more clues,
>
> zoran
>
> On Thu, Jul 27, 2017 at 9:58 AM, James Green 
> wrote:
>
> > This is a Spring Boot 1.3 application that was recently re-imaged
> (Docker)
> > and rebooted after several months of loyal service. We are unaware of any
> > major changes beyond going from java:8 to openjdk:8.
> >
> > It receives payloads from ActiveMQ, works against Mongo, and spits out
> > payloads to HTTP and SMTP endpoints. Since deployment, each morning
> during
> > "rush hour" the application has ceased operating seconds - the JVM is
> alive
> > yet the logs and data processing have all halted. A restart resumes
> things.
> >
> > So what's in the logs? It seems we have a loading problem contacting the
> > HTTP endpoint (NoHttpResponseException), which we will fix. There are
> also
> > warnings about ActiveMQ Inactivity Monitor exceeding 30s and will
> reconnect
> > which we don't have any obvious clue about.
> >
> > But I'm surprised either of these should (eventually) completely halt the
> > system!
> >
> > The very last log lines are absolutely normal behaviour indicating that
> it
> > has completed processing the message, indicating at least one thread has
> > finished.
> >
> > Can anyone suggest what could cause what we're seeing? My next step is to
> > capture a heap dump but we're down to dark magic levels.
> >
> > We're trying hawt.io to get some visibility but it's a real pain within
> a
> > docker-compose launched set of containers due to some security
> restrictions
> > recently introduced and apparent bugs within.
> >
> > Appreciate the help in advance.
> >
> > Thanks,
> >
> > James
> >
>
>
>
> --
> Zoran Regvart
>

Application halts for 30 minutes or until restart

[James Green]

This is a Spring Boot 1.3 application that was recently re-imaged (Docker)
and rebooted after several months of loyal service. We are unaware of any
major changes beyond going from java:8 to openjdk:8.

It receives payloads from ActiveMQ, works against Mongo, and spits out
payloads to HTTP and SMTP endpoints. Since deployment, each morning during
"rush hour" the application has ceased operating seconds - the JVM is alive
yet the logs and data processing have all halted. A restart resumes things.

So what's in the logs? It seems we have a loading problem contacting the
HTTP endpoint (NoHttpResponseException), which we will fix. There are also
warnings about ActiveMQ Inactivity Monitor exceeding 30s and will reconnect
which we don't have any obvious clue about.

But I'm surprised either of these should (eventually) completely halt the
system!

The very last log lines are absolutely normal behaviour indicating that it
has completed processing the message, indicating at least one thread has
finished.

Can anyone suggest what could cause what we're seeing? My next step is to
capture a heap dump but we're down to dark magic levels.

We're trying hawt.io to get some visibility but it's a real pain within a
docker-compose launched set of containers due to some security restrictions
recently introduced and apparent bugs within.

Appreciate the help in advance.

Thanks,

James

wiretap + sampler = potentially lost exchanges?

[James Green]

The thought occurred to me that I could use a wiretap on a route to send an
exchange both to the original destination and to a route that logs what is
happening.

The "logger" route would start with a sampler to reduce the logging output.

However, if the wiretap thread pool is full, wiretap would call the
"logger" route synchronously, according to "Wiretap Thread Pool" here:
http://camel.apache.org/wire-tap.html

Doesn't that infer that with a sampler, some exchanges might not eventually
reach their original destination? Or do I have my mental image of things
incorrect?

Thanks,

James

Re: Large message handling

[James Green]

That's pretty much what we were describing.

I see there is no DSL for this so beyond it being a known algorithm it
remains a "write-your-own-implementation". I guess therefore it's a
relatively narrow use-case...


On 4 November 2016 at 16:50, Quinn Stevenson 
wrote:

> I think the EIP you’re referring to is the “Claim Check” pattern (
> http://www.enterpriseintegrationpatterns.com/patterns/messaging/
> StoreInLibrary.html <http://www.enterpriseintegrationpatterns.
> com/patterns/messaging/StoreInLibrary.html> ), and Camel does support
> that EIP ( http://camel.apache.org/claim-check.html <
> http://camel.apache.org/claim-check.html> )
>
> HTH
>
>
> > On Nov 4, 2016, at 8:53 AM, James Green 
> wrote:
> >
> > Hi,
> >
> > We are preparing to start handling very large messages. Currently we have
> > small (<1k) messages arriving from message queues and being processed,
> but
> > these new messages could be several mb each.
> >
> > Each message is basically a JSON formatted payload with metadata and a
> > content-body. It's this content-body that may end up being much larger in
> > some cases.
> >
> > We have speculated that this may be best handled by recognising a
> reference
> > within the message meta-data to a URI that actually has the content-body.
> > This feels like a pattern that may have already been invented. Not unlike
> > SOAP where references to files sent separately can be achieved.
> >
> > Anyone know of such a system or even terms to hit Google with? And might
> > there be something in the Camel-sphere that loads external references
> > already?
> >
> > Thanks,
> >
> > James
>
>

Re: Best way to build a wait/retry loop with Camel?

[James Green]

Are you unable to move the messages into a database for "long-term"
storage? That's what we do, and we simply scan for messages due to be
"re-sent" and re-submit them back into the queue.

I do not believe ActiveMQ was really intended to hold many messages for
long term storage, hence we use something that was.


On 3 November 2016 at 15:46, Stephan Burkard  wrote:

> Hi Camel users
>
> TLDR:
> - how to implement wait/retry loop?
> - messages "wait" in a queue
> - each message should be reprocessed only once per interval (let's say per
> day)
> - after reprocessing a message either returns to the waiting queue or
> continues (goes out of loop)
> - after [maxRetry] attempts it is moved away (goes out of loop)
>
>
> Full story:
>
> As part of a typical processing workflow, I have a queue with "waiting"
> messages. These messages are waiting for data of another system and I have
> no idea when the data arrives. Therefore I want to reprocess the messages
> in an interval, let's say once a day. If the data is still missing, they go
> again to the waiting queue.
> To move messages away that would wait forever, I set and check a maxRetry.
>
> How would I best implement this? Some thoughts I made:
>
> 1. Just throw an exception if the data is missing. The message is
> redelivered.
>Problem: The message is instantly redelivered. So it does the retries
> within milliseconds. I cannot customize the interval.
>
> 2. Use the Camel delayer.
>Works good in general (my current solution). I can even calculate the
> delay based on the JMSTimestamp to take into account the time a message
> waits to be consumed.
>Problem: For an interval of 1 day, a message is permanently in
> processing state. The consumer is blocked. When I shutdown the container,
> Camel waits 5 minutes and after restarting the message goes to the DLQ.
>
> 3. Use a CronScheduledRoutePolicy to start/stop the route in the given
> interval.
>Problem: When I start the route once a day for 5 minutes, the messages
> with missing data are circulating until the route is stopped again. So they
> try to find the data multiple times per second and instantly reach the
> maxRetry. They must try only once per interval.
>
> 4. Use a JMS selector as from-Endpoint that selects "JMSTimestamp <
> (currentTime - intervalTime)"
>Problem: The from-Endpoint URI seems to be a constant, I can't make the
> selector dynamic.
>
> 5. Use the Camel Throttler
>Problem: The throttler sets a bandwith, that is not what we need.
>
> 6. Use a Timer from-Endpoint and hand over to a bean that consumes the
> messages (newest idea, not yet tried).
>I guess I could manage to consume all waiting messages just once (even
> if they already return before I am finished).
>Problems I can think of: It is not very nice to build another JMS
> consumer (beside Camel), but I could use Spring JMS Template.
>
>
> Numbers 1, 3, 4 and 5 simply do not work (or I don't use them the right
> way) for this case. Number 2 is my current solution, number 6 a new idea.
> Any recommendations or other suggestions how to build this wait/retry loop?
>
> Thanks a lot
> Stephan
>

Large message handling

[James Green]

Hi,

We are preparing to start handling very large messages. Currently we have
small (<1k) messages arriving from message queues and being processed, but
these new messages could be several mb each.

Each message is basically a JSON formatted payload with metadata and a
content-body. It's this content-body that may end up being much larger in
some cases.

We have speculated that this may be best handled by recognising a reference
within the message meta-data to a URI that actually has the content-body.
This feels like a pattern that may have already been invented. Not unlike
SOAP where references to files sent separately can be achieved.

Anyone know of such a system or even terms to hit Google with? And might
there be something in the Camel-sphere that loads external references
already?

Thanks,

James

Re: Non-Blocking throttler?

[James Green]

Just looked at the `SamplingThrottler` source and with a period defined it
looks like it is what we need.

Thanks!


On 26 October 2016 at 13:42, Claus Ibsen  wrote:

> There is a sampling eip
> http://camel.apache.org/sampling
>
> Maybe its something you can use?
>
> On Wed, Oct 26, 2016 at 2:28 PM, James Green 
> wrote:
> > I'm looking at a route that will be exercised in the event of an
> emergency
> > situation such as "database is down".
> >
> > Is there a non-blocking Throttler, one that lets the caller continue AND
> > only samples the Exchanges that arrives? I would like to call a third
> party
> > if this route is called but they won't want to be called very frequently,
> > e.g. no more than once per ten minutes?
> >
> > Ideas?
> >
> > James
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Non-Blocking throttler?

[James Green]

I'm looking at a route that will be exercised in the event of an emergency
situation such as "database is down".

Is there a non-blocking Throttler, one that lets the caller continue AND
only samples the Exchanges that arrives? I would like to call a third party
if this route is called but they won't want to be called very frequently,
e.g. no more than once per ten minutes?

Ideas?

James

Re: IDE for newer Camel versions using Camel Spring Boot

[James Green]

Just installed the update but ctrl+alt+4 would not show any Camel items
until I put the cursor between inside a from()...to() route. Putting the
cursor inside a RouteBuilder was not sufficient, maybe an area for
improvement...


On 26 October 2016 at 08:52, Claus Ibsen  wrote:

> Hi
>
> Yeah it was a bug in the tooling. Its because you dont have a
> src/main/webapp folder.
>
> Are you using latest release of the camel addon?
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22io.
> fabric8.forge%22%20AND%20a%3A%22camel%22
>
> The latest today is 2.3.60
>
>
>
> On Tue, Oct 25, 2016 at 3:29 PM, James Green 
> wrote:
> > Nice video indeed, however on asking to edit an endpoint in IDEA
> 2016.2.5 I
> > get "No Facet of type [interface
> > org.jboss.forge.addon.projects.facets.WebResourcesFacet] is installed."
> >
> > Not sure I know where this needs to be reported as a bug - is it a JBoss
> > thing, a fabic8 thing, or a Camel thing?
> >
> > On 24 October 2016 at 08:17, Claus Ibsen  wrote:
> >
> >> Hi
> >>
> >> There is also the fabric8 Camel forge tooling for Apache Camel
> >> http://fabric8.io/guide/forge.html
> >>
> >> As well the maven plugin to validate your Camel endpoints/expressions
> >> http://fabric8.io/guide/camelMavenPlugin.html
> >>
> >> The forge tooling works in any IDE such as Eclipse, IDEA or NetBeans.
> >> I recorded a video in the start of the year
> >> http://www.davsclaus.com/2015/12/video-of-apache-camel-
> >> tooling-to-edit.html
> >>
> >> For graphical drag and drop then there is as you say JBoss Eclipse
> >> tooling for Camel where a new version was recently released that
> >> support Camel 2.17.x
> >> http://lhein.blogspot.se/2016/10/jboss-fuse-tooling-80-for-
> >> eclipse-mars.html
> >>
> >> The real power of Camel is that you do NOT need any tooling, its just
> >> java, scala, groovy or xml code. The more skilled (Camel) developers I
> >> hear just uses their IDE of choice/
> >>
> >> Though for Spring Boot users I do like the auto completion tooling
> >> that IDEA has when editing application.properties where you can get
> >> code assistance to see all the options you can configure, and with
> >> documentation.
> >>
> >>
> >>
> >> On Sun, Oct 23, 2016 at 9:35 PM, Pontus Ullgren 
> wrote:
> >> > Hi,
> >> >
> >> > I know about JBoss Tools Camel Tooling and been using it. It works
> great
> >> as
> >> > long as we stayed with the RedHat supported versions of Camel and
> JBoss
> >> > Fuse. But lately we have moved away from this and going with Camel
> Spring
> >> > Boot and more up to date versions of Camel.
> >> >
> >> > The main reason for this is to get new features faster.
> >> >
> >> > The problem now is that JBoss Tools does not handle this combination
> >> well.
> >> > But that is a JBoss specific issue so that is not what I want to
> discuss
> >> > here. There is other forums for this.
> >> >
> >> > Instead my question: What do you use for developing your Camel based
> >> > applications ?
> >> > I quickly tested Spring Tool Suite which kind of give us most of what
> we
> >> > look for including good support for gradle. But hope to get some more
> >> > suggestions.
> >> >
> >> > We mostly use the Spring XML DSL to define the routes but also some
> Java
> >> > DSL.
> >> > Code completion and some tooltips in XML editing mode is a
> requirement.
> >> > Graphical visualisation and editing of the routes is a bonus but I
> assume
> >> > that JBoss Tools is the only one that supports this.
> >> >
> >> > Thanks for any insight you can share
> >> > Pontus
> >>
> >>
> >>
> >> --
> >> Claus Ibsen
> >> -
> >> http://davsclaus.com @davsclaus
> >> Camel in Action 2: https://www.manning.com/ibsen2
> >>
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Re: IDE for newer Camel versions using Camel Spring Boot

[James Green]

Nice video indeed, however on asking to edit an endpoint in IDEA 2016.2.5 I
get "No Facet of type [interface
org.jboss.forge.addon.projects.facets.WebResourcesFacet] is installed."

Not sure I know where this needs to be reported as a bug - is it a JBoss
thing, a fabic8 thing, or a Camel thing?

On 24 October 2016 at 08:17, Claus Ibsen  wrote:

> Hi
>
> There is also the fabric8 Camel forge tooling for Apache Camel
> http://fabric8.io/guide/forge.html
>
> As well the maven plugin to validate your Camel endpoints/expressions
> http://fabric8.io/guide/camelMavenPlugin.html
>
> The forge tooling works in any IDE such as Eclipse, IDEA or NetBeans.
> I recorded a video in the start of the year
> http://www.davsclaus.com/2015/12/video-of-apache-camel-
> tooling-to-edit.html
>
> For graphical drag and drop then there is as you say JBoss Eclipse
> tooling for Camel where a new version was recently released that
> support Camel 2.17.x
> http://lhein.blogspot.se/2016/10/jboss-fuse-tooling-80-for-
> eclipse-mars.html
>
> The real power of Camel is that you do NOT need any tooling, its just
> java, scala, groovy or xml code. The more skilled (Camel) developers I
> hear just uses their IDE of choice/
>
> Though for Spring Boot users I do like the auto completion tooling
> that IDEA has when editing application.properties where you can get
> code assistance to see all the options you can configure, and with
> documentation.
>
>
>
> On Sun, Oct 23, 2016 at 9:35 PM, Pontus Ullgren  wrote:
> > Hi,
> >
> > I know about JBoss Tools Camel Tooling and been using it. It works great
> as
> > long as we stayed with the RedHat supported versions of Camel and JBoss
> > Fuse. But lately we have moved away from this and going with Camel Spring
> > Boot and more up to date versions of Camel.
> >
> > The main reason for this is to get new features faster.
> >
> > The problem now is that JBoss Tools does not handle this combination
> well.
> > But that is a JBoss specific issue so that is not what I want to discuss
> > here. There is other forums for this.
> >
> > Instead my question: What do you use for developing your Camel based
> > applications ?
> > I quickly tested Spring Tool Suite which kind of give us most of what we
> > look for including good support for gradle. But hope to get some more
> > suggestions.
> >
> > We mostly use the Spring XML DSL to define the routes but also some Java
> > DSL.
> > Code completion and some tooltips in XML editing mode is a requirement.
> > Graphical visualisation and editing of the routes is a bonus but I assume
> > that JBoss Tools is the only one that supports this.
> >
> > Thanks for any insight you can share
> > Pontus
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

onException documentation error?

[James Green]

Referencing http://camel.apache.org/exception-clause.html under "Marking
exceptions as handled" is an example "Example using handled" where it is
stated:

"In this route below we want to do special handling of all
OrderFailedException as we want to return a customized response to the
caller. First we setup our routing as:"

[ skip code ]

I've written a test that shows that the caller does not receive anything at
all. In fact, the only circumstances in which the Exchange propagates
beyond the onException rules are:

1. Where continued is set and the Exchange will continue along the existing
route as if nothing had happened (as documented)
2. Where the onException rules include explicit to("direct:foo") where
direct:foo will then receive the Exchange.

Importantly, if an Exchange is passed (mid-way) from one route to another
and the second route handles an Exception, the Exchange does not return to
the original route (where further processing of any responses from that
second route may be parsed). This is contrary to standard Java call stack
of a method (A) in one class resuming when calling a method (B) in a second
class where that method B experiences and handles an Exception itself.

The simple answer, assuming I have this right and it is expected, is to
update the documentation to that that the Exchange will be dropped until
the onException rules apply a to() directive.

I hope this makes sense!

Thanks,

James

Re: MockEndpoint header test seems wrong

[James Green]

Forget this - finally found a case where the header was being set in a
somewhat contrived manner.

On 2 August 2016 at 18:02, James Green  wrote:

> Hi,
>
> In my test I have:
>
> mockEndpoint.allMessages().header("SomeKey").isInstanceOf(SomeClazz.class);
>
> Which should fail, as the route sets SomeKey as a Property of the
> Exchange, not a Header. I have scanned the code base several times for
> SomeKey to be set as a Header but I cannot find such a thing which leads me
> to suspect the test method itself...
>
> Camel version: 2.17.0.
>
> Thanks,
>
> James
>
>

MockEndpoint header test seems wrong

[James Green]

Hi,

In my test I have:

mockEndpoint.allMessages().header("SomeKey").isInstanceOf(SomeClazz.class);

Which should fail, as the route sets SomeKey as a Property of the Exchange,
not a Header. I have scanned the code base several times for SomeKey to be
set as a Header but I cannot find such a thing which leads me to suspect
the test method itself...

Camel version: 2.17.0.

Thanks,

James

description vs routeDescription

[James Green]

Hi,

Not clear on the difference. It seems at runtime I only get the last one
set.

Am I expected to use both to serve different purposes?

James

Re: ClassNotFoundException ObjectFactory

[James Green]

Interestingly we get something similar:

10/May/2016 16:36:54,356 [DEBUG] ObjectHelper: Cannot find class:
java.lang.ObjectFactory
10/May/2016 16:36:54,357 [DEBUG] ObjectHelper: Cannot find class:
java.lang.ObjectFactory
10/May/2016 16:36:54,357 [DEBUG] ObjectHelper: Cannot find class:
org.apache.activemq.command.ObjectFactory
10/May/2016 16:36:54,357 [DEBUG] ObjectHelper: Cannot find class:
org.apache.activemq.command.ObjectFactory
10/May/2016 17:06:54,234 [DEBUG] ObjectHelper: Cannot find class:
com.mongodb.ObjectFactory
10/May/2016 17:06:54,234 [DEBUG] ObjectHelper: Cannot find class:
com.mongodb.ObjectFactory
10/May/2016 17:06:54,234 [DEBUG] ObjectHelper: Cannot find class:
org.apache.camel.component.jms.ObjectFactory
10/May/2016 17:06:54,235 [DEBUG] ObjectHelper: Cannot find class:
org.apache.camel.component.jms.ObjectFactory
10/May/2016 17:06:54,255 [DEBUG] ObjectHelper: Cannot find class:
com.mongodb.ObjectFactory
10/May/2016 17:06:54,255 [DEBUG] ObjectHelper: Cannot find class:
com.mongodb.ObjectFactory
10/May/2016 17:06:54,256 [DEBUG] ObjectHelper: Cannot find class:
org.apache.camel.impl.ObjectFactory
10/May/2016 17:06:54,256 [DEBUG] ObjectHelper: Cannot find class:
org.apache.camel.impl.ObjectFactory
10/May/2016 17:06:54,260 [DEBUG] ObjectHelper: Cannot find class:
java.lang.ObjectFactory
10/May/2016 17:06:54,260 [DEBUG] ObjectHelper: Cannot find class:
java.lang.ObjectFactory
10/May/2016 17:06:54,260 [DEBUG] ObjectHelper: Cannot find class:
sun.nio.cs.ObjectFactory
10/May/2016 17:06:54,261 [DEBUG] ObjectHelper: Cannot find class:
sun.nio.cs.ObjectFactory
10/May/2016 17:06:54,261 [DEBUG] ObjectHelper: Cannot find class:
java.lang.ObjectFactory
10/May/2016 17:06:54,261 [DEBUG] ObjectHelper: Cannot find class:
java.lang.ObjectFactory
10/May/2016 17:06:54,262 [DEBUG] ObjectHelper: Cannot find class:
java.lang.ObjectFactory

Camel 2.17.0. Looks like before 2.17 it may have been wrapped?

at
org.apache.camel.util.ObjectHelper.wrapCamelExecutionException(ObjectHelper.java:1635)
~[sms-sender.jar:?]



On 12 May 2016 at 18:34, yogu13  wrote:

> Need more info on your route and project setup..
>
> Regards,
> -Yogesh
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/ClassNotFoundException-ObjectFactory-tp5782443p5782502.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>

Re: interceptSendToEndpoint

[James Green]

You could do it that way and add a second interceptSendToEndpoint
intercepting the next hop I guess.

You may wish to consider what you are trying to achieve - if you do not
require the full payload to be audited it may be that using an HTTP proxy
satisfies your requirements and requires very little code to be maintained.

On 10 May 2016 at 20:49, Bassett, Derek 
wrote:

> Hi,
>
>From the description on http://camel.apache.org/intercept.html page it
> says:
>
> "You can think of it as a AOP before that is applied at each DSL keyword
> you have defined in your route"
>
>
> Can I use interceptSendToEndpoint if I want to do both a Before and After
> or do I have to use something else?  Basically I need to generate a WireTap
> for Auditing purposes ever time I make a http request out.  I understand
> the performance impacts but the business thinks its more important then
> actually being performant.  I wanted to see if there was a way I could do
> that with interceptSendToEndpoint, maybe using a custom Processors or
> something akin to a Before/After Advice.
>
>
> Derek
>

ActiveMQ Consumer stalled?

[James Green]

Got a Message Driven Consumer which the broker shows as connected but after
a while it seems to stop accepting new messages.

Nothing amiss in the logs, the whole process just appears stalled. I have
just obtained a thread dump (see
https://gist.github.com/jmkgreen/8c4e399520f731c9175ee1bad969261f for this).

My reading is that Camel has a single thread which is the Message Driven
Consumer and that in this case it is currently blocked on a Jedis Pool? It
also seems where are other ActiveMQ transports spare?

We're been having issues with Jedis and connection handling - I'm wanting
to narrow down what might be happening right now.

Thanks,

James

Sub-classing org.apache.camel.spring.javaconfig.Main - bug?

[James Green]

Tried writing an Application.java extending
org.apache.camel.spring.javaconfig.Main and overriding the public void
setBasedPackages(String config) method.

My sub-class method does not get called yet the base class version does get
called. On inspection, there's a static call
to org.apache.camel.spring.javaconfig.Main. Is this intentional?

If it is, shouldn't the method be marked final to prevent developer wrongly
extending it?

Thanks,

James

Re: CamelContext.hasComponent()

[James Green]

I'm looking at code that conditionally adds activemq if configuration is
provided at runtime, hence my use as a consumer.

On 30 March 2016 at 11:25, Claus Ibsen  wrote:

> Just to add a bit context.
>
> This method is less intended for Camel end users, but more for
> component developers / camel itself.
>
>
> On Wed, Mar 30, 2016 at 12:00 PM, Claus Ibsen 
> wrote:
> > No this is by design
> >
> > On Wed, Mar 30, 2016 at 11:56 AM, James Green 
> wrote:
> >> I was expecting this to return boolean, but it returns a Component if
> >> present or null otherwise.
> >>
> >> This feels counter-intuitive and horrible to code against. Are there
> plans
> >> to this this?
> >>
> >> Thanks,
> >>
> >> James
> >
> >
> >
> > --
> > Claus Ibsen
> > -
> > http://davsclaus.com @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

CamelContext.hasComponent()

[James Green]

I was expecting this to return boolean, but it returns a Component if
present or null otherwise.

This feels counter-intuitive and horrible to code against. Are there plans
to this this?

Thanks,

James

Multiple interceptors?

[James Green]

http://camel.apache.org/intercept.html does not describe the behaviour of
having more than one interceptor in use.

For example:

intercept().to("log:foo");
intercept().to("log:bar");

from("direct:start").to("direct:end");

Do both logging endpoints get triggered? If so, in any particular order?

Is it even allowed?

Our use case is where we intercept a recipient list endpoint that may be
queue or http. We clearly need to marshal to json first for which we have
an interceptor. But for a queue we also need to set In/Out to wait for the
reply. My thoughts are another interceptor, this time for queues only.

Thanks,

James

Re: Use Simple to log Message History?

[James Green]

Yeah we switched that on and nothing happened. Must have been us but it
seemed pretty simple!

On 24 February 2016 at 11:34, Claus Ibsen  wrote:

> You can use the tracer
> http://camel.apache.org/tracer
>
> On Wed, Feb 24, 2016 at 12:12 PM, James Green 
> wrote:
> > Our use-case was in debugging why a processor was being triggered twice.
> We
> > wanted to log immediately before the processor to see where the Exchange
> > came from second time around.
> >
> > I see a few people via Google asking how to log where the Exchange has
> > been, thought something like this would be a useful quick tool in the
> > toolbox.
> >
> > On 24 February 2016 at 10:35, Claus Ibsen  wrote:
> >
> >> What kind of logging do you want.
> >>
> >> Do you mean that verbose logging you see when there is an exception?
> >>
> >> The message history on the exchange is stored as a list of events that
> >> track the details. But the formatting is done elsewhere.
> >>
> >>
> >>
> >> On Wed, Feb 24, 2016 at 10:48 AM, James Green  >
> >> wrote:
> >> > Is this possible?
> >> >
> >> > We really just want to from().log("${exchange.history}").to() in our
> >> route.
> >> > Seems like this should be really easy?
> >> >
> >> > Thanks,
> >> >
> >> > James
> >>
> >>
> >>
> >> --
> >> Claus Ibsen
> >> -
> >> http://davsclaus.com @davsclaus
> >> Camel in Action 2: https://www.manning.com/ibsen2
> >>
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Re: Use Simple to log Message History?

[James Green]

Our use-case was in debugging why a processor was being triggered twice. We
wanted to log immediately before the processor to see where the Exchange
came from second time around.

I see a few people via Google asking how to log where the Exchange has
been, thought something like this would be a useful quick tool in the
toolbox.

On 24 February 2016 at 10:35, Claus Ibsen  wrote:

> What kind of logging do you want.
>
> Do you mean that verbose logging you see when there is an exception?
>
> The message history on the exchange is stored as a list of events that
> track the details. But the formatting is done elsewhere.
>
>
>
> On Wed, Feb 24, 2016 at 10:48 AM, James Green 
> wrote:
> > Is this possible?
> >
> > We really just want to from().log("${exchange.history}").to() in our
> route.
> > Seems like this should be really easy?
> >
> > Thanks,
> >
> > James
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Use Simple to log Message History?

[James Green]

Is this possible?

We really just want to from().log("${exchange.history}").to() in our route.
Seems like this should be really easy?

Thanks,

James

Sending Exchange to Multiple HTTP endpoints

[James Green]

I'm curious how others might do this.

On the Exchange I can dynamically build a list of URIs (web hooks,
basically) that need the body of this message. First attempt: add this list
to a known header and pass it into recipient list:

recipientList(header('webHooksList'))

Sadly I also need to replace https with https4 and http with http4, which
feels potentially dangerous.

Thinking ahead I might need to configure the http client with
authentication for each URI. Should I somehow deep clone the message and
send them each down a route that configurers each URI in turn? Feels
perhaps more complex than initially required - can this be simplified?

Thanks,

James

Re: [security] http4 endpoint headers "leaking"

[James Green]

To follow-up, are we clear that the bug is when a remote HTTP server is
called via to(http4:...) ? The remote side gets to see all the exchange
headers, which is the leak.

>From your email I was reading you thought it was to do with the consumer
being wrong but it's the producer we're seeing bad things on. I'm no expert
but I'm not seeing anything obvious to fix this in the commit.

Thanks,

James


On 5 August 2015 at 10:04, James Green  wrote:

> We're using to - i.e. a producer. ..to(http4:some.host) and some.host gets
> all the headers in the request.
>
>
> On 5 August 2015 at 09:57, Claus Ibsen  wrote:
>
>> Hi
>>
>> Yeah the http filter was filtering only for the producer. We should do
>> it for the consumer as well, so camel-jetty etc do not include Camel
>> headers in the http responses by default.
>>
>> There is plenty of options already we should not add more.
>>
>> I logged a ticket to let the http filter strategy filter those for
>> both the producer and consumer
>> https://issues.apache.org/jira/browse/CAMEL-9052
>>
>>
>>
>> On Wed, Aug 5, 2015 at 9:51 AM, James Green 
>> wrote:
>> > We recently had cause to tcpdump an http request from the http4
>> component
>> > to a web site. We were most surprised to find a load of exchange headers
>> > listed as HTTP "header: value" pairs.
>> >
>> > A quick search on-line brings up a couple of Red Hat / Fuse documents
>> > saying that headers named 'Camel...' are not transmitted onwards, others
>> > are.
>> >
>> > Two concerns:
>> >
>> > 1. We see no documentation concerning this on the http4 component's page
>> > 2. There may be a great many applications deployed unintentionally
>> > transmitting internal headers to third parties potentially in breach of
>> > policy or legal restrictions without human knowledge
>> >
>> > I suggest adding a new option, CopyAllHeadersToHttpHeaders, defaulted to
>> > false. This would allow developers to "correct" their applications
>> without
>> > code changes, and those taking advantage of this facility can switch it
>> on
>> > explicitly.
>> >
>> > This isn't a Camel security vulnerability but I very much expect it to
>> be
>> > leading to information leakage "out there". It is certainly not a
>> behaviour
>> > we expected to see given the documentation. There may be other
>> components
>> > that require similar attention.
>> >
>> > Thoughts?
>> >
>> > James
>>
>>
>>
>> --
>> Claus Ibsen
>> -
>> http://davsclaus.com @davsclaus
>> Camel in Action 2nd edition: http://www.manning.com/ibsen2
>>
>
>

Re: [security] http4 endpoint headers "leaking"

[James Green]

We're using to - i.e. a producer. ..to(http4:some.host) and some.host gets
all the headers in the request.


On 5 August 2015 at 09:57, Claus Ibsen  wrote:

> Hi
>
> Yeah the http filter was filtering only for the producer. We should do
> it for the consumer as well, so camel-jetty etc do not include Camel
> headers in the http responses by default.
>
> There is plenty of options already we should not add more.
>
> I logged a ticket to let the http filter strategy filter those for
> both the producer and consumer
> https://issues.apache.org/jira/browse/CAMEL-9052
>
>
>
> On Wed, Aug 5, 2015 at 9:51 AM, James Green 
> wrote:
> > We recently had cause to tcpdump an http request from the http4 component
> > to a web site. We were most surprised to find a load of exchange headers
> > listed as HTTP "header: value" pairs.
> >
> > A quick search on-line brings up a couple of Red Hat / Fuse documents
> > saying that headers named 'Camel...' are not transmitted onwards, others
> > are.
> >
> > Two concerns:
> >
> > 1. We see no documentation concerning this on the http4 component's page
> > 2. There may be a great many applications deployed unintentionally
> > transmitting internal headers to third parties potentially in breach of
> > policy or legal restrictions without human knowledge
> >
> > I suggest adding a new option, CopyAllHeadersToHttpHeaders, defaulted to
> > false. This would allow developers to "correct" their applications
> without
> > code changes, and those taking advantage of this facility can switch it
> on
> > explicitly.
> >
> > This isn't a Camel security vulnerability but I very much expect it to be
> > leading to information leakage "out there". It is certainly not a
> behaviour
> > we expected to see given the documentation. There may be other components
> > that require similar attention.
> >
> > Thoughts?
> >
> > James
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2nd edition: http://www.manning.com/ibsen2
>

[security] http4 endpoint headers "leaking"

[James Green]

We recently had cause to tcpdump an http request from the http4 component
to a web site. We were most surprised to find a load of exchange headers
listed as HTTP "header: value" pairs.

A quick search on-line brings up a couple of Red Hat / Fuse documents
saying that headers named 'Camel...' are not transmitted onwards, others
are.

Two concerns:

1. We see no documentation concerning this on the http4 component's page
2. There may be a great many applications deployed unintentionally
transmitting internal headers to third parties potentially in breach of
policy or legal restrictions without human knowledge

I suggest adding a new option, CopyAllHeadersToHttpHeaders, defaulted to
false. This would allow developers to "correct" their applications without
code changes, and those taking advantage of this facility can switch it on
explicitly.

This isn't a Camel security vulnerability but I very much expect it to be
leading to information leakage "out there". It is certainly not a behaviour
we expected to see given the documentation. There may be other components
that require similar attention.

Thoughts?

James

Stuck route with file2 - suggestion for defaults change

[James Green]

We have an application that uses http://camel.apache.org/file2.html to scan
for files as input to a route. Nothing special about it and until last week
was working just fine.

Then we noticed the route was handling nothing from the file component.
When we checked there was in excess of 500,000 files pending. Nothing was
showing in our logs.

We reconfigured the endpoint URI to have a maxMessagesPerPoll of 1,000 from
the default. The route sprang to life.

Our conclusion was to suggest here that perhaps a sensible default should
be applied to this in future versions rather than 0 (infinite). Quite what
this might be is arguable of course, but 0 is quite capable of shutting
down an application in our experience.

Thanks,

James

Re: ElasticSearch- Best practice for indexing entire JSON Files?

[James Green]

If widgets.json is effectively a database of products and each product
should existing as a document in an elasticsearch index you will need to
split it before sending it onwards. You could use Camel, but also consider
logstash.

If widgets.json is one of many source files representing products that you
want to be able to search and find, you could simply forward it onwards.
Again consider logstash  in case it offers an advantage.

Ultimately you need to decide how you want it stored the other end.


On 14 May 2015 at 20:52, erd  wrote:

> Hello,
>
> What is the best way to index an entire JSON file? Say i have a file called
> "widgets.json" with structure
>
> {"widgets": {
> {"name":"foo","properties":{"status":"green", "type": "fooWidget"}},
> {"name": "ayy", "properties":{"status":"lmao"}}
> }
> }
>
> I am currently using a splitter, but the actual file is quite large, and
> makes thousands of messages to send to the server. Is there a way where I
> could just send the file or string, and ES will use the default analyzer to
> split it?
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/ElasticSearch-Best-practice-for-indexing-entire-JSON-Files-tp5767123.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>

DLQ, cause:null

[James Green]

We have a camel route consuming from ActiveMQ and occasionally get a DLQ
entry without anything logged through our deadLetterChannel.

The only thing we have to go on is a dlqFailureCause header which says:

java.lang.Throwable: Exceeded redelivery policy limit:RedeliveryPolicy
{destination = null, collisionAvoidanceFactor = 0.15, maximumRedeliveries =
6, maximumRedeliveryDelay = -1, initialRedeliveryDelay = 1000,
useCollisionAvoidance = false, useExponentialBackOff = false,
backOffMultiplier = 5.0, redeliveryDelay = 1000}, cause:null

The suggestion internally is that because the deadLetterChannel goes to a
route that logs the exception on the Exchange, yet we have nothing logged,
the camel route was in fact not involved thus perhaps it's an ActiveMQ
problem.

ActiveMQ, for it's part, logged nothing either.

Any suggestions at all?

Thanks,

James

Re: Sending email - possible bug?

[James Green]

To be honest the documentation at
http://camel.apache.org/dead-letter-channel.html is a little contradictory
and could use some touch-ups:

1. Under "Redelivery default values" the service is turned off and has 0
maximumRedeliveries, yet later it says "By default Camel will try to
process the exchange 1 + 5 times."

2. There is no example of how one might log the Exception + stacktrace that
caused the DLC to be invoked. This must be a common requirement?

On 13 April 2015 at 16:19, Claus Ibsen  wrote:

> The DLC do not magically include stacktraces. It sends the message
> as-is. If you want to include stacktraces / exception message or
> whatever you need to enrich the message before sending to the DLQ to
> include that.
>
> On Mon, Apr 13, 2015 at 5:12 PM, James Green 
> wrote:
> > An update: the email is sent just fine (I received it eventually). The
> > trouble is later on - the deadLetterChannel does not appear to log a
> stack
> > trace.
> >
> > An engineer here is currently scratching his head over this one - unable
> to
> > see what the route cause is. Any ideas?
> >
> > On 10 April 2015 at 17:32, Reji Mathews  wrote:
> >
> >> Can u make your Q a little more clear. I assume u got this exception as
> >> there is  no smtp server on ur local host at Port 25.
> >> Obviously it will be caught by ur error handler and since u have used a
> >> dead letter handler , after specified retry attempts it will get
> persisted
> >> to the dead letter uri viz in ur case a jms queue
> >>
> >> What's the issue exactly.?
> >>
> >> If you are searching for the stack trace it won't be there as its
> caught by
> >> ur error handler and message managed .
> >>
> >> If u remove ur handlers , u will get the connection refused exception
> and
> >> stack traces.
> >>
> >> Cheers
> >> Reji
> >> On 10 Apr 2015 16:51, "James Green"  wrote:
> >>
> >> > We just saw this in the log:
> >> >
> >> > 10/Apr/2015 10:56:04,683- DefaultJavaMailSender: Connecting to
> >> localhost:25
> >> > 10/Apr/2015 10:56:04,701- DefaultJavaMailSender: Sending MimMessage:
> >> > javax.mail.internet.MimeMessage@385158f4 using host: localhost
> >> > 10/Apr/2015 10:56:04,715- DeadLetterChannel: Failed delivery for
> >> > (MessageId: ID-ngw-audit-01-39856-1428654916549-0-69 on ExchangeId:
> >> > ID-ngw-audit-01-39
> >> > 856-1428654916549-0-66). On delivery attempt: 0 caught:
> >> > java.lang.NullPointerException
> >> >
> >> > The endpoint concerned is smtp://localhost and we're sending a
> >> MimeMessage
> >> > down it. Sadly there's nothing more to go on - should we not expect a
> >> stack
> >> > trace somewhere?
> >> >
> >> > Error handler:
> >> >
> >> >
> >> >
> >>
> errorHandler(deadLetterChannel("activemq:queue:DeliveryReportByEmail.DQL").useOriginalMessage());
> >> >
> >> > The logStackTrace should be on by default looking at the camel
> sources?
> >> >
> >> > Thanks,
> >> >
> >> > James
> >> >
> >>
>
>
>
> --
> Claus Ibsen
> -
> Red Hat, Inc.
> Email: cib...@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
> hawtio: http://hawt.io/
> fabric8: http://fabric8.io/
>

Re: Sending email - possible bug?

[James Green]

s/route/root/ that's habit creaking in for you.

On 13 April 2015 at 16:12, James Green  wrote:

> An update: the email is sent just fine (I received it eventually). The
> trouble is later on - the deadLetterChannel does not appear to log a stack
> trace.
>
> An engineer here is currently scratching his head over this one - unable
> to see what the route cause is. Any ideas?
>
> On 10 April 2015 at 17:32, Reji Mathews  wrote:
>
>> Can u make your Q a little more clear. I assume u got this exception as
>> there is  no smtp server on ur local host at Port 25.
>> Obviously it will be caught by ur error handler and since u have used a
>> dead letter handler , after specified retry attempts it will get persisted
>> to the dead letter uri viz in ur case a jms queue
>>
>> What's the issue exactly.?
>>
>> If you are searching for the stack trace it won't be there as its caught
>> by
>> ur error handler and message managed .
>>
>> If u remove ur handlers , u will get the connection refused exception and
>> stack traces.
>>
>> Cheers
>> Reji
>> On 10 Apr 2015 16:51, "James Green"  wrote:
>>
>> > We just saw this in the log:
>> >
>> > 10/Apr/2015 10:56:04,683- DefaultJavaMailSender: Connecting to
>> localhost:25
>> > 10/Apr/2015 10:56:04,701- DefaultJavaMailSender: Sending MimMessage:
>> > javax.mail.internet.MimeMessage@385158f4 using host: localhost
>> > 10/Apr/2015 10:56:04,715- DeadLetterChannel: Failed delivery for
>> > (MessageId: ID-ngw-audit-01-39856-1428654916549-0-69 on ExchangeId:
>> > ID-ngw-audit-01-39
>> > 856-1428654916549-0-66). On delivery attempt: 0 caught:
>> > java.lang.NullPointerException
>> >
>> > The endpoint concerned is smtp://localhost and we're sending a
>> MimeMessage
>> > down it. Sadly there's nothing more to go on - should we not expect a
>> stack
>> > trace somewhere?
>> >
>> > Error handler:
>> >
>> >
>> >
>> errorHandler(deadLetterChannel("activemq:queue:DeliveryReportByEmail.DQL").useOriginalMessage());
>> >
>> > The logStackTrace should be on by default looking at the camel sources?
>> >
>> > Thanks,
>> >
>> > James
>> >
>>
>
>

Re: Sending email - possible bug?

[James Green]

An update: the email is sent just fine (I received it eventually). The
trouble is later on - the deadLetterChannel does not appear to log a stack
trace.

An engineer here is currently scratching his head over this one - unable to
see what the route cause is. Any ideas?

On 10 April 2015 at 17:32, Reji Mathews  wrote:

> Can u make your Q a little more clear. I assume u got this exception as
> there is  no smtp server on ur local host at Port 25.
> Obviously it will be caught by ur error handler and since u have used a
> dead letter handler , after specified retry attempts it will get persisted
> to the dead letter uri viz in ur case a jms queue
>
> What's the issue exactly.?
>
> If you are searching for the stack trace it won't be there as its caught by
> ur error handler and message managed .
>
> If u remove ur handlers , u will get the connection refused exception and
> stack traces.
>
> Cheers
> Reji
> On 10 Apr 2015 16:51, "James Green"  wrote:
>
> > We just saw this in the log:
> >
> > 10/Apr/2015 10:56:04,683- DefaultJavaMailSender: Connecting to
> localhost:25
> > 10/Apr/2015 10:56:04,701- DefaultJavaMailSender: Sending MimMessage:
> > javax.mail.internet.MimeMessage@385158f4 using host: localhost
> > 10/Apr/2015 10:56:04,715- DeadLetterChannel: Failed delivery for
> > (MessageId: ID-ngw-audit-01-39856-1428654916549-0-69 on ExchangeId:
> > ID-ngw-audit-01-39
> > 856-1428654916549-0-66). On delivery attempt: 0 caught:
> > java.lang.NullPointerException
> >
> > The endpoint concerned is smtp://localhost and we're sending a
> MimeMessage
> > down it. Sadly there's nothing more to go on - should we not expect a
> stack
> > trace somewhere?
> >
> > Error handler:
> >
> >
> >
> errorHandler(deadLetterChannel("activemq:queue:DeliveryReportByEmail.DQL").useOriginalMessage());
> >
> > The logStackTrace should be on by default looking at the camel sources?
> >
> > Thanks,
> >
> > James
> >
>

Are transactions useful in these use-cases?

[James Green]

We have a number of routes:

from(HTTP POST).to(JMS)
from(JMS).to(SOAP Endpoint).to(JMS)
from(JMS).to(MongoDB)
from(MongoDB).to(JMS)

Hugely simplified and these are across various JAR services. Are
transactions actually useful in the above?

Actually understanding the behaviour of code routes is one challenge,
understanding with transactional management adds some cognitive overhead
which may not be necessary. I'm unsure given the use-cases we have whether
it is usual to drop them in favour of client-acking of JMS messages for
instance.

Thanks,

James

Re: can i get discount for camel in action book

[James Green]

Ah ServiceMix. Another on my list of "just why does this software exist?" I
guess I need to read a paragraph entitled "Practical ServiceMix" to know...

On 6 March 2015 at 06:42, Cristiano Costantini <
cristiano.costant...@gmail.com> wrote:

> I cannot avoid to say too that reading the book of Claus has been extremely
> revealing for me; I work a lot with ServiceMix, I started to really
> understand it only after reading Camel in Action.
>
> Well... thank you Claus!
>
>
> Il giorno ven 6 mar 2015 alle ore 07:13 Claus Ibsen  >
> ha scritto:
>
> > On Fri, Mar 6, 2015 at 3:21 AM, chaituu  wrote:
> > > camel40 code is working.which option do i need to use  if i need
> physical
> > > book.howlong will it take to get the shipment to india?
> > >
> > >
> > > $49.99  pBook + eBook (includes PDF, ePub, and Kindle)
> > > $39.99  eBook only (includes PDF, ePub, and Kindle)
> > >
> >
> > The physical book is what they call pBook.
> > The electronic book (such as PDF etc) is the eBook.
> >
> > If you buy the physical book you always get the eBook also.
> >
> > So above the physical book is the first.
> >
> > > Thanks
> > > chaitanya
> > >
> > >
> > >
> > > --
> > > View this message in context: http://camel.465427.n5.nabble.
> > com/can-i-get-discount-for-camel-in-action-book-tp5763608p5763708.html
> > > Sent from the Camel - Users mailing list archive at Nabble.com.
> >
> >
> >
> > --
> > Claus Ibsen
> > -
> > Red Hat, Inc.
> > Email: cib...@redhat.com
> > Twitter: davsclaus
> > Blog: http://davsclaus.com
> > Author of Camel in Action: http://www.manning.com/ibsen
> > hawtio: http://hawt.io/
> > fabric8 : http://fabric8.io/
> >
>

Re: can i get discount for camel in action book

[James Green]

The Camel in Action is worth every penny.

A light bulb came on in my mind when reading the early chapter on how
Spring Application Contexts get wired together - I was pretty early in my
Spring experience back then. The rest of the book is about Camel itself and
really the only thing it lacks is a "tips and tricks" for real-world use
when doing things like error handlers across multiple routes.

In our case we read from a queue and send over the Internet. Transactional
error handling is a bit of a disaster in this use-case as the original
message does not get taken off the queue so one message creates a message
backlog. Explaining how to use the dead letter queue as the error handler
and shift the message to a temporary location is thus well worth
understanding but I guess one has to experience such scenarios to
appreciate the behaviours of your technology stacks.

Still, book well worth it.


On 5 March 2015 at 06:31, Claus Ibsen  wrote:

> Hi
>
> Sometimes Manning has discount deals, where you can get it cheaper.
> But then you would need to order it directly from them.
>
> But I was given a discount code many years ago. I wonder if it still
> works: camel40. That gives you 40%.
>
> If you work for an employeer that uses Apache Camel. Then maybe that
> employers is interred in that its staff is more productive, and
> therefore investing about $20 on a single eBook about Camel is well
> spent.
>
> We do frankly see too many people here in the mailing list who can be
> much more productive if they just purchased one of the 4 Camel books
> and spend some hours reading. An altternative for a book would be to
> read parts of the Camel website (I agree its not well structured, and
> a book is much much better reading experience), or sometimes better
> some of the Camel tutorials / blogs / articles we have at:
> http://camel.apache.org/articles
>
>
>
> On Thu, Mar 5, 2015 at 7:17 AM, Jan Matèrne (jhm) 
> wrote:
> > You could order an ebook, if the shipping is your main cost factor.
> > http://www.manning.com/ibsen/
> > "$39.99 eBook only (includes PDF, ePub, and Kindle)"
> >
> >
> > Jan
> >
> >
> >> -Ursprüngliche Nachricht-
> >> Von: chaituu [mailto:yarlagadd...@gmail.com]
> >> Gesendet: Donnerstag, 5. März 2015 03:37
> >> An: users@camel.apache.org
> >> Betreff: can i get discount for camel in action book
> >>
> >> hi,
> >>
> >> I reside in india.but camel in action not published in india so it
> >> comes with huge price.can i get some discount on this book?if yes where
> >> can i get it?
> >>
> >>
> >>
> >> --
> >> View this message in context: http://camel.465427.n5.nabble.com/can-i-
> >> get-discount-for-camel-in-action-book-tp5763608.html
> >> Sent from the Camel - Users mailing list archive at Nabble.com.
> >
>
>
>
> --
> Claus Ibsen
> -
> Red Hat, Inc.
> Email: cib...@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
> hawtio: http://hawt.io/
> fabric8: http://fabric8.io/
>

Re: Test body mutation

[James Green]

Or am I being silly - is it really as simple as asserting that the endpoint
got the message,then doing simple JUnit assertions on the body sent in to
check it is now as expected?

(Brain somewhat stuck in asynchronous routes at the moment.)

On 2 March 2015 at 10:27, James Green  wrote:

> I need to check that an object is mutated by a route properly.
>
> The testing.html page does not show this - only that the message passed
> through routes as expected. I'm downloading the camel sources now - is
> there a good test class that demonstrates this?
>
> Thanks,
>
> James
>
>

Test body mutation

[James Green]

I need to check that an object is mutated by a route properly.

The testing.html page does not show this - only that the message passed
through routes as expected. I'm downloading the camel sources now - is
there a good test class that demonstrates this?

Thanks,

James

Re: How to trap most specific exceptions?

[James Green]

Doesn't it have something to do with the order in which onException is
given in the DSL? I.e. reverse the lines of code and it should work? I
could be wrong...

On 25 February 2015 at 14:29, Claus Ibsen  wrote:

> Hi
>
> If you have a copy of Camel in Action its explained in much detail in
> chapter 5.
> You may find some information on the Camel doc website as well, but
> not as deep as in the book.
>
> On Mon, Feb 23, 2015 at 5:15 PM, toomanyedwards
>  wrote:
> > Thanks for the pointer.  Can you give some insight into why Camel matches
> > from the bottom up of the exception chain rather from the top?  This
> appears
> > to be an explicit design decision and it'd be useful to know the
> rationale
> > behind it to help leverage exception trapping more effectively.
> >
> >
> >
> > --
> > View this message in context:
> http://camel.465427.n5.nabble.com/How-to-trap-most-specific-exceptions-tp5762994p5763086.html
> > Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
>
> --
> Claus Ibsen
> -
> Red Hat, Inc.
> Email: cib...@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
> hawtio: http://hawt.io/
> fabric8: http://fabric8.io/
>

http4 - socket timeout configured per-message?

[James Green]

I have a route that sends to a uri provided in the message. Also in the
message is the socket timeout value.

The first part is easy, but I can't see a way of specifying the socket
timeout at runtime.

Any ideas?

Thanks,

James

http4.html Possible error

[James Green]

Halfway down the page under "Configuring the URI to call" the example is
given:

from("direct:start")
  .setHeader(Exchange.HTTP_URI, constant("http://newhost";))
  .to("http4://oldhost");

Under it states:

"*Where Constants is the class,
org.apache.camel.component.http4.Constants."*

Is this correct as the header accepts String and usually constant() is
pretty well used elsewhere?

Thanks,

James

java-dsl.html error

[James Green]

At the bottom it talks about intercept() but doesn't use it. Confusing at
least!

And the link to InterceptorProcessor is a 404.

James

Re: request-reply with ActiveMQ and Camel

[James Green]

I'm guessing you need the reply to include a reference to one or more
"files" that can be picked up independently? I can't see a multi-message
reply working. Prepared to be corrected of course.

On 12 February 2015 at 16:58, Marco Crivellaro 
wrote:

> Hi,
> I have managed to get a simple request-reply working with ActiveMQ and
> Camel/NMS.
> - The Producer is an NMS client which creates a temporary queue and then
> sends the request to a queue (queue.request) setting the replyTo header to
> the temporary queue.
> - The Consumer is a Java component which uses Camel and InOut pattern which
> consumes queue.request
>
> This setup works fine but I wanted to extend it so that if the response is
> too big this is split into several chunks and pushed to the temporary
> queue.
> So in effect for a request there will be one or more replies.
> I did not manage to get this working, no matter what I do the consumer
> always receive the last message pushed to the temporary queue.
>
> The java consumer is using a ProducerTemplate to send all the responses bar
> the last one which is sent as part of the InOut exchange.
>
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/request-reply-with-ActiveMQ-and-Camel-tp5762666.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>

Cross RouteBuilder exceptions

[James Green]

Our application contains a few RouteBuilders. I understand I can use
onException across these but only by having them chained together through
OO inheritance.

Is there an alternative means?

Ideally the RouteBuilder that constructs our public interface ought to be
catching and mapping exceptions thrown by nested RouteBuilders without
"knowing" how they were wired together. My first thought was to use
onException and perhaps throw another new exception but I've no reason to
believe this will work.

I appear limited to using the DefaultErrorHandler otherwise.

James

Re: Route with JMS down

[James Green]

org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1522)
~[ngw-smtp-receiver.jar:?]
at
org.apache.activemq.ActiveMQConnection.createSession(ActiveMQConnection.java:328)
~[ngw-smtp-receiver.jar:?]
at
org.springframework.jms.support.JmsAccessor.createSession(JmsAccessor.java:196)
~[ngw-smtp-receiver.jar:?]
at
org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:457)
~[ngw-smtp-receiver.jar:?]
... 22 more
Caused by: org.apache.activemq.transport.InactivityIOException: Cannot
send, channel has already failed: tcp://10.0.0.97:61616
at
org.apache.activemq.transport.AbstractInactivityMonitor.doOnewaySend(AbstractInactivityMonitor.java:297)
~[ngw-smtp-receiver.jar:?]
at
org.apache.activemq.transport.AbstractInactivityMonitor.oneway(AbstractInactivityMonitor.java:286)
~[ngw-smtp-receiver.jar:?]
at
org.apache.activemq.transport.TransportFilter.oneway(TransportFilter.java:85)
~[ngw-smtp-receiver.jar:?]
at
org.apache.activemq.transport.WireFormatNegotiator.oneway(WireFormatNegotiator.java:104)
~[ngw-smtp-receiver.jar:?]
at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:68)
~[ngw-smtp-receiver.jar:?]
at
org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:81)
~[ngw-smtp-receiver.jar:?]
at
org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:86)
~[ngw-smtp-receiver.jar:?]
at
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1406)
~[ngw-smtp-receiver.jar:?]
at
org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1522)
~[ngw-smtp-receiver.jar:?]
at
org.apache.activemq.ActiveMQConnection.createSession(ActiveMQConnection.java:328)
~[ngw-smtp-receiver.jar:?]
at
org.springframework.jms.support.JmsAccessor.createSession(JmsAccessor.java:196)
~[ngw-smtp-receiver.jar:?]
at
org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:457)
~[ngw-smtp-receiver.jar:?]
... 22 more

09/Feb/2015 15:58:40,168- Pipeline: Message exchange has failed: so
breaking out of pipeline for exchange: Exchange[Message: [Body is instance
of org.apache.camel.StreamCache]] Exception:
org.springframework.jms.UncategorizedJmsException: Uncategorized exception
occured during JMS processing; nested exception is javax.jms.JMSException:
Cannot send, channel has already failed: tcp://10.0.0.97:61616
09/Feb/2015 15:58:40,167- DefaultErrorHandler: Failed delivery for
(MessageId: ID-ngw-smtp-01-50108-1423497456378-0-7 on ExchangeId:
ID-ngw-smtp-01-50108-1423497456378-0-11). Exhausted after delivery attempt:
1 caught: org.springframework.jms.UncategorizedJmsException: Uncategorized
exception occured during JMS processing; nested exception is
javax.jms.JMSException: Cannot send, channel has already failed: tcp://
10.0.0.97:61616

My route looks like this:

rest("/from-smtp/")
.post()
.type(EmailedSmsRequest.class)
.to("direct:fromSmtp");

Eventually this turns into:
.setExchangePattern(ExchangePattern.InOnly)
.to("direct:router")
.setExchangePattern(ExchangePattern.InOut)

Where the direct:router route sends the JMS message.

The remaining route sets the body to the response I want the http client to
receive.

No blindingly obvious faults can you see?

Thanks,

James


On 9 February 2015 at 15:39, Claus Ibsen  wrote:

> Hi
>
> If you use ActiveMQ you may need to turn off asyncSend
> http://activemq.apache.org/async-sends.html
>
> On Mon, Feb 9, 2015 at 4:20 PM, James Green 
> wrote:
> > We have a route from a REST endpoint into a JMS (InOnly) endpoint.
> >
> > We took down the broker to see what would happen. Turns out HTTP clients
> > hang waiting for a response (for several minutes) while a load of stack
> > traces are logged by Camel:
> >
> > 09/Feb/2015 15:07:52,677- DefaultErrorHandler: Failed delivery for
> > (MessageId: ID-ngw-smtp-01-56823-1423494454408-0-1 on ExchangeId:
> > ID-ngw-smtp-01-56823-1423494454408-0-5). On delivery attempt: 0 caught:
> > org.springframework.jms.UncategorizedJmsException: Uncategorized
> exception
> > occured during JMS processing; nested exception is
> javax.jms.JMSException:
> > Cannot send, channel has already failed: tcp://10.0.0.97:61616
> > 09/Feb/2015 15:07:52,677- DefaultErrorHandler: Failed delivery for
> > (MessageId: ID-ngw-smtp-01-56823-1423494454408-0-1 on ExchangeId:
> > ID-ngw-smtp-01-56823-1423494454408-0-4). On delivery attempt: 0 caught:
> > org.springframework.jms.UncategorizedJmsException: Uncategorized
> exception
> > occured during JMS processing; nested exception is
> javax.jms.JMSException:
> > Cannot send, channel has already failed: tcp://10.0.0.97:61616
> > 09/Feb/2015 15:07:52,684- DefaultErrorHandler:

Route with JMS down

[James Green]

We have a route from a REST endpoint into a JMS (InOnly) endpoint.

We took down the broker to see what would happen. Turns out HTTP clients
hang waiting for a response (for several minutes) while a load of stack
traces are logged by Camel:

09/Feb/2015 15:07:52,677- DefaultErrorHandler: Failed delivery for
(MessageId: ID-ngw-smtp-01-56823-1423494454408-0-1 on ExchangeId:
ID-ngw-smtp-01-56823-1423494454408-0-5). On delivery attempt: 0 caught:
org.springframework.jms.UncategorizedJmsException: Uncategorized exception
occured during JMS processing; nested exception is javax.jms.JMSException:
Cannot send, channel has already failed: tcp://10.0.0.97:61616
09/Feb/2015 15:07:52,677- DefaultErrorHandler: Failed delivery for
(MessageId: ID-ngw-smtp-01-56823-1423494454408-0-1 on ExchangeId:
ID-ngw-smtp-01-56823-1423494454408-0-4). On delivery attempt: 0 caught:
org.springframework.jms.UncategorizedJmsException: Uncategorized exception
occured during JMS processing; nested exception is javax.jms.JMSException:
Cannot send, channel has already failed: tcp://10.0.0.97:61616
09/Feb/2015 15:07:52,684- DefaultErrorHandler: Failed delivery for
(MessageId: ID-ngw-smtp-01-56823-1423494454408-0-1 on ExchangeId:
ID-ngw-smtp-01-56823-1423494454408-0-4). Exhausted after delivery attempt:
1 caught: org.springframework.jms.UncategorizedJmsException: Uncategorized
exception occured during JMS processing; nested exception is
javax.jms.JMSException: Cannot send, channel has already failed: tcp://
10.0.0.97:61616

09/Feb/2015 15:07:52,689- TransactionErrorHandler: Transaction rollback
(0x5d16d955) redelivered(unknown) for (MessageId:
ID-ngw-smtp-01-56823-14234944
54408-0-1 on ExchangeId: ID-ngw-smtp-01-56823-1423494454408-0-5) caught:
org.springframework.jms.UncategorizedJmsException: Uncategorized exception
occ
ured during JMS processing; nested exception is javax.jms.JMSException:
Cannot send, channel has already failed: tcp://10.0.0.97:61616
09/Feb/2015 15:07:52,689- MulticastProcessor: Message exchange has failed:
Sequential processing failed for number 0 for exchange: Exchange[Message: [B
ody is instance of org.apache.camel.StreamCache]] Exception:
org.apache.camel.RuntimeCamelException:
org.springframework.jms.UncategorizedJmsException:
 Uncategorized exception occured during JMS processing; nested exception is
javax.jms.JMSException: Cannot send, channel has already failed: tcp://10.0
.0.97:61616
09/Feb/2015 15:07:52,689- MulticastProcessor: Done sequential processing 1
exchanges
09/Feb/2015 15:07:52,689- Pipeline: Message exchange has failed: so
breaking out of pipeline for exchange: Exchange[Message: [Body is instance
of org.a
pache.camel.StreamCache]] Exception:
org.apache.camel.RuntimeCamelException:
org.springframework.jms.UncategorizedJmsException: Uncategorized exception
 occured during JMS processing; nested exception is javax.jms.JMSException:
Cannot send, channel has already failed: tcp://10.0.0.97:61616
09/Feb/2015 15:07:52,689- Pipeline: Message exchange has failed: so
breaking out of pipeline for exchange: Exchange[Message: [Body is instance
of org.a
pache.camel.StreamCache]] Exception:
org.apache.camel.RuntimeCamelException:
org.springframework.jms.UncategorizedJmsException: Uncategorized exception
 occured during JMS processing; nested exception is javax.jms.JMSException:
Cannot send, channel has already failed: tcp://10.0.0.97:61616
09/Feb/2015 15:07:52,690- TransactionErrorHandler: Transaction rollback
(0x5d16d955) redelivered(unknown) for (MessageId:
ID-ngw-smtp-01-56823-1423494454408-0-1 on ExchangeId:
ID-ngw-smtp-01-56823-1423494454408-0-2) caught:
org.springframework.jms.UncategorizedJmsException: Uncategorized exception
occured during JMS processing; nested exception is javax.jms.JMSException:
Cannot send, channel has already failed: tcp://10.0.0.97:61616

We have plugged on some onException clauses but none appear to execute:

onException(javax.jms.JMSException.class, Exception.class,
RuntimeException.class)
.log(LoggingLevel.ERROR, logger, "Exception!")
.handled(true)
.setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500))
.setBody().constant("Something bad happened");

Can someone advice on what I'm missing? What we want is to respond with a
500 HTTP code but catching JMSException appears not be working.

Thanks,

James

MongoDB, insert, and _id

[James Green]

I have a route:

from("direct:input")
.wiretap("direct:sendToTopic")
.to("mongodb:deliveredEventMongoDB?database=ngw&collection=deliveredevents&operation=insert");

direct:input provably receives a brand new BasicDBObject filled with a
document and lacks a _id.

direct:sendToTopic provably receives the same BasicDBObject except now it
has an _id field.

Is the mongodb insert operation intended to mutate the input data? That is
the only thing I can think is happening.

[ Another case perhaps where multicast with a cloned Message is actually
required... ]

James

Re: REST InOut with JMS InOnly

[James Green]

That's where I ended up too. I was minded to make onPrepare a fragment for
embedding into wiretap too however one might imagine that someone using
wiretap does not want to modify the exchange based on individual onward
paths.

So in our case multicast() may be more appropriate with stopOnException()
to handle a custom response should the JMS route in the middle fail.

On 5 February 2015 at 09:59, Morgan Hautman 
wrote:

> James,
>
> It seems to be documented here: http://camel.apache.org/multicast.html
> (end of page)
>
> And the class they use:
> https://github.com/apache/camel/blob/master/camel-core/
> src/test/java/org/apache/camel/processor/AnimalDeepClonePrepare.java
>
> Regards,
> Morgan
>
>
> On 5/02/2015 10:38, James Green wrote:
>
>> Yes this is the simple bit.
>>
>> The not so simple bit is appreciating what happens under the hood.
>> wiretap,
>> quite rightly, sends the same object references down each path. If one of
>> those paths mutates the Exchange's Message, the other routes will spot the
>> change and the developer gets a rude surprise.
>>
>> Under these circumstances I presume the onPrepare to clone the Exchange is
>> required? It's not overly well documented on the wiretap page.
>>
>> James
>>
>>
>> On 4 February 2015 at 06:11, Claus Ibsen  wrote:
>>
>>  On Tue, Feb 3, 2015 at 2:30 PM, James Green 
>>> wrote:
>>>
>>>> Nope :)
>>>>
>>>> rest("/from-smtp/")
>>>>  .post()
>>>>  .type(EmailedSmsRequest.class)
>>>>  .to("direct:fromSmtp");
>>>>
>>>> direct:fromSmtp routes onward to direct:router. direct:router sends it
>>>> onwards to jms:queue:foo asynchronously. The route that reads
>>>> from("direct:router") is intended for be fully re-usable and has
>>>> multiple
>>>> public interfaces sending messages into it but is not expected to reply
>>>>
>>> at
>>>
>>>> all (except for raising exceptions of course).
>>>>
>>>> Beyond direct:fromSmtp routing to direct:router, I want to set the OUT
>>>>
>>> part
>>>
>>>> of the exchange so that the rest component knows what to send back to
>>>> the
>>>> http client.
>>>>
>>>>  Then do additional routing after, eg to set the OUT part you want
>>>
>>>
>>>
>>>  I suspect I can wiretap() to split the messaging across two routes - one
>>>>
>>> to
>>>
>>>> direct:router and the other to processing that provides the OUT part of
>>>>
>>> the
>>>
>>>> exchange however it doesn't feel entirely natural hence I didn't think
>>>> of
>>>> it myself.
>>>>
>>>> [ I have not yet tried wiretap in the code I'm asking the question
>>>> about,
>>>> will do shortly ]
>>>>
>>>>
>>>>
>>>> On 3 February 2015 at 13:20, Morgan Hautman 
>>>> wrote:
>>>>
>>>>  Yes I understand we can encounter a timeout when we don't respond to
>>>>> http/rest because it's synchronous.
>>>>>
>>>>> But I think what James means is :
>>>>>
>>>>> 1st route:
>>>>> from(cxf:...).to(activemq:bar)
>>>>>
>>>>> 2nd route
>>>>> from(activemq: bar).to(processing)
>>>>>
>>>>> The first route sends a message to the second route through activemq
>>>>> and
>>>>> waits for the second route to process the message and the second route
>>>>> respond to the first route who will answer to the client what "route2"
>>>>> responded. (timeout or not)
>>>>>
>>>>> Hope It's comprehensive.
>>>>>
>>>>> PS: I'm not in James team, I just try to help and understand a problem
>>>>> I
>>>>> had myself some months ago but didn't look further.
>>>>>
>>>>>
>>>>> On 3/02/2015 13:54, Claus Ibsen wrote:
>>>>>
>>>>>  On Tue, Feb 3, 2015 at 1:27 PM, Morgan Hautman <
>>>>>>
>>>>> morgan.haut...@gmail.com>
>>>
>>>> wrote:
>>>>>>
>>>>>>  Claus,
>>>>>>>
>>>>>>> Is their any 

Re: REST InOut with JMS InOnly

[James Green]

Yes this is the simple bit.

The not so simple bit is appreciating what happens under the hood. wiretap,
quite rightly, sends the same object references down each path. If one of
those paths mutates the Exchange's Message, the other routes will spot the
change and the developer gets a rude surprise.

Under these circumstances I presume the onPrepare to clone the Exchange is
required? It's not overly well documented on the wiretap page.

James


On 4 February 2015 at 06:11, Claus Ibsen  wrote:

> On Tue, Feb 3, 2015 at 2:30 PM, James Green 
> wrote:
> > Nope :)
> >
> > rest("/from-smtp/")
> > .post()
> > .type(EmailedSmsRequest.class)
> > .to("direct:fromSmtp");
> >
> > direct:fromSmtp routes onward to direct:router. direct:router sends it
> > onwards to jms:queue:foo asynchronously. The route that reads
> > from("direct:router") is intended for be fully re-usable and has multiple
> > public interfaces sending messages into it but is not expected to reply
> at
> > all (except for raising exceptions of course).
> >
> > Beyond direct:fromSmtp routing to direct:router, I want to set the OUT
> part
> > of the exchange so that the rest component knows what to send back to the
> > http client.
> >
>
> Then do additional routing after, eg to set the OUT part you want
>
>
>
> > I suspect I can wiretap() to split the messaging across two routes - one
> to
> > direct:router and the other to processing that provides the OUT part of
> the
> > exchange however it doesn't feel entirely natural hence I didn't think of
> > it myself.
> >
> > [ I have not yet tried wiretap in the code I'm asking the question about,
> > will do shortly ]
> >
> >
> >
> > On 3 February 2015 at 13:20, Morgan Hautman 
> > wrote:
> >
> >> Yes I understand we can encounter a timeout when we don't respond to
> >> http/rest because it's synchronous.
> >>
> >> But I think what James means is :
> >>
> >> 1st route:
> >> from(cxf:...).to(activemq:bar)
> >>
> >> 2nd route
> >> from(activemq: bar).to(processing)
> >>
> >> The first route sends a message to the second route through activemq and
> >> waits for the second route to process the message and the second route
> >> respond to the first route who will answer to the client what "route2"
> >> responded. (timeout or not)
> >>
> >> Hope It's comprehensive.
> >>
> >> PS: I'm not in James team, I just try to help and understand a problem I
> >> had myself some months ago but didn't look further.
> >>
> >>
> >> On 3/02/2015 13:54, Claus Ibsen wrote:
> >>
> >>> On Tue, Feb 3, 2015 at 1:27 PM, Morgan Hautman <
> morgan.haut...@gmail.com>
> >>> wrote:
> >>>
> >>>> Claus,
> >>>>
> >>>> Is their any way a queue (using activemq) could respond , like a
> >>>> request-reply mechanism?
> >>>>
> >>>> http://camel.apache.org/request-reply.html
> >>>>
> >>>>  Not sure I follow. Camel can do InOnly and InOut over JMS. So yeah
> >>> both is possible.
> >>>
> >>> Just mind that a client like HTTP / REST is synchronous in that sense
> >>> the client awaits a response, so whether that is just a OK or to
> >>> respond with some new data, then that needs to happen, and occurs when
> >>> the exchange is done being routed, and the control is back at the
> >>> consumer.
> >>>
> >>>  On 3/02/2015 13:14, Claus Ibsen wrote:
> >>>>
> >>>>> Hi
> >>>>>
> >>>>> You can send the message to the JMS as InOnly or use WireTap
> >>>>>
> >>>>> On Tue, Feb 3, 2015 at 12:27 PM, James Green <
> james.mk.gr...@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> I have two routes:
> >>>>>>
> >>>>>> 1. A rest dsl accepting data from HTTP clients and sending it to the
> >>>>>> route
> >>>>>> below before replying to the client
> >>>>>> 2. A "backend" route that receives an Exchange and sends it to a JMS
> >>>>>> queue
> >>>>>>
> >>>>>> By default, although the JMS queue gets the message, a stack trace
> >>>>>> occurs
> >>>>>> because the queue did not respond. So I set the backend route to be
> >>>>>> InOnly
> >>>>>> and now no stack trace occurs.
> >>>>>>
> >>>>>> However, the remaining part of my rest dsl route does not execute.
> >>>>>>
> >>>>>> So how do I accept some REST request, fire off an asynchronous JMS
> >>>>>> message,
> >>>>>> and reply to the HTTP client?
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> James
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>
>
>
>
> --
> Claus Ibsen
> -
> Red Hat, Inc.
> Email: cib...@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
> hawtio: http://hawt.io/
> fabric8: http://fabric8.io/
>

MailProducer not documented

[James Green]

http://camel.apache.org/mail.html mentions MailProducer but I can't find an
example and the JavaDoc does not show it being used.

Can anyone provide an update to the documentation as I'm not aware of
whether we should be using it instead of an smtp: endpoint.

Thanks,

James

Re: REST InOut with JMS InOnly

[James Green]

Nope :)

rest("/from-smtp/")
.post()
.type(EmailedSmsRequest.class)
.to("direct:fromSmtp");

direct:fromSmtp routes onward to direct:router. direct:router sends it
onwards to jms:queue:foo asynchronously. The route that reads
from("direct:router") is intended for be fully re-usable and has multiple
public interfaces sending messages into it but is not expected to reply at
all (except for raising exceptions of course).

Beyond direct:fromSmtp routing to direct:router, I want to set the OUT part
of the exchange so that the rest component knows what to send back to the
http client.

I suspect I can wiretap() to split the messaging across two routes - one to
direct:router and the other to processing that provides the OUT part of the
exchange however it doesn't feel entirely natural hence I didn't think of
it myself.

[ I have not yet tried wiretap in the code I'm asking the question about,
will do shortly ]



On 3 February 2015 at 13:20, Morgan Hautman 
wrote:

> Yes I understand we can encounter a timeout when we don't respond to
> http/rest because it's synchronous.
>
> But I think what James means is :
>
> 1st route:
> from(cxf:...).to(activemq:bar)
>
> 2nd route
> from(activemq: bar).to(processing)
>
> The first route sends a message to the second route through activemq and
> waits for the second route to process the message and the second route
> respond to the first route who will answer to the client what "route2"
> responded. (timeout or not)
>
> Hope It's comprehensive.
>
> PS: I'm not in James team, I just try to help and understand a problem I
> had myself some months ago but didn't look further.
>
>
> On 3/02/2015 13:54, Claus Ibsen wrote:
>
>> On Tue, Feb 3, 2015 at 1:27 PM, Morgan Hautman 
>> wrote:
>>
>>> Claus,
>>>
>>> Is their any way a queue (using activemq) could respond , like a
>>> request-reply mechanism?
>>>
>>> http://camel.apache.org/request-reply.html
>>>
>>>  Not sure I follow. Camel can do InOnly and InOut over JMS. So yeah
>> both is possible.
>>
>> Just mind that a client like HTTP / REST is synchronous in that sense
>> the client awaits a response, so whether that is just a OK or to
>> respond with some new data, then that needs to happen, and occurs when
>> the exchange is done being routed, and the control is back at the
>> consumer.
>>
>>  On 3/02/2015 13:14, Claus Ibsen wrote:
>>>
>>>> Hi
>>>>
>>>> You can send the message to the JMS as InOnly or use WireTap
>>>>
>>>> On Tue, Feb 3, 2015 at 12:27 PM, James Green 
>>>> wrote:
>>>>
>>>>> I have two routes:
>>>>>
>>>>> 1. A rest dsl accepting data from HTTP clients and sending it to the
>>>>> route
>>>>> below before replying to the client
>>>>> 2. A "backend" route that receives an Exchange and sends it to a JMS
>>>>> queue
>>>>>
>>>>> By default, although the JMS queue gets the message, a stack trace
>>>>> occurs
>>>>> because the queue did not respond. So I set the backend route to be
>>>>> InOnly
>>>>> and now no stack trace occurs.
>>>>>
>>>>> However, the remaining part of my rest dsl route does not execute.
>>>>>
>>>>> So how do I accept some REST request, fire off an asynchronous JMS
>>>>> message,
>>>>> and reply to the HTTP client?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> James
>>>>>
>>>>
>>>>
>>>>
>>
>>
>

Re: REST InOut with JMS InOnly

[James Green]

Surely its the job of the queue consumer to reply, not ActiveMQ?

On 3 February 2015 at 12:27, Morgan Hautman 
wrote:

> Claus,
>
> Is their any way a queue (using activemq) could respond , like a
> request-reply mechanism?
>
> http://camel.apache.org/request-reply.html
>
>
> On 3/02/2015 13:14, Claus Ibsen wrote:
>
>> Hi
>>
>> You can send the message to the JMS as InOnly or use WireTap
>>
>> On Tue, Feb 3, 2015 at 12:27 PM, James Green 
>> wrote:
>>
>>> I have two routes:
>>>
>>> 1. A rest dsl accepting data from HTTP clients and sending it to the
>>> route
>>> below before replying to the client
>>> 2. A "backend" route that receives an Exchange and sends it to a JMS
>>> queue
>>>
>>> By default, although the JMS queue gets the message, a stack trace occurs
>>> because the queue did not respond. So I set the backend route to be
>>> InOnly
>>> and now no stack trace occurs.
>>>
>>> However, the remaining part of my rest dsl route does not execute.
>>>
>>> So how do I accept some REST request, fire off an asynchronous JMS
>>> message,
>>> and reply to the HTTP client?
>>>
>>> Thanks,
>>>
>>> James
>>>
>>
>>
>>
>

REST InOut with JMS InOnly

[James Green]

I have two routes:

1. A rest dsl accepting data from HTTP clients and sending it to the route
below before replying to the client
2. A "backend" route that receives an Exchange and sends it to a JMS queue

By default, although the JMS queue gets the message, a stack trace occurs
because the queue did not respond. So I set the backend route to be InOnly
and now no stack trace occurs.

However, the remaining part of my rest dsl route does not execute.

So how do I accept some REST request, fire off an asynchronous JMS message,
and reply to the HTTP client?

Thanks,

James

Re: Periodic queue consumer

[James Green]

Interesting choice in JMS 2 to add a delivery delay based in milliseconds.
Was there a reason not to accept a Date do we know?

On 2 February 2015 at 09:55, Claus Ibsen  wrote:

> Hi
>
> ActiveMQ has a scheduler on the client side, so you can delay sending
> the message
> http://activemq.apache.org/delay-and-schedule-message-delivery.html
>
> Also there is maybe something about setting a timestamp on the message
> before the message is valid. Can't remember if there was something
> like that in JMS spec, so you can say this message is only valid after
> now + 10 sec.
>
>
>
> On Fri, Jan 30, 2015 at 4:28 PM, James Green 
> wrote:
> > We have a need to route message to a temporary location and to re-submit
> > them every n seconds.
> >
> > We're thinking of sending the message to a queue if a later re-try is
> > needed.
> >
> > A separate process would then be required to read from the queue and
> > re-submit. This is fine but clearly listening on a queue is normally a
> > constant process, so out of the box we'd get the message intended for
> > re-try immediately and send it onwards for re-trying without any delay.
> >
> > It would be nice therefore to "wake up" a queue consumer after some sleep
> > interval. Lets the background processes run that caused the need for a
> > re-try.
> >
> > Any good way of achieving this?
> >
> > [ We have tried pushing them into a database and periodically pulling
> them
> > back out into the main process again, but we're hitting
> > ConcurrentModificationExceptions which are proving difficult to
> understand.
> > ]
> >
> > Thanks,
> >
> > James
>
>
>
> --
> Claus Ibsen
> -
> Red Hat, Inc.
> Email: cib...@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
> hawtio: http://hawt.io/
> fabric8: http://fabric8.io/
>

Periodic queue consumer

[James Green]

We have a need to route message to a temporary location and to re-submit
them every n seconds.

We're thinking of sending the message to a queue if a later re-try is
needed.

A separate process would then be required to read from the queue and
re-submit. This is fine but clearly listening on a queue is normally a
constant process, so out of the box we'd get the message intended for
re-try immediately and send it onwards for re-trying without any delay.

It would be nice therefore to "wake up" a queue consumer after some sleep
interval. Lets the background processes run that caused the need for a
re-try.

Any good way of achieving this?

[ We have tried pushing them into a database and periodically pulling them
back out into the main process again, but we're hitting
ConcurrentModificationExceptions which are proving difficult to understand.
]

Thanks,

James

Re: Modifying a shipped TypeConverter

[James Green]

CAMEL-8290

On 28 January 2015 at 11:22, Raul Kripalani  wrote:

> Yes, we definitely need an option to pick up a custom ObjectMapper. Could
> you file a JIRA and assign it to me, please?
>
> However, the type converter is only used as a (very convenient) fallback.
> If you provide a DBObject to your endpoint, no type conversions will be
> triggered.
>
> Therefore, for now, you can just implement a processor/bean to convert your
> custom Object into a DBObject with a code similar to [1], but controlling
> whichever options you want in the ObjectMapper.
>
> [1]
>
> https://github.com/raulk/camel-mongodb/blob/master/src/main/java/org/apache/camel/component/mongodb/converters/MongoDbBasicConverters.java#L67
>
> Hope that helps,
>
> *Raúl Kripalani*
> Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> Integration specialist
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
>
> On Tue, Jan 20, 2015 at 3:58 PM, James Green 
> wrote:
>
> > Given MongoDB has an ISODate type natively, should the default
> ObjectMapper
> > be changed within the component itself to not write timestamps as longs?
> >
> > I.e. should this be considered a bug..?
> >
> > On 20 January 2015 at 15:29, Jakub Korab 
> > wrote:
> >
> > > I haven't tried this, so it's just conjecture, but you could try to
> > > remove the offending type converter from the TypeConverterRegistry and
> > > replace it with your own:
> > >
> > > |CamelContext context = ...|
> > > |TypeConverterRegistry converterRegistry =
> > > context.getTypeConverterRegistry();
> > > ||converterRegistry.remove|||TypeConverter|(DBObject.class,
> > Object.class);
> > > converterRegistry.addTypeConverter||(DBObject.class, Object.class, new
> > > FixedTypeConverter());|
> > >
> > > See:
> > >
> > >
> >
> http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/spi/TypeConverterRegistry.html#removeTypeConverter%28java.lang.Class,%20java.lang.Class%29
> > >
> > > Jakub
> > >
> > > On 20/01/15 14:50, James Green wrote:
> > > > The mongodb component uses Jackson to marshal Object to DBObject. The
> > > > trouble is that Date becomes long due to the default configuration of
> > > > Jackson.
> > > >
> > > > Is it possible to change this by obtaining that Jackson instance and
> > > > reconfiguring it?
> > > >
> > > > Or must be add a TypeConvertor for our specify type to the registry?
> > > >
> > > > Thanks,
> > > >
> > > > James
> > > >
> > >
> > >
> >
>

Re: Rest DSL Exception mapping

[James Green]

Just re-reading the "Binding POJOs" bit, will this also take effect for the
out part of an exception?

onException(MyException.class).handled(true).setHeader(Exchange.HTTP_RESPONSE_CODE,
constant(400)).process(myExceptionHandler).end()

Should I expect the Message provided by myExceptionHandler to be formatted
to JSON/XML according to the HTTP client's choice?


On 21 January 2015 at 11:51, James Green  wrote:

> If Camel can accept and map both JSON and XML inputs to POJOs, is there a
> way of reversing this for onException handling purposes?
>
> The only example of onException sets the content-type and formatted
> content on the Exchange. But I may not know this.
>
> Within Spring MVC there is @ResponseStatus allowing us to specify the HTTP
> response code for a particular Exception without needing to care about the
> response content type, which is the bit I'm not spotting an equivalent for.
>
> Am I missing something or is this a bit of a hole?
>
> Thanks,
>
> James
>
>

Rest DSL Exception mapping

[James Green]

If Camel can accept and map both JSON and XML inputs to POJOs, is there a
way of reversing this for onException handling purposes?

The only example of onException sets the content-type and formatted content
on the Exchange. But I may not know this.

Within Spring MVC there is @ResponseStatus allowing us to specify the HTTP
response code for a particular Exception without needing to care about the
response content type, which is the bit I'm not spotting an equivalent for.

Am I missing something or is this a bit of a hole?

Thanks,

James

Re: Messages sitting on ActiveMq for x period of time

[James Green]

May be worth connecting to ActiveMQ to inspect it at the JMX level (hawt.io
is an excellent interface). Check why ActiveMQ thinks it should not be
delivering it.

On 21 January 2015 at 04:29, mvandersteen <
mark.vanderst...@servicestream.com.au> wrote:

> Hi Guys,
>
> I have 1 queue created through camel that holds onto messages for approx 15
> minute before a consumer will pick them up.
>
> A cxf web service listens for incoming message as SOAP, then pushes
> translated message to  said queue.
>
> That message will sit there for approx 15 minutes before another route will
> pick it up for processing. We have approx 100 different queues across 25
> bundles or so and this is the only one I've seen this happen on. Which to
> me
> indicates some configuration somewhere.
>
> I've been developing camel for approx 18 months and not seen this behaviour
> before either hence the question to you guys. I can't see anything obvious
> in configuration files for the bundle or parameters being set for the jms
> queue either.
>
> Could anyone please give me a few pointers on what might be happening here.
>
> Cheers
> Mark
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Messages-sitting-on-ActiveMq-for-x-period-of-time-tp5761970.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>

Re: simple recipientlist expansion

[James Green]

Map? I meant a List on the header, of course.

On 20 January 2015 at 16:00, James Green  wrote:

> I ended up with a Processor that built a new Map on a header iterating
> over the media and prefixing each in the header variant.
>
> I may in-line this in the camel route (as per your example) to level the
> knowledge a little better though.
>
> Thanks for the suggestions.
>
> On 20 January 2015 at 15:16, Jakub Korab 
> wrote:
>
>> One way to do this is to assemble the list of destinations in a header,
>> then reference that. Here's a rough example:
>>
>> .process( new Processor() {
>> public void process(Exchange exchange) {
>> Message in = exchange.getIn();
>> List mediaList = ((YourPojo) in.getBody()).getMedia();
>> String destinations = "";
>> int i = 0;
>> for (String media : mediaList) {
>> if (i++ > 0) {
>> destinations += ",";
>> }
>> destinations += "direct:" + media;
>> }
>> in.setHeader("mediaDestinations", destinations);
>> }
>> })
>> .recipientList(header("mediaDestinations"))
>>
>> This has a nice side-effect of making it really easy to debug by
>> dropping a log statement before the recipientList.
>> You could also use bean binding instead of a processor:
>>
>> .setHeader(method(new MyRouter(), "route(${body.media})"))
>>
>> with a class like:
>>
>> public class MyRouter {
>> public String route(List media) {...} // returns
>> comma-seperated endpoints
>> }
>>
>> Jakub
>>
>> On 19/01/15 18:01, James Green wrote:
>> > You mean a class implementing Expression?
>> >
>> > On 19 January 2015 at 17:56, Claus Ibsen  wrote:
>> >
>> >> You can use a method call expression (aka java bean) where you add the
>> >> direct: prefix to the media headers.
>> >>
>> >> Or try look at groovy or something which may be able to prefix to a
>> >> list. I think I have seen that done in fabric8 v1.
>> >>
>> >>
>> >> On Mon, Jan 19, 2015 at 6:32 PM, James Green > >
>> >> wrote:
>> >>> .recipientList(simple("direct:${body.media}"))
>> >>>
>> >>> So media is a List property where each entry has a media
>> value:
>> >>> "sms", "email", etc.
>> >>>
>> >>> What I get out of this is an exception (where "sms" is the only
>> media):
>> >>>
>> >>>
>> org.apache.camel.component.direct.DirectConsumerNotAvailableException: No
>> >>> consumers available on endpoint: Endpoint[direct://%5Bsms%5D].
>> >>>
>> >>> If I remove the direct: from the simple expression and place it
>> directly
>> >> in
>> >>> the media property value it works fine. But then my POJO "knows" about
>> >>> direct: prefixes. Not what I had hoped.
>> >>>
>> >>> Any ideas? I can't use transform() as the rest of the message needs
>> to be
>> >>> passed onwards.
>> >>>
>> >>> James
>> >>
>> >>
>> >> --
>> >> Claus Ibsen
>> >> -
>> >> Red Hat, Inc.
>> >> Email: cib...@redhat.com
>> >> Twitter: davsclaus
>> >> Blog: http://davsclaus.com
>> >> Author of Camel in Action: http://www.manning.com/ibsen
>> >> hawtio: http://hawt.io/
>> >> fabric8: http://fabric8.io/
>> >>
>>
>>
>

Re: simple recipientlist expansion

[James Green]

I ended up with a Processor that built a new Map on a header iterating over
the media and prefixing each in the header variant.

I may in-line this in the camel route (as per your example) to level the
knowledge a little better though.

Thanks for the suggestions.

On 20 January 2015 at 15:16, Jakub Korab 
wrote:

> One way to do this is to assemble the list of destinations in a header,
> then reference that. Here's a rough example:
>
> .process( new Processor() {
> public void process(Exchange exchange) {
> Message in = exchange.getIn();
> List mediaList = ((YourPojo) in.getBody()).getMedia();
> String destinations = "";
> int i = 0;
> for (String media : mediaList) {
> if (i++ > 0) {
> destinations += ",";
> }
> destinations += "direct:" + media;
> }
> in.setHeader("mediaDestinations", destinations);
> }
> })
> .recipientList(header("mediaDestinations"))
>
> This has a nice side-effect of making it really easy to debug by
> dropping a log statement before the recipientList.
> You could also use bean binding instead of a processor:
>
> .setHeader(method(new MyRouter(), "route(${body.media})"))
>
> with a class like:
>
> public class MyRouter {
> public String route(List media) {...} // returns
> comma-seperated endpoints
> }
>
> Jakub
>
> On 19/01/15 18:01, James Green wrote:
> > You mean a class implementing Expression?
> >
> > On 19 January 2015 at 17:56, Claus Ibsen  wrote:
> >
> >> You can use a method call expression (aka java bean) where you add the
> >> direct: prefix to the media headers.
> >>
> >> Or try look at groovy or something which may be able to prefix to a
> >> list. I think I have seen that done in fabric8 v1.
> >>
> >>
> >> On Mon, Jan 19, 2015 at 6:32 PM, James Green 
> >> wrote:
> >>> .recipientList(simple("direct:${body.media}"))
> >>>
> >>> So media is a List property where each entry has a media value:
> >>> "sms", "email", etc.
> >>>
> >>> What I get out of this is an exception (where "sms" is the only media):
> >>>
> >>> org.apache.camel.component.direct.DirectConsumerNotAvailableException:
> No
> >>> consumers available on endpoint: Endpoint[direct://%5Bsms%5D].
> >>>
> >>> If I remove the direct: from the simple expression and place it
> directly
> >> in
> >>> the media property value it works fine. But then my POJO "knows" about
> >>> direct: prefixes. Not what I had hoped.
> >>>
> >>> Any ideas? I can't use transform() as the rest of the message needs to
> be
> >>> passed onwards.
> >>>
> >>> James
> >>
> >>
> >> --
> >> Claus Ibsen
> >> -
> >> Red Hat, Inc.
> >> Email: cib...@redhat.com
> >> Twitter: davsclaus
> >> Blog: http://davsclaus.com
> >> Author of Camel in Action: http://www.manning.com/ibsen
> >> hawtio: http://hawt.io/
> >> fabric8: http://fabric8.io/
> >>
>
>

Re: Modifying a shipped TypeConverter

[James Green]

Given MongoDB has an ISODate type natively, should the default ObjectMapper
be changed within the component itself to not write timestamps as longs?

I.e. should this be considered a bug..?

On 20 January 2015 at 15:29, Jakub Korab 
wrote:

> I haven't tried this, so it's just conjecture, but you could try to
> remove the offending type converter from the TypeConverterRegistry and
> replace it with your own:
>
> |CamelContext context = ...|
> |TypeConverterRegistry converterRegistry =
> context.getTypeConverterRegistry();
> ||converterRegistry.remove|||TypeConverter|(DBObject.class, Object.class);
> converterRegistry.addTypeConverter||(DBObject.class, Object.class, new
> FixedTypeConverter());|
>
> See:
>
> http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/spi/TypeConverterRegistry.html#removeTypeConverter%28java.lang.Class,%20java.lang.Class%29
>
> Jakub
>
> On 20/01/15 14:50, James Green wrote:
> > The mongodb component uses Jackson to marshal Object to DBObject. The
> > trouble is that Date becomes long due to the default configuration of
> > Jackson.
> >
> > Is it possible to change this by obtaining that Jackson instance and
> > reconfiguring it?
> >
> > Or must be add a TypeConvertor for our specify type to the registry?
> >
> > Thanks,
> >
> > James
> >
>
>

Modifying a shipped TypeConverter

[James Green]

The mongodb component uses Jackson to marshal Object to DBObject. The
trouble is that Date becomes long due to the default configuration of
Jackson.

Is it possible to change this by obtaining that Jackson instance and
reconfiguring it?

Or must be add a TypeConvertor for our specify type to the registry?

Thanks,

James

Re: simple recipientlist expansion

[James Green]

You mean a class implementing Expression?

On 19 January 2015 at 17:56, Claus Ibsen  wrote:

> You can use a method call expression (aka java bean) where you add the
> direct: prefix to the media headers.
>
> Or try look at groovy or something which may be able to prefix to a
> list. I think I have seen that done in fabric8 v1.
>
>
> On Mon, Jan 19, 2015 at 6:32 PM, James Green 
> wrote:
> > .recipientList(simple("direct:${body.media}"))
> >
> > So media is a List property where each entry has a media value:
> > "sms", "email", etc.
> >
> > What I get out of this is an exception (where "sms" is the only media):
> >
> > org.apache.camel.component.direct.DirectConsumerNotAvailableException: No
> > consumers available on endpoint: Endpoint[direct://%5Bsms%5D].
> >
> > If I remove the direct: from the simple expression and place it directly
> in
> > the media property value it works fine. But then my POJO "knows" about
> > direct: prefixes. Not what I had hoped.
> >
> > Any ideas? I can't use transform() as the rest of the message needs to be
> > passed onwards.
> >
> > James
>
>
>
> --
> Claus Ibsen
> -
> Red Hat, Inc.
> Email: cib...@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
> hawtio: http://hawt.io/
> fabric8: http://fabric8.io/
>

simple recipientlist expansion

[James Green]

.recipientList(simple("direct:${body.media}"))

So media is a List property where each entry has a media value:
"sms", "email", etc.

What I get out of this is an exception (where "sms" is the only media):

org.apache.camel.component.direct.DirectConsumerNotAvailableException: No
consumers available on endpoint: Endpoint[direct://%5Bsms%5D].

If I remove the direct: from the simple expression and place it directly in
the media property value it works fine. But then my POJO "knows" about
direct: prefixes. Not what I had hoped.

Any ideas? I can't use transform() as the rest of the message needs to be
passed onwards.

James

Re: Where is logName used?

[James Green]

We just upgraded to log4j2. We are logging via slf4j.

Given:
onException(AccountNotFoundException.class).log(LoggingLevel.WARN,
"com.foo.server.ngw", "Account not found");

We see in the Tomcat log:
2015-01-16 10:45:07,357 WARN  [http-bio-8080-exec-1]
org.apache.camel.util.CamelLogger (CamelLogger.java:182) - Account not found

Not sure what that tells you quite frankly. We did previously use log()
handing in our own org.slf4j.Logger without further success.


On 16 January 2015 at 06:30, Claus Ibsen  wrote:

> Hi
>
> Kinda weird as that log name refers to the slf4j marker which you can
> also use. Are you sure the log() method you use, its the logger name
> and not some marker parameter?
>
> Also you do not use any custom logger instance, as if so then that is
> used over what you specify in the log method,.
>
> https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/component/log/LogComponent.java#L55
>
>
> On Tue, Jan 13, 2015 at 11:17 AM, James Green 
> wrote:
> > The following code:
> >
> > .log(LoggingLevel.ERROR, "com.foo.server.ngw.router",
> > "Account Not Found. Message discarded.").stop();
> >
> > Results in the following in the log:
> >
> > 10:12:11,690 ERROR org.slf4j.helpers.MarkerIgnoringBase:145 error() -
> > Account Not Found. Message discarded.
> >
> > I was expecting to see com.foo.server.ngw.router somewhere above? Not
> sure
> > what else it is supplied for..?
> >
> > James
>
>
>
> --
> Claus Ibsen
> -
> Red Hat, Inc.
> Email: cib...@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
> hawtio: http://hawt.io/
> fabric8: http://fabric8.io/
>

Re: Irrecoverable faults

[James Green]

I saw a StackOverflow question asking the difference between errorHandler
and onException. I believe the answer given was that errorHandler handles
exceptions not otherwise trapped by onException.

If this is true (and the complete answer) it may be wise to add this line
to the documentation..?

On 10 January 2015 at 07:20, Willem Jiang  wrote:

> Current Camel ErrorHandler just provides a way to let you handle the
> error. Even it provides retry mechanism, you still can do some work for the
> Irrecoverable error.
>
> With the ControlBus[1], you can stop the route which has the irrecoverable
> faults.
> If you want to stop the message, you can setup the exchange stop header to
> be true just like this:
> exchange.setProperty(Exchange.ROUTE_STOP, Boolean.TRUE);
>
> [1]https://camel.apache.org/controlbus.html
>
>
> --
> Willem Jiang
>
> Red Hat, Inc.
> Web: http://www.redhat.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.iteye.com (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
>
>
> On January 9, 2015 at 5:53:32 PM, James Green (james.mk.gr...@gmail.com)
> wrote:
> > Should we avoid issuing these?
> >
> > We are implementing some checks that ask, for example, "Is the customer
> > allowed to do this?" And if the answer is no we're treating this as
> > irrecoverable.
> >
> > Map this to irrecoverable according to Camel in Action Ch 5, Error
> > Handling. Yet this chapter barely touches irrecoverable errors, focusing
> > almost entirely on recoverable errors which are Throwables from the
> route.
> > The web site also seems to have the same focus.
> >
> > Am I modelling this in my mind? When Camel thinks of irrecoverable, does
> it
> > consider this as a "stop the runtime" type of error or "stop the message"
> > type of error? And am I barking up the wrong tree entirely - should all
> > business logic checks that "fail" actually be considered recoverable
> > according to Camel?
> >
> > N.B. I noticed Google has reference to a years-old discussion suggesting
> to
> > remove Fault, which has raised alarm bells in my thinking too.
> >
> > Thanks,
> >
> > James
> >
>
>

Re: Where is logName used?

[James Green]

log4j.appender.console=org.apache.log4j.ConsoleAppender
log4j.appender.console.layout=org.apache.log4j.PatternLayout
log4j.appender.console.layout.ConversionPattern=%d{ABSOLUTE} %5p %C:%L %M()
- %m%n
### set log levels - for more verbose logging change 'info' to 'debug' ###
log4j.rootLogger=debug, console
log4j.logger.org=warn
log4j.logger.com=warn
log4j.logger.com.example=debug
log4j.logger.org.hibernate=warn
log4j.logger.org.springframework.transaction=warn
log4j.logger.com.foo=debug

Not much I can really say about that except it's a variant of what is
widely given as basic examples.

Does this help explain why the logName is not used at all?


On 14 January 2015 at 14:06, Willem Jiang  wrote:

> The “com.foo.server.ngw.router” is the log name to use, I’m not sure why
> the “org.slf4j.helpers.MarkerIgnoringBase” is used. Can you double check
> your log configuration to make sure you setup the log rightly?
>
> --
> Willem Jiang
>
> Red Hat, Inc.
> Web: http://www.redhat.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.iteye.com (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
>
>
> On January 13, 2015 at 6:17:48 PM, James Green (james.mk.gr...@gmail.com)
> wrote:
> > The following code:
> >
> > .log(LoggingLevel.ERROR, "com.foo.server.ngw.router",
> > "Account Not Found. Message discarded.").stop();
> >
> > Results in the following in the log:
> >
> > 10:12:11,690 ERROR org.slf4j.helpers.MarkerIgnoringBase:145 error() -
> > Account Not Found. Message discarded.
> >
> > I was expecting to see com.foo.server.ngw.router somewhere above? Not
> sure
> > what else it is supplied for..?
> >
> > James
> >
>
>

Where is logName used?

[James Green]

The following code:

.log(LoggingLevel.ERROR, "com.foo.server.ngw.router",
"Account Not Found. Message discarded.").stop();

Results in the following in the log:

10:12:11,690 ERROR org.slf4j.helpers.MarkerIgnoringBase:145 error() -
Account Not Found. Message discarded.

I was expecting to see com.foo.server.ngw.router somewhere above? Not sure
what else it is supplied for..?

James

Re: onException is ignored

[James Green]

Mea culpa. Who knew AccountNumberFoundException was part of
javax.security..! Fixed the import, the onException now executes.

However, the .log line:
.log(LoggingLevel.ERROR, "com.foo.server.ngw", "Account Not
Found. Message discarded.").stop();

Actually writes the line:

14:22:03,993 ERROR org.slf4j.helpers.MarkerIgnoringBase:145 error() -
Account Not Found. Message discarded.

So what was the point of supplying a logName?


On 12 January 2015 at 12:05, James Green  wrote:

> As suggested:
>
> errorHandler(transactionErrorHandler().maximumRedeliveries(3));
> onException(AccountNotFoundException.class)
> .log(LoggingLevel.ERROR, "com.foo.server.ngw", "Account
> Not Found. Message discarded.").stop();
>
>
> from(source())
> .transacted()
> .unmarshal(jacksonUnmarshall)
> .process(router)
> .recipientList(simple("${body.media}"));
>
> I can see Camel attempt redelivery three times as a result of catching
> AccountNotFoundException. After the fourth and final attempt fails I can't
> actually see much different to that logged for the previous three attempts.
> I've kept the reporting down to what I hope is pertinent below:
>
> 10:32:23,885 ERROR org.slf4j.helpers.MarkerIgnoringBase:161 error() -
> Failed delivery for (MessageId:
> queue_inbound_ID_JGREENWIN7-54570-142105884-3_1_1_1_3 on ExchangeId:
> ID-JGREENWIN7-54739-1421058738390-0-6). Exhausted after delivery attempt: 4
> caught: com.foo.server.ngw.router.AccountNotFoundException: Account not
> found
> ...
> 10:32:23,932  WARN org.apache.camel.spring.spi.TransactionErrorHandler:287
> logTransactionRollback() - Transaction rollback (0x2017df6a)
> redelivered(true) for (MessageId:
> ID:JGREENWIN7-54570-142105884-3:1:1:1:3 on ExchangeId:
> ID-JGREENWIN7-54739-1421058738390-0-7) caught:
> com.foo.server.ngw.router.AccountNotFoundException: Account not found
> 10:32:23,932  WARN org.slf4j.helpers.MarkerIgnoringBase:136 warn() -
> Execution of JMS message listener failed. Caused by:
> [org.apache.camel.RuntimeCamelException -
> com.foo.server.ngw.router.AccountNotFoundException: Account not found]
> org.apache.camel.RuntimeCamelException:
> com.foo.server.ngw.router.AccountNotFoundException: Account not found
> at
> org.apache.camel.util.ObjectHelper.wrapRuntimeCamelException(ObjectHelper.java:1364)
> at
> org.apache.camel.spring.spi.TransactionErrorHandler$1.doInTransactionWithoutResult(TransactionErrorHandler.java:188)
> at
> org.springframework.transaction.support.TransactionCallbackWithoutResult.doInTransaction(TransactionCallbackWithoutResult.java:34)
> at
> org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:133)
> at
> org.apache.camel.spring.spi.TransactionErrorHandler.doInTransactionTemplate(TransactionErrorHandler.java:174)
> at
> org.apache.camel.spring.spi.TransactionErrorHandler.processInTransaction(TransactionErrorHandler.java:134)
> at
> org.apache.camel.spring.spi.TransactionErrorHandler.process(TransactionErrorHandler.java:103)
> at
> org.apache.camel.spring.spi.TransactionErrorHandler.process(TransactionErrorHandler.java:112)
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
> at
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:105)
> at
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:87)
> at
> org.apache.camel.component.jms.EndpointMessageListener.onMessage(EndpointMessageListener.java:103)
> at
> org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:562)
> at
> org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:500)
> at
> org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:468)
> at
> org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:325)
> at
> org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:243)
> at
> org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1101)
> at
> org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListene

Re: onException is ignored

[James Green]

actionErrorHandler.processByErrorHandler(TransactionErrorHandler.java:218)
at
org.apache.camel.spring.spi.TransactionErrorHandler.process(TransactionErrorHandler.java:99)
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:166)
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.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:416)
at
org.apache.camel.spring.spi.TransactionErrorHandler.processByErrorHandler(TransactionErrorHandler.java:218)
at
org.apache.camel.spring.spi.TransactionErrorHandler.process(TransactionErrorHandler.java:99)
at
org.apache.camel.spring.spi.TransactionErrorHandler.process(TransactionErrorHandler.java:112)
at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:416)
at
org.apache.camel.spring.spi.TransactionErrorHandler.processByErrorHandler(TransactionErrorHandler.java:218)
at
org.apache.camel.spring.spi.TransactionErrorHandler$1.doInTransactionWithoutResult(TransactionErrorHandler.java:181)
... 22 more

Is the above consistent with expectations? The log() message doesn't appear
in there and as you can see I have removed the sending to the queue after
logging (just in case)...

Thanks,

James

On 12 January 2015 at 10:10, Claus Ibsen  wrote:

> Hi
>
> No the onException should be triggered even for TX.
>
> You may try to configure onException after errorHandler.
>
>
> On Mon, Jan 12, 2015 at 11:02 AM, James Green 
> wrote:
> > So when using onException it's really important not to use a component
> that
> > is already partaking in the transaction being rolled back? I get that
> now,
> > but it's not immediately obvious.
> >
> > Does this explain why the log()ged message, "Account Not Found. Message
> > discarded." does not appear in the console though?
> >
> > On 10 January 2015 at 07:23, Willem Jiang 
> wrote:
> >
> >> If the Exception is thrown from the source() endpoint, the onException
> >> error handler won’t work as you expected.
> >>
> >> --
> >> Willem Jiang
> >>
> >> Red Hat, Inc.
> >> Web: http://www.redhat.com
> >> Blog: http://willemjiang.blogspot.com (English)
> >> http://jnn.iteye.com (Chinese)
> >> Twitter: willemjiang
> >> Weibo: 姜宁willem
> >>
> >>
> >>
> >> On January 10, 2015 at 1:38:52 AM, James Green (
> james.mk.gr...@gmail.com)
> >> wrote:
> >> > Project is Spring based with Camel 2.14 and the following
> configuration:
> >> >
> >> > onException(AccountNotFoundException.class)
> >> > .log("Account Not Found. Message
> >> > discarded.").to("jms:queue:RouterAccountNotFound").stop();
> >> >
> >> > errorHandler(transactionErrorHandler().maximumRedeliveries(3));
> >> >
> >> > from(source())
> >> > .transacted()
> >> > .unmarshal(jacksonUnmarshall)
> >> > .process(router)
> >> > .recipientList(simple("${body.media}"));
> >> >
> >> > We have a JMS connection and a JPA connection wrapped in a Atomikos
> >> > transaction manager (a XA transaction manager I understand to be
> >> required).
> >> > The above errorHandler triggers if the router throws an Exception, but
> >> the
> >> > onException statement does not fire despite the logs recording the
> >> > AccountNotFoundException being caught by Camel.
> >> >
> >> > Consequently the log()ing and the RouterAccountNotFound queue do not
> fire
> >> > at all.
> >> >
> >> > The documentation suggests onException should be usable at this point.
> >> Can
> >> > anyone suggest why the above only partly works?
> >> >
> >> > Thanks,
> >> >
> >> > James
> >> >
> >>
> >>
>
>
>
> --
> Claus Ibsen
> -
> Red Hat, Inc.
> Email: cib...@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
> hawtio: http://hawt.io/
> fabric8: http://fabric8.io/
>

Re: onException is ignored

[James Green]

So when using onException it's really important not to use a component that
is already partaking in the transaction being rolled back? I get that now,
but it's not immediately obvious.

Does this explain why the log()ged message, "Account Not Found. Message
discarded." does not appear in the console though?

On 10 January 2015 at 07:23, Willem Jiang  wrote:

> If the Exception is thrown from the source() endpoint, the onException
> error handler won’t work as you expected.
>
> --
> Willem Jiang
>
> Red Hat, Inc.
> Web: http://www.redhat.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.iteye.com (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
>
>
> On January 10, 2015 at 1:38:52 AM, James Green (james.mk.gr...@gmail.com)
> wrote:
> > Project is Spring based with Camel 2.14 and the following configuration:
> >
> > onException(AccountNotFoundException.class)
> > .log("Account Not Found. Message
> > discarded.").to("jms:queue:RouterAccountNotFound").stop();
> >
> > errorHandler(transactionErrorHandler().maximumRedeliveries(3));
> >
> > from(source())
> > .transacted()
> > .unmarshal(jacksonUnmarshall)
> > .process(router)
> > .recipientList(simple("${body.media}"));
> >
> > We have a JMS connection and a JPA connection wrapped in a Atomikos
> > transaction manager (a XA transaction manager I understand to be
> required).
> > The above errorHandler triggers if the router throws an Exception, but
> the
> > onException statement does not fire despite the logs recording the
> > AccountNotFoundException being caught by Camel.
> >
> > Consequently the log()ing and the RouterAccountNotFound queue do not fire
> > at all.
> >
> > The documentation suggests onException should be usable at this point.
> Can
> > anyone suggest why the above only partly works?
> >
> > Thanks,
> >
> > James
> >
>
>

onException is ignored

[James Green]

Project is Spring based with Camel 2.14 and the following configuration:

onException(AccountNotFoundException.class)
.log("Account Not Found. Message
discarded.").to("jms:queue:RouterAccountNotFound").stop();

errorHandler(transactionErrorHandler().maximumRedeliveries(3));

from(source())
.transacted()
.unmarshal(jacksonUnmarshall)
.process(router)
.recipientList(simple("${body.media}"));

We have a JMS connection and a JPA connection wrapped in a Atomikos
transaction manager (a XA transaction manager I understand to be required).
The above errorHandler triggers if the router throws an Exception, but the
onException statement does not fire despite the logs recording the
AccountNotFoundException being caught by Camel.

Consequently the log()ing and the RouterAccountNotFound queue do not fire
at all.

The documentation suggests onException should be usable at this point. Can
anyone suggest why the above only partly works?

Thanks,

James

Irrecoverable faults

[James Green]

Should we avoid issuing these?

We are implementing some checks that ask, for example, "Is the customer
allowed to do this?" And if the answer is no we're treating this as
irrecoverable.

Map this to irrecoverable according to Camel in Action Ch 5, Error
Handling. Yet this chapter barely touches irrecoverable errors, focusing
almost entirely on recoverable errors which are Throwables from the route.
The web site also seems to have the same focus.

Am I modelling this in my mind? When Camel thinks of irrecoverable, does it
consider this as a "stop the runtime" type of error or "stop the message"
type of error? And am I barking up the wrong tree entirely - should all
business logic checks that "fail" actually be considered recoverable
according to Camel?

N.B. I noticed Google has reference to a years-old discussion suggesting to
remove Fault, which has raised alarm bells in my thinking too.

Thanks,

James

Re: Spring auto-registration of Components?

[James Green]

Sorry, Spring JavaConfig. We've not looked at Spring Boot - I think it was
being announced as we started doing stuff with Spring Framework, we/I
considered it bleeding edge when we needed stable.

Solving the problem of configuring JMS using just a properties file without
the need for java code would be a good thing but I don't see how without
using a strategy similar to the routes method.

On 8 January 2015 at 17:51, Claus Ibsen  wrote:

> Hi
>
> Are you talking about spring-boot or spring javaconfig?
>
>
>
> On Thu, Jan 8, 2015 at 11:58 AM, James Green 
> wrote:
> > If CamelConfiguration.routes() registers RouteBuilders found in the
> > application content, is there a reason why CamelConfiguration does not
> > register Components in the same way?
> >
> > I'm just learning about this stuff so I may be mentally missing some
> steps
> > :)
> >
> > Really looking to let our ops people configure the JMS broker using just
> a
> > .properties file but that doesn't seem realistic without registering
> > connection factories for each allowable implementation within code...
> >
> > James
>
>
>
> --
> Claus Ibsen
> -
> Red Hat, Inc.
> Email: cib...@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
> hawtio: http://hawt.io/
> fabric8: http://fabric8.io/
>

Re: RecipientList to queue?

[James Green]

I eventually solved this but making the media list return a set of
"direct:" strings. Then, a set of separate routes from
direct: to jms:queue: via a Jackson marshaller however this
isn't particularly dynamic.

On 8 January 2015 at 17:43, Claus Ibsen  wrote:

> The WARN is from camel-jms when you send to a jms endpoint and the
> message body type cannot be determined to match a suitable JMS type.
>
> When this happens it fallback to use Object type which is serialized
> java objects which often is not desired.
>
> See the jms page for more details and how mapping, and what you can do
> http://camel.apache.org/jms
>
> On Thu, Jan 8, 2015 at 4:36 PM, James Green 
> wrote:
> > This errors:
> >
> > from(source())
> > .transacted()
> > .unmarshal(jacksonUnmarshall)
> > .process(router)
> > .recipientList(simple("${body.media}"))
> > .marshal(jacksonMarshall);
> >
> > The router sets the In of the Exchange to an object that has a
> List
> > media. This is as single String of value "activemq:queue:foo".
> >
> > The error:
> >
> > 15:29:32,463  WARN org.apache.camel.component.jms.JmsBinding:486
> > createJmsMessage() - Cannot determine specific JmsMessage type to use
> from
> > body class. Will use generic JmsMessage. Body class:
> > com.foo.server.ngw.msgtosend.MessageToSend. If you want to send a POJO
> then
> > your class might need to implement java.io.Serializable, or you can
> force a
> > specific type by setting the jmsMessageType option on the JMS endpoint.
> >
> > I tried with marshal before the recipientList but then ${body.media}
> cannot
> > be found.
> >
> > I'm guessing I'm bending things in ways not intended. The router wants to
> > set which media(s) the message should be transmitted onwards to. Camel
> > should then transmit to those as a set of queues.
> >
> > Pretty simple, but crashes. Suggestions?
> >
> > James
>
>
>
> --
> Claus Ibsen
> -
> Red Hat, Inc.
> Email: cib...@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
> hawtio: http://hawt.io/
> fabric8: http://fabric8.io/
>

RecipientList to queue?

[James Green]

This errors:

from(source())
.transacted()
.unmarshal(jacksonUnmarshall)
.process(router)
.recipientList(simple("${body.media}"))
.marshal(jacksonMarshall);

The router sets the In of the Exchange to an object that has a List
media. This is as single String of value "activemq:queue:foo".

The error:

15:29:32,463  WARN org.apache.camel.component.jms.JmsBinding:486
createJmsMessage() - Cannot determine specific JmsMessage type to use from
body class. Will use generic JmsMessage. Body class:
com.foo.server.ngw.msgtosend.MessageToSend. If you want to send a POJO then
your class might need to implement java.io.Serializable, or you can force a
specific type by setting the jmsMessageType option on the JMS endpoint.

I tried with marshal before the recipientList but then ${body.media} cannot
be found.

I'm guessing I'm bending things in ways not intended. The router wants to
set which media(s) the message should be transmitted onwards to. Camel
should then transmit to those as a set of queues.

Pretty simple, but crashes. Suggestions?

James

Spring auto-registration of Components?

[James Green]

If CamelConfiguration.routes() registers RouteBuilders found in the
application content, is there a reason why CamelConfiguration does not
register Components in the same way?

I'm just learning about this stuff so I may be mentally missing some steps
:)

Really looking to let our ops people configure the JMS broker using just a
.properties file but that doesn't seem realistic without registering
connection factories for each allowable implementation within code...

James

Are getters/setters required for simple?

[James Green]

http://camel.apache.org/simple.html talks about using getters/setters of a
POJO.

If the POJO has no business logic, can it not merely hold a set of public
fields? Is this intended for work? No real point in the getters/setters
existing.

James

Recording events

[James Green]

We're about to build a number of jars which will use Camel to route
messages from sources to destinations via business logic processors.

One of things we're looking for is the ability to record business events as
they happen. Sounds a bit like Wire Tap?

We're unsure. Ultimately the events will form an activity stream for our
customers and billing systems. The input data and the event itself will
likely differ.

We don't want to invent the wheel here. Ideas?

James

Re: Cryptography - real world use

[James Green]

Incidentally what you expect to see if I have a POJO and sent it to MongoDB
via an encrypting marshaller? A document full of binary or a hash where the
values are binary?

On 24 December 2014 at 11:39, James Green  wrote:

> OK do we need to wrap the process() with both un-marshal to a POJO
> beforehand and marshal to XML/JSON afterwards, and wrap this in
> decrypt/encrypt basically.
>
> Not seeing examples showing the chaining together of marshal calls so
> there's doubts in my mind reading this stuff.
>
> On 24 December 2014 at 11:07, David Karlsen 
> wrote:
>
>> Yes - you got it - maybe an jaxbUnmarshaller if your byBusinessProcessor
>> returns an jaxb object.
>> Get that to work first - then you might want to use
>> http://camel.apache.org/binding.html as well (which is really just
>> syntactic sugar to make the dataformat a property of the
>> endpoint/transport.
>>
>> 2014-12-24 11:29 GMT+01:00 James Green :
>> >
>> > So something like:
>> >
>> >
>> >
>> from("the.input.queue").unmarshal(cryptoDataFormat).unmarshal(jaxbMapper).process(byBusinessProcessor).marshal(cryptoDataFormat).to("the.output.queue")
>> > ?
>> >
>> > Not entirely convinced I have this mentally modelled yet...
>> >
>> > On 24 December 2014 at 10:22, David Karlsen 
>> > wrote:
>> >
>> > > Sure! The crypto is agnostic of transport and payload - stick it in
>> > between
>> > > the marshalling and the endpoint - and inbetween endpoint and
>> > unmarshalling
>> > > and you should be fit for fight.
>> > > Good luck!
>> > >
>> > > 2014-12-24 11:17 GMT+01:00 James Green :
>> > > >
>> > > > I'm looking at Camel's CryptoDataFormat and am wondering to what
>> extent
>> > > we
>> > > > might employ it.
>> > > >
>> > > > In our use-case we want multiple Camel-powered JARs to send each
>> other
>> > > > messages via a message broker. Some of message needs to remain
>> private
>> > so
>> > > > cryptography needs to be used. Right now we have routes that produce
>> > and
>> > > > consume from brokers and use jaxb classes for mapping to/from POJOs.
>> > > >
>> > > > http://camel.apache.org/crypto.html Does not really deal with
>> anything
>> > > > realistic - only mock endpoints. Can this be put into the above
>> > > > applications?
>> > > >
>> > > > Thanks,
>> > > >
>> > > > James
>> > > >
>> > >
>> > >
>> > > --
>> > > --
>> > > David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
>> > >
>> >
>>
>>
>> --
>> --
>> David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
>>
>
>

Re: Cryptography - real world use

[James Green]

OK do we need to wrap the process() with both un-marshal to a POJO
beforehand and marshal to XML/JSON afterwards, and wrap this in
decrypt/encrypt basically.

Not seeing examples showing the chaining together of marshal calls so
there's doubts in my mind reading this stuff.

On 24 December 2014 at 11:07, David Karlsen  wrote:

> Yes - you got it - maybe an jaxbUnmarshaller if your byBusinessProcessor
> returns an jaxb object.
> Get that to work first - then you might want to use
> http://camel.apache.org/binding.html as well (which is really just
> syntactic sugar to make the dataformat a property of the
> endpoint/transport.
>
> 2014-12-24 11:29 GMT+01:00 James Green :
> >
> > So something like:
> >
> >
> >
> from("the.input.queue").unmarshal(cryptoDataFormat).unmarshal(jaxbMapper).process(byBusinessProcessor).marshal(cryptoDataFormat).to("the.output.queue")
> > ?
> >
> > Not entirely convinced I have this mentally modelled yet...
> >
> > On 24 December 2014 at 10:22, David Karlsen 
> > wrote:
> >
> > > Sure! The crypto is agnostic of transport and payload - stick it in
> > between
> > > the marshalling and the endpoint - and inbetween endpoint and
> > unmarshalling
> > > and you should be fit for fight.
> > > Good luck!
> > >
> > > 2014-12-24 11:17 GMT+01:00 James Green :
> > > >
> > > > I'm looking at Camel's CryptoDataFormat and am wondering to what
> extent
> > > we
> > > > might employ it.
> > > >
> > > > In our use-case we want multiple Camel-powered JARs to send each
> other
> > > > messages via a message broker. Some of message needs to remain
> private
> > so
> > > > cryptography needs to be used. Right now we have routes that produce
> > and
> > > > consume from brokers and use jaxb classes for mapping to/from POJOs.
> > > >
> > > > http://camel.apache.org/crypto.html Does not really deal with
> anything
> > > > realistic - only mock endpoints. Can this be put into the above
> > > > applications?
> > > >
> > > > Thanks,
> > > >
> > > > James
> > > >
> > >
> > >
> > > --
> > > --
> > > David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
> > >
> >
>
>
> --
> --
> David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
>

Re: Cryptography - real world use

[James Green]

Bought this but it's pretty shallow for a real-world example, not seeing
much I didn't learn from the web site. Adding encryption/decryption where
there already exists marshalling/un-marshalling would have been far more
meaningful.

On 24 December 2014 at 10:58, Claus Ibsen  wrote:

> Scott and Jakubs book has an excellent chapter about security where
> they cover this
>
> https://www.packtpub.com/application-development/apache-camel-developers-cookbook
>
> On Wed, Dec 24, 2014 at 11:29 AM, James Green 
> wrote:
> > So something like:
> >
> >
> from("the.input.queue").unmarshal(cryptoDataFormat).unmarshal(jaxbMapper).process(byBusinessProcessor).marshal(cryptoDataFormat).to("the.output.queue")
> > ?
> >
> > Not entirely convinced I have this mentally modelled yet...
> >
> > On 24 December 2014 at 10:22, David Karlsen 
> wrote:
> >
> >> Sure! The crypto is agnostic of transport and payload - stick it in
> between
> >> the marshalling and the endpoint - and inbetween endpoint and
> unmarshalling
> >> and you should be fit for fight.
> >> Good luck!
> >>
> >> 2014-12-24 11:17 GMT+01:00 James Green :
> >> >
> >> > I'm looking at Camel's CryptoDataFormat and am wondering to what
> extent
> >> we
> >> > might employ it.
> >> >
> >> > In our use-case we want multiple Camel-powered JARs to send each other
> >> > messages via a message broker. Some of message needs to remain
> private so
> >> > cryptography needs to be used. Right now we have routes that produce
> and
> >> > consume from brokers and use jaxb classes for mapping to/from POJOs.
> >> >
> >> > http://camel.apache.org/crypto.html Does not really deal with
> anything
> >> > realistic - only mock endpoints. Can this be put into the above
> >> > applications?
> >> >
> >> > Thanks,
> >> >
> >> > James
> >> >
> >>
> >>
> >> --
> >> --
> >> David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
> >>
>
>
>
> --
> Claus Ibsen
> -
> Red Hat, Inc.
> Email: cib...@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
> hawtio: http://hawt.io/
> fabric8: http://fabric8.io/
>

Re: Cryptography - real world use

[James Green]

So something like:

from("the.input.queue").unmarshal(cryptoDataFormat).unmarshal(jaxbMapper).process(byBusinessProcessor).marshal(cryptoDataFormat).to("the.output.queue")
?

Not entirely convinced I have this mentally modelled yet...

On 24 December 2014 at 10:22, David Karlsen  wrote:

> Sure! The crypto is agnostic of transport and payload - stick it in between
> the marshalling and the endpoint - and inbetween endpoint and unmarshalling
> and you should be fit for fight.
> Good luck!
>
> 2014-12-24 11:17 GMT+01:00 James Green :
> >
> > I'm looking at Camel's CryptoDataFormat and am wondering to what extent
> we
> > might employ it.
> >
> > In our use-case we want multiple Camel-powered JARs to send each other
> > messages via a message broker. Some of message needs to remain private so
> > cryptography needs to be used. Right now we have routes that produce and
> > consume from brokers and use jaxb classes for mapping to/from POJOs.
> >
> > http://camel.apache.org/crypto.html Does not really deal with anything
> > realistic - only mock endpoints. Can this be put into the above
> > applications?
> >
> > Thanks,
> >
> > James
> >
>
>
> --
> --
> David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
>

Cryptography - real world use

[James Green]

I'm looking at Camel's CryptoDataFormat and am wondering to what extent we
might employ it.

In our use-case we want multiple Camel-powered JARs to send each other
messages via a message broker. Some of message needs to remain private so
cryptography needs to be used. Right now we have routes that produce and
consume from brokers and use jaxb classes for mapping to/from POJOs.

http://camel.apache.org/crypto.html Does not really deal with anything
realistic - only mock endpoints. Can this be put into the above
applications?

Thanks,

James

SMTP receiver

[James Green]

The components page lists camel-mail as the SMTP component (twice in fact)
but that it can only send emails.

Is there something that can listen for inbound SMTP connections?

James

Re: [ANNOUNCE] Apache Camel 2.13.3 Released

[James Green]

The [4] link below does not exist.

The download page shows 2.13.3 but is linked to 2.13.2.

On 1 November 2014 07:53, Christian Mueller  wrote:

> The Apache Camel project [1] is a powerful open source integration
> framework based on known Enterprise Integration Patterns [2].
>
> The Camel community announces the immediate availability of the new patch
> release camel-2.13.3.
>
> The artifacts are published and ready for you to download [3] either from
> the Apache mirrors or from the Central Maven repository.
> For more details please take a look at the release notes [4].
>
> Many thanks to the Camel community for the hard work.
>
> Christian
>
> [1]http://camel.apache.org/
> [2]http://camel.apache.org/enterprise-integration-patterns.html
> [3]http://camel.apache.org/download.html
> [4]http://camel.apache.org/camel-2133-release.html
>

Camel 2.14 breaks our test

[James Green]

We just upgraded from 2.13.2 to 2.14.0 and our test now hangs using the
producerTemplate to send to an ActiveMQ (5.10.0) endpoint.

The route accepts the message, sends it through JAXB and into a Processor
which doesn't seem to be executed.

We set debug logging on, and ActiveMQ seems to increment the enqueuedCount,
then there's a 20 second delay before Camel logs a timeout.

The route has been modified to log the inbound message, but this doesn't
trigger either.

It works fine if we revert back to Camel 2.13.2. Any ideas?

Thanks,

James

Re: Application naivity about endpoints

[James Green]

This is a standalone Spring app with Java configuration.

On 7 October 2014 12:21, Christian Schneider 
wrote:

> If you are deploying to a web container then you should refer to the
> ConnectionFactory using JNDI. If you are using OSGi you can use an OSGi
> service.
> This way you avoid making your route bundle depend on the jms provider.
>
> Christian
>
>
> On 07.10.2014 13:18, James Green wrote:
>
>> I want my application to connect to ActiveMQ today, and possibly RabbitMQ
>> tomorrow. Therefore I do not want anything in code to mention either - it
>> should just be a matter of altering a .properties file and restarting,
>> right?
>>
>> However we're having trouble working out how to do this without expressly
>> referring to individual connection factories in code.
>>
>> Are we missing something?
>>
>> Thanks,
>>
>> James
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>

Application naivity about endpoints

[James Green]

I want my application to connect to ActiveMQ today, and possibly RabbitMQ
tomorrow. Therefore I do not want anything in code to mention either - it
should just be a matter of altering a .properties file and restarting,
right?

However we're having trouble working out how to do this without expressly
referring to individual connection factories in code.

Are we missing something?

Thanks,

James

Re: Can unit tests be @Transactional?

[James Green]

Understood. I am trying to summarise for those of us trying to get an
initial project "up and running" as too often deep technical text can put
off the reader.

I have added the following: "Spring's transactional model ensures each
transaction is bound to one thread. A Camel route may invoke additional
threads which is where the blockage may occur. This is not a fault of Camel
but as the programmer you must be aware of the consequences of beginning a
transaction in a test thread and expecting a separate thread created by
your Camel route to be participate, which it cannot. You can, in your test,
mock the parts that cause separate threads to avoid this issue."

Hopefully this addresses your core point.


On 23 September 2014 00:23, Minh Tran  wrote:

> I think it’s important to understand the reason why your test fails, it’s
> not really camel’s fault. It's because your camel route executes your dao
> method on a separate thread. If you’re using a JMS consumer then this will
> definitely run under a separate thread.
>
> This is a spring transaction “feature”, transactions are bound to the
> current thread and if you have multiple threads then it will create
> separate transactions. Lets say you had a spring unit test purely testing
> your dao method(minus all the camel stuff) and you put @Transactional on
> the unit test. Then you did the same thing and seed the data, your test
> would run just fine because your dao would participate in the same
> transaction as your unit test. But if you change your dao to thread off and
> then execute a transaction then you’d have the same blocking issue. So the
> problem isn’t explicitly camel, it’s spring’s rule of one transaction per
> thread.
>
> Alternatively think about using a mocked dao instead and not worry about
> these transactional issues. Either by using @MockEndpointsAndSkip or inject
> via a third party mocking library like mockito. The real dao method can be
> unit tested separately.
>
> Or in your unit test, you can remove the jms component out using
> @UseAdviceWith and replace with a direct component. This will ensure no
> threading will occur due to the jms consumer when you execute the route in
> your unit test.
>
> On 23 Sep 2014, at 1:41 am, James Green  wrote:
>
> > OK - we have a working solution. Someone should document this at
> > http://camel.apache.org/transactional-client.html and
> > http://camel.apache.org/spring-testing.html since we have had many days
> of
> > trouble.
> >
> > The crux is the source here:
> >
> https://github.com/rajivj2/example2/blob/master/src/test/java/com/example/NotificationRouterIT.java
> >
> > Essentially in our case the test runner is a Spring integration test that
> > seeds data then tests a route that consumes a JMS message and processes
> it
> > in a database.
> >
> > First problem is that database access requires a transaction. We annotate
> > our Processor classes @Transactional (remembering not to do so within the
> > DAO, a common error) and crucially avoid annotating our test method
> > @Transactional. Instead, the test method creates a TransactionTemplate
> from
> > Spring, handing it the injected TransactionManager and execute the data
> > seeding operation. Finally, send a test message and assert that the sun
> > still shines.
> >
> > If the test method itself is annotated @Transactional, as Minh infers,
> the
> > seed data is held in memory until the test method completes. We were
> > expecting Camel, using the shared TransactionManager, to see this data
> but
> > instead is either hangs because of a separate transaction context, or
> just
> > doesn't see anything if no transaction is used. Programming the
> transaction
> > using the TransactionTemplate lets us commit the seed data before the end
> > of the test, allowing Camel's transaction context to see database data
> > written already.
> >
> > Improvements and corrections welcome.
> >
> >
> > On 22 September 2014 15:17, Minh Tran  wrote:
> >
> >> The reason for the hang is because Spring unit test transaction is
> >> separate to the camel transaction. The camel transaction is blocked
> waiting
> >> because the spring has uncommitted changes to the same table it is
> trying
> >> to read from.
> >>
> >> Either
> >> 1. commit the spring transaction first, drop the @Transactional and use
> a
> >> TransactionTemplate to do this OR
> >> 2. Somehow get the spring and camel to participate in the same
> transaction
> >> during the unit test. If they share the same transaction manager and
> camel
> 

Re: Can unit tests be @Transactional?

[James Green]

OK - we have a working solution. Someone should document this at
http://camel.apache.org/transactional-client.html and
http://camel.apache.org/spring-testing.html since we have had many days of
trouble.

The crux is the source here:
https://github.com/rajivj2/example2/blob/master/src/test/java/com/example/NotificationRouterIT.java

Essentially in our case the test runner is a Spring integration test that
seeds data then tests a route that consumes a JMS message and processes it
in a database.

First problem is that database access requires a transaction. We annotate
our Processor classes @Transactional (remembering not to do so within the
DAO, a common error) and crucially avoid annotating our test method
@Transactional. Instead, the test method creates a TransactionTemplate from
Spring, handing it the injected TransactionManager and execute the data
seeding operation. Finally, send a test message and assert that the sun
still shines.

If the test method itself is annotated @Transactional, as Minh infers, the
seed data is held in memory until the test method completes. We were
expecting Camel, using the shared TransactionManager, to see this data but
instead is either hangs because of a separate transaction context, or just
doesn't see anything if no transaction is used. Programming the transaction
using the TransactionTemplate lets us commit the seed data before the end
of the test, allowing Camel's transaction context to see database data
written already.

Improvements and corrections welcome.


On 22 September 2014 15:17, Minh Tran  wrote:

> The reason for the hang is because Spring unit test transaction is
> separate to the camel transaction. The camel transaction is blocked waiting
> because the spring has uncommitted changes to the same table it is trying
> to read from.
>
> Either
> 1. commit the spring transaction first, drop the @Transactional and use a
> TransactionTemplate to do this OR
> 2. Somehow get the spring and camel to participate in the same transaction
> during the unit test. If they share the same transaction manager and camel
> transaction is set to PROPAGATION_REQUIRED which is the default, this
> should just work. This assumes your unit test and camel execution is
> running under the same thread though. If not then stick to the first method.
>
> On 22 Sep 2014, at 11:51 pm, James Green  wrote:
>
> > We have a Spring project that has a unit test annotated @Transactional.
> > This uses a DAO to save a sample Entity before invoking a Camel route
> that
> > accepts a JMS message and sends it to some Processors.
> >
> > The problem we have is when the test itself is annotated @Transactional.
> > The route stops having received the message and begin performing a
> database
> > query - it literally hangs performing the SELECT. Naturally after 20s the
> > time-out is hit.
> >
> > If we remove @Transactional from the test the route continues but finds
> > nothing in the database as the initial Entity save had no effect (it
> > appears).
> >
> > So we're clearly missing something here - how should we seed test data if
> > @Transactional hangs and without it the data is not committed?
> >
> > Thanks,
> >
> > James
>
>

Corrections to Wiki

[James Green]

Apparently I don't have permission to edit the following page:

http://camel.apache.org/transactional-client.html

Could someone correct the links to the Spring website (there are several
that now 404)?

Thanks,

James