Dirk,
Thanks for the help. The following endpoint is what is the job being persisted:
<quartz:inbound-endpoint jobName="pollModemServiceJob" cronExpression="${poll.modems.cron.expression}">
<property key="method" value="findAll"/>
<quartz:event-generator-job />
</quartz:inbound-endpoint>
So far I have had to add Serialization to a number of classes. I am not sure why these classes are being persisted to be honest with you. I have had to Serialize DefaultMuleContext obviously, but I have also had to add Serialization to a number of ExpressionEvaluators such as org.mule.expression.MuleExpressionEvaluator. Why are these being persisted?
I am more than happy to provide any help I can to resolve this issue. I can continue adding Serialization to classes, but it concerns me that doing this will prevent me from upgrading to newer versions of Mule moving forward.
Thanks,
Rob
Dirk Olmes-5 wrote:
rstacy@zcorum.com wrote:
> Hi All,
>
> I am running Mule 2.2.1 and trying to implement the clustered JDBC store for
> quartz.
>
> When mule starts up and trys to create my quartz jobs I get the following
> exception:
[...]
>
> After reading the exception it would lead me to believe that the
> DefaultMuleContext is the problem since it is not implementing serializable.
> I am hoping to disprove this as I don't want to have to modify Mule code to
> cluster quartz, nor should I have to. I have a hard time believing that
> more people have not tried to cluster quartz in Mule.
Obviuosly nobody ever tried :-)
We're currently reviewing serialization of various classes in Mule so
while I'm at it I could take a look. But only if you help a bit: what's
the root object that will be persisted?
-dirk
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
