I have used Quartz Scheduler to Schedule certain Task. This is done as a simple Java Application which I later export as a runnable Jar File. This Jar File is build into my web Service and I export the entire project as a WAR file. I run this WAR File in my Apache Tomcat.
My Runnable JAR File accesses the catalina.home but everything time it tries to.... System.getProperty(catalina.home ) returns null. I understand that this may be because my JAR is a Java application. But since I am putting the jar inside a war and deploying it in the server... i thought it might be able to access catalina.home but it cannot. Any suggestions on how I can fix this issue?
The real question is "why are you attempting to access CATALINA_HOME?".
The only stuff in CATALINA_HOME is stuff that Tomcat itself needs. Web applications (and stand-alone applications) shouldn't be directly accessing anything there.
An IDE is no substitute for an Intelligent Developer.
Joined: Sep 22, 2011
I am saving my log files there.... I figured if I need to deploy my application in different systems across different OS, I need a constant place where i can save and access the log files, can't use user.home cause they keeping changing with system and user..... that'd mean I would have to access it at different locations each time.... catalina.home makes it easy because I'll know i can always access my log files there.... in catalina's home directory....
Rather than CATALINA_HOME, then, what you really need is a LOG_HOME. I'll make an exception to my assertion about "hands off catalina.home" for logfiles. But on a Unix/Linux system, the recommended place for logfiles is under /var/log. I'm not familiar enough with OSX, but I think that it, too has a /var/log. Windows, of course, is up for grabs.
It's not really a good idea to use environment variables to obtain parameters like this, however. For one thing, environment variables are global to the entire JVM, but a Tomcat server can potentially contain many webapps, with possibly conflicting configuration needs.
A better source for variable information like this is JNDI. You can setup the defaults in the webapp WEB-INF/web.xml file and override them as needed using the Context configuration. That, in fact, is what I do.
The one problem with using JNDI is that it needs a JNDI server, so while that works fine for webapps, a stand-alone execution would have to be aimed at a stand-alone JNDI server. Or, if you don't happen to have one of those handy, you could always work around it. webapps have no main() method, so the standalone could obtain the required path via environment or command-line parameter in the main method and a ServletContextListener could use JNDI.