I see the source and the JIRA reflecting the fact that the code should
support more Xstream converters / aliases. All good.
One small thing... I would just like to tweak the output to tweak the
package name.
In Xstream I can do the following:
XStream xstream = new XStream();
In Spring I can do this:
I cannot see how to do that using the new Properties. Any advice?
Thanks
Ray
--
View this message in context:
http://camel.465427.n5.nabble.com/2-4-0-Properties-via-URL-tp2651118p2651118.html
Sen
Doh! RTFM for me Sorry to have bothered you ...
--
View this message in context:
http://camel.465427.n5.nabble.com/2-4-0-Properties-via-URL-tp2651118p2651150.html
Sent from the Camel - Users mailing list archive at Nabble.com.
I have this all working nice now:
In the Camel Spring context file:
http://camel.apache.org/schema/spring";>
In the Jetty configuration file:
http://jetty.mortbay.org/configure.dtd";>
org.mortbay.jetty.webapp.WebInfConfiguration
Any more news on this?
--
View this message in context:
http://camel.465427.n5.nabble.com/Abstracting-Routes-using-Components-tp3234703p3360406.html
Sent from the Camel - Users mailing list archive at Nabble.com.
The program wants to access the queues via jndi - and this is how you get jetty
to expose those features using jndi.
You don't have to use jndi of course, this was just as example for cases where
that is desirable or needed.
Best regards
Ray
Sent from my iPad
On 27 Feb 2013, at 13:29, "naksh
Folks
I am confused by the documentation:
Time in millis that an aggregated exchange should be inactive before its
complete. Camel has a background task that runs once a minute to check for
inactive aggregated exchanges. This option can be set as either a fixed
value or using an Expression which
I want to get data from three sources:
from(fromURI).multicast().to("seda:coreVehicleData",
"seda:warrantyVehicleData", "seda:accessoryVehicleData");
from("seda:coreVehicleData").to("bean:coreVehicleData").to("seda:vehicleDataAggregator");
from("seda:warrantyVehicleData").
I will fire up the PDF reader ;-)
Thanks Claus
--
View this message in context:
http://camel.465427.n5.nabble.com/aggregator-completionTimeout-tp4283669p4283687.html
Sent from the Camel - Users mailing list archive at Nabble.com.
This looks like issue #CAMEL-1549 but I have tried with 2.4.0 and 2.7.0 so I
guess there is no regression and there must be something else wrong.
Any ideas on where I can look?
Thanks
Ray
[03-05-2011 12:05:39:299] INFO DefaultCamelContext - Apache Camel 2.7.0
(CamelContext: TQS_JMS_BRIDGE) star
I was originally getting the queuename from a String (via JNDI) but needed to
create an Endpoint instead..
Now it all works nicely :)
Thanks
Best regards
Ray
--
View this message in context:
http://camel.465427.n5.nabble.com/Odd-stacktrace-when-starting-route-tp4366854p4367058.htm
Here is a Processor that works on ZIP files:
import org.apache.camel.util.ExchangeHelper;
import org.apache.camel.util.IOHelper;
public class ZipFileSplittingProcessor implements Processor {
public void process(Exchange exchange) throws Exception {
InputStream is = ExchangeHelper.get
Claus,
Just thought I would follow up.
I don't know if this counts as a contribution, but I ended up doing this as
a splitter as in:
from(fromUri)
.split().method(OuterZipFileDecompressingSplitter.class,
"split")
.streaming()
.parallelPro
Again, just a follow up note, I simplified this in the end as in:
public class GetVehicleData extends RouteBuilder {
private String fromURI;
@Override
public void configure() throws Exception {
from(fromURI).multicast(new
VehicleDataAggregator()).stopOnException()
OK. It's done
https://issues.apache.org/jira/browse/CAMEL-4024
--
View this message in context:
http://camel.465427.n5.nabble.com/FTP-to-HDFS-large-gzipped-files-tp3192431p4433386.html
Sent from the Camel - Users mailing list archive at Nabble.com.
I had a user today that had camel blow up because he was sending a message
body of 96Mb and had the tracer on. By default the tracer outputs bodies so
he ran out of memory ;-)
Quite an easy fix to configure a formatter and turn off the printing of
message bodies... but it made me think, shouldn't
I think the point is that showBody should be false or at least limited in
length by default
--
View this message in context:
http://camel.465427.n5.nabble.com/tracing-large-messages-tp4921360p4921789.html
Sent from the Camel - Users mailing list archive at Nabble.com.
I would like to clarify something regarding Camel exeption handling
>From the IBM manuals:
"The WebSphere® MQ queue manager keeps a record of the number of times that
each message has been backed out. When this number reaches a configurable
threshold value, the message consumer requeues the m
18 matches
Mail list logo