Objectives:
1. Get Grails to work with MS SQL Server 2005
2. Integrate Tomcat into IIS so that no additional ports have to be opened on the server
Starting the day with the MS SQL Server migration, things went pretty smooth. I set up a custom environment "mssqlProduction" in DataSource.groovy using the driver class and connection string as outlined on the MS driver's homepage. Afterwards, I copied the MS driver jar sqljdbc4.jar into the project's "lib/" dir and generated the first .war file of the day (using "grails -Dgrails.env=mssqlProduction war" because of the custom environment).
Logging into the server, I installed Tomcat 6 in Program Files (x86) and encountered the first issue: the Tomcat service did not launch. Turns out that Tomcat 6 is delivered with 32bit binaries but since my system is running a 64bit OS, the binary failed to execute. Once I had replaced the binary with the 64bit version (which can be downloaded right from Tomcat's SVN), things were running smoothly.
Next step: creating a new DB and user account in MS SQL Management Studio so that Tomcat is able to connect. This worked like a charm (once I figured out how MS SQL Management Studio works). After I had adjusted user name and password in DataSource.groovy, I attempted the first deployment into Tomcat. As the Grails project uses the domain classes "User" and "Rule" and Grails automatically maps those to the tables "user" and "rule" respectively, the DB eventually gave some errors during deployment. "user" and "rule" are both reserved keywords within MS SQL Server 2005 and thus raise issues in SQL statements. Changing the "mapping" closure for each of the classes and adding "table 'new_table_name'" statements fixed that issue.
Without any further problems, the app was up and running within Tomcat using MS SQL Server as its DB. Sweet!
Since I did not want to open up more ports on the server, the second task of the day was integrating Tomcat with IIS 6. I basically followed the instructions given on the Tomcat website. Obviously, this didn't work the first time around and I had to go back and forth verifying the different Registry settings and the changes that had to be made in other places. My key take away: rename the redirect file to exactly what's proposed in the How-To as you're bound to run into problems if not.
Eventually, the Tomcat ISAPI filter in IIS came up green and was launched successfully. The problem, however, was that it was only invoked properly for certain virtual directories defined within IIS but failed to forward any requests to Tomcat (instead, I was greeted with Service Unavailable messages in my browser for any site I tried to access). Turns out that I had to configure the App Pool containing the jakarta virtual directory to have Local System as the account to run with. Now that solved the problem of the filter not redirecting any traffic to Tomcat.
However, when trying to access one of the Tomcat-managed sites, IIS was constantly asking me for my Windows logon credentials. Obviously something was off. After a lot of unsuccessful digging, I eventually changed the security settings for the isapi_redirect.dll to grant execute permissions to the IIS user account that was configured for anonymous browsing of the jakarta virtual directory. Another issue down!
Server's up and running now though I have seen a couple of things that I want to take another look at:
- Currently, all filter files except for the dll (workers.properties, uriworkermap.properties, isapi.log) are stored in root directory as I was really struggling to get rid of the dreaded red arrow that kept appearing in IIS' ISAPI filter dialog.
- Regular HTTP-authentication requested by a Tomcat-served page does not seem to work correctly.
No comments:
Post a Comment