On Fri, Apr 27, 2012 at 3:32 PM, Reynald wrote:
> Hi Claus,
>
> Thanks for the promptness!
>
>> So you decouple a servlet request by submitting a job to a quartz
>> scheduler. The scheduler will trigger the job
>> sometime in the future, and the job is to send a message to a queue?
>> Why do yo
Hi Claus,
Thanks for the promptness!
> So you decouple a servlet request by submitting a job to a quartz
> scheduler. The scheduler will trigger the job
> sometime in the future, and the job is to send a message to a queue?
> Why do you want to do that?
We want to integrate our calendar/proce
Hi
On Wed, Apr 25, 2012 at 5:11 PM, Reynald wrote:
> Hi all,
>
> I'm reading through all the documentation of Camel. I'm really excited but
> due to the extent of the docs and my lack of experience on it, I'd
> appreciate if somebody give some guidelines on the following scenario. I
> want to ke
On 15 April 2012 08:56, Claus Ibsen wrote:
> On Sat, Apr 14, 2012 at 11:35 PM, Bob Jolliffe wrote:
>> Hi Claus
>>
>> On 13 April 2012 16:12, Claus Ibsen wrote:
>>> Hi
>>>
>>> What runtime do you use? Tomcat, Standalone, OSGi etc?
>>
>> Both tomcat and jetty in different settings.
>>
>>> Camel sh
On Sat, Apr 14, 2012 at 11:35 PM, Bob Jolliffe wrote:
> Hi Claus
>
> On 13 April 2012 16:12, Claus Ibsen wrote:
>> Hi
>>
>> What runtime do you use? Tomcat, Standalone, OSGi etc?
>
> Both tomcat and jetty in different settings.
>
>> Camel should pickup that bean automatic as it lookup the registr
Hi Claus
On 13 April 2012 16:12, Claus Ibsen wrote:
> Hi
>
> What runtime do you use? Tomcat, Standalone, OSGi etc?
Both tomcat and jetty in different settings.
> Camel should pickup that bean automatic as it lookup the registry by type.
> As shown here
> http://camel.apache.org/advanced-config
Hi
What runtime do you use? Tomcat, Standalone, OSGi etc?
Camel should pickup that bean automatic as it lookup the registry by type.
As shown here
http://camel.apache.org/advanced-configuration-of-camelcontext-using-spring.html
And does you class really have the correct name? It starts with impo
Aha, don't worry about those deprecated methods as they're all doubly
declared both on:
org.apache.camel.CamelContext
And
org.apache.camel.model.ModelCamelContext
So just reference your context as ModelCamelContext, then you should be
fine. At [1] you see a similar question. The corresponding J
Thanks Babak for the suggestions. A few queries in line ...
On 13 April 2012 14:00, Babak Vahdat wrote:
> Hi
>
> You could look at [1] to see how easily you can add routes from XML, and
> check the commit log at the bottom of that link for some examples.
Yes I have seen this and have tried (suc
Hi
You could look at [1] to see how easily you can add routes from XML, and
check the commit log at the bottom of that link for some examples.
You could also add routes dynamically at runtime [2] using Camel's JMX
ManagedCamelContext MBean.
[1] http://camel.apache.org/loading-routes-from-xml-fil
Brian, Mirko:
Thanks much for your help. I got it to work at last... whew! :-) yaay!
-Anita
--
View this message in context:
http://camel.465427.n5.nabble.com/Newbie-question-tp4896854p4899690.html
Sent from the Camel - Users mailing list archive at Nabble.com.
You don't need to code a servlet yourself, you just declare to consume from the
camel servlet like this:
After the from you do whatever processing you need, keeping in mind that camel
maps the http request headers to the exchange.in.headers and the http body to
exchange.in.body
Read the came
I'm not sure how did you remove the Jetty endpoint?
>From the camel route configuration, I can just tell that the Jetty endpoint
is used to accept the request from http://localhost:8081/msgs, just like the
file endpoint does.
If you want to remove the Jetty endpoint, you need remove the this whole
How about creating a processor that calls upon the filter and captures the
resultant exchange? Then if that goes well use a producer template to send
out both the resultant exchange and the original exchange concurrently.
No transaction required and you'll achieve higher throughput.
--
View this
I thought that calling conn.rollback() would sort out the DB side and the
thrown SQL exception would sort out the JMS side.
I am clearly missing something rather important here, so I will take your
advice and spend some time looking into Spring.
On Fri, Feb 20, 2009 at 7:26 PM, Claus Ibsen wr
Hi
Well you gotta get some TX manager in the mix. Otherwise how would you
ensure that the JMS and DB participates in the same transaction?
Of couse the Camel JMS consumer will be able to rollback if there is
an exception thrown, but that does still not ensure that the JMS and
DB are managed in th
Hi,
Your approach is valid and will work as expected. However there is no need
for this header field to be added.
I would add an exception clause to deal with any exceptions thrown by the
DBFilter. For more on exception handling check out
http://camel.apache.org/exception-clause.html
http://cam
Try filtering using a custom bean expression instead. Something like this
from("jms:queue:testQueue").filter().method("myTestDBFilter",
"hasNewContent").to("jms:queue:otherTestQueue");
Where your bean would be something like this
class TestDBFilter {
public static boolean hasNewConte
18 matches
Mail list logo
