You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Barry Kaplan <gr...@memelet.com> on 2009/12/01 00:10:27 UTC
No camel-clock? How does one test?
Am I missing the abstraction of a camel clock? I've tried to start using the
new Sampling Throttle and notice that it uses java.lang.System.nanoTime()
directly. So I'm guessing all other camel components go right to System for
time...
What I'm looking for (needing) is something like in Drools, where they
define a clock with various implementations (eg, pseudo, system, fixed).
This is key also for running after the fact simulations and replay of data
into our system.
--
View this message in context: http://old.nabble.com/No-camel-clock--How-does-one-test--tp26583664p26583664.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: No camel-clock? How does one test?
Posted by Barry Kaplan <gr...@memelet.com>.
Claus Ibsen-2 wrote:
>
> BTW What would the API of the Clock be?
>
The only api that would be "needed" for current code could simply mirror
System.*, eg:
interface CamelClock {
public long currentTimeMillis();
public long nanoTime();
}
Of course this won't help with timers and the like.
--
View this message in context: http://old.nabble.com/No-camel-clock--How-does-one-test--tp26583664p26618836.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: No camel-clock? How does one test?
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Dec 1, 2009 at 8:33 PM, Barry Kaplan <gr...@memelet.com> wrote:
>
>
> James.Strachan wrote:
>>
>> I guess it could be injected via Ioc? Or available on the CamelContext I
>> guess?
>>
>
> But there is no camel wide IOC in place, is there? I look if the
> CamelContext is available in the places where the CamelClock is need. (Now
> if only I didn't have play "find my non-published dependency" every time I
> do an svn-update ;-)
>
It sounds as if the clock is for internal EIPs, processors and whatnot
and to aid in testing and potential new use cases in the future.
In most cases the CamelContext is the container with the various
pieces configured. And its always accessible from EIPs and the likes.
So I bet its the best place to offer the Clock.
However its also exposed to end users so I wonder if they need to work
with such a clock?
BTW What would the API of the Clock be?
> --
> View this message in context: http://old.nabble.com/No-camel-clock--How-does-one-test--tp26583664p26597741.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: No camel-clock? How does one test?
Posted by Barry Kaplan <gr...@memelet.com>.
James.Strachan wrote:
>
> I guess it could be injected via Ioc? Or available on the CamelContext I
> guess?
>
But there is no camel wide IOC in place, is there? I look if the
CamelContext is available in the places where the CamelClock is need. (Now
if only I didn't have play "find my non-published dependency" every time I
do an svn-update ;-)
--
View this message in context: http://old.nabble.com/No-camel-clock--How-does-one-test--tp26583664p26597741.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: No camel-clock? How does one test?
Posted by James Strachan <ja...@gmail.com>.
2009/12/1 Barry Kaplan <gr...@memelet.com>:
> Looking thru 2.1, there really aren't too many places where System.* time
> methods are used. Would Camel be interesting in patch that provides a clock
> abstraction (with just the two System.* time methods) where the default
> implementation would be System.*?
Sounds good to me! :)
> If so, what would be the camel way of providing access to the CamelClock to
> components? Via a static? Via Service (assuming that only components that
> extend Service would need the clock)? Or...?
I guess it could be injected via Ioc? Or available on the CamelContext I guess?
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
Re: No camel-clock? How does one test?
Posted by Barry Kaplan <gr...@memelet.com>.
Looking thru 2.1, there really aren't too many places where System.* time
methods are used. Would Camel be interesting in patch that provides a clock
abstraction (with just the two System.* time methods) where the default
implementation would be System.*?
If so, what would be the camel way of providing access to the CamelClock to
components? Via a static? Via Service (assuming that only components that
extend Service would need the clock)? Or...?
--
View this message in context: http://old.nabble.com/No-camel-clock--How-does-one-test--tp26583664p26584617.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: No camel-clock? How does one test?
Posted by Hadrian Zbarcea <hz...@gmail.com>.
There are two abstractions of a clock. One is the camel-timer, the
other one camel-quartz. The model is not as sophisticated as the
Drools one, and I wonder if it should be. It sounds interesting though.
If you host camel in servicemix (which we recommend) there is a
servicemix-drools component that may help you (I never used it myself).
Cheers,
Hadrian
On Nov 30, 2009, at 6:10 PM, Barry Kaplan wrote:
>
> Am I missing the abstraction of a camel clock? I've tried to start
> using the
> new Sampling Throttle and notice that it uses
> java.lang.System.nanoTime()
> directly. So I'm guessing all other camel components go right to
> System for
> time...
>
> What I'm looking for (needing) is something like in Drools, where they
> define a clock with various implementations (eg, pseudo, system,
> fixed).
> This is key also for running after the fact simulations and replay
> of data
> into our system.
> --
> View this message in context: http://old.nabble.com/No-camel-clock--How-does-one-test--tp26583664p26583664.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>