views:

208

answers:

1

Hi All,

I posted this very same item on SERVERFAULT, but got no reply. So here goes:

I'm currently in the process of finishing up a Rails application. I am using Warbler to package it up as a ".war" file and am using GlassFish to deploy it. I do this because the application is to be distributed to companies for in-house use. Arguably i could/should have used another framework to develop an application of this nature, however, I chose ease/speed of development over deployment hassle.

That said, I've got the setup working reasonably well on my development machine. However, I'm curious as to how to go about automating environment initialization. In other words, I need to figure out how to ensure that all DBs, files,etc. are configured upon deployment. All of the examples I've seen thus far assume you're running your IDE on the system to which you wish to deploy and they have you run your rake tasks manually before deployment. However I need to simply give the end user the ".war" and be able to run all rake tasks upon application deployment/launch.

Can someone point me in the right direction regarding this? FWIW there is nothing in the Glassfish manual about environment initialization etc. -- then again, I don't suppose I should expect them to cover every single aspect of deployment.

Best.

A: 

Depending on your database requirements you can embed Derby within the Glassfish environment. You can easily create a blank/default database and then put that clean version in each Glassfish environment you have to set up.

I'm not sure what else you need to configure and initialize, but I'd say that if you can, script it up, either with some rake tasks. Embedding Derby takes care of database startup and initialization. Remember that a war file is just a zip file, so adding config files via a script shouldn't be so hard. You can use rails initializers (/config/initializers/) to load up yml files for configuration or whatever you need to do as the app starts up.

You won't be able to have the intializers create the schema in the database, but you could have them check for default seed data and put it in if it isn't there.

You should be able to access any part of the file system that Glassfish and the JVM can access. I don't know much about Glassfish but the only problems I've had with jruby rails apps on Tomcat were related to relative paths being relative to where the startup script was called from, and not always relative to the installation root. This could probably be solved with the right startup scripts in Tomcat or setting the appropriate start-in folder, I just haven't had a need to dive in to that very much.

danivovich
Basically I need to set up some directories and the database and that's it. I'd rather not deal with another installation (as this will be distributed and I'll be responsible for supporting yet another item), so I'd like to avoid Derby. Is it possible to have the initializers be responsible for setting up the DB without the app complaining on startup? Out of curiosity, is directory writing and file creation inhibited in any way due to using Glassfish?…
humble_coder
…I ask because I have a licensing scheme in which I need to copy a file to the same directory as the application. If possible I'd like to use the Glassfish interface to copy the file, however if I can't then I'll add a web page to the application for doing so. Either way, I need to know Glassfish won't be in my way. Does that make any sense?
humble_coder
I augmented my answer a bit based on your comments
danivovich
So you're saying that there is no straightforward mechanism by which to initialize (and progressively update with each release) the database via migrations, etc? Does this mean that we will need to have explicitly created SQL scripts for each release?
humble_coder
you can update the database with your migrations, but you probably won't be able to do that as part of the application initialization from a war file. It is perfectly reasonable to send update SQL to run on a database as part of a new release.
danivovich
I definitely agree that it's reasonable, I was just hoping for as much automation as possible. Thanks your your input, fyi.
humble_coder