Hi
If you are using maven you can exclude the quartz from camel-quartz and
include the right version of quartz that you want.
BTW, what kind of trouble did you get when you built the trunk ?
Willem
----------------------------------
Apache Camel, Apache CXF committer
Open SOA http://www.fusesource.com
Blog http://willemjiang.blogspot.com
Tiwtter http://twitter.com/willemjiang
Ingo Düppe wrote:
Fine, I currently work on the 2.3.0 version of /tags. Because I have
some trouble to build the trunk.
Ingo
On Tue, Jun 22, 2010 at 4:13 PM, Ingo Düppe <mailing-li...@dueppe.com> wrote:
Hi,
does any reason exists for not upgrading camel-quartz to use the current
quartz version 1.8.1?
Its been upgraded to 1.8.2 on trunk.
Regrads
Ingo
Am 04.06.10 14:36, schrieb Ingo Düppe:
Hi Claus,
fine, I might possibly have some time on next monday to create a patch
for it.
If not then in two weeks after my vacation I will create a patch for it.
Regards
Ingo
Am 04.06.10 06:55, schrieb Claus Ibsen:
Hi Ingo
On Thu, Jun 3, 2010 at 10:30 PM, Ingo Düppe <mailing-li...@dueppe.com> wrote:
Hi Claus,
well I'm not sure if it is right. But I guess if the trigger is marked
as volatile it will be automatically removed within in the database.
Normally volatile jobs won't be stored in a db but in a cluster
environment they will be.
The problem with camel is, that I cannot define an volatile trigger like
"quartz://trigger?job.volatility=true&cron..." and also define a cluster
environment within the quartz.properties. This is because CamelJob isn't
serializable.
As I mentioned I haven't dig into it very deep. I just wanted to be
sure, that I didn't miss something obviously before I invest time into it.
Ah thanks for point this out. I have created a ticket
https://issues.apache.org/activemq/browse/CAMEL-2788
To improve camel-quartz so you can set that volatile option and also
see what we can about the quartz.properties etc.
And to see how we can serialize CamelJob
Regards
Ingo
Am 03.06.10 15:08, schrieb Claus Ibsen:
Hi
If you have the app crash using kill -3 / -9 and then start it again
and expect quartz to recover and it does not.
Then I think you should ask at the Quartz user forum about this.
And maybe you can create a plain example with pure Quartz to not
pollute the example with Camel as the Quartz guys would just say its a
Camel problem.
Just as I say its most likely a Quartz problem :)
And if there is something that must be configured / tweaked in Quartz
to have this working then let us know. Maybe there is something we can
do easier in camel-quartz for that.
On Thu, Jun 3, 2010 at 12:08 PM, Ingo Düppe <mailing-li...@dueppe.com> wrote:
Am 01.06.10 08:37, schrieb Claus Ibsen:
On Mon, May 31, 2010 at 6:48 PM, Ingo Düppe <mailing-li...@dueppe.com> wrote:
I forgot to mention that I currently use version 2.2.0.
Can you create a small sample application that demonstrates this? Then
its much easier to look into it to see what / if we can do in Camel.
- Ingo
Sure, i created a small example that you can find at
http://dl.dropbox.com/u/4043036/quartz-cluster.tar.gz.
It contains just a small JUnit Test Case (see below). The test runs fine
as long you execute the whole test. As I find out yesterday, quartz
deletes some information within the database on a clean shutdown.
So the next test run will also run fine.
But if you kill the running test - to simulate a server crash - the next
test run will end up with an exception.
So how do I handle such inconsist data on startup of camel?
Regards
Ingo
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(
locations = {
"classpath*:context-test.xml"
}
)
public class QuartzClusterTest extends TestCase {
@Autowired
private CamelContext camelContext;
@EndpointInject(uri = "mock:result")
protected MockEndpoint resultEndpoint;
@Test
@DirtiesContext
@Repeat(value=2)
public void testTriggering() throws Exception {
camelContext.addRoutes(new QuartzRouteBuilder());
resultEndpoint.setMinimumExpectedMessageCount(5);
resultEndpoint.setResultWaitTime(5000L);
resultEndpoint.assertIsSatisfied();
}
public static class QuartzRouteBuilder extends RouteBuilder {
@Override
public void configure() throws Exception {
from("quartz://trigger?stateful=true&cron=0/1+*+*+*+*+?").to("mock:result");
}
}
}
