Paul Yu wrote:
> I'm trying to learn how to do a WAR/SSDD deployment to Tomcat.
It's tricky :-). I went through this over a year ago, and posted
my experiences on the list:
http://objectstyle.org/woproject-old/lists/woproject-dev/2005/02/0038.html
That message may give you some context. I haven't had time
to write up in any detail how I eventually solved things, but I've
been building our SSDD war deployment with wolips for over
a year. I'm no expert, but I can try to help answer questions.
Also, wolips has changed a lot during the intervening time,
so the web.xml content it generates now may not have some
of the problems indicated in that older message. YMMV.
> As you can see, no class, no lib, and no Library directories in the
> WOLips generated directory structure.
Correct. The wolips-generated dir layout is different than
what xcode will produce, IIRC, and also differs quite a bit from
what a typical WAR file would look like. It still works, but it does
mean that the classpath and some other items in the web.xml file
will look quite a bit different from a non-wolips WAR (or one
created in xcode).
I'm extremely happy with our SSDD builds and deployment,
once I figured out how to make it work. Currently, I still use the
directory layout produced by embed="true" for frameworks within the
woapplication task for wolips. However, I've switched to a custom
web.xml file instead of the one generated by wolips for other reasons.
First, I want to be able to distribute our SSDD without a license
key embedded in it, so other sites (who've purchased their own
WO licenses) can install and run their own copies of our apps.
So I had to fix things up so that the app could detect the fact
that no license was installed, and direct the user to a license entry
page (and install the license key, etc). Needless to say, that has to
be done in pure java, without any WO. If you're
interested, you can see a movie here:
http://web-cat.cs.vt.edu/WCWiki/InstallationWalkthrough
That movie also covers our self-installation wizard, where
users provide their database server connection info (yes, the
app handles creation and table setup for all of its internal
data models, together with auto-upgrading of table structures
when new versions of our frameworks are released).
Second, I wanted to be able to support automatic updates for
my app, which runs on a number of servers maintained by
other organizations. The frameworks in our app are hooked
together sort of like plug-ins, and each one is separately version-
controlled. Our app can auto-update its frameworks from an
update site on the web (sort of like eclipse's update support), and
also allows new features to be added by downloading and installing
new frameworks.
To support all this, I ended up having to go with a custom
subclass of WOServletAdaptor, and some pure java bootstrapping
code for downloading and installing frameworks (packaged up
as single jar files). I threw in some code inspired by project
wonder to build the classpath dynamically (which is how I can
support adding new features that aren't part of the base install).
By the time you get that far, none of the auto-generated content
in the web.xml file produced by the woapplication task is
worth very much :-).
Yes, this was an e-x-t-r-e-m-e-l-y long journey, but the
results are definitely worth it! And ideas from various contributors
on this list have certainly helped immensely.
-- 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 Oct 04 2006 - 12:29:41 EDT