springframework-developer

[Springframework-developer] Quartz support

[<jue...@we...>]

Everybody,
=20
I've revived my Quartz support classes for Spring today. They emerged =
from a job scheduling consulting project I did in autumn 2003. We have =
concrete needs for this now at werk3AT, thus the revival: It's about =
quite simple cron-style scheduling of application jobs.
=20
The basic idea is to set up a Quartz Scheduler via a =
SchedulerFactoryBean, also allowing to register scheduled jobs there via =
a <list> of <refs> to ScheduledJobDefinition beans. A =
ScheduledJobDefinition is just a simple combination of a Quartz =
JobDetail and a Quartz Trigger.
=20
ScheduledJobDefinition bean implementations include:
- DefaultScheduledJobDefinition, allowing to use any implementation of =
Quartz' Job interface with a declaratively configured job data map and =
cron trigger
- MethodInvokingJobDefinition, allowing to specify a method of a =
Spring-managed bean to execute as job (completely declarative, without =
the need for implementing a custom Job object), with a cron trigger.
=20
Both job definition beans can link in a separate Quartz Trigger instance =
instead of a cron expression; DefaultScheduledJobDefinition can also =
link in a separate Quartz JobDetail instance instead of a job class.
=20
That's all there is: A simple declarative way of using Quartz within =
Spring. Typically no rescheduling or the like: All schedules are set up =
on context startup, defined as bean definitions. Of course, you can also =
fetch the Scheduler instance and perform any custom scheduling, instead =
of using preconfigured ScheduledJobDefinition beans.
=20
The typical usage scenario are low-level jobs within an application, =
like data synchronization or storage cleanup - all predefined jobs that =
are just customized by an administrator. Fits nicely into Spring's =
application context model; most jobs will simply delegate to =
Spring-managed business objects.
=20
I expect to have this polished by the end of the week, as we need it at =
werk3AT quite urgently. I'd like to include this already in Spring 1.0 =
final, as it's just 6 pretty simple classes (yes, I know - feature =
freeze - never mind ;-). The main question is where to put it: I suggest =
"org.springframework.scheduling.quartz".
=20
If there are no general objections, I'll commit it by the end of this =
week, for review within the next week - still plenty of time before 1.0 =
final ;-) Looking forward to your feedback!=20
=20
Juergen
=20

Re: [Springframework-developer] Quartz support

[Colin S. <col...@ex...>]

I would actually be able to use this, since right now I am setting up=20
some quartz jobs by hand. I don't know however if I will have time to=20
switch over my quartz usage to this in the next few weeks. That code is=20
working fine and I am in a time crunch.

They obviously don't pose much danger to the rest of spring since it is=20
all new code, and if they have unit tests that covers the actual new=20
code, so from my point of view, go for it...



j=FCrgen h=F6ller [werk3AT] wrote:

>Everybody,
>=20
>I've revived my Quartz support classes for Spring today. They emerged fr=
om a job scheduling consulting project I did in autumn 2003. We have conc=
rete needs for this now at werk3AT, thus the revival: It's about quite si=
mple cron-style scheduling of application jobs.
>=20
>The basic idea is to set up a Quartz Scheduler via a SchedulerFactoryBea=
n, also allowing to register scheduled jobs there via a <list> of <refs> =
to ScheduledJobDefinition beans. A ScheduledJobDefinition is just a simpl=
e combination of a Quartz JobDetail and a Quartz Trigger.
>=20
>ScheduledJobDefinition bean implementations include:
>- DefaultScheduledJobDefinition, allowing to use any implementation of Q=
uartz' Job interface with a declaratively configured job data map and cro=
n trigger
>- MethodInvokingJobDefinition, allowing to specify a method of a Spring-=
managed bean to execute as job (completely declarative, without the need =
for implementing a custom Job object), with a cron trigger.
>=20
>Both job definition beans can link in a separate Quartz Trigger instance=
 instead of a cron expression; DefaultScheduledJobDefinition can also lin=
k in a separate Quartz JobDetail instance instead of a job class.
>=20
>That's all there is: A simple declarative way of using Quartz within Spr=
ing. Typically no rescheduling or the like: All schedules are set up on c=
ontext startup, defined as bean definitions. Of course, you can also fetc=
h the Scheduler instance and perform any custom scheduling, instead of us=
ing preconfigured ScheduledJobDefinition beans.
>=20
>The typical usage scenario are low-level jobs within an application, lik=
e data synchronization or storage cleanup - all predefined jobs that are =
just customized by an administrator. Fits nicely into Spring's applicatio=
n context model; most jobs will simply delegate to Spring-managed busines=
s objects.
>=20
>I expect to have this polished by the end of the week, as we need it at =
werk3AT quite urgently. I'd like to include this already in Spring 1.0 fi=
nal, as it's just 6 pretty simple classes (yes, I know - feature freeze -=
 never mind ;-). The main question is where to put it: I suggest "org.spr=
ingframework.scheduling.quartz".
>=20
>If there are no general objections, I'll commit it by the end of this we=
ek, for review within the next week - still plenty of time before 1.0 fin=
al ;-) Looking forward to your feedback!=20
>=20
>Juergen
>=20
>

Re: [Springframework-developer] Quartz support

[Mike Cannon-B. <mi...@at...>]

Woo! Good work! :)

It will allow us to get rid of Atlassian Scheduler - basically just a simpl=
e
wrapper around Quartz with a simple file for configuration of jobs and
triggers. (sample config file attached if anyone's interested)

Does yours do all that? (simple setup of job classes, cron and simple
triggers etc)

(I'm sure it can - just checking)

Cheers,
Mike
=20
On 19/2/04 9:43 AM, "j=FCrgen h=F6ller [werk3AT]" (jue...@we...)
penned the words:

> Everybody,
>=20
> I've revived my Quartz support classes for Spring today. They emerged fro=
m a
> job scheduling consulting project I did in autumn 2003. We have concrete =
needs
> for this now at werk3AT, thus the revival: It's about quite simple cron-s=
tyle
> scheduling of application jobs.
>=20
> The basic idea is to set up a Quartz Scheduler via a SchedulerFactoryBean=
,
> also allowing to register scheduled jobs there via a <list> of <refs> to
> ScheduledJobDefinition beans. A ScheduledJobDefinition is just a simple
> combination of a Quartz JobDetail and a Quartz Trigger.
>=20
> ScheduledJobDefinition bean implementations include:
> - DefaultScheduledJobDefinition, allowing to use any implementation of Qu=
artz'
> Job interface with a declaratively configured job data map and cron trigg=
er
> - MethodInvokingJobDefinition, allowing to specify a method of a
> Spring-managed bean to execute as job (completely declarative, without th=
e
> need for implementing a custom Job object), with a cron trigger.
>=20
> Both job definition beans can link in a separate Quartz Trigger instance
> instead of a cron expression; DefaultScheduledJobDefinition can also link=
 in a
> separate Quartz JobDetail instance instead of a job class.
>=20
> That's all there is: A simple declarative way of using Quartz within Spri=
ng.
> Typically no rescheduling or the like: All schedules are set up on contex=
t
> startup, defined as bean definitions. Of course, you can also fetch the
> Scheduler instance and perform any custom scheduling, instead of using
> preconfigured ScheduledJobDefinition beans.
>=20
> The typical usage scenario are low-level jobs within an application, like=
 data
> synchronization or storage cleanup - all predefined jobs that are just
> customized by an administrator. Fits nicely into Spring's application con=
text
> model; most jobs will simply delegate to Spring-managed business objects.
>=20
> I expect to have this polished by the end of the week, as we need it at
> werk3AT quite urgently. I'd like to include this already in Spring 1.0 fi=
nal,
> as it's just 6 pretty simple classes (yes, I know - feature freeze - neve=
r
> mind ;-). The main question is where to put it: I suggest
> "org.springframework.scheduling.quartz".
>=20
> If there are no general objections, I'll commit it by the end of this wee=
k,
> for review within the next week - still plenty of time before 1.0 final ;=
-)
> Looking forward to your feedback!
>=20
> Juergen
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=CCk
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Quartz support

[Cameron B. <ca...@da...>]

Yeah +1 from me too..=20

I have been hand wiring quartz jobs in the past, so this will certainly
clean things up.

Cheers,

Cameron

> -----Original Message-----
> From: spr...@li...=20
> [mailto:spr...@li...]
>  On Behalf Of j=FCrgen h=F6ller [werk3AT]
> Sent: Thursday, 19 February 2004 8:43 AM
> To: spr...@li...
> Subject: [Springframework-developer] Quartz support
>=20
> Everybody,
> =20
> I've revived my Quartz support classes for Spring today. They=20
> emerged from a job scheduling consulting project I did in=20
> autumn 2003. We have concrete needs for this now at werk3AT,=20
> thus the revival: It's about quite simple cron-style=20
> scheduling of application jobs.
> =20
> The basic idea is to set up a Quartz Scheduler via a=20
> SchedulerFactoryBean, also allowing to register scheduled=20
> jobs there via a <list> of <refs> to ScheduledJobDefinition=20
> beans. A ScheduledJobDefinition is just a simple combination=20
> of a Quartz JobDetail and a Quartz Trigger.
> =20
> ScheduledJobDefinition bean implementations include:
> - DefaultScheduledJobDefinition, allowing to use any=20
> implementation of Quartz' Job interface with a declaratively=20
> configured job data map and cron trigger
> - MethodInvokingJobDefinition, allowing to specify a method=20
> of a Spring-managed bean to execute as job (completely=20
> declarative, without the need for implementing a custom Job=20
> object), with a cron trigger.
> =20
> Both job definition beans can link in a separate Quartz=20
> Trigger instance instead of a cron expression;=20
> DefaultScheduledJobDefinition can also link in a separate=20
> Quartz JobDetail instance instead of a job class.
> =20
> That's all there is: A simple declarative way of using Quartz=20
> within Spring. Typically no rescheduling or the like: All=20
> schedules are set up on context startup, defined as bean=20
> definitions. Of course, you can also fetch the Scheduler=20
> instance and perform any custom scheduling, instead of using=20
> preconfigured ScheduledJobDefinition beans.
> =20
> The typical usage scenario are low-level jobs within an=20
> application, like data synchronization or storage cleanup -=20
> all predefined jobs that are just customized by an=20
> administrator. Fits nicely into Spring's application context=20
> model; most jobs will simply delegate to Spring-managed=20
> business objects.
> =20
> I expect to have this polished by the end of the week, as we=20
> need it at werk3AT quite urgently. I'd like to include this=20
> already in Spring 1.0 final, as it's just 6 pretty simple=20
> classes (yes, I know - feature freeze - never mind ;-). The=20
> main question is where to put it: I suggest=20
> "org.springframework.scheduling.quartz".
> =20
> If there are no general objections, I'll commit it by the end=20
> of this week, for review within the next week - still plenty=20
> of time before 1.0 final ;-) Looking forward to your feedback!=20
> =20
> Juergen
> =20
>=20
>=20
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with a free=20
> DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20

Re: [Springframework-developer] Quartz support

[Daniel P. <po...@ci...>]

We would definitely use this! +1 from me.

Daniel

On Wed, Feb 18, 2004 at 11:43:14PM +0100, j?rgen h?ller [werk3AT] wrote:
> Everybody,
> =20
> I've revived my Quartz support classes for Spring today. They emerged fro=
m a job scheduling consulting project I did in autumn 2003. We have concret=
e needs for this now at werk3AT, thus the revival: It's about quite simple =
cron-style scheduling of application jobs.
> =20
> The basic idea is to set up a Quartz Scheduler via a SchedulerFactoryBean=
, also allowing to register scheduled jobs there via a <list> of <refs> to =
ScheduledJobDefinition beans. A ScheduledJobDefinition is just a simple com=
bination of a Quartz JobDetail and a Quartz Trigger.
> =20
> ScheduledJobDefinition bean implementations include:
> - DefaultScheduledJobDefinition, allowing to use any implementation of Qu=
artz' Job interface with a declaratively configured job data map and cron t=
rigger
> - MethodInvokingJobDefinition, allowing to specify a method of a Spring-m=
anaged bean to execute as job (completely declarative, without the need for=
 implementing a custom Job object), with a cron trigger.
> =20
> Both job definition beans can link in a separate Quartz Trigger instance =
instead of a cron expression; DefaultScheduledJobDefinition can also link i=
n a separate Quartz JobDetail instance instead of a job class.
> =20
> That's all there is: A simple declarative way of using Quartz within Spri=
ng. Typically no rescheduling or the like: All schedules are set up on cont=
ext startup, defined as bean definitions. Of course, you can also fetch the=
 Scheduler instance and perform any custom scheduling, instead of using pre=
configured ScheduledJobDefinition beans.
> =20
> The typical usage scenario are low-level jobs within an application, like=
 data synchronization or storage cleanup - all predefined jobs that are jus=
t customized by an administrator. Fits nicely into Spring's application con=
text model; most jobs will simply delegate to Spring-managed business objec=
ts.
> =20
> I expect to have this polished by the end of the week, as we need it at w=
erk3AT quite urgently. I'd like to include this already in Spring 1.0 final=
, as it's just 6 pretty simple classes (yes, I know - feature freeze - neve=
r mind ;-). The main question is where to put it: I suggest "org.springfram=
ework.scheduling.quartz".
> =20
> If there are no general objections, I'll commit it by the end of this wee=
k, for review within the next week - still plenty of time before 1.0 final =
;-) Looking forward to your feedback!=20
> =20
> Juergen
> =20
>=20
>=20
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Quartz support

[Daniel P. <po...@ci...>]

Juergen,
I have a question regarding these classes and/or your general experience
using Quartz with Spring in an J2EE container.  We've run into JNDI
lookup issues with jobs that attempt to use Spring beans that contain
references to JNDI resources (thru a JndiObjectFactoryBean).  It appears
the Quartz job doesn't know it's running within the container (even
though the scheduler is started in the init() method of a servlet), so it's
dependencies fail to locate the default JNDI context (and therefore fail
to locate their JNDI dependencies).  I assume this is because the
scheduler is running in its own thread, so it doesn't have any implicit
knowledge of the container.  To get around this, we've been
forced to use a separate Spring config file for the Quartz jobs that
overrides the default JNDI settings used by the JndiObjectFactoryBean
like this (as if the job had to connect to JNDI remotely):

  <!-- JNDI connection information -->
  <bean id=3D"myJndiTemplate"
class=3D"org.springframework.jndi.JndiTemplate">
    <property name=3D"environment">
      <props>
        <prop
key=3D"java.naming.factory.initial">com.ibm.websphere.naming.WsnInitialCont=
extFactory</prop>
        <prop
key=3D"java.naming.provider.url">iiop://localhost:9091</prop>
        <prop key=3D"java.naming.security.credentials">user</prop>
        <prop key=3D"java.naming.security.principal">pw</prop>
       </props>
     </property>
  </bean>

  <!-- QUEUE CONNECTION FACTORY -->
  <bean id=3D"jmsQueueConnectionFactory"
        class=3D"org.springframework.jndi.JndiObjectFactoryBean"
        lazy-init=3D"true">
    <property name=3D"inContainer">
        <value>false</value>
    </property>
    <property name=3D"jndiTemplate">
        <ref local=3D"myJndiTemplate"/>
    </property>
    <property name=3D"jndiName">
      <value>Example/QueueConnectionFactory</value>
    </property>
  </bean>

This also requires us to load a separate application context for the
Quartz jobs that uses these settings, rather than being able to share
the application context used by the rest of the application.
=20
Have you ever run into this issue?  Do your support classes get around
this somehow?

Regards,
Daniel

On Wed, Feb 18, 2004 at 11:43:14PM +0100, j?rgen h?ller [werk3AT] wrote:
> Everybody,
> =20
> I've revived my Quartz support classes for Spring today. They emerged fro=
m a job scheduling consulting project I did in autumn 2003. We have concret=
e needs for this now at werk3AT, thus the revival: It's about quite simple =
cron-style scheduling of application jobs.
> =20
> The basic idea is to set up a Quartz Scheduler via a SchedulerFactoryBean=
, also allowing to register scheduled jobs there via a <list> of <refs> to =
ScheduledJobDefinition beans. A ScheduledJobDefinition is just a simple com=
bination of a Quartz JobDetail and a Quartz Trigger.
> =20
> ScheduledJobDefinition bean implementations include:
> - DefaultScheduledJobDefinition, allowing to use any implementation of Qu=
artz' Job interface with a declaratively configured job data map and cron t=
rigger
> - MethodInvokingJobDefinition, allowing to specify a method of a Spring-m=
anaged bean to execute as job (completely declarative, without the need for=
 implementing a custom Job object), with a cron trigger.
> =20
> Both job definition beans can link in a separate Quartz Trigger instance =
instead of a cron expression; DefaultScheduledJobDefinition can also link i=
n a separate Quartz JobDetail instance instead of a job class.
> =20
> That's all there is: A simple declarative way of using Quartz within Spri=
ng. Typically no rescheduling or the like: All schedules are set up on cont=
ext startup, defined as bean definitions. Of course, you can also fetch the=
 Scheduler instance and perform any custom scheduling, instead of using pre=
configured ScheduledJobDefinition beans.
> =20
> The typical usage scenario are low-level jobs within an application, like=
 data synchronization or storage cleanup - all predefined jobs that are jus=
t customized by an administrator. Fits nicely into Spring's application con=
text model; most jobs will simply delegate to Spring-managed business objec=
ts.
> =20
> I expect to have this polished by the end of the week, as we need it at w=
erk3AT quite urgently. I'd like to include this already in Spring 1.0 final=
, as it's just 6 pretty simple classes (yes, I know - feature freeze - neve=
r mind ;-). The main question is where to put it: I suggest "org.springfram=
ework.scheduling.quartz".
> =20
> If there are no general objections, I'll commit it by the end of this wee=
k, for review within the next week - still plenty of time before 1.0 final =
;-) Looking forward to your feedback!=20
> =20
> Juergen
> =20
>=20
>=20
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Quartz support

[Lars H. <ho...@ar...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Daniel!

Today we ran into the problem that a Quartz job had no java:comp/env =20
context. Referencing EJBs (or resources) by
using the full JNDI path was no problem but java:comp/env was a no-go.

Yours,
Lars

Am 19.02.2004 um 16:16 schrieb Daniel Potter:

> Juergen,
> I have a question regarding these classes and/or your general =20
> experience
> using Quartz with Spring in an J2EE container.  We've run into JNDI
> lookup issues with jobs that attempt to use Spring beans that contain
> references to JNDI resources (thru a JndiObjectFactoryBean).  It =20
> appears
> the Quartz job doesn't know it's running within the container (even
> though the scheduler is started in the init() method of a servlet), so =
=20
> it's
> dependencies fail to locate the default JNDI context (and therefore =20=

> fail
> to locate their JNDI dependencies).  I assume this is because the
> scheduler is running in its own thread, so it doesn't have any =
implicit
> knowledge of the container.  To get around this, we've been
> forced to use a separate Spring config file for the Quartz jobs that
> overrides the default JNDI settings used by the JndiObjectFactoryBean
> like this (as if the job had to connect to JNDI remotely):
>
>   <!-- JNDI connection information -->
>   <bean id=3D"myJndiTemplate"
> class=3D"org.springframework.jndi.JndiTemplate">
>     <property name=3D"environment">
>       <props>
>         <prop
> =
key=3D"java.naming.factory.initial">com.ibm.websphere.naming.WsnInitialCo=20=

> ntextFactory</prop>
>         <prop
> key=3D"java.naming.provider.url">iiop://localhost:9091</prop>
>         <prop key=3D"java.naming.security.credentials">user</prop>
>         <prop key=3D"java.naming.security.principal">pw</prop>
>        </props>
>      </property>
>   </bean>
>
>   <!-- QUEUE CONNECTION FACTORY -->
>   <bean id=3D"jmsQueueConnectionFactory"
>         class=3D"org.springframework.jndi.JndiObjectFactoryBean"
>         lazy-init=3D"true">
>     <property name=3D"inContainer">
>         <value>false</value>
>     </property>
>     <property name=3D"jndiTemplate">
>         <ref local=3D"myJndiTemplate"/>
>     </property>
>     <property name=3D"jndiName">
>       <value>Example/QueueConnectionFactory</value>
>     </property>
>   </bean>
>
> This also requires us to load a separate application context for the
> Quartz jobs that uses these settings, rather than being able to share
> the application context used by the rest of the application.
>
> Have you ever run into this issue?  Do your support classes get around
> this somehow?
>
> Regards,
> Daniel
>
> On Wed, Feb 18, 2004 at 11:43:14PM +0100, j?rgen h?ller [werk3AT] =20
> wrote:
>> Everybody,
>>
>> I've revived my Quartz support classes for Spring today. They emerged =
=20
>> from a job scheduling consulting project I did in autumn 2003. We =20
>> have concrete needs for this now at werk3AT, thus the revival: It's =20=

>> about quite simple cron-style scheduling of application jobs.
>>
>> The basic idea is to set up a Quartz Scheduler via a =20
>> SchedulerFactoryBean, also allowing to register scheduled jobs there =20=

>> via a <list> of <refs> to ScheduledJobDefinition beans. A =20
>> ScheduledJobDefinition is just a simple combination of a Quartz =20
>> JobDetail and a Quartz Trigger.
>>
>> ScheduledJobDefinition bean implementations include:
>> - DefaultScheduledJobDefinition, allowing to use any implementation =20=

>> of Quartz' Job interface with a declaratively configured job data map =
=20
>> and cron trigger
>> - MethodInvokingJobDefinition, allowing to specify a method of a =20
>> Spring-managed bean to execute as job (completely declarative, =20
>> without the need for implementing a custom Job object), with a cron =20=

>> trigger.
>>
>> Both job definition beans can link in a separate Quartz Trigger =20
>> instance instead of a cron expression; DefaultScheduledJobDefinition =20=

>> can also link in a separate Quartz JobDetail instance instead of a =20=

>> job class.
>>
>> That's all there is: A simple declarative way of using Quartz within =20=

>> Spring. Typically no rescheduling or the like: All schedules are set =20=

>> up on context startup, defined as bean definitions. Of course, you =20=

>> can also fetch the Scheduler instance and perform any custom =20
>> scheduling, instead of using preconfigured ScheduledJobDefinition =20
>> beans.
>>
>> The typical usage scenario are low-level jobs within an application, =20=

>> like data synchronization or storage cleanup - all predefined jobs =20=

>> that are just customized by an administrator. Fits nicely into =20
>> Spring's application context model; most jobs will simply delegate to =
=20
>> Spring-managed business objects.
>>
>> I expect to have this polished by the end of the week, as we need it =20=

>> at werk3AT quite urgently. I'd like to include this already in Spring =
=20
>> 1.0 final, as it's just 6 pretty simple classes (yes, I know - =20
>> feature freeze - never mind ;-). The main question is where to put =20=

>> it: I suggest "org.springframework.scheduling.quartz".
>>
>> If there are no general objections, I'll commit it by the end of this =
=20
>> week, for review within the next week - still plenty of time before =20=

>> 1.0 final ;-) Looking forward to your feedback!
>>
>> Juergen
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>> Build and deploy apps & Web services for Linux with
>> a free DVD software kit from IBM. Click Now!
>> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dclick
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQDTfDrcyzbDWnRDCEQLftgCaA2Fahb3SxkDaVukOgQCQwqbNwhkAoO/u
f4iliYO7q6nORpL/n709U/nS
=3Dppnq
-----END PGP SIGNATURE-----

Re: [Springframework-developer] Quartz support

[Colin S. <col...@ex...>]

This is to be expected, since the ENC (java:/comp/env) is typically 
bound to a thread, and is specific to some sort of component (ejb, war, 
etc.) for which it represents the local namespace, so to speak. Quartz 
fires the jobs in a new thread, which will not have any sort of ENC bound...


Lars Hoss wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi Daniel!
>
>Today we ran into the problem that a Quartz job had no java:comp/env  
>context. Referencing EJBs (or resources) by
>using the full JNDI path was no problem but java:comp/env was a no-go.
>
>Yours,
>Lars
>
>Am 19.02.2004 um 16:16 schrieb Daniel Potter:
>
>  
>
>>Juergen,
>>I have a question regarding these classes and/or your general  
>>experience
>>using Quartz with Spring in an J2EE container.  We've run into JNDI
>>lookup issues with jobs that attempt to use Spring beans that contain
>>references to JNDI resources (thru a JndiObjectFactoryBean).  It  
>>appears
>>the Quartz job doesn't know it's running within the container (even
>>though the scheduler is started in the init() method of a servlet), so  
>>it's
>>dependencies fail to locate the default JNDI context (and therefore  
>>fail
>>to locate their JNDI dependencies).  I assume this is because the
>>scheduler is running in its own thread, so it doesn't have any implicit
>>knowledge of the container.  To get around this, we've been
>>forced to use a separate Spring config file for the Quartz jobs that
>>overrides the default JNDI settings used by the JndiObjectFactoryBean
>>like this (as if the job had to connect to JNDI remotely):
>>
>>  <!-- JNDI connection information -->
>>  <bean id="myJndiTemplate"
>>class="org.springframework.jndi.JndiTemplate">
>>    <property name="environment">
>>      <props>
>>        <prop
>>key="java.naming.factory.initial">com.ibm.websphere.naming.WsnInitialCo 
>>ntextFactory</prop>
>>        <prop
>>key="java.naming.provider.url">iiop://localhost:9091</prop>
>>        <prop key="java.naming.security.credentials">user</prop>
>>        <prop key="java.naming.security.principal">pw</prop>
>>       </props>
>>     </property>
>>  </bean>
>>
>>  <!-- QUEUE CONNECTION FACTORY -->
>>  <bean id="jmsQueueConnectionFactory"
>>        class="org.springframework.jndi.JndiObjectFactoryBean"
>>        lazy-init="true">
>>    <property name="inContainer">
>>        <value>false</value>
>>    </property>
>>    <property name="jndiTemplate">
>>        <ref local="myJndiTemplate"/>
>>    </property>
>>    <property name="jndiName">
>>      <value>Example/QueueConnectionFactory</value>
>>    </property>
>>  </bean>
>>
>>This also requires us to load a separate application context for the
>>Quartz jobs that uses these settings, rather than being able to share
>>the application context used by the rest of the application.
>>
>>Have you ever run into this issue?  Do your support classes get around
>>this somehow?
>>
>>Regards,
>>Daniel
>>
>>On Wed, Feb 18, 2004 at 11:43:14PM +0100, j?rgen h?ller [werk3AT]  
>>wrote:
>>    
>>
>>>Everybody,
>>>
>>>I've revived my Quartz support classes for Spring today. They emerged  
>>>from a job scheduling consulting project I did in autumn 2003. We  
>>>have concrete needs for this now at werk3AT, thus the revival: It's  
>>>about quite simple cron-style scheduling of application jobs.
>>>
>>>The basic idea is to set up a Quartz Scheduler via a  
>>>SchedulerFactoryBean, also allowing to register scheduled jobs there  
>>>via a <list> of <refs> to ScheduledJobDefinition beans. A  
>>>ScheduledJobDefinition is just a simple combination of a Quartz  
>>>JobDetail and a Quartz Trigger.
>>>
>>>ScheduledJobDefinition bean implementations include:
>>>- DefaultScheduledJobDefinition, allowing to use any implementation  
>>>of Quartz' Job interface with a declaratively configured job data map  
>>>and cron trigger
>>>- MethodInvokingJobDefinition, allowing to specify a method of a  
>>>Spring-managed bean to execute as job (completely declarative,  
>>>without the need for implementing a custom Job object), with a cron  
>>>trigger.
>>>
>>>Both job definition beans can link in a separate Quartz Trigger  
>>>instance instead of a cron expression; DefaultScheduledJobDefinition  
>>>can also link in a separate Quartz JobDetail instance instead of a  
>>>job class.
>>>
>>>That's all there is: A simple declarative way of using Quartz within  
>>>Spring. Typically no rescheduling or the like: All schedules are set  
>>>up on context startup, defined as bean definitions. Of course, you  
>>>can also fetch the Scheduler instance and perform any custom  
>>>scheduling, instead of using preconfigured ScheduledJobDefinition  
>>>beans.
>>>
>>>The typical usage scenario are low-level jobs within an application,  
>>>like data synchronization or storage cleanup - all predefined jobs  
>>>that are just customized by an administrator. Fits nicely into  
>>>Spring's application context model; most jobs will simply delegate to  
>>>Spring-managed business objects.
>>>
>>>I expect to have this polished by the end of the week, as we need it  
>>>at werk3AT quite urgently. I'd like to include this already in Spring  
>>>1.0 final, as it's just 6 pretty simple classes (yes, I know -  
>>>feature freeze - never mind ;-). The main question is where to put  
>>>it: I suggest "org.springframework.scheduling.quartz".
>>>
>>>If there are no general objections, I'll commit it by the end of this  
>>>week, for review within the next week - still plenty of time before  
>>>1.0 final ;-) Looking forward to your feedback!
>>>
>>>Juergen
>>>      
>>>

Re: [Springframework-developer] Quartz support

[Lars H. <ho...@ar...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I forgot to mention that this problum occured on WebSphere ;-)

Am 19.02.2004 um 17:06 schrieb Lars Hoss:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Daniel!
>
> Today we ran into the problem that a Quartz job had no java:comp/env
> context. Referencing EJBs (or resources) by
> using the full JNDI path was no problem but java:comp/env was a no-go.
>
> Yours,
> Lars
>
> Am 19.02.2004 um 16:16 schrieb Daniel Potter:
>
>> Juergen,
>> I have a question regarding these classes and/or your general
>> experience
>> using Quartz with Spring in an J2EE container.  We've run into JNDI
>> lookup issues with jobs that attempt to use Spring beans that contain
>> references to JNDI resources (thru a JndiObjectFactoryBean).  It
>> appears
>> the Quartz job doesn't know it's running within the container (even
>> though the scheduler is started in the init() method of a servlet), =
so
>> it's
>> dependencies fail to locate the default JNDI context (and therefore
>> fail
>> to locate their JNDI dependencies).  I assume this is because the
>> scheduler is running in its own thread, so it doesn't have any =20
>> implicit
>> knowledge of the container.  To get around this, we've been
>> forced to use a separate Spring config file for the Quartz jobs that
>> overrides the default JNDI settings used by the JndiObjectFactoryBean
>> like this (as if the job had to connect to JNDI remotely):
>>
>>   <!-- JNDI connection information -->
>>   <bean id=3D"myJndiTemplate"
>> class=3D"org.springframework.jndi.JndiTemplate">
>>     <property name=3D"environment">
>>       <props>
>>         <prop
>> =
key=3D"java.naming.factory.initial">com.ibm.websphere.naming.WsnInitialC=20=

>> o
>> ntextFactory</prop>
>>         <prop
>> key=3D"java.naming.provider.url">iiop://localhost:9091</prop>
>>         <prop key=3D"java.naming.security.credentials">user</prop>
>>         <prop key=3D"java.naming.security.principal">pw</prop>
>>        </props>
>>      </property>
>>   </bean>
>>
>>   <!-- QUEUE CONNECTION FACTORY -->
>>   <bean id=3D"jmsQueueConnectionFactory"
>>         class=3D"org.springframework.jndi.JndiObjectFactoryBean"
>>         lazy-init=3D"true">
>>     <property name=3D"inContainer">
>>         <value>false</value>
>>     </property>
>>     <property name=3D"jndiTemplate">
>>         <ref local=3D"myJndiTemplate"/>
>>     </property>
>>     <property name=3D"jndiName">
>>       <value>Example/QueueConnectionFactory</value>
>>     </property>
>>   </bean>
>>
>> This also requires us to load a separate application context for the
>> Quartz jobs that uses these settings, rather than being able to share
>> the application context used by the rest of the application.
>>
>> Have you ever run into this issue?  Do your support classes get =
around
>> this somehow?
>>
>> Regards,
>> Daniel
>>
>> On Wed, Feb 18, 2004 at 11:43:14PM +0100, j?rgen h?ller [werk3AT]
>> wrote:
>>> Everybody,
>>>
>>> I've revived my Quartz support classes for Spring today. They =
emerged
>>> from a job scheduling consulting project I did in autumn 2003. We
>>> have concrete needs for this now at werk3AT, thus the revival: It's
>>> about quite simple cron-style scheduling of application jobs.
>>>
>>> The basic idea is to set up a Quartz Scheduler via a
>>> SchedulerFactoryBean, also allowing to register scheduled jobs there
>>> via a <list> of <refs> to ScheduledJobDefinition beans. A
>>> ScheduledJobDefinition is just a simple combination of a Quartz
>>> JobDetail and a Quartz Trigger.
>>>
>>> ScheduledJobDefinition bean implementations include:
>>> - DefaultScheduledJobDefinition, allowing to use any implementation
>>> of Quartz' Job interface with a declaratively configured job data =
map
>>> and cron trigger
>>> - MethodInvokingJobDefinition, allowing to specify a method of a
>>> Spring-managed bean to execute as job (completely declarative,
>>> without the need for implementing a custom Job object), with a cron
>>> trigger.
>>>
>>> Both job definition beans can link in a separate Quartz Trigger
>>> instance instead of a cron expression; DefaultScheduledJobDefinition
>>> can also link in a separate Quartz JobDetail instance instead of a
>>> job class.
>>>
>>> That's all there is: A simple declarative way of using Quartz within
>>> Spring. Typically no rescheduling or the like: All schedules are set
>>> up on context startup, defined as bean definitions. Of course, you
>>> can also fetch the Scheduler instance and perform any custom
>>> scheduling, instead of using preconfigured ScheduledJobDefinition
>>> beans.
>>>
>>> The typical usage scenario are low-level jobs within an application,
>>> like data synchronization or storage cleanup - all predefined jobs
>>> that are just customized by an administrator. Fits nicely into
>>> Spring's application context model; most jobs will simply delegate =
to
>>> Spring-managed business objects.
>>>
>>> I expect to have this polished by the end of the week, as we need it
>>> at werk3AT quite urgently. I'd like to include this already in =
Spring
>>> 1.0 final, as it's just 6 pretty simple classes (yes, I know -
>>> feature freeze - never mind ;-). The main question is where to put
>>> it: I suggest "org.springframework.scheduling.quartz".
>>>
>>> If there are no general objections, I'll commit it by the end of =
this
>>> week, for review within the next week - still plenty of time before
>>> 1.0 final ;-) Looking forward to your feedback!
>>>
>>> Juergen
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>>> Build and deploy apps & Web services for Linux with
>>> a free DVD software kit from IBM. Click Now!
>>> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dclick
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-=20
>>> developer
>>
>>
>> -------------------------------------------------------
>> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>> Build and deploy apps & Web services for Linux with
>> a free DVD software kit from IBM. Click Now!
>> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dclick
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.0.3
>
> iQA/AwUBQDTfDrcyzbDWnRDCEQLftgCaA2Fahb3SxkDaVukOgQCQwqbNwhkAoO/u
> f4iliYO7q6nORpL/n709U/nS
> =3Dppnq
> -----END PGP SIGNATURE-----
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQDTjKLcyzbDWnRDCEQI/dgCgzh+oxO2wfy19PfvUHkPCruCsK8UAn34F
BEFyVURmwJ5Xw0TWkOveCagO
=3Dn1uu
-----END PGP SIGNATURE-----