You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Luke McCollum <lu...@sacramentopress.com> on 2010/09/09 00:59:53 UTC
Setting up Quartz Scheduler and making it available via JNDI
I use OpenEJB+Jetty as a development environment for a quick starting alternative to building an ear and deploying to JBoss. Unfortunately, this means duplicating some things that are JBoss-specific. I do have everything running swimmingly, but now I'm trying to add some new functionality.
Currently, I'm trying to get Quartz fully set up and started by the container and make the Scheduler available via JNDI. I've seen some older correspondences on getting it to work using the Resource Adapter, but according to the this page: http://www.len.ro/2008/10/another-way-to-use-quartz-in-jboss/ , I don't actually need it. Mainly because I'm using Quartz to schedule jobs on the the fly (and persist them). The resource adapter method seems to be more for people wanting to schedule jobs using MDBs.
So I think the correct approach to this problem would be simply to create a service-jar.xml for OpenEJB with something like this:
<ServiceJar>
<ServiceProvider
id="Quartz"
service="Resource"
types="org.quartz.Scheduler"
factory-name="getDefaultScheduler"
class-name="org.quartz.impl.StdSchedulerFactory">
</ServiceProvider>
</ServiceJar>
And declare a resource in my openejb.xml like so:
<Resource id="Quartz" type="org.quartz.Scheduler" provider="Quartz" />
This is essentially what the JBoss MBean (aka QuartzService in the link above) is providing - a factory to create the service on startup and expose it via JNDI, but this seems to be not working the way I'd expect. I'm putting the service-jar.xml in my src/test/resources directory on my EJB project, which ends up being on the classpath when Jetty/OpenEJB start up. Am I misunderstanding how the service-jar.xml works? Maybe putting it in the wrong place? Or maybe I'm taking the wrong approach altogether?
Re: Setting up Quartz Scheduler and making it available via JNDI
Posted by Andy <an...@orprovision.com>.
Made the RA lookup name consistent. It should now work as described - The RA 'id' was missing in the repo ra.xml.
new InitialContext().lookup("java:openejb/Resource/QuartzResourceAdapter")
Andy.
Re: Setting up Quartz Scheduler and making it available via JNDI
Posted by Luke McCollum <lu...@sacramentopress.com>.
Thank you David! This fixed my problem.
Also, thanks to Andy for providing the RA solution. For anyone else attempting the same thing, my quartz resource adapter ended up being in JNDI here:
"java:openejb/Resource/quartz-ra-1.0.jarRA"
I think I remember reading on another thread that Open EJB publishes modules on something like: java:openejb/Resource/[classpath][RA if its a resource adapter], so if you have the ra.xml included as a maven project, then the jndi location might be:
java:openejb/Resources/quartz-ra/classesRA or something to that effect.
On Sep 13, 2010, at 8:45 PM, David Blevins wrote:
>
> On Sep 13, 2010, at 2:50 PM, Luke McCollum wrote:
>
>> When using the alternate descriptors functionality, OpenEJB seems to load all of the beans from both my test.ejb-jar.xml and the normal ejb-jar.xml.
>
> Might be that the two files are not in the same directory and thus count as two different modules, i.e:
>
> somepath/META-INF/test.ejb-jar.xml
> anotherpath/META-INF/ejb-jar.xml
>
> The most common mistake is reference to Maven structure. This is two modules:
>
> foo/src/main/resources/META-INF/ejb-jar.xml
> foo/src/test/resources/META-INF/ejb-jar.xml
>
> As is this (openejb.altdd.prefix=test):
>
> foo/src/main/resources/META-INF/ejb-jar.xml
> foo/src/test/resources/META-INF/test.ejb-jar.xml
>
>
> -David
>
Re: Setting up Quartz Scheduler and making it available via JNDI
Posted by David Blevins <da...@visi.com>.
On Sep 13, 2010, at 2:50 PM, Luke McCollum wrote:
> When using the alternate descriptors functionality, OpenEJB seems to load all of the beans from both my test.ejb-jar.xml and the normal ejb-jar.xml.
Might be that the two files are not in the same directory and thus count as two different modules, i.e:
somepath/META-INF/test.ejb-jar.xml
anotherpath/META-INF/ejb-jar.xml
The most common mistake is reference to Maven structure. This is two modules:
foo/src/main/resources/META-INF/ejb-jar.xml
foo/src/test/resources/META-INF/ejb-jar.xml
As is this (openejb.altdd.prefix=test):
foo/src/main/resources/META-INF/ejb-jar.xml
foo/src/test/resources/META-INF/test.ejb-jar.xml
-David
Re: Setting up Quartz Scheduler and making it available via JNDI
Posted by Luke McCollum <lu...@sacramentopress.com>.
I've gotten this to work using the method Andy described, but I'm having trouble making the bean container specific. When using the alternate descriptors functionality, OpenEJB seems to load all of the beans from both my test.ejb-jar.xml and the normal ejb-jar.xml.
Is there a better way to do this, or some way to make OpenEJB only load the beans from one descriptor?
On Sep 9, 2010, at 4:36 PM, Luke McCollum wrote:
> Also, is there a better way to get a container specific bean than having multiple ejb-jar.xml files? I can imagine it getting out of control when eventually a lot has to be duplicated between two ejb-jars...
>
> I'm not terribly experienced with EJBs and all, I just keep wishing I had an easy way to override bean definitions.
>
> On Sep 9, 2010, at 4:14 PM, Luke McCollum wrote:
>
>> I'm giving this a shot now, but is there no way to do it as I've described? If I could make it work with the service-jar.xml method somehow, that would work best for me.
>>
>>
>> On Sep 9, 2010, at 12:10 AM, Andy wrote:
>>
>>> On 09.09.2010 00:59, Luke McCollum wrote:
>>>> I use OpenEJB+Jetty as a development environment for a quick starting alternative to building an ear and deploying to JBoss. Unfortunately, this means duplicating some things that are JBoss-specific. I do have everything running swimmingly, but now I'm trying to add some new functionality.
>>>>
>>>> Currently, I'm trying to get Quartz fully set up and started by the container and make the Scheduler available via JNDI. I've seen some older correspondences on getting it to work using the Resource Adapter, but according to the this page: http://www.len.ro/2008/10/another-way-to-use-quartz-in-jboss/ , I don't actually need it. Mainly because I'm using Quartz to schedule jobs on the the fly (and persist them). The resource adapter method seems to be more for people wanting to schedule jobs using MDBs.
>>>>
>>>> So I think the correct approach to this problem would be simply to create a service-jar.xml for OpenEJB with something like this:
>>>> <ServiceJar>
>>>> <ServiceProvider
>>>> id="Quartz"
>>>> service="Resource"
>>>> types="org.quartz.Scheduler"
>>>> factory-name="getDefaultScheduler"
>>>> class-name="org.quartz.impl.StdSchedulerFactory">
>>>>
>>>> </ServiceProvider>
>>>> </ServiceJar>
>>>>
>>>> And declare a resource in my openejb.xml like so:
>>>> <Resource id="Quartz" type="org.quartz.Scheduler" provider="Quartz" />
>>>>
>>>> This is essentially what the JBoss MBean (aka QuartzService in the link above) is providing - a factory to create the service on startup and expose it via JNDI, but this seems to be not working the way I'd expect. I'm putting the service-jar.xml in my src/test/resources directory on my EJB project, which ends up being on the classpath when Jetty/OpenEJB start up. Am I misunderstanding how the service-jar.xml works? Maybe putting it in the wrong place? Or maybe I'm taking the wrong approach altogether?
>>>>
>>> Hi Luke,
>>>
>>> If you drop the "\openejb3\examples\quartz-app\quartz-ra\target\quartz-ra-1.0-SNAPSHOT.jar" into your "[Path to OpenEJB]\lib" directory (and restart OpenEJB) then you can use a bean method something like the following to access the Scheduler:
>>>
>>> import org.apache.openejb.resource.quartz.QuartzResourceAdapter;
>>> import org.quartz.Scheduler;
>>> ....
>>>
>>> protected Scheduler getScheduler() throws InstantiationException {
>>>
>>> try {
>>> final QuartzResourceAdapter ra = (QuartzResourceAdapter) new InitialContext().lookup("java:openejb/Resource/QuartzResourceAdapter");
>>> log.debug("QuartzResourceAdapter: " + (null != ra ? "found" : "not found"));
>>> return ra.getScheduler();
>>> } catch (Throwable e) {
>>> final String err = "Lookup of QuartzResourceAdapter failed";
>>> log.warn(err, e);
>>> throw new InstantiationException(err);
>>> }
>>> }
>>>
>>> Doing it this way gives you the best of both worlds - And prevents possible conflicting configurations.
>>> Note, this is obviously not portable as is - But it would be trivial to use reflection or a container specific bean to gain access to the Scheduler, eg. JBoss provides the Scheduler like so:
>>>
>>> final InitialContext ctx = new InitialContext();
>>> return (Scheduler) ctx.lookup("Quartz");
>>>
>>> Regards,
>>>
>>> Andy.
>>>
>>>
>>
>
Re: Setting up Quartz Scheduler and making it available via JNDI
Posted by Luke McCollum <lu...@sacramentopress.com>.
Also, is there a better way to get a container specific bean than having multiple ejb-jar.xml files? I can imagine it getting out of control when eventually a lot has to be duplicated between two ejb-jars...
I'm not terribly experienced with EJBs and all, I just keep wishing I had an easy way to override bean definitions.
On Sep 9, 2010, at 4:14 PM, Luke McCollum wrote:
> I'm giving this a shot now, but is there no way to do it as I've described? If I could make it work with the service-jar.xml method somehow, that would work best for me.
>
>
> On Sep 9, 2010, at 12:10 AM, Andy wrote:
>
>> On 09.09.2010 00:59, Luke McCollum wrote:
>>> I use OpenEJB+Jetty as a development environment for a quick starting alternative to building an ear and deploying to JBoss. Unfortunately, this means duplicating some things that are JBoss-specific. I do have everything running swimmingly, but now I'm trying to add some new functionality.
>>>
>>> Currently, I'm trying to get Quartz fully set up and started by the container and make the Scheduler available via JNDI. I've seen some older correspondences on getting it to work using the Resource Adapter, but according to the this page: http://www.len.ro/2008/10/another-way-to-use-quartz-in-jboss/ , I don't actually need it. Mainly because I'm using Quartz to schedule jobs on the the fly (and persist them). The resource adapter method seems to be more for people wanting to schedule jobs using MDBs.
>>>
>>> So I think the correct approach to this problem would be simply to create a service-jar.xml for OpenEJB with something like this:
>>> <ServiceJar>
>>> <ServiceProvider
>>> id="Quartz"
>>> service="Resource"
>>> types="org.quartz.Scheduler"
>>> factory-name="getDefaultScheduler"
>>> class-name="org.quartz.impl.StdSchedulerFactory">
>>>
>>> </ServiceProvider>
>>> </ServiceJar>
>>>
>>> And declare a resource in my openejb.xml like so:
>>> <Resource id="Quartz" type="org.quartz.Scheduler" provider="Quartz" />
>>>
>>> This is essentially what the JBoss MBean (aka QuartzService in the link above) is providing - a factory to create the service on startup and expose it via JNDI, but this seems to be not working the way I'd expect. I'm putting the service-jar.xml in my src/test/resources directory on my EJB project, which ends up being on the classpath when Jetty/OpenEJB start up. Am I misunderstanding how the service-jar.xml works? Maybe putting it in the wrong place? Or maybe I'm taking the wrong approach altogether?
>>>
>> Hi Luke,
>>
>> If you drop the "\openejb3\examples\quartz-app\quartz-ra\target\quartz-ra-1.0-SNAPSHOT.jar" into your "[Path to OpenEJB]\lib" directory (and restart OpenEJB) then you can use a bean method something like the following to access the Scheduler:
>>
>> import org.apache.openejb.resource.quartz.QuartzResourceAdapter;
>> import org.quartz.Scheduler;
>> ....
>>
>> protected Scheduler getScheduler() throws InstantiationException {
>>
>> try {
>> final QuartzResourceAdapter ra = (QuartzResourceAdapter) new InitialContext().lookup("java:openejb/Resource/QuartzResourceAdapter");
>> log.debug("QuartzResourceAdapter: " + (null != ra ? "found" : "not found"));
>> return ra.getScheduler();
>> } catch (Throwable e) {
>> final String err = "Lookup of QuartzResourceAdapter failed";
>> log.warn(err, e);
>> throw new InstantiationException(err);
>> }
>> }
>>
>> Doing it this way gives you the best of both worlds - And prevents possible conflicting configurations.
>> Note, this is obviously not portable as is - But it would be trivial to use reflection or a container specific bean to gain access to the Scheduler, eg. JBoss provides the Scheduler like so:
>>
>> final InitialContext ctx = new InitialContext();
>> return (Scheduler) ctx.lookup("Quartz");
>>
>> Regards,
>>
>> Andy.
>>
>>
>
Re: Setting up Quartz Scheduler and making it available via JNDI
Posted by Luke McCollum <lu...@sacramentopress.com>.
I'm giving this a shot now, but is there no way to do it as I've described? If I could make it work with the service-jar.xml method somehow, that would work best for me.
On Sep 9, 2010, at 12:10 AM, Andy wrote:
> On 09.09.2010 00:59, Luke McCollum wrote:
>> I use OpenEJB+Jetty as a development environment for a quick starting alternative to building an ear and deploying to JBoss. Unfortunately, this means duplicating some things that are JBoss-specific. I do have everything running swimmingly, but now I'm trying to add some new functionality.
>>
>> Currently, I'm trying to get Quartz fully set up and started by the container and make the Scheduler available via JNDI. I've seen some older correspondences on getting it to work using the Resource Adapter, but according to the this page: http://www.len.ro/2008/10/another-way-to-use-quartz-in-jboss/ , I don't actually need it. Mainly because I'm using Quartz to schedule jobs on the the fly (and persist them). The resource adapter method seems to be more for people wanting to schedule jobs using MDBs.
>>
>> So I think the correct approach to this problem would be simply to create a service-jar.xml for OpenEJB with something like this:
>> <ServiceJar>
>> <ServiceProvider
>> id="Quartz"
>> service="Resource"
>> types="org.quartz.Scheduler"
>> factory-name="getDefaultScheduler"
>> class-name="org.quartz.impl.StdSchedulerFactory">
>>
>> </ServiceProvider>
>> </ServiceJar>
>>
>> And declare a resource in my openejb.xml like so:
>> <Resource id="Quartz" type="org.quartz.Scheduler" provider="Quartz" />
>>
>> This is essentially what the JBoss MBean (aka QuartzService in the link above) is providing - a factory to create the service on startup and expose it via JNDI, but this seems to be not working the way I'd expect. I'm putting the service-jar.xml in my src/test/resources directory on my EJB project, which ends up being on the classpath when Jetty/OpenEJB start up. Am I misunderstanding how the service-jar.xml works? Maybe putting it in the wrong place? Or maybe I'm taking the wrong approach altogether?
>>
> Hi Luke,
>
> If you drop the "\openejb3\examples\quartz-app\quartz-ra\target\quartz-ra-1.0-SNAPSHOT.jar" into your "[Path to OpenEJB]\lib" directory (and restart OpenEJB) then you can use a bean method something like the following to access the Scheduler:
>
> import org.apache.openejb.resource.quartz.QuartzResourceAdapter;
> import org.quartz.Scheduler;
> ....
>
> protected Scheduler getScheduler() throws InstantiationException {
>
> try {
> final QuartzResourceAdapter ra = (QuartzResourceAdapter) new InitialContext().lookup("java:openejb/Resource/QuartzResourceAdapter");
> log.debug("QuartzResourceAdapter: " + (null != ra ? "found" : "not found"));
> return ra.getScheduler();
> } catch (Throwable e) {
> final String err = "Lookup of QuartzResourceAdapter failed";
> log.warn(err, e);
> throw new InstantiationException(err);
> }
> }
>
> Doing it this way gives you the best of both worlds - And prevents possible conflicting configurations.
> Note, this is obviously not portable as is - But it would be trivial to use reflection or a container specific bean to gain access to the Scheduler, eg. JBoss provides the Scheduler like so:
>
> final InitialContext ctx = new InitialContext();
> return (Scheduler) ctx.lookup("Quartz");
>
> Regards,
>
> Andy.
>
>
Re: Setting up Quartz Scheduler and making it available via JNDI
Posted by joe <fi...@yahoo.de>.
> Just put it in the OpenEJB 'conf' directory - I use it too, and always
> add the following to remove the update nag:
>
> org.quartz.scheduler.skipUpdateCheck = true
>
> I'll eventually add the quartz properties to the RA configuration.
This sounds better than my last workaround, replacing the
quartz.properties file inside the quartz-1.5.2.jar ;)
For unit testing it seeems it has to be put in the source (root) folder
of the test classes.
thx
Re: Setting up Quartz Scheduler and making it available via JNDI
Posted by Andy <an...@orprovision.com>.
On 21.09.2010 12:08, joe wrote:
>> If you drop the
>> "\openejb3\examples\quartz-app\quartz-ra\target\quartz-ra-1.0-SNAPSHOT.jar"
>>
>> into your "[Path to OpenEJB]\lib" directory (and restart OpenEJB) then
>> you can use a bean method something like the following to access the
>> Scheduler:
>
> yes this works here too, nice.
> For configuring quartz i normally use a quartz.properties file.
> Is it possible to configure Quartz in this way with OpenEJB,
> where do i have to put the quartz.properties file?
>
>
Just put it in the OpenEJB 'conf' directory - I use it too, and always
add the following to remove the update nag:
org.quartz.scheduler.skipUpdateCheck = true
I'll eventually add the quartz properties to the RA configuration.
Andy.
Re: Setting up Quartz Scheduler and making it available via JNDI
Posted by joe <fi...@yahoo.de>.
> If you drop the
> "\openejb3\examples\quartz-app\quartz-ra\target\quartz-ra-1.0-SNAPSHOT.jar"
> into your "[Path to OpenEJB]\lib" directory (and restart OpenEJB) then
> you can use a bean method something like the following to access the
> Scheduler:
yes this works here too, nice.
For configuring quartz i normally use a quartz.properties file.
Is it possible to configure Quartz in this way with OpenEJB,
where do i have to put the quartz.properties file?
Re: Setting up Quartz Scheduler and making it available via JNDI
Posted by Andy <an...@orprovision.com>.
On 09.09.2010 00:59, Luke McCollum wrote:
> I use OpenEJB+Jetty as a development environment for a quick starting alternative to building an ear and deploying to JBoss. Unfortunately, this means duplicating some things that are JBoss-specific. I do have everything running swimmingly, but now I'm trying to add some new functionality.
>
> Currently, I'm trying to get Quartz fully set up and started by the container and make the Scheduler available via JNDI. I've seen some older correspondences on getting it to work using the Resource Adapter, but according to the this page: http://www.len.ro/2008/10/another-way-to-use-quartz-in-jboss/ , I don't actually need it. Mainly because I'm using Quartz to schedule jobs on the the fly (and persist them). The resource adapter method seems to be more for people wanting to schedule jobs using MDBs.
>
> So I think the correct approach to this problem would be simply to create a service-jar.xml for OpenEJB with something like this:
> <ServiceJar>
> <ServiceProvider
> id="Quartz"
> service="Resource"
> types="org.quartz.Scheduler"
> factory-name="getDefaultScheduler"
> class-name="org.quartz.impl.StdSchedulerFactory">
>
> </ServiceProvider>
> </ServiceJar>
>
> And declare a resource in my openejb.xml like so:
> <Resource id="Quartz" type="org.quartz.Scheduler" provider="Quartz" />
>
> This is essentially what the JBoss MBean (aka QuartzService in the link above) is providing - a factory to create the service on startup and expose it via JNDI, but this seems to be not working the way I'd expect. I'm putting the service-jar.xml in my src/test/resources directory on my EJB project, which ends up being on the classpath when Jetty/OpenEJB start up. Am I misunderstanding how the service-jar.xml works? Maybe putting it in the wrong place? Or maybe I'm taking the wrong approach altogether?
>
Hi Luke,
If you drop the
"\openejb3\examples\quartz-app\quartz-ra\target\quartz-ra-1.0-SNAPSHOT.jar"
into your "[Path to OpenEJB]\lib" directory (and restart OpenEJB) then
you can use a bean method something like the following to access the
Scheduler:
import org.apache.openejb.resource.quartz.QuartzResourceAdapter;
import org.quartz.Scheduler;
....
protected Scheduler getScheduler() throws InstantiationException {
try {
final QuartzResourceAdapter ra = (QuartzResourceAdapter) new
InitialContext().lookup("java:openejb/Resource/QuartzResourceAdapter");
log.debug("QuartzResourceAdapter: " + (null != ra ? "found" :
"not found"));
return ra.getScheduler();
} catch (Throwable e) {
final String err = "Lookup of QuartzResourceAdapter failed";
log.warn(err, e);
throw new InstantiationException(err);
}
}
Doing it this way gives you the best of both worlds - And prevents
possible conflicting configurations.
Note, this is obviously not portable as is - But it would be trivial to
use reflection or a container specific bean to gain access to the
Scheduler, eg. JBoss provides the Scheduler like so:
final InitialContext ctx = new InitialContext();
return (Scheduler) ctx.lookup("Quartz");
Regards,
Andy.