camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Müller <christian.muel...@gmail.com>
Subject Re: Camel Quartz component and the startDelayedSeconds attribute
Date Fri, 07 Sep 2012 11:22:01 GMT
Thanks for the detailed explanation Claus. I create a JIRA for it [1] and
will go ahead.

Some details about our "problem":
We face this only in our unit tests where we use "interseptSendToEndpoint"
to mock an endpoint and throw an exception to test the exceptional use
case. Because the Quartz component sent the trigger message before we could
modify the route in our unit test, we have to delay it. We could solve the
problem by moving this "interseptSendToEndpoint" into the setUp method, but
this requires us to have a separate unit test for each different
exceptional unit test.

[1] https://issues.apache.org/jira/browse/CAMEL-5577

Best,
Christian

On Fri, Sep 7, 2012 at 1:02 PM, Claus Ibsen <claus.ibsen@gmail.com> wrote:

> On Fri, Sep 7, 2012 at 12:44 PM, Christian Müller
> <christian.mueller@gmail.com> wrote:
> > Is there any reason why we don't support 'startDelayedSeconds' as URL
> > option? At present, we only supporting this by directly setting this in
> the
> > component:
> > <bean id="quartz"
> class="org.apache.camel.component.quartz.QuartzComponent">
> >     <property name="propertiesFile"
> > value="com/mycompany/myquartz.properties"/>
> > </bean>
> >
> > If not, I will go ahead and fix it, so that we can use it as URL option
> like
> > quartz://myGroup/myTimerName?startDelayedSeconds=5
> >
>
> Its a component level option only, as the scheduler is tied to the
> lifecycle of the component.
>
> So you can't really use it on an endpoint. What if you have 2+
> endpoints, each with a different value of that option.
> There is only 1 scheduler on the component.
>
> A "trick" could be though to allow endpoint to configure this option
> on the component, if the component hasn't been started etc.
> Then it makes it easier for end users, as they dont need to setup a
> <bean> for the quartz component.
>
> And if 2 endpoints tries to configure the same option, we could barf
> and fail, and tell it has already been configured? Or
> we could log a WARN that we override the value etc.
>
> So despite being a component option, it could maybe make it nice to
> have in endpoint as well, so ppl dont have to configure the <bean>
> just for that option. And it makes it simpler if you have 1 quartz
> endpoint.
>
> > Best,
> > Christian
> >
> > --
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>



--

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message