Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Message-ID: <1227802008.6531269891548402.JavaMail.jira@brutus.apache.org>
Date: Mon, 29 Mar 2010 19:39:08 +0000 (UTC)
From: "Jim Talbut (JIRA)" <jira@apache.org>
To: camel-dev@activemq.apache.org
Subject: [jira] Commented: (CAMEL-2563) The Trace mechanism is inflexible
 and inefficient - specifically it doesn't enable custom tracing around a
 node.
In-Reply-To: <78257883.18211269005150642.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/activemq/browse/CAMEL-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=58551#action_58551 ] 

Jim Talbut commented on CAMEL-2563:
-----------------------------------

@Claus,
Thanks, fair point.

I've pulled back slightly from the previous patch to make it slightly tighter, but I need more unit tests for it.
When it's done the options will be (in order of increasing complexity):
1. Use the standard v2.2 features, these will be completely unchanged in behaviour and won't be implemented using my new features.
   This guarantees backward compatibility and makes the change a bit smaller.
2. Specify your own JpaTraceEventMessageClassName as a property on the Tracer.
   This gives easy freedom of the database structure/naming and allows you to add new fields that can be calculated without reference to the exchange (the host name is one example).
   This does not give you the ability to query the Exchange object and still uses the v2.2 infrastructure.
3. Write a handler class that implements the TraceHandler interface and specify it as a property on the Tracer.
   This gives direct access to the Exchange object with no other infrastructure, the downside is that the TraceHandler is shared across all routes/nodes/threads.
4. Write a handler class and a TraceInterceptorFactory object, then in the TraceInterceptorFactory create a new TraceInterceptor (using the out of the box class) but after creation add your own TraceHandler instance.
   This sounds complex, but is really simple and allows you to create your own TraceHandler instance per node, providing direct access to the Exchange with no threading worries and without risk of breaking the TraceInterceptor.
5. Write your own subclass of the TraceInterceptor and a TraceInterceptorFactory object that instantiates it.
   This provide the ultimate control, but plenty of opportunity for breaking the TraceInterceptor.

All of these should be fully configurable from Spring - my holdup now is that I need tests for all of them and I'm not clear on how to test spring configurations from the camel unit tests.

> The Trace mechanism is inflexible and inefficient - specifically it doesn't enable custom tracing around a node.
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-2563
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-2563
>             Project: Apache Camel
>          Issue Type: Improvement
>          Components: camel-core
>    Affects Versions: 2.3.0
>         Environment: All.
>            Reporter: Jim Talbut
>            Priority: Minor
>             Fix For: Future
>
>         Attachments: tracechanges.diff, tracechanges.diff, tracechanges.diff
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> 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.
> 4. Give the Tracer a payload object that can be used to pass information to the TraceInterceptor.
> 5. Change the various trace* functions to take in and return a payload Object.
> Custom users could then dervice from TraceInterceptor and override the trace* functions as necessary (probably just traceExchange).
> I'm working on a patch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.