Skip to content

absolute vs. relative paths for properties files #6

flydrivefloatrun opened this Issue Feb 15, 2012 · 5 comments

2 participants


This may be more of a clarification than an issue. I've been doing development with restSQL on my local machine (terrific project, by the way), and followed the very clear instructions on linking to property files with absolute addresses, and was working with SQL in no time. But now I am preparing to deploy the war file on an internal server where other project code and the real mySQL database lives. Our admin wants me to tuck all the files into the restSQL.war file. So, that would be the overall, .xsd files, etc. How would I do that, and are there any undesirable side-effects?

restsql commented Feb 16, 2012

Thanks for the feedback and I'm thrilled to hear you are finding it useful!

Well first I would recommend against denaturing the restsql war for maintainability reasons (admin overhead for upgrades, especially if you are co-mingling the deployment descriptor). Second, I don't think it'll work unless you use an exploded war deployment. Restsql loads the properties, sql resource files and trigger classes using standard facilities, which aren't capable of opening up a war file. An exploded war has all the files available on disk in its natural hierarchy. For example in WebLogic you unpack all the files in {domain}/applications/restsql. Note that all the paths are absolute except for the logging.config. The log4j or java logging config file must be in the classpath.

Good luck!


I'm not sure I get the maintenance issue, we'd have to crack open the new restSQL war file to update the deployment web.xml file anyway. But, otherwise I totally agree with you. I don't understand the big deal about an extra directory structure either, and I don't think it'll halt use of restSQL at this point. But you might keep it in mind for the future, for admins with a bit of tidy-freak in them. It would also make it easier for developers to deploy from an IDE -- I often have privileges to deploy/redeploy a .war file, but not to write files into individual directories. Welcome to red-tape land!


restsql commented Feb 18, 2012

The maintenance issue -- when the next upgrade comes, instead of just redeploying the packed war, you have to expand it, and then layer in your elements. It's a little extra work that could be error prone. But sounds like you're arms are tied on the deployment options.

Let's turn your request into a documented feature request. You want to embed the restsql properties file, sql resources, triggers definition and classes in a packed war, possibly the restsql war. Correct?


Yes, that's it in a nutshell. Thanks!

restsql commented Feb 20, 2012

See Issue #8

@restsql restsql closed this Feb 20, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.