EXcellent. How about posting this on the wiki on wodev.com? There's
already an 'Eclipse' bit on there. This would make a good addition.
Stephen Edwards wrote:
> Since I mentioned that I had slogged through this myself a while
> back, I thought I'd finally contribute a more detailed explanation of
> my experiences. This is a bit long, so feel free to skip it if you aren't
> interested.
>
> Bear in mind that I am no WO expert, and certainly not a Tomcat/
> servlet expert! This was my first experience trying to deploy a WO
> app as a servlet, and I relied heavily on the info in the "Practical
> WebObjects" book (an excellent book, IMHO).
>
> OK, so the first thing I did was to follow the comments in my wolips-
> generated build.xml file and enable the war and ssdd targets as
> indicated. I added the webXML="true" attribute to the woapplication
> Since I was shooting for an ssdd, I also create a plain text file called
> LICENSE containing a single line with my deployment license key in it,
> and placed it in the root of my project. So far so good.
>
> Also, from elsewhere on this list, I had added the (undocumented!)
> attribute embed="true" to all of the frameworks tags within the
> woapplication task of the build.woapp target. This attribute causes
> the contents of the corresponding framework(s) to be copied
> into the directory from which the war is built. Put it on *every*
> framework set within the woapplication task if you are trying for
> an ssdd that can run on a server that does not have WO installed.
>
> Building went fine, but it wouldn't start up correctly when
> deployed (I was deploying on Tomcat running alongside apache).
> One of the first things I noticed is that the directory layout within
> the generated war wasn't what was in the "Practical WebObjects"
> book or what I would expect in a traditional servlet--everything was
> all contained within the WEB-INF directory. In the end, I decided
> to stick with the dir layout generated by the default build file
> instead of trying to change to a more traditional layout, however.
>
> I took a look into the web.xml file and found these issues:
>
> 1) The WOROOT parameter was set to the correct value for
> a non-ssdd install, but obviously wouldn't work for ssdd.
> I added a web_XML_WOROOT="..." attribute to the woapplication
> task in the build.xml file to specify a value appropriate for
> my final installation location. Note that the embed="true" attribute
> for the frameworks within the woapplication task causes the frameworks
> to be copied into the WEB-INF/<appname>.woa/Contents/Frameworks
> folder. As a result, the addition I made looks like this:
> <woapplication
> ...
>
> webXML_WOROOT="${servlet.install.dir}/${project.name}/WEB-INF/${project.name}.woa/Contents/Frameworks"
>
> >
>
> Here, the ${servlet.install.dir} was a new property that
> I defined in my build.properties file.
>
> 2) The LOCALROOT parameter had the same problem. I
> fixed it by adding a webXML_LOCALROOT="..." attribute
> to the woapplication task. It pointed to the same dir that
> the webXML_WOROOT did (all local and system frameworks
> get copied to the same spot if you embed="true").
>
> 3) The WOAINSTALLROOT parameter had the same problem.
> I don't really know if that is an issue or not, since I don't know what
> it is used for. I fixed it anyway, by adding a
> webXML_WOAINSTALLROOT="..."
> attribute to the woapplication task:
> <woapplication
> ...
>
> webXML_WOAINSTALLROOT="${servlet.install.dir}/${project.name}/WEB-INF"
> >
>
> 4) The WOClasspath was hosed. Every entry began with:
> WEBINFROOTAPPROOT. For example, if the JavaWebObjects
> framework were on your classpath, it would appear like this
> in the web.xml file:
>
> WEBINFROOTAPPROOT\Frameworks\Library\Frameworks\JavaWebObjects.framework\Resources\Java\javawebobjects.jar
>
>
> I know that these prefixes on the classpath entries are substituted
> using the parameters present in the web.xml file (I think by the
> WOServletAdaptor, but I'm not positive). Whatever engine does the
> substituting, it is very myopic, and won't substitute the above
> appropriately.
> Again, I'm not positive, but I think it will only substitute WEBINFROOT
> (anyone know for sure?). I could never get "APPROOT" to substitute no
> matter what I did.
>
> In the end, I changed all the WOClasspath entries to look like this:
>
> WEBINFROOT/<appname>.woa/Contents/Frameworks/Library/Frameworks/JavaWebObjects.framework/Resources/Java/javawebobjects.jar
>
>
> This does work. Since I didn't want to have to hand-edit the
> web.xml file every time I rebuilt, I wrote a small perl script to
> do this munging for me.
>
> 5) The classpath ordering was wrong--it is the app's
> Contents/Resources/Jar
> directory first, followed by the dependent frameworks purely in
> alphabetical order. In particular, the framework ordering in
> the project's .classpath file has no effect. Is there a better way in
> WOLips to control this? Anyway, since I use woproject in this app
> and wanted the ERExtensions framework to initialize before any of
> my own frameworks, and I also wanted the frameworks containing
> eomodel prototypes to appear before frameworks using the prototypes,
> I wanted to control this ordering. I tweaked my
> perl script so that it would "bubble" the ERJars, ERExtensions, and
> *Prototypes classpath items to the front of the list..
>
> 6) The woapplication task generated the web.xml file in the
> ${dest.dir}/${project.name}/WEB-INF/${project.name}.woa/Contents
> dir, but the war task expected it to be in a slightly different
> location.
> I edited the pre-generated value for webxml="..." in the war task
> to point to the same location the woapplication task used.
>
> 7) I added a basedir="${dest.dir}/${project.name}" attribute to
> the war task so that it would not include extra levels of
> subdirectories
> in the generated war file. I also deleted the existing .woa/**
> fileset that
> was there, since the entire .woa tree was already inside the WEB-INF
> root (and the fileset didn't seem to match anything in the build
> structure
> for the ant file).
>
> 8) The LICENSE fileset in the war task also seemed to be broken,
> and pointed to the wrong dir (it points outside the project dir,
> if ant is invoked at the top level of the project). Further, it would
> place the LICENSE file in the wrong place (it needs to be in the
> WEB-INF dir). Instead, I moved this to a copy task in the ssdd target:
>
> <copy todir="${dest.dir}/${project.name}/WEB-INF/">
> <fileset dir=".">
> <include name="LICENSE"/>
> </fileset>
> </copy>
>
> 9) The default zipfileset entry in the war task for the WO tag library
> resulted in the tag library being placed in a location different
> from the one that the web.xml file points to, so I had to fix that.
> I ended up just removing the zipfileset entry and instead using
> a copy task in the ssdd directive:
>
> <copy todir="${dest.dir}/${project.name}/WEB-INF/tlds">
> <fileset
> dir="${wo.systemroot}/Library/Frameworks/JavaWOJSPServlet.framework/Resources/">
>
> <include name="WOtaglib_1_0.tld"/>
> </fileset>
> </copy>
>
> 10) There is no 10th change :-). Actually, I tested & retested the
> deploy, then customized my build.xml file so that my funky perl
> script would correct the web.xml classpath entries, and then
> split the build directive into two separate paths so that I could
> do an ssdd servlet installation or build/install a traditional
> stand-alone
> app from the same build.xml file.
>
> As near as I can reconstruct, these are the main things I had to
> change. The result is an odd-looking war file, since *everything*
> is inside the WEB-INF directory, but that seemed like the path of
> least resistance for getting the existing woproject ant tasks to produce
> a working war using the wolips-generated build.xml file. And
> like I said, since I'm no expert on this, I didn't want to try for
> major overhauls. Of course, that also means I may have done
> something the hard way that could've been done more easily.
>
> For woproject developers, the big issues were with the WOClasspath
> in the web.xml generated by the woapplication task. As near as
> I can tell, the generated classpath being produced just doesn't
> work. For wolips developers, the big issues were with the generated
> build.xml file, which provides incorrect placement of some
> items in the war file (e.g., the license file and the tag library),
> and omits some of the steps necessary for an ssdd war.
>
> Whew! That was a long message. Now you know why it took
> me so long to send it ;-).
>
> -- Steve
>
> --
> Stephen Edwards 604 McBryde Hall Dept. of Computer
> Science
> e-mail : edward..s.vt.edu U.S. mail: Virginia Tech (VPI&SU)
> office phone: (540)-231-5723 Blacksburg, VA 24061
> -------------------------------------------------------------------------------
>
>
This archive was generated by hypermail 2.0.0 : Wed Feb 09 2005 - 16:59:33 EST