Update: Added some details of the build settings for converting an existing WebObjects Application project to a tidy servlet deployment package.
King, Josh and I spent the morning in the WebObjects lab trying to figure out a way to get Pachyderm deployed on non-MacOSX boxes under the new regime. We’ve now got a spanky new Tomcat-enabled build, that sucks in all of the supporting WebObjects, APOLLO, and Pachyderm jars into a single .war – topping 112MB of compiled goodness.
The good news is that it works, and seems to work well (once you have identified and addressed the mines laid in your path). The bad news is that form of deployment requires a valid WebObjects deployment license – which is no longer available separately from MacOSX Server 10.4 (for WO 5.3 at least – separate deployment licenses are still available for 5.2.4, but they are refused by apps compiled on 5.3)
A very helpful Apple engineer in the lab (who will remain nameless to protect him/her from any flak for going out on a limb to help us with this) was able to obtain a WO 5.3 deployment license string for us to test our Tomcat deployment. It looks like it worked perfectly. I had to delete the license so this engineer could keep their job, so I can’t test again, or on another platform at the moment.
One strategy we may have/get to adopt is to keep a WO 5.2.4 development system around, so that it can compile the .war SSD bundle with a 5.2.4 platform-agnostic deployment license – That’s plan B, though, since I’m really (futilely?) hoping that we can convince Apple to reconsider the MacOSX-only licensing. (I’m even 100% OK with non-MacOSX Server deployments being unsupported – just don’t make the app refuse to light up because of a license string!)
I’ll post a little write-up on the steps we had to take, and the build settings that need twiddling – and how they differ from the documented bits. That’s currently locked on my Powerbook, which is now a paperweight after sucking the life-sustaining juices from 2 separate batteries. I’ll plug it in when I get back to the hotel.
Oh, and to the person that IMed me to ask me about this – your timing was absolutely perfect! We were just getting to the solution when your IM came up. I’m very sorry that I was such a rude prick to you, but I didn’t want to be distracted right then, and we were using iChat to pass config files and data around.
Update: Here’s some info about the settings you need to tweak to have a project build as a nice tidy servlet doowackie.
First, you need to add JavaWOJSPServlet.framework to your project. That seems to automagically do some stuff to start building a .war file. Yay.
But, you also need to tell WebObjects more explicitly how you want your servlet compiled. These are the settings that worked for me. No warrantee, no guarantee, YMMV, IANAL, etc… If it borks something for you, well you probably should have backed up first…
Replace the fuzzy part with your WebObjects deployment license (5.2.4 would be a good bet, if you’re still on it – otherwise, you may want to take a look in /System/Library/Frameworks/JavaWebObjects.framework/Resources/ for some random ASCII that might do the trick – just be sure to abide by the EULA, and don’t break your license agreement. I’m only mentioning this so you can test on your own machine, and replace the license with one you purchase for deployment), and replace the SERVLET_WEBAPPS_DIR with the path to the directory you want to build this sucker. I just built into a quick/fresh download of Tomcat 3.3.2, still living in my ~/Downloads directory. Not likely the final deployment directory, but you get the idea. Also, this could be any directory you like. It’s just the build location – it doesn’t talk to the Tomcat installation or anything.
In my case, this built a directory that contained 112MB of our code, as well as the Entire WebObjects System, and any other dependent .jars.
Update the second: On a lark, I thought I’d try deploying under Tomcat 5.5.9 – the latest build. Out of the .tar, it requires java 1.5, so until you install the 1.4 compatability stuff it’s no joy on MacOSX. But adding the compatability stuff is trivial. But, it still doesn’t get my app deployed – as expected, Tomcat 5.x appears to have difficulty hosting a WebObjects application servlet, since it’s supporing a newer rev. of the servlet spec (2.4, IIRC), when WO spits out servlets matching version 2.2 of the servlet spec. Not a critical thing at this point. Just gathering data points for discussions with the PHBs.
Update: Added some details of the build settings for converting an existing WebObjects Application project to a tidy servlet deployment package.
King, Josh and I spent the morning in the WebObjects lab trying to figure out a way to get Pachyderm deployed on non-MacOSX boxes under the new regime. We’ve now got a spanky new Tomcat-enabled build, that sucks in all of the supporting WebObjects, APOLLO, and Pachyderm jars into a single .war – topping 112MB of compiled goodness.
The good news is that it works, and seems to work well (once you have identified and addressed the mines laid in your path). The bad news is that form of deployment requires a valid WebObjects deployment license – which is no longer available separately from MacOSX Server 10.4 (for WO 5.3 at least – separate deployment licenses are still available for 5.2.4, but they are refused by apps compiled on 5.3)
A very helpful Apple engineer in the lab (who will remain nameless to protect him/her from any flak for going out on a limb to help us with this) was able to obtain a WO 5.3 deployment license string for us to test our Tomcat deployment. It looks like it worked perfectly. I had to delete the license so this engineer could keep their job, so I can’t test again, or on another platform at the moment.
One strategy we may have/get to adopt is to keep a WO 5.2.4 development system around, so that it can compile the .war SSD bundle with a 5.2.4 platform-agnostic deployment license – That’s plan B, though, since I’m really (futilely?) hoping that we can convince Apple to reconsider the MacOSX-only licensing. (I’m even 100% OK with non-MacOSX Server deployments being unsupported – just don’t make the app refuse to light up because of a license string!)
I’ll post a little write-up on the steps we had to take, and the build settings that need twiddling – and how they differ from the documented bits. That’s currently locked on my Powerbook, which is now a paperweight after sucking the life-sustaining juices from 2 separate batteries. I’ll plug it in when I get back to the hotel.
Oh, and to the person that IMed me to ask me about this – your timing was absolutely perfect! We were just getting to the solution when your IM came up. I’m very sorry that I was such a rude prick to you, but I didn’t want to be distracted right then, and we were using iChat to pass config files and data around.
Update: Here’s some info about the settings you need to tweak to have a project build as a nice tidy servlet doowackie.
First, you need to add JavaWOJSPServlet.framework to your project. That seems to automagically do some stuff to start building a .war file. Yay.
But, you also need to tell WebObjects more explicitly how you want your servlet compiled. These are the settings that worked for me. No warrantee, no guarantee, YMMV, IANAL, etc… If it borks something for you, well you probably should have backed up first…
Replace the fuzzy part with your WebObjects deployment license (5.2.4 would be a good bet, if you’re still on it – otherwise, you may want to take a look in /System/Library/Frameworks/JavaWebObjects.framework/Resources/ for some random ASCII that might do the trick – just be sure to abide by the EULA, and don’t break your license agreement. I’m only mentioning this so you can test on your own machine, and replace the license with one you purchase for deployment), and replace the SERVLET_WEBAPPS_DIR with the path to the directory you want to build this sucker. I just built into a quick/fresh download of Tomcat 3.3.2, still living in my ~/Downloads directory. Not likely the final deployment directory, but you get the idea. Also, this could be any directory you like. It’s just the build location – it doesn’t talk to the Tomcat installation or anything.
In my case, this built a directory that contained 112MB of our code, as well as the Entire WebObjects System, and any other dependent .jars.
Update the second: On a lark, I thought I’d try deploying under Tomcat 5.5.9 – the latest build. Out of the .tar, it requires java 1.5, so until you install the 1.4 compatability stuff it’s no joy on MacOSX. But adding the compatability stuff is trivial. But, it still doesn’t get my app deployed – as expected, Tomcat 5.x appears to have difficulty hosting a WebObjects application servlet, since it’s supporing a newer rev. of the servlet spec (2.4, IIRC), when WO spits out servlets matching version 2.2 of the servlet spec. Not a critical thing at this point. Just gathering data points for discussions with the PHBs.
