springframework-developer — Spring Framework developers list

Re: [Springframework-developer] org.springframework.jdbc.support.JdbcUtils error

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

Oops, a copy-and-paste error ;-) Thanks for pointing it out!
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Laurent PETIT
Gesendet: Fr 20.02.2004 10:21
An: spr...@li...
Betreff: [Springframework-developer] =
org.springframework.jdbc.support.JdbcUtils error


Hello,
=20
Just my 0.02 euros on this :=20
=20
Line 27 of source file org.springframework.jdbc.support.JdbcUtils should =
be corrected to use a correct logger ?
=20
private static final Log logger =3D =
LogFactory.getLog(FileCopyUtils.class);
=20
into=20
=20
private static final Log logger =3D LogFactory.getLog(JdbcUtils.class);
=20
=20
Hope this helps,
=20
--=20
Laurent PETIT [SQLI - Lyon] - lp...@sq...
=20
Groupe SQLI - www.sqli.com

[Springframework-developer] org.springframework.jdbc.support.JdbcUtils error

[Laurent P. <lol...@fr...>]

Hello,

Just my 0.02 euros on this :=20

Line 27 of source file org.springframework.jdbc.support.JdbcUtils should =
be corrected to use a correct logger ?

private static final Log logger =3D =
LogFactory.getLog(FileCopyUtils.class);

into=20

private static final Log logger =3D LogFactory.getLog(JdbcUtils.class);


Hope this helps,

--=20
Laurent PETIT [SQLI - Lyon] - lp...@sq...

Groupe SQLI - www.sqli.com

Re: [Springframework-developer] Add execute(sql) method to JdbcTemplate?

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

I'm happy with both changes too!
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Rod Johnson
Gesendet: Fr 20.02.2004 08:05
An: spr...@li...
Betreff: Re: [Springframework-developer] Add execute(sql) method to =
JdbcTemplate?



I'm in favour of a new execute(String) method. I think the name change =
for
the existing method is fine.

----- Original Message -----
From: "Thomas Risberg" <tri...@tr...>
To: <spr...@li...>
Sent: Friday, February 20, 2004 4:59 AM
Subject: [Springframework-developer] Add execute(sql) method to
JdbcTemplate?


> I like the new convenience methods we added to JdbcTemplate, but there
> is still one missing.  I would like to add a simple "void =
execute(String
> sql) method that simply creates a statement and executes the sql. No
> return values, prepared statements or parameters, just a plain =
execute.
> It would be nice for something like the following:
>
>         JdbcTemplate jt =3D new JdbcTemplate(dataSource);
>         jt.execute("drop table spring_test");
>         jt.execute("create table spring_test (id integer, name
> varchar(100))");
>         jt.update("insert into spring_test (id, name) values (?, ?)",
> new Object[] {new Integer(1), "Marc"});
>         jt.update("insert into spring_test (id, name) values (?, ?)",
> new Object[] {new Integer(2), "Bill"});
>         List l =3D jt.queryForList("select * from spring_test");
>         System.out.println(l);
>
> I could use an update(sql) for the DDL statements, but they are not
> update statements, so I would prefer the execute name and also =
bypassing
> the prepared statement - no reason to prepare a statement for a one =
off
> statement without bind variables.
>
> The only problem is that we have another execute method that is used =
by
> the StoredProcedure for running a CallableStatement.  We could rename
> that one to call() or executeCall().  I don't think anybody is using
> this method directly, so the impact on existing code would be low.
>
> What do you all think?
>
> Thomas
>
>
>
> -------------------------------------------------------
> 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=3D1356&alloc_id=3D3438&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=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Add execute(sql) method to JdbcTemplate?

[Rod J. <rod...@in...>]

I'm in favour of a new execute(String) method. I think the name change for
the existing method is fine.

----- Original Message -----
From: "Thomas Risberg" <tri...@tr...>
To: <spr...@li...>
Sent: Friday, February 20, 2004 4:59 AM
Subject: [Springframework-developer] Add execute(sql) method to
JdbcTemplate?


> I like the new convenience methods we added to JdbcTemplate, but there
> is still one missing.  I would like to add a simple "void execute(String
> sql) method that simply creates a statement and executes the sql. No
> return values, prepared statements or parameters, just a plain execute.
> It would be nice for something like the following:
>
>         JdbcTemplate jt = new JdbcTemplate(dataSource);
>         jt.execute("drop table spring_test");
>         jt.execute("create table spring_test (id integer, name
> varchar(100))");
>         jt.update("insert into spring_test (id, name) values (?, ?)",
> new Object[] {new Integer(1), "Marc"});
>         jt.update("insert into spring_test (id, name) values (?, ?)",
> new Object[] {new Integer(2), "Bill"});
>         List l = jt.queryForList("select * from spring_test");
>         System.out.println(l);
>
> I could use an update(sql) for the DDL statements, but they are not
> update statements, so I would prefer the execute name and also bypassing
> the prepared statement - no reason to prepare a statement for a one off
> statement without bind variables.
>
> The only problem is that we have another execute method that is used by
> the StoredProcedure for running a CallableStatement.  We could rename
> that one to call() or executeCall().  I don't think anybody is using
> this method directly, so the impact on existing code would be low.
>
> What do you all think?
>
> Thomas
>
>
>
> -------------------------------------------------------
> 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_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] Idea for Spring HttpServlet and Filter beans

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

I don't use spring mvc, so this idea may already be implemented.
 
The pattern goes something like this :
 
Have a SpringBeanDelegatingServlet and a SpringBeanDelegatingFilter class
that implement HttpServlet and Filter respectively.
 
These classes use init-params to define a named bean to delegate to within
spring.
 
Their process methods (process(request,response) or
filter(request,response,chain)) delegate to this bean within spring.
 
This allows the beans witin spring to implement HttpServlet or Filter, and
to be configured using normal bean configuration like any other bean.
 
I presume that something like this is already integrated into the MVC
portion of spring, but I would like to have these two standalone classes to
be able to write my own servlets that don't use any other parts of the mcv
system.
 
Thanks,
 
Cameron.

[Springframework-developer] Add execute(sql) method to JdbcTemplate?

[Thomas R. <tri...@tr...>]

I like the new convenience methods we added to JdbcTemplate, but there 
is still one missing.  I would like to add a simple "void execute(String 
sql) method that simply creates a statement and executes the sql. No 
return values, prepared statements or parameters, just a plain execute.  
It would be nice for something like the following:

        JdbcTemplate jt = new JdbcTemplate(dataSource);
        jt.execute("drop table spring_test");
        jt.execute("create table spring_test (id integer, name 
varchar(100))");
        jt.update("insert into spring_test (id, name) values (?, ?)", 
new Object[] {new Integer(1), "Marc"});
        jt.update("insert into spring_test (id, name) values (?, ?)", 
new Object[] {new Integer(2), "Bill"});
        List l = jt.queryForList("select * from spring_test");
        System.out.println(l);
       
I could use an update(sql) for the DDL statements, but they are not 
update statements, so I would prefer the execute name and also bypassing 
the prepared statement - no reason to prepare a statement for a one off 
statement without bind variables.

The only problem is that we have another execute method that is used by 
the StoredProcedure for running a CallableStatement.  We could rename 
that one to call() or executeCall().  I don't think anybody is using 
this method directly, so the impact on existing code would be low.

What do you all think?

Thomas

Re: [Springframework-developer] Quartz support

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

As a little bonus, I've also added scheduling support classes for =
java.util.Timer :-) It's as similar as possible in concept to the Quartz =
support. Of course, it's quite limited in terms of scheduling options: =
delays and periods, that's all that Timer is capable of.
=20
A configuration example:
=20
 <bean id=3D"timer" =
class=3D"org.springframework.scheduling.timer.TimerFactoryBean">
  <property name=3D"scheduledTimerTasks">
   <list>
    <ref bean=3D"myScheduledTimerTask"/>
   </list>
  </property>
 </bean>
=20
 <bean id=3D"myScheduledTimerTask" =
class=3D"org.springframework.scheduling.timer.ScheduledTimerTask">
  <property name=3D"timerTask"><ref bean=3D"myTimerTask"/></property>
  <property name=3D"delay"><value>1000</value></property>
  <property name=3D"period"><value>2000</value></property>
 </bean>
=20
 <bean id=3D"myTimerTask" =
class=3D"org.springframework.scheduling.timer.MethodInvokingTimerTaskFact=
oryBean">
  <property name=3D"targetObject"><ref =
bean=3D"exampleService"/></property>
  <property name=3D"targetMethod"><value>doSomething</value></property>
 </bean>

SchedulerTimerTask also supports a "fixedRate" property, deciding on =
Timer's schedule vs scheduleAtFixedRate. There's nothing else: For more =
demanding needs like cron expressions, choose Quartz.
=20
BTW, the whole Timer support just took about two hours of development =
time ;-)
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Do 19.02.2004 22:09
An: spr...@li...
Betreff: Re: [Springframework-developer] Quartz support



Good point - I'll re-add "staticMethod" as convenience setter!


________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Do 19.02.2004 21:54
An: spr...@li...
Betreff: Re: [Springframework-developer] Quartz support



Hey Juergen,

The Quartz stuff looks like good stuff on an initial lookover.

I do have a comment about your refactoring of MethodInvokingFactoryBean.

For the static method call case, your refactoring is arguably cleaner
because the same property is used for specifyng the method name as for
the non-static case, but on the other hand, static methods are probably
one of the most common uses of this class, and you've turned a one
property config into a two property config, i.e.
  <bean id=3D"qa-util-initProfileImpl"
class=3D"org.springframework.beans.factory.config.MethodInvokingFactoryBe=
an">
    <property
name=3D"staticMethod"><value>com.whatever.qaserver.device.ProfileClassesI=
nit.initProfileClasses</value></property>
  </bean>
tnow becomes
  <bean id=3D"qa-util-initProfileImpl"
class=3D"org.springframework.beans.factory.config.MethodInvokingFactoryBe=
an">
    <property
name=3D"targetMethod"><value>initProfileClasses</value></property>
    <property
name=3D"targetClass"><value>com.whatever.qaserver.device.ProfileClassesIn=
it</value></property>
  </bean>

As well, this also breaks backwards compatibility for anybody using it.
Perhaps you can add back the
  staticMethod
property, and on a set, the code inside it would break up the supplied
string into calls to setTargetMethod and setTargetClass (it would have
to create the class itself).

This would allow both forms to be used, and keep backwards =
compatibility...

Regards,
Colin

j=FCrgen h=F6ller [werk3AT] wrote:

>The Quartz support is already in CVS, and also in use within the =
werk3AT app it was intended for... feel free to check it out!
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
>Gesendet: Do 19.02.2004 16:54
>An: spr...@li...
>Betreff: RE: [Springframework-developer] Quartz support
>
>
>
>Daniel,
>
>As you say, this is most likely caused by the fact that Quartz uses its =
own threads. WebSphere seems to associate the JNDI context information =
with container-managed threads; unfortunately, this does not apply to =
Quartz threads.
>
>However, there's a strategy that should work: pre-locate the JNDI =
objects, and pass the objects to Quartz' job data map. This way, the =
Quartz job should receive the pre-located objects when running in its =
own thread, not needing to do a JNDI lookup itself.
>
>The Quartz support classes (to be committed within an hour!) provide =
the following:
>
>- a SchedulerFactoryBean that sets up a Quartz Scheduler, allowing to =
register JobDetails, Calendars and Triggers with it
>
>- convenience subclasses of JobDetail, CronTrigger and SimpleTrigger =
that allow for easy bean-style usage; the latter allow for implicit =
registration of an associated JobDetail
>
>- a FactoryBean for a JobDetail that invokes a method of an existing =
object, to avoid the need for writing one-line Job implementations that =
just delegate to a business method
>
>- a convenience implementation of Quartz' Job interface, applying job =
data map entries as bean properties
>
>A configuration example:
>
>        <bean id=3D"scheduler" =
class=3D"org.springframework.scheduling.quartz.SchedulerFactoryBean">
>                <property name=3D"triggers">
>                        <list>
>                                <ref bean=3D"myTrigger1"/>
>                                <ref bean=3D"myTrigger2"/>
>                        </list>
>                </property>
>        </bean>
>
>        <bean id=3D"myJobDetail1" =
class=3D"org.springframework.scheduling.quartz.JobDetailBean">
>                <property =
name=3D"jobClass"><value>werk3.example.MyJob</value></property>
>                <property name=3D"jobDataAsMap">
>                        <map>
>                                <entry key=3D"testBean">
>                                        <bean =
class=3D"org.springframework.beans.TestBean">
>                                                <property =
name=3D"age"><value>99</value></property>
>                                        </bean>
>                                </entry>
>                        </map>
>                </property>
>        </bean>
>
>        <bean id=3D"myJobDetail2" =
class=3D"org.springframework.scheduling.quartz.MethodInvokingJobDetailFac=
toryBean">
>                <property name=3D"targetObject"><ref =
bean=3D"exampleService"/></property>
>                <property =
name=3D"targetMethod"><value>doSomething</value></property>
>        </bean>
>
>        <bean id=3D"myTrigger1" =
class=3D"org.springframework.scheduling.quartz.CronTriggerBean">
>                <property name=3D"jobDetail"><ref =
bean=3D"myJobDetail1"/></property>
>                <property name=3D"cronExpression"><value>0/5 * * * * =
?</value></property>
>        </bean>
>
>        <bean id=3D"myTrigger2" =
class=3D"org.springframework.scheduling.quartz.SimpleTriggerBean">
>                <property name=3D"jobDetail"><ref =
bean=3D"myJobDetail2"/></property>
>                <property =
name=3D"repeatInterval"><value>1000</value></property>
>        </bean>
>
>MyJob (as referenced from "myJobDetail1") can be implemented as =
follows:
>
>        public static class MyJob extends QuartzJobBean {
>
>                private TestBean testBean;
>
>                public void setTestBean(TestBean testBean) {
>                        this.testBean =3D testBean;
>                }
>
>                protected void executeInternal(JobExecutionContext =
jobExecutionContext) {
>                        System.out.println("Executing job..." + =
testBean.getAge());
>                }
>        }
>
>Note that the "testBean" entry in the job data map is automatically =
applied as bean property in MyJob.
>
>As a side note, I've refactored Colin's MethodInvokingFactoryBean into =
org.springframework.util.MethodInvoker, with MethodInvokingFactoryBean =
and MethodInvokingJobDetailFactoryBean as subclasses. They provide =
exactly the same invocation capabilities.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Daniel Potter
>Sent: Thursday, February 19, 2004 4:17 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Quartz support
>
>
>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.WsnInitialC=
ontextFactory</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
>> =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=3Dick
_______________________________________________
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=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Quartz support

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

Good point - I'll re-add "staticMethod" as convenience setter!
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Do 19.02.2004 21:54
An: spr...@li...
Betreff: Re: [Springframework-developer] Quartz support



Hey Juergen,

The Quartz stuff looks like good stuff on an initial lookover.

I do have a comment about your refactoring of MethodInvokingFactoryBean.

For the static method call case, your refactoring is arguably cleaner
because the same property is used for specifyng the method name as for
the non-static case, but on the other hand, static methods are probably
one of the most common uses of this class, and you've turned a one
property config into a two property config, i.e.
  <bean id=3D"qa-util-initProfileImpl"
class=3D"org.springframework.beans.factory.config.MethodInvokingFactoryBe=
an">
    <property
name=3D"staticMethod"><value>com.whatever.qaserver.device.ProfileClassesI=
nit.initProfileClasses</value></property>
  </bean>
tnow becomes
  <bean id=3D"qa-util-initProfileImpl"
class=3D"org.springframework.beans.factory.config.MethodInvokingFactoryBe=
an">
    <property
name=3D"targetMethod"><value>initProfileClasses</value></property>
    <property
name=3D"targetClass"><value>com.whatever.qaserver.device.ProfileClassesIn=
it</value></property>
  </bean>

As well, this also breaks backwards compatibility for anybody using it.
Perhaps you can add back the
  staticMethod
property, and on a set, the code inside it would break up the supplied
string into calls to setTargetMethod and setTargetClass (it would have
to create the class itself).

This would allow both forms to be used, and keep backwards =
compatibility...

Regards,
Colin

j=FCrgen h=F6ller [werk3AT] wrote:

>The Quartz support is already in CVS, and also in use within the =
werk3AT app it was intended for... feel free to check it out!
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
>Gesendet: Do 19.02.2004 16:54
>An: spr...@li...
>Betreff: RE: [Springframework-developer] Quartz support
>
>
>
>Daniel,
>
>As you say, this is most likely caused by the fact that Quartz uses its =
own threads. WebSphere seems to associate the JNDI context information =
with container-managed threads; unfortunately, this does not apply to =
Quartz threads.
>
>However, there's a strategy that should work: pre-locate the JNDI =
objects, and pass the objects to Quartz' job data map. This way, the =
Quartz job should receive the pre-located objects when running in its =
own thread, not needing to do a JNDI lookup itself.
>
>The Quartz support classes (to be committed within an hour!) provide =
the following:
>
>- a SchedulerFactoryBean that sets up a Quartz Scheduler, allowing to =
register JobDetails, Calendars and Triggers with it
>
>- convenience subclasses of JobDetail, CronTrigger and SimpleTrigger =
that allow for easy bean-style usage; the latter allow for implicit =
registration of an associated JobDetail
>
>- a FactoryBean for a JobDetail that invokes a method of an existing =
object, to avoid the need for writing one-line Job implementations that =
just delegate to a business method
>
>- a convenience implementation of Quartz' Job interface, applying job =
data map entries as bean properties
>
>A configuration example:
>
>        <bean id=3D"scheduler" =
class=3D"org.springframework.scheduling.quartz.SchedulerFactoryBean">
>                <property name=3D"triggers">
>                        <list>
>                                <ref bean=3D"myTrigger1"/>
>                                <ref bean=3D"myTrigger2"/>
>                        </list>
>                </property>
>        </bean>
>
>        <bean id=3D"myJobDetail1" =
class=3D"org.springframework.scheduling.quartz.JobDetailBean">
>                <property =
name=3D"jobClass"><value>werk3.example.MyJob</value></property>
>                <property name=3D"jobDataAsMap">
>                        <map>
>                                <entry key=3D"testBean">
>                                        <bean =
class=3D"org.springframework.beans.TestBean">
>                                                <property =
name=3D"age"><value>99</value></property>
>                                        </bean>
>                                </entry>
>                        </map>
>                </property>
>        </bean>
>
>        <bean id=3D"myJobDetail2" =
class=3D"org.springframework.scheduling.quartz.MethodInvokingJobDetailFac=
toryBean">
>                <property name=3D"targetObject"><ref =
bean=3D"exampleService"/></property>
>                <property =
name=3D"targetMethod"><value>doSomething</value></property>
>        </bean>
>
>        <bean id=3D"myTrigger1" =
class=3D"org.springframework.scheduling.quartz.CronTriggerBean">
>                <property name=3D"jobDetail"><ref =
bean=3D"myJobDetail1"/></property>
>                <property name=3D"cronExpression"><value>0/5 * * * * =
?</value></property>
>        </bean>
>
>        <bean id=3D"myTrigger2" =
class=3D"org.springframework.scheduling.quartz.SimpleTriggerBean">
>                <property name=3D"jobDetail"><ref =
bean=3D"myJobDetail2"/></property>
>                <property =
name=3D"repeatInterval"><value>1000</value></property>
>        </bean>
>
>MyJob (as referenced from "myJobDetail1") can be implemented as =
follows:
>
>        public static class MyJob extends QuartzJobBean {
>
>                private TestBean testBean;
>
>                public void setTestBean(TestBean testBean) {
>                        this.testBean =3D testBean;
>                }
>
>                protected void executeInternal(JobExecutionContext =
jobExecutionContext) {
>                        System.out.println("Executing job..." + =
testBean.getAge());
>                }
>        }
>
>Note that the "testBean" entry in the job data map is automatically =
applied as bean property in MyJob.
>
>As a side note, I've refactored Colin's MethodInvokingFactoryBean into =
org.springframework.util.MethodInvoker, with MethodInvokingFactoryBean =
and MethodInvokingJobDetailFactoryBean as subclasses. They provide =
exactly the same invocation capabilities.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Daniel Potter
>Sent: Thursday, February 19, 2004 4:17 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Quartz support
>
>
>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.WsnInitialC=
ontextFactory</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:
>=20
>
>>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
>>  =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=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Quartz support

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

Hey Juergen,

The Quartz stuff looks like good stuff on an initial lookover.

I do have a comment about your refactoring of MethodInvokingFactoryBean.

For the static method call case, your refactoring is arguably cleaner=20
because the same property is used for specifyng the method name as for=20
the non-static case, but on the other hand, static methods are probably=20
one of the most common uses of this class, and you've turned a one=20
property config into a two property config, i.e.
  <bean id=3D"qa-util-initProfileImpl"=20
class=3D"org.springframework.beans.factory.config.MethodInvokingFactoryBe=
an">
    <property=20
name=3D"staticMethod"><value>com.whatever.qaserver.device.ProfileClassesI=
nit.initProfileClasses</value></property>
  </bean>
tnow becomes
  <bean id=3D"qa-util-initProfileImpl"=20
class=3D"org.springframework.beans.factory.config.MethodInvokingFactoryBe=
an">
    <property=20
name=3D"targetMethod"><value>initProfileClasses</value></property>
    <property=20
name=3D"targetClass"><value>com.whatever.qaserver.device.ProfileClassesIn=
it</value></property>
  </bean>

As well, this also breaks backwards compatibility for anybody using it.=20
Perhaps you can add back the
  staticMethod
property, and on a set, the code inside it would break up the supplied=20
string into calls to setTargetMethod and setTargetClass (it would have=20
to create the class itself).

This would allow both forms to be used, and keep backwards compatibility.=
..

Regards,
Colin

j=FCrgen h=F6ller [werk3AT] wrote:

>The Quartz support is already in CVS, and also in use within the werk3AT=
 app it was intended for... feel free to check it out!
>=20
>Juergen
>=20
>
>________________________________
>
>Von: spr...@li... im Auftrag vo=
n j=FCrgen h=F6ller [werk3AT]
>Gesendet: Do 19.02.2004 16:54
>An: spr...@li...
>Betreff: RE: [Springframework-developer] Quartz support
>
>
>
>Daniel,
>
>As you say, this is most likely caused by the fact that Quartz uses its =
own threads. WebSphere seems to associate the JNDI context information wi=
th container-managed threads; unfortunately, this does not apply to Quart=
z threads.
>
>However, there's a strategy that should work: pre-locate the JNDI object=
s, and pass the objects to Quartz' job data map. This way, the Quartz job=
 should receive the pre-located objects when running in its own thread, n=
ot needing to do a JNDI lookup itself.
>
>The Quartz support classes (to be committed within an hour!) provide the=
 following:
>
>- a SchedulerFactoryBean that sets up a Quartz Scheduler, allowing to re=
gister JobDetails, Calendars and Triggers with it
>
>- convenience subclasses of JobDetail, CronTrigger and SimpleTrigger tha=
t allow for easy bean-style usage; the latter allow for implicit registra=
tion of an associated JobDetail
>
>- a FactoryBean for a JobDetail that invokes a method of an existing obj=
ect, to avoid the need for writing one-line Job implementations that just=
 delegate to a business method
>
>- a convenience implementation of Quartz' Job interface, applying job da=
ta map entries as bean properties
>
>A configuration example:
>
>        <bean id=3D"scheduler" class=3D"org.springframework.scheduling.q=
uartz.SchedulerFactoryBean">
>                <property name=3D"triggers">
>                        <list>
>                                <ref bean=3D"myTrigger1"/>
>                                <ref bean=3D"myTrigger2"/>
>                        </list>
>                </property>
>        </bean>
>
>        <bean id=3D"myJobDetail1" class=3D"org.springframework.schedulin=
g.quartz.JobDetailBean">
>                <property name=3D"jobClass"><value>werk3.example.MyJob</=
value></property>
>                <property name=3D"jobDataAsMap">
>                        <map>
>                                <entry key=3D"testBean">
>                                        <bean class=3D"org.springframewo=
rk.beans.TestBean">
>                                                <property name=3D"age"><=
value>99</value></property>
>                                        </bean>
>                                </entry>
>                        </map>
>                </property>
>        </bean>
>
>        <bean id=3D"myJobDetail2" class=3D"org.springframework.schedulin=
g.quartz.MethodInvokingJobDetailFactoryBean">
>                <property name=3D"targetObject"><ref bean=3D"exampleServ=
ice"/></property>
>                <property name=3D"targetMethod"><value>doSomething</valu=
e></property>
>        </bean>
>
>        <bean id=3D"myTrigger1" class=3D"org.springframework.scheduling.=
quartz.CronTriggerBean">
>                <property name=3D"jobDetail"><ref bean=3D"myJobDetail1"/=
></property>
>                <property name=3D"cronExpression"><value>0/5 * * * * ?</=
value></property>
>        </bean>
>
>        <bean id=3D"myTrigger2" class=3D"org.springframework.scheduling.=
quartz.SimpleTriggerBean">
>                <property name=3D"jobDetail"><ref bean=3D"myJobDetail2"/=
></property>
>                <property name=3D"repeatInterval"><value>1000</value></p=
roperty>
>        </bean>
>
>MyJob (as referenced from "myJobDetail1") can be implemented as follows:
>
>        public static class MyJob extends QuartzJobBean {
>
>                private TestBean testBean;
>
>                public void setTestBean(TestBean testBean) {
>                        this.testBean =3D testBean;
>                }
>
>                protected void executeInternal(JobExecutionContext jobEx=
ecutionContext) {
>                        System.out.println("Executing job..." + testBean=
.getAge());
>                }
>        }
>
>Note that the "testBean" entry in the job data map is automatically appl=
ied as bean property in MyJob.
>
>As a side note, I've refactored Colin's MethodInvokingFactoryBean into o=
rg.springframework.util.MethodInvoker, with MethodInvokingFactoryBean and=
 MethodInvokingJobDetailFactoryBean as subclasses. They provide exactly t=
he same invocation capabilities.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Daniel Potter
>Sent: Thursday, February 19, 2004 4:17 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Quartz support
>
>
>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 i=
t'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.WsnInitialC=
ontextFactory</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:
> =20
>
>>Everybody,
>>
>>I've revived my Quartz support classes for Spring today. They emerged f=
rom a job scheduling consulting project I did in autumn 2003. We have con=
crete needs for this now at werk3AT, thus the revival: It's about quite s=
imple cron-style scheduling of application jobs.
>>
>>The basic idea is to set up a Quartz Scheduler via a SchedulerFactoryBe=
an, also allowing to register scheduled jobs there via a <list> of <refs>=
 to ScheduledJobDefinition beans. A ScheduledJobDefinition is just a simp=
le 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 cr=
on 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 instanc=
e instead of a cron expression; DefaultScheduledJobDefinition can also li=
nk in a separate Quartz JobDetail instance instead of a job class.
>>
>>That's all there is: A simple declarative way of using Quartz within Sp=
ring. Typically no rescheduling or the like: All schedules are set up on =
context startup, defined as bean definitions. Of course, you can also fet=
ch the Scheduler instance and perform any custom scheduling, instead of u=
sing preconfigured ScheduledJobDefinition beans.
>>
>>The typical usage scenario are low-level jobs within an application, li=
ke data synchronization or storage cleanup - all predefined jobs that are=
 just customized by an administrator. Fits nicely into Spring's applicati=
on context model; most jobs will simply delegate to Spring-managed busine=
ss 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 f=
inal, 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.sp=
ringframework.scheduling.quartz".
>>
>>If there are no general objections, I'll commit it by the end of this w=
eek, for review within the next week - still plenty of time before 1.0 fi=
nal ;-) Looking forward to your feedback!
>>
>>Juergen
>>   =20
>>

Re: [Springframework-developer] Quartz support

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

The Quartz support is already in CVS, and also in use within the werk3AT =
app it was intended for... feel free to check it out!
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Do 19.02.2004 16:54
An: spr...@li...
Betreff: RE: [Springframework-developer] Quartz support



Daniel,

As you say, this is most likely caused by the fact that Quartz uses its =
own threads. WebSphere seems to associate the JNDI context information =
with container-managed threads; unfortunately, this does not apply to =
Quartz threads.

However, there's a strategy that should work: pre-locate the JNDI =
objects, and pass the objects to Quartz' job data map. This way, the =
Quartz job should receive the pre-located objects when running in its =
own thread, not needing to do a JNDI lookup itself.

The Quartz support classes (to be committed within an hour!) provide the =
following:

- a SchedulerFactoryBean that sets up a Quartz Scheduler, allowing to =
register JobDetails, Calendars and Triggers with it

- convenience subclasses of JobDetail, CronTrigger and SimpleTrigger =
that allow for easy bean-style usage; the latter allow for implicit =
registration of an associated JobDetail

- a FactoryBean for a JobDetail that invokes a method of an existing =
object, to avoid the need for writing one-line Job implementations that =
just delegate to a business method

- a convenience implementation of Quartz' Job interface, applying job =
data map entries as bean properties

A configuration example:

        <bean id=3D"scheduler" =
class=3D"org.springframework.scheduling.quartz.SchedulerFactoryBean">
                <property name=3D"triggers">
                        <list>
                                <ref bean=3D"myTrigger1"/>
                                <ref bean=3D"myTrigger2"/>
                        </list>
                </property>
        </bean>

        <bean id=3D"myJobDetail1" =
class=3D"org.springframework.scheduling.quartz.JobDetailBean">
                <property =
name=3D"jobClass"><value>werk3.example.MyJob</value></property>
                <property name=3D"jobDataAsMap">
                        <map>
                                <entry key=3D"testBean">
                                        <bean =
class=3D"org.springframework.beans.TestBean">
                                                <property =
name=3D"age"><value>99</value></property>
                                        </bean>
                                </entry>
                        </map>
                </property>
        </bean>

        <bean id=3D"myJobDetail2" =
class=3D"org.springframework.scheduling.quartz.MethodInvokingJobDetailFac=
toryBean">
                <property name=3D"targetObject"><ref =
bean=3D"exampleService"/></property>
                <property =
name=3D"targetMethod"><value>doSomething</value></property>
        </bean>

        <bean id=3D"myTrigger1" =
class=3D"org.springframework.scheduling.quartz.CronTriggerBean">
                <property name=3D"jobDetail"><ref =
bean=3D"myJobDetail1"/></property>
                <property name=3D"cronExpression"><value>0/5 * * * * =
?</value></property>
        </bean>

        <bean id=3D"myTrigger2" =
class=3D"org.springframework.scheduling.quartz.SimpleTriggerBean">
                <property name=3D"jobDetail"><ref =
bean=3D"myJobDetail2"/></property>
                <property =
name=3D"repeatInterval"><value>1000</value></property>
        </bean>

MyJob (as referenced from "myJobDetail1") can be implemented as follows:

        public static class MyJob extends QuartzJobBean {

                private TestBean testBean;

                public void setTestBean(TestBean testBean) {
                        this.testBean =3D testBean;
                }

                protected void executeInternal(JobExecutionContext =
jobExecutionContext) {
                        System.out.println("Executing job..." + =
testBean.getAge());
                }
        }

Note that the "testBean" entry in the job data map is automatically =
applied as bean property in MyJob.

As a side note, I've refactored Colin's MethodInvokingFactoryBean into =
org.springframework.util.MethodInvoker, with MethodInvokingFactoryBean =
and MethodInvokingJobDetailFactoryBean as subclasses. They provide =
exactly the same invocation capabilities.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Daniel Potter
Sent: Thursday, February 19, 2004 4:17 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Quartz support


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.WsnInitialCo=
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,
>=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
> Juergen
>=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


-------------------------------------------------------
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=3Dick
_______________________________________________
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=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Quartz support

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

Juergen,
We'll give your strategy a shot when we get a chance.  Sounds like it
should work.  I'll be sure to respond to this list with the results.

Thanks for your help!
Daniel

On Thu, Feb 19, 2004 at 04:54:18PM +0100, j?rgen h?ller [werk3AT] wrote:
> Daniel,
>=20
> As you say, this is most likely caused by the fact that Quartz uses its o=
wn threads. WebSphere seems to associate the JNDI context information with =
container-managed threads; unfortunately, this does not apply to Quartz thr=
eads.
>=20
> However, there's a strategy that should work: pre-locate the JNDI objects=
, and pass the objects to Quartz' job data map. This way, the Quartz job sh=
ould receive the pre-located objects when running in its own thread, not ne=
eding to do a JNDI lookup itself.
>=20
> The Quartz support classes (to be committed within an hour!) provide the =
following:
>=20
> - a SchedulerFactoryBean that sets up a Quartz Scheduler, allowing to reg=
ister JobDetails, Calendars and Triggers with it
>=20
> - convenience subclasses of JobDetail, CronTrigger and SimpleTrigger that=
 allow for easy bean-style usage; the latter allow for implicit registratio=
n of an associated JobDetail
>=20
> - a FactoryBean for a JobDetail that invokes a method of an existing obje=
ct, to avoid the need for writing one-line Job implementations that just de=
legate to a business method
>=20
> - a convenience implementation of Quartz' Job interface, applying job dat=
a map entries as bean properties
>=20
> A configuration example:
>=20
> 	<bean id=3D"scheduler" class=3D"org.springframework.scheduling.quartz.Sc=
hedulerFactoryBean">
> 		<property name=3D"triggers">
> 			<list>
> 				<ref bean=3D"myTrigger1"/>
> 				<ref bean=3D"myTrigger2"/>
> 			</list>
> 		</property>
> 	</bean>
>=20
> 	<bean id=3D"myJobDetail1" class=3D"org.springframework.scheduling.quartz=
.JobDetailBean">
> 		<property name=3D"jobClass"><value>werk3.example.MyJob</value></propert=
y>
> 		<property name=3D"jobDataAsMap">
> 			<map>
> 				<entry key=3D"testBean">
> 					<bean class=3D"org.springframework.beans.TestBean">
> 						<property name=3D"age"><value>99</value></property>
> 					</bean>
> 				</entry>
> 			</map>
> 		</property>
> 	</bean>
>=20
> 	<bean id=3D"myJobDetail2" class=3D"org.springframework.scheduling.quartz=
.MethodInvokingJobDetailFactoryBean">
> 		<property name=3D"targetObject"><ref bean=3D"exampleService"/></propert=
y>
> 		<property name=3D"targetMethod"><value>doSomething</value></property>
> 	</bean>
>=20
> 	<bean id=3D"myTrigger1" class=3D"org.springframework.scheduling.quartz.C=
ronTriggerBean">
> 		<property name=3D"jobDetail"><ref bean=3D"myJobDetail1"/></property>
> 		<property name=3D"cronExpression"><value>0/5 * * * * ?</value></propert=
y>
> 	</bean>
>=20
> 	<bean id=3D"myTrigger2" class=3D"org.springframework.scheduling.quartz.S=
impleTriggerBean">
> 		<property name=3D"jobDetail"><ref bean=3D"myJobDetail2"/></property>
> 		<property name=3D"repeatInterval"><value>1000</value></property>
> 	</bean>
>=20
> MyJob (as referenced from "myJobDetail1") can be implemented as follows:
>=20
> 	public static class MyJob extends QuartzJobBean {
>=20
> 		private TestBean testBean;
>=20
> 		public void setTestBean(TestBean testBean) {
> 			this.testBean =3D testBean;
> 		}
>=20
> 		protected void executeInternal(JobExecutionContext jobExecutionContext)=
 {
> 			System.out.println("Executing job..." + testBean.getAge());
> 		}
> 	}
>=20
> Note that the "testBean" entry in the job data map is automatically appli=
ed as bean property in MyJob.
>=20
> As a side note, I've refactored Colin's MethodInvokingFactoryBean into or=
g.springframework.util.MethodInvoker, with MethodInvokingFactoryBean and Me=
thodInvokingJobDetailFactoryBean as subclasses. They provide exactly the sa=
me invocation capabilities.
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Daniel Potter
> Sent: Thursday, February 19, 2004 4:17 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Quartz support
>=20
>=20
> 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):
>=20
>   <!-- 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=
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>
>=20
>   <!-- 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>
>=20
> 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?
>=20
> Regards,
> Daniel
>=20
> 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 f=
rom a job scheduling consulting project I did in autumn 2003. We have concr=
ete needs for this now at werk3AT, thus the revival: It's about quite simpl=
e cron-style scheduling of application jobs.
> > =20
> > The basic idea is to set up a Quartz Scheduler via a SchedulerFactoryBe=
an, also allowing to register scheduled jobs there via a <list> of <refs> t=
o ScheduledJobDefinition beans. A ScheduledJobDefinition is just a simple c=
ombination 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 f=
or implementing a custom Job object), with a cron trigger.
> > =20
> > Both job definition beans can link in a separate Quartz Trigger instanc=
e 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 Sp=
ring. Typically no rescheduling or the like: All schedules are set up on co=
ntext startup, defined as bean definitions. Of course, you can also fetch t=
he Scheduler instance and perform any custom scheduling, instead of using p=
reconfigured ScheduledJobDefinition beans.
> > =20
> > The typical usage scenario are low-level jobs within an application, li=
ke data synchronization or storage cleanup - all predefined jobs that are j=
ust customized by an administrator. Fits nicely into Spring's application c=
ontext model; most jobs will simply delegate to Spring-managed business obj=
ects.
> > =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 fin=
al, as it's just 6 pretty simple classes (yes, I know - feature freeze - ne=
ver mind ;-). The main question is where to put it: I suggest "org.springfr=
amework.scheduling.quartz".
> > =20
> > If there are no general objections, I'll commit it by the end of this w=
eek, for review within the next week - still plenty of time before 1.0 fina=
l ;-) 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
>=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=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=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

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-----

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

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

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

Daniel,

As you say, this is most likely caused by the fact that Quartz uses its =
own threads. WebSphere seems to associate the JNDI context information =
with container-managed threads; unfortunately, this does not apply to =
Quartz threads.

However, there's a strategy that should work: pre-locate the JNDI =
objects, and pass the objects to Quartz' job data map. This way, the =
Quartz job should receive the pre-located objects when running in its =
own thread, not needing to do a JNDI lookup itself.

The Quartz support classes (to be committed within an hour!) provide the =
following:

- a SchedulerFactoryBean that sets up a Quartz Scheduler, allowing to =
register JobDetails, Calendars and Triggers with it

- convenience subclasses of JobDetail, CronTrigger and SimpleTrigger =
that allow for easy bean-style usage; the latter allow for implicit =
registration of an associated JobDetail

- a FactoryBean for a JobDetail that invokes a method of an existing =
object, to avoid the need for writing one-line Job implementations that =
just delegate to a business method

- a convenience implementation of Quartz' Job interface, applying job =
data map entries as bean properties

A configuration example:

	<bean id=3D"scheduler" =
class=3D"org.springframework.scheduling.quartz.SchedulerFactoryBean">
		<property name=3D"triggers">
			<list>
				<ref bean=3D"myTrigger1"/>
				<ref bean=3D"myTrigger2"/>
			</list>
		</property>
	</bean>

	<bean id=3D"myJobDetail1" =
class=3D"org.springframework.scheduling.quartz.JobDetailBean">
		<property =
name=3D"jobClass"><value>werk3.example.MyJob</value></property>
		<property name=3D"jobDataAsMap">
			<map>
				<entry key=3D"testBean">
					<bean class=3D"org.springframework.beans.TestBean">
						<property name=3D"age"><value>99</value></property>
					</bean>
				</entry>
			</map>
		</property>
	</bean>

	<bean id=3D"myJobDetail2" =
class=3D"org.springframework.scheduling.quartz.MethodInvokingJobDetailFac=
toryBean">
		<property name=3D"targetObject"><ref =
bean=3D"exampleService"/></property>
		<property name=3D"targetMethod"><value>doSomething</value></property>
	</bean>

	<bean id=3D"myTrigger1" =
class=3D"org.springframework.scheduling.quartz.CronTriggerBean">
		<property name=3D"jobDetail"><ref bean=3D"myJobDetail1"/></property>
		<property name=3D"cronExpression"><value>0/5 * * * * =
?</value></property>
	</bean>

	<bean id=3D"myTrigger2" =
class=3D"org.springframework.scheduling.quartz.SimpleTriggerBean">
		<property name=3D"jobDetail"><ref bean=3D"myJobDetail2"/></property>
		<property name=3D"repeatInterval"><value>1000</value></property>
	</bean>

MyJob (as referenced from "myJobDetail1") can be implemented as follows:

	public static class MyJob extends QuartzJobBean {

		private TestBean testBean;

		public void setTestBean(TestBean testBean) {
			this.testBean =3D testBean;
		}

		protected void executeInternal(JobExecutionContext =
jobExecutionContext) {
			System.out.println("Executing job..." + testBean.getAge());
		}
	}

Note that the "testBean" entry in the job data map is automatically =
applied as bean property in MyJob.

As a side note, I've refactored Colin's MethodInvokingFactoryBean into =
org.springframework.util.MethodInvoker, with MethodInvokingFactoryBean =
and MethodInvokingJobDetailFactoryBean as subclasses. They provide =
exactly the same invocation capabilities.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Daniel Potter
Sent: Thursday, February 19, 2004 4:17 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Quartz support


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.WsnInitialCo=
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.
=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 =
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
>=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


-------------------------------------------------------
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=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Form View and Results View on same page issue.

[Shane W. <swa...@si...>]

Trevor,

I would also like to see your controller as I been banging my head over the
same type scenario.  Would you be willing to post it to the group?

Thanks,

Shane Walters

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Trevor Cook
Sent: Tuesday, February 17, 2004 8:06 AM
To: spr...@li...
Subject: RE: [Springframework-developer] Form View and Results View on
same page issue.


>>I believe that the controller shouldn't have to be altered just because
it's returning to the same view
While this sounds good, the problem is there are 2 pieces, the model and
view.  You can use the same view by simply setting successView the same as
formView.  The issue is that other methods (like referenceData) are not
generating the model correctly.  While this is wrong in the scenario you
describe, generating the model for successView all the time would mean a
bloated model for the current usage where you are sending to a different
view.

Another simple way to handle this is to use "return showForm(...)" in the
onSubmit method.  I personally don't like this, mainly because you still
have extra baggage in the SimpleFormController that you aren't using.

I'll post my controller this afternoon.

Trevor


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of William Lyvers
Sent: February 17, 2004 8:40 AM
To: spr...@li...
Subject: RE: [Springframework-developer] Form View and Results View on
same page issue.


First, you described the problem correctly.  The link you sent is the exact
scenario that I was describing.  When I first realized that
SimpleFormController wasn't going to support this type of page out of the
box, I looked at extended BaseCommandController as you have done.  I
resisted this mainly for 2 reasons.
1. As you mentioned, it was yet another FormController and I didn't thing it
was likely that it would be pulled back into Spring since there are already
about 5 flavors of controllers.  Arguably, there may already be too many
versions of controllers within the Framework.
2. Personally, I believe that the controller shouldn't have to be altered
just because it's returning to the same view.  I should be able to return a
success view string and not have to alter my subclass just because I am
reposting back to the same form.

In either case, this is such a common scenario I would hope that the Spring
Framework would support this out of the box by either another
CommandController as you have suggested or enhancing SimpleFormController as
I did in the first part of this thread.

Thanks,
Bill Lyvers

I would be very interested in seeing your SelfPostingFormController.  It is
probably a much simpler workflow since you know you are only working with
one view.


---------- Original Message ----------------------------------
From: "Trevor Cook" <tc...@in...>
Reply-To: spr...@li...
Date:  Mon, 16 Feb 2004 22:18:54 -0500

>It sounds like your problem is with the workflow of SimpleFormController.
>Before recommending an option, let me clarify what you are trying to do.
It
>sounds like it should be:
>
>- use posted bean to determine search params (if it exists - for "get" use
>default values of search-param bean)
>- return view with search results
>
>You don't need a "FormView"/"SuccessView", just a single view.  You also
>would need any "referenceData" like method to be called before returning
the
>view, regardless of get/post.  Is this a correct understanding of your
>problem?  If so, take a quick look at something I've implemented at
>http://www.fotosource.com/my_local_store.html .  Basically, the filters
>above the search results are constantly redisplayed with changing results
>underneath.  The form also works for an initial get request (with no search
>filters) and then successive posts (through the filter button).
>
>I implemented this by extending BaseCommandController
>(SimpleFormController's "grandfather").  You can probably simply implement
>what you're looking for by extending this class (or if necessary, step back
>another level to AbstractController).  I never contributed this class (I
>called it "SelfPostingFormController") because it was fairly simple to
>implement, and considering most custom apps functionality is "exactly like
>class X except for Y" I didn't want to bloat Spring.  Would this type of
>class be generally useful (or has another developer already snuck this in)?
>If multiple users want this I'll add it, otherwise I'll just post the code
>seperately for you to use.
>
>Trevor
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of wi...@ly...
>Sent: February 16, 2004 7:18 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Form View and Results View on
>same page issue.
>
>
>I posted this late last week but didn't get any bites -- maybe I'll try
>a different angle :).
>In short, I believe that the SimpleFormController should be enhanced to
>support posting results back to the originating form page.  The current
>implementation requires implementing classes to know they are returning
>back to the originating form page.  This limits the generic ability of
>wiring up views via IOC and getSuccessView() on SimpleFormHandler.
>Since this is such a common scenario, I was hoping this could be
>addressed prior to the 1.0 release.  Thoughts?
>
>Bill Lyvers
>
>
>wi...@ly... wrote:
>
>> I recently started using the web framework portion of Spring.  One
>> concept in particular has bitten me a couple of times and I have been
>> unable to determine a best practice.  The concept is how
>> SimpleFormHandler has a different workflow based on whether it is a
>> get request versus a post request.  This concept seemed very intuitive
>> and works fine if the post goes off to a result page.  However, below
>> is a scenario that I believe is quite common and SimpleFormHandler
>> doesn't seem to deal with it very elegantly.  The problem arises when
>> a page displays both a form and the results of a form post on the same
>> page.
>>
>> Scenario:
>> There is item search page with a item search form on the top and a
>> tabular view of the item search results below the search page.
>>
>> Example Controller:
>> public class ItemSearchController extends SimpleFormController {
>>    private ItemManager manager;
>>    public void setSearchManager(ItemManager manager) {
>>        this.manager = manager;
>>    }
>>    protected Map referenceData(HttpServletRequest request) throws
>> Exception {
>>        Map map = new HashMap();
>>        map.put( "itemTypes", manager.getItemTypes() );
>>        return map;
>>    }
>>    protected ModelAndView onSubmit(Object object) throws Exception {
>>        Item command = (Item)object;
>>        return new ModelAndView( getSuccessView(), "items",
>> manager.findItemsByExample( command ));
>>    }
>> }
>>
>> So, I request the page via /searchItem.htm which maps
>> ItemSearchController.  The "get" workflow works as usual --
>> referenceData gets called and the page displays fine.  The user
>> submits a search criteria which then goes through "post" workflow and
>> onSubmit gets called which returns a list of items via ModelAndView.
>> The successView now needs to return to the same page and this time the
>> results will be displayed below the form. However,
>>    1. If I forward back to /searchItem.htm, then I end up in an
>> infinite loop because the controller keeps processing it as a post.
>>    2. If I forward on to the jsp that displayed the form originally, I
>> will not go through the same workflow as when the page was first
>> loaded and referenceData won't get called. Not too mention that I'll
>> get an binding errors missing exception -- I saw that RC1 tried to
>> address this, but only if you don't override onsubmit.
>>
>> So, I decided to solve the problem with option 1 and cause the form to
>> realize that the post had already been handled and it must be a "get"
>> request being caused by a forward.  The main reason for this is that
>> the get workflow gets used when entering the page each.  To fix it, I
>> overrode isFormSubmission and set an attribute when a formSubmission
>> was recognized.  If this attribute already exists, it assumes that it
>> is a get request instead. Example:
>> protected boolean isFormSubmission(HttpServletRequest
>> httpServletRequest) {
>>        Object alreadySubmitted = httpServletRequest.getAttribute(
>> "formSubmission");
>>        if (alreadySubmitted != null) {
>>            return false;
>>        }
>>        boolean formSubmission =
>> super.isFormSubmission(httpServletRequest);
>>        if( formSubmission ) {
>>            httpServletRequest.setAttribute( "formSubmission",
>> Boolean.TRUE );
>>        }
>>        return formSubmission;
>> }
>>
>>
>> I am a surprised that SimpleFormController doesn't deal with this
>> scenario since it is so common or maybe I am missing something and it
>> does.   With the above code you can switch out the success view to go
>> to a seperate result page later by just changing the IOC
>> configuration.   Basically, your controller doesn't really need to
>> know that the results page is the same view as the form view.
>>
>> I am very curious on how others are dealing with this scenario and if
>> Spring deals with it and I have just overlooked it.
>>
>> Keep up the good work,
>> Bill Lyvers
>>
>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> 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_id=3438&op=click
>> _______________________________________________
>> 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_id=3438&op=click
>_______________________________________________
>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_id=3438&op=click
>_______________________________________________
>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_id=3438&op=click
_______________________________________________
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_id=3438&op=click
_______________________________________________
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

[Springframework-developer] Code example error

[Eduardo I. I. <zi...@su...>]

The code example in Section 3.6.2 of the reference manual is wrong:


XmlBeanFactory factory = new XmlBeanFactory(new FileInputStream("beans.xml"));
Properties props = new Properties();
props.load(new FileInputStream("jdbc.properties"));
PropertyPlaceholderConfigurer cfg = new PropertyPlaceholderConfigurer(props);
cfg.postProcessBeanFactory(factory);


PropertyPlaceholderConfigurer only have a default constructor, so the 
setProperties must be used.


Also, the other day I sent some questions regarding the docs, but nobody 
noticed... I'm sending them again, in the hope to have the already good 
reference manual being always improved.


-----

I have some observations on some points that should be clarified in the
document:


1.1 -	The term "messaging" reminds me of Middleware. It should be replaced
everywhere by text messages, resource bundle or something similar.

3.1 -	BeanFactories are thread safe?

3.2.4 -	why there are two ways to identify beans, using name/id attributes? When
use one or another?

3.2.5 -	A singleton bean is unique per BeanFactory or the entire JVM?

3.3.3 -	What happens if the dependency check failed?
	If dependency check is on all setter methods must be called?

3.4.2 -	It would be good to explain that these are callback methods that will be
called by the BeanFactory and must me implemented by the JavaBeans.

3.4.3 -	Typo "The org.springframework.beans.factory.FactoryBean is to be
implemented *BY* objects that are..."
	When I have to implement a FactoryBean? Maybe this section should be moved to 3.6
	
3.5 -	Typo "maintaining a registry oof"

3.6 -	Is it really so advanced? Its name can scare users and keep them of
reading useful information like PropertyPlaceholderConfigurer.

3.6.2 -	In the third box there is a floating "=" in the first line
	A few line breaks would make the code look clearer:
	
	XmlBeanFactory factory = new XmlBeanFactory(new FileInputStream("beans.xml"));
	
	Properties props = new Properties();
	props.load(new FileInputStream("jdbc.properties"));
	
	PropertyPlaceholderConfigurer cfg = new PropertyPlaceholderConfigurer(props);
	cfg.postProcessBeanFactory(factory);

	And for the above code to work, must I say that the beans are constructed on
demand, even singletons, and not at the instantiation of the factory?
	
3.7.1 -	What if there is no default constructor? And when there are
constructor-args?
	7. The so called init-method?
	It's not clear exactly when the destruction methods will be called, only when
the vm is shutting down, or it can be done programatically?

3.8.3 -	This section should be a subsection of 3.8.2
	ref looks up for beans by the id or name attribute?
	List elements and Map values can be properties, lists, maps or refs?
	There is no support for arrays?
	
3.9 -	Typo "constructor-based depenency injection"
	Is it right to say that as a rule of thumb, I should use BeanFactory in a
standalone application, and ApplicationContext in web and ejb applications?

3.10 -	It starts to talk about ApplicationContext funcionality but it don't
explain how can I get an instance of it! Where it would come from? A simple
application example would be useful here.

	Typo "The ResourceBundleMessageSource is more interesting and is the one we
will provide(s) an example for"

3.10.2-	Table 3.4 - Typo "Closed here means that are singletos are destroyed"

	In the examples, setters should not be ommitted for brevity, but should be
included for clarity (they are not that long)


General -

What spring jars are available? Whats their dependency?

Formating: the text should not be right justified and should not use
hyphenation, to ease reading.

Authors?

[Springframework-developer] possible null pointer dereferences x 3 (findbugs)

[Janek B. <ya...@st...>]

findbugs 0.7.1 located 3 possible null pointer dereferences in
spring.jar (RC1). I've pasted the relevant source code here along with a
count of other potential bugs located by findbugs.


Not short circuited logic:

org.springframework.web.servlet.mvc.AbstractWizardFormController.setPages(String[])

	public final void setPages(String[] pages) {
		if (pages == null | pages.length == 0)  {
			throw new IllegalArgumentException("No wizard pages defined");
		}
		this.pages = pages;
	}



viewClass could be null when getName() is invoked:

org.springframework.web.servlet.view.UrlBasedViewResolver.setViewClass(Class)

	public void setViewClass(Class viewClass) {
		if (viewClass == null || !requiredViewClass().isAssignableFrom(viewClass)) {
			throw new IllegalArgumentException("Given View class [" + viewClass.getName() + "] is not of type [" +
                        requiredViewClass().getName() + "]");
		}
		this.viewClass = viewClass;
	}



Should the method exit when factory is found to be undefined?

org.springframework.web.servlet.view.tiles.TilesView.

	protected void renderMergedOutputModel(Map model, HttpServletRequest request,
	                                       HttpServletResponse response) throws Exception {
		if (!response.isCommitted()) {
			response.setContentType(getContentType());
		}
		
		// get definitions factory
		DefinitionsFactory factory = (DefinitionsFactory)
			getWebApplicationContext().getServletContext().
			getAttribute(TilesUtilImpl.DEFINITIONS_FACTORY);
		if (factory == null) {
			response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
                        "Tiles definitions factory not found: TilesConfigurer not defined?");
		}

		// get component definition
		ComponentDefinition definition = factory.getDefinition(getUrl(), request, getServletContext());



findbugs also noted potential bugs in 11 other categories:

	Dropped or ignored exception: 1
	Dubious method used: 7
	Method returning array may expose internal representation: 15
	Equal objects must have equal hashcodes: 6
	Mutable static field: 7
	Using notify() rather than notifyAll() in method: 1
	Redundant comparison to null: 2
	Should be static inner class: 2
	Incorrect definition of serializable class: 6
	Unread field: 1
	Unused field: 2

I picked the easiest category (potential NPEs) to highlight. Whether the remaining bugs are important or actually bugs at all requires a bit more thought!

-Janek 

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

[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

[Ou, R. <Ro...@sa...>]

This would be actually quite useful to us too.

+1

Rong


> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]
> On Behalf
> Of j=FCrgen h=F6ller [werk3AT]
> Sent: Wednesday, February 18, 2004 4:43 PM
> To: spr...@li...
> Subject: [Springframework-developer] Quartz support
>=20
>=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 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

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

[Dmitriy K. <dko...@ru...>]

Nice feature! We might be able to utilize this=2E +1 from me=2E=2E=2E

Regards=2C
Dmitriy=2E

----- Original Message -----
From=3A j=C3=BCrgen h=C3=B6ller =5Bwerk3AT=5D =3Cjuergen=2Ehoeller=40werk=
3at=2Ecom=3E
Date=3A Wednesday=2C February 18=2C 2004 5=3A43 pm
Subject=3A =5BSpringframework-developer=5D Quartz support

=3E Everybody=2C
=3E =

=3E I=27ve revived my Quartz support classes for Spring today=2E They =

=3E emerged from a job scheduling consulting project I did in autumn =

=3E 2003=2E We have concrete needs for this now at werk3AT=2C thus the =

=3E revival=3A It=27s about quite simple cron-style scheduling of =

=3E application jobs=2E
=3E =

=3E The basic idea is to set up a Quartz Scheduler via a =

=3E SchedulerFactoryBean=2C also allowing to register scheduled jobs =

=3E there via a =3Clist=3E of =3Crefs=3E to ScheduledJobDefinition beans=2E=
 A =

=3E ScheduledJobDefinition is just a simple combination of a Quartz =

=3E JobDetail and a Quartz Trigger=2E
=3E =

=3E ScheduledJobDefinition bean implementations include=3A
=3E - DefaultScheduledJobDefinition=2C allowing to use any =

=3E implementation of Quartz=27 Job interface with a declaratively =

=3E configured job data map and cron trigger
=3E - MethodInvokingJobDefinition=2C allowing to specify a method of a =

=3E Spring-managed bean to execute as job (completely declarative=2C =

=3E without the need for implementing a custom Job object)=2C with a =

=3E cron trigger=2E
=3E =

=3E Both job definition beans can link in a separate Quartz Trigger =

=3E instance instead of a cron expression=3B =

=3E DefaultScheduledJobDefinition can also link in a separate Quartz =

=3E JobDetail instance instead of a job class=2E
=3E =

=3E That=27s all there is=3A A simple declarative way of using Quartz =

=3E within Spring=2E Typically no rescheduling or the like=3A All =

=3E schedules are set up on context startup=2C defined as bean =

=3E definitions=2E Of course=2C you can also fetch the Scheduler instance=
 =

=3E and perform any custom scheduling=2C instead of using preconfigured =

=3E ScheduledJobDefinition beans=2E
=3E =

=3E The typical usage scenario are low-level jobs within an =

=3E application=2C like data synchronization or storage cleanup - all =

=3E predefined jobs that are just customized by an administrator=2E Fits =

=3E nicely into Spring=27s application context model=3B most jobs will =

=3E simply delegate to Spring-managed business objects=2E
=3E =

=3E I expect to have this polished by the end of the week=2C as we need =

=3E it at werk3AT quite urgently=2E I=27d like to include this already in=
 =

=3E Spring 1=2E0 final=2C as it=27s just 6 pretty simple classes (yes=2C =
I =

=3E know - feature freeze - never mind =3B-)=2E The main question is wher=
e =

=3E to put it=3A I suggest =22org=2Espringframework=2Escheduling=2Equartz=
=22=2E
=3E =

=3E If there are no general objections=2C I=27ll commit it by the end of =

=3E this week=2C for review within the next week - still plenty of time =

=3E before 1=2E0 final =3B-) Looking forward to your feedback! =

=3E =

=3E Juergen
=3E =

=3E =

=3E =

=3E -------------------------------------------------------
=3E SF=2ENet is sponsored by=3A Speed Start Your Linux Apps Now=2E
=3E Build and deploy apps =26 Web services for Linux with
=3E a free DVD software kit from IBM=2E Click Now!
=3E http=3A//ads=2Eosdn=2Ecom/=3Fad=5Fid=1356=26alloc=5Fid438=26op=3Dclic=
k
=3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
=3E Springframework-developer mailing list
=3E Springframework-developer=40lists=2Esourceforge=2Enet
=3E https=3A//lists=2Esourceforge=2Enet/lists/listinfo/springframework-de=
veloper
=3E 

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
>