ter
> Apache Servicemix PMC Member
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
>
>
>
> On Friday, January 19, 2018, 7:46:44 AM GMT+1, Paul Gale
> wrote:
>
>
>
>
>
> Funny that, I never had any problems editing the wiki.
no
wrote:
> The only thing to consider here is that having a site separated from repo
> with docs never really worked and it's ALWAYS out of sync.
> Inviato da Yahoo Mail su Android
>
> Il ven, 19 gen, 2018 alle 2:00, Paul Gale ha
> scritto: >I generally agree that the doc
s which are
> propagated provide a mechanism to have very late binding on route endpoints.
> Morph into RAAS (Routes as a Service)? TNBT?? Perhaps a step too far at the
> moment but something to counter the “clicks v code” objections I get from
> customers. How far has Mulesoft push
to be the case in most projects,
> especially in Camel. Most project maintainers, myself included, would trip
> over themselves to help contributors interested in re-writing docs that we
> ourselves wrote. Plus, how is that any different than contributing changes
> to *code* that someone e
hat is concerning? And with the exception of the eventual
> merge/commit, why would that limit the documentation pool to committers
> only? From my experience, the Camel committer team have always been
> incredibly quick to respond to and work through pull requests...
>
>
>
> O
ing every
> single page) mentioning the stale state and future plans. Better yet, could
> we consider setting up a redirect sooner rather than later, even if that's
> temporarily to GitHub (maybe
> https://github.com/apache/camel/blob/master/docs/user-manual/en/SUMMARY.md)?
>
>
>
Can someone with the relevant privileges investigate why snippets
being referenced by the Camel wiki appear to be universally broken and
what can be done to fix them? They are an integral part of the
documentation and need to work. At a glance I can see that most
snippets reference source files fro
Hi,
I just saw this at the top of the Camel Jetty page: "The producer is
deprecated - do not use. We only recommend using jetty as consumer (eg from
jetty)".
Can someone explain why this decision was made? It doesn't say what should
be used in its place. I do hope that it's not HTTP4 et al as th
Hi Ryan,
It seems to be that you'd be better off breaking up some of those routes;
they seem very large and monolithic. Prefer composed routes instead, each
with discrete error handlers. Currently you're looking for a fault through
a large slice of functionality. The use of the doCatch clauses is
>Do I also need to change the Camel side to publish to a queue instead of a
topic?
No you do not.
Seems perhaps that you're confused. The fact that you're using a virtual
topic, rather than a durable topic subscription, doesn't change the fact
that messages should still be published to a topic. A
There's still a problem with your code. This:
String number =
consumerTemplate.receiveBody("activemq:topic:Consumer.A.VirtualTopic.bar",
String.class);
must be changed to this:
String number =
consumerTemplate.receiveBody("activemq:queue:Consumer.A.VirtualTopic.bar",
String.class);
Despite bein
I believe your client should look like this:
String msg =
consumerTemplate.receiveBody("activemq:queue:Consumer.blah.VirtualTopic.BAR",
String.class);
...where 'blah' is replaced with an identifier (that does not contain
period characters) of your choosing.
Thanks,
Paul
On Tue, Apr 14, 2015 at
ding a "depends-on" attribute to the
> definition to tell Spring the order to start/stop things...
>
> xmlns="http://camel.apache.org/schema/spring"; depends-on="activemq,
> remote.activemq">
>
>
> Paul Gale wrote
> > Hi,
> >
&
Hi,
ActiveMQ 5.9.1
Camel 2.13.1
Spring 3.2.5
OS: RHEL 6.3
Tanuki Java Service Wrapper 3.5.24
When I shutdown my broker inside which a Camel context is containing just
one route (shown below) it hangs. The route connects to a topic on a remote
broker and writes out the messages to a queue on the l
Hi,
I have written an embedded Camel client in JRuby. I've been trying to use
Camel's JMX annotations on my bean, without success. (I've implemented
beans in Java (on Java projects) in the past using Camel's JMX annotations
without a problem.)
I was wondering how can I leverage Camel's built in J
Hi,
Is connection pooling needed when sending to an _embedded_ ActiveMQ broker
from Camel using the VM protocol vm://? If so, why?
According to page 288 of the Camel In Action book the VM protocol bypasses
the TCP stack tends to make me think not.
The example given here http://camel.apache.org/a
claus.takeLeafFrom(christian.getBook());
:)
On Mon, Mar 31, 2014 at 5:09 PM, Christian Posta
wrote:
> On Fri, Mar 28, 2014 at 10:06 AM, Paul Gale wrote:
> > Hi,
> >
> > I have an embedded Camel client that contains a single route. All
> messages
> > the route c
Hi,
I have an embedded Camel client that contains a single route. All messages
the route consumes have their JMSXGroupID property set.
What I need to know is how message grouping behaves in the context of
concurrent consumers and how does the choice of the prefetch buffer size
come into play (whe
er (therefore any
message sent to a DLQ would just stay there)? Is there a simpler
approach that I've overlooked?
Thanks,
Paul
On Wed, Jan 15, 2014 at 4:06 AM, Claus Ibsen wrote:
> On Tue, Jan 14, 2014 at 4:59 PM, Paul Gale wrote:
>> Hi,
>>
>> What is the recommended
Hi,
What is the recommended way to handle the following scenario.
I intend to embed Camel in a client (a standalone Java process). The
client receives messages from a queue on an ActiveMQ 5.8.0 broker. The
client's processor is expected to save each message to a database
(amongst other things).
Hi Geoff,
You could try something like this which is working for us:
Put the following entry (or similar) in your pom.xml file:
com.tibco.ems
tibjms
5.0.0
runtime
and th
Hi,
(Apologies if this has been covered already...I did search but didn't find
anything explicit.)
Is Camel 2.12.1 known to be compatible with ActiveMQ 5.8.0?
I am looking to upgrade the version of Camel (2.10.3) that shipped with
ActiveMQ 5.8.0 to 2.12.1.
(I realize that changes are required f
; Your use case doesn't fit with the concept of messaging, lightweight
> DB storage is better suited. While you can find ways to implement it
> on AMQ, the solution will be suboptimal.
> We offer a camel-redis component as of Camel 2.11. You can use it with
> camel-jms to brid
ppreciated.
Thanks,
Paul
On Mon, Feb 25, 2013 at 4:32 PM, Christian Müller <
christian.muel...@gmail.com> wrote:
> You have to build your own solution on top of what Camel already
> provides...
>
> Best,
> Christian
>
> Sent from a mobile device
> Am 25.02.2
24 matches
Mail list logo
