Thanks Claus, but that still doesn't let me do what I want and is
inefficient.
What it won't let me do:
I want to be able to correlate the "out" trace with the "in" trace, in
one database row without commiting the row until the route has completed.
This requires a JPA transaction to exist around each of the nodes that
are called.
I'm finding that the transaction has ended by the time of the "out" trace.
Inefficiencies:
1. It causes the construction of the new Exchange object and a bunch of
String objects that I don't want.
2. It causes the invocation of a new route, that is unnecessary.
I think it would be better to:
1. Pass the class to use as the TraceInterceptor into Tracer.
2. Break the existing TraceInterceptor into two, a base class that
tracks the RouteNodes and a subclass that implements traceExchange.
3. Change traceExchange so that it returns an Object and pass that
Object in to the call to traceExchange for "out" traces.
If you think this is a sane approach I can produce a patch for it.
Jim
I want to be able to correlate the
On 17/03/2010 19:42, Claus Ibsen wrote:
Hi
Looks like the getTracedExchange method was removed a bit later. I
have adde a ticket to track this
https://issues.apache.org/activemq/browse/CAMEL-2556
On Wed, Mar 17, 2010 at 7:06 PM, Jim Talbut<jtal...@spudsoft.co.uk> wrote:
I'm sorry, but I'm afraid I must be missing something.
You say "just use your own JPA code to persist the message" like it's a
simple thing to do, but it doesn't appear to be.
The out of the box TraceInterceptor hard codes the canonical name of the
class that it's loading, and loads it excplicitly, so I can't intercept that
other than by providing another class in the same package.
That's nasty and hacky and still doesn't solve the problem because it just
gets called by the IntrospectionSupport, so I don't get the opportunity to
access the Exchange object.
That led me to try to replace the TraceInterceptor with my own, but that is
complicated because the TraceInterceptor also builds up the TracedRouteNodes
(and because I can't remove the out of the box TraceInterceptor).
It seems to me that there should be a way to subclass the TraceInterceptor
and just get access to the pre and post Exchange object to log it - that
would need to be set on the default Trace object before any routes get
created.
But as I said, I must be missing something.
Jim
On 13/03/2010 09:06, Claus Ibsen wrote:
You can just use your own JPA code to persist the message instead of
the out of the box feature.
On Sat, Mar 13, 2010 at 9:54 AM, Jim Talbut<jtal...@spudsoft.co.uk>
wrote:
On 13/03/2010 07:36, Claus Ibsen wrote:
On Sat, Mar 13, 2010 at 8:27 AM, Jim Talbut<jtal...@spudsoft.co.uk>
wrote:
Willem,
Ah.
I still have no idea how the TypeConverter is being called, but it's
working
great :).
I can make my SOAP:Fault converter into an interceptor, which has the
benefit of making the routes simpler and thus more understandable by my
clients.
However if I do so the Tracer (using JPA) does not record the altered
SOAP:fault.
I have got tracer.setTraceInterceptors( true ); but that doesn't seem
to
make any difference, neither does the order in which the interceptors
are
added.
Is it possible to make the Tracer record the output from another
interceptor?
If it isn't I'll just log the change myself.
When the Tracer logs an exception it's just using toString, which
misses
out
on a lot of information in a soap:fault.
I tried writing a TypeConverter for
org.apache.cxf.binding.soap.SoapFault,
but that's not being called.
Is there a way to make the Tracer use a TypeConverter for logging
exceptions?
You can implement your own
org.apache.camel.processor.interceptor.TraceFormatter and format the
traced message exactly how you like it.
TraceFormatter is just for logged tracing - I'm using JPA.
Thanks.
Jim
