Jasper Rosenberg - [12/Jun/06 02:38 PM ] If property 'org.quartz.scheduler.jmx.export' is 'true', then export the QuartzScheduler to the local MBean server using commons modeler. Commons modeler was chosen in the hope of remaining mbean server implementation independent while not introducing new licensing issues. Create the object name using pattern: quartz:type=QuartzScheduler,name=<instanceName>,instance=<instanceId> but also allow the object name to be explicitly specified. If property 'org.quartz.scheduler.jmx.proxy' is true, then StdSchedulerFactory will return a proxied instance of the scheduler to the exported JMX instance (just like for RMI). There will be a check to make sure both jmx and rmi proxying is not specified. Because the 'javax.management.remote' package is new for JEE 5, we can't just provide a generic JMX scheduler proxy (at least not w/o updating the jmx.jar) Instead, for now, support a property 'org.quartz.scheduler.jmx.proxy.class' which will be a jmx proxy scheduler instance implementing a few methods off a base class to do the actual remote communication. It will also support properties (like JobFactory). We should look at how Spring does its MBean proxying when we are ready to support a generic JMXConnector. For now, the can at least provide a proxy class implementation for JBoss's RMIAdaptor.

Tore Gard - [08/Nov/06 08:39 AM ] It would be nice if for example the Glassfish app.server could host Quartz in an standard MBean. I've manage to start an instans in Glassfish But it's jar files (core) may conflict (many error messages at start up..?). Jboss has an JNDI solution that use "org.jboss.naming.NonSerializableFactory" to put the Quartz NonSerializable instance on to the tree. This is not a standard api.