RMI is a nice feature of the Java library. The capability to a call a method on an object from one JVM on a second JVM located on a machine in another part of the world is really powerful. But for RMI to work, several things must be in total alignment. Java is a very dynamic programming language. It supports the capability to (at runtime) download new class files that are not defined within the JVM's classpath. Along with this flexibility comes danger. You can imagine the bad things that could happen if your application were to download someone else's classes without you having knowledge of what's inside.
Using the RMISecurityManager
When using RMI, code that doesn't yet exist in the client can be dynamically downloaded from the server program. By default, the RMI application does not install a SecurityManager. This can be dangerous if an unsuspecting client downloads malicious code. To help secure the application, the RMI server application should install a special SecurityManager called RMISecurityManager.
The RMISecurityManager uses a Java security policy file to determine what permissions are granted to the RMI application. By default, Java looks for a policy file in the java.home/lib/security directory. A sample policy file entry is shown here:
grant { permission java.security.AllPermission; };
This policy file entry grants full access to everyone. You should start with this setting to get everything working and then tighten your security policy.
Creating a Quartz RMI Server |
Scheduling in the Enterprise
Getting Started with Quartz
Hello, Quartz
Scheduling Jobs
Cron Triggers and More
JobStores and Persistence
Implementing Quartz Listeners
Using Quartz Plug-Ins
Using Quartz Remotely
Using Quartz with J2EE
Clustering Quartz
Quartz Cookbook
Quartz and Web Applications
Using Quartz with Workflow
Appendix A. Quartz Configuration Reference