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