Thanks for the hint, but unfortunately we stick to 2.6.0 with this service in the time being.
Best, Christian On Fri, Sep 7, 2012 at 1:28 PM, Claus Ibsen <[email protected]> wrote: > Hi > > If you use a recent version of Camel then in the unit test you can > override the isUseAdviceWith method and return true. > So bottom of: > http://camel.apache.org/advicewith.html > > Then it ought to defer starting Camel, and you can do your > interceptors and whatnot. And then start Camel. > > > On Fri, Sep 7, 2012 at 1:22 PM, Christian Müller > <[email protected]> wrote: > > 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 <[email protected]> > wrote: > > > >> On Fri, Sep 7, 2012 at 12:44 PM, Christian Müller > >> <[email protected]> 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: [email protected] > >> Web: http://fusesource.com > >> Twitter: davsclaus, fusenews > >> Blog: http://davsclaus.com > >> Author of Camel in Action: http://www.manning.com/ibsen > >> > > > > > > > > -- > > > > -- > Claus Ibsen > ----------------- > FuseSource > Email: [email protected] > Web: http://fusesource.com > Twitter: davsclaus, fusenews > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen > --
