On Fri, 3 May 2002, vj struts wrote:
> Date: Fri, 3 May 2002 06:25:58 -0700 (PDT)
> From: vj struts <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Now how does one do this?
>
>
> dear all,
>
> how do you share across different web applications useful ActionForms
> you have created say for example a LogonForm?
>
> i'm using tomcat with its class loader hierarchy which i have read
> something about in http://husted.com/struts/FAQ/installation.htm.
>
> if i put them in the common "apps" tomcat directory which is where
> tomcat suggest i keep common application classes, i still get a
> classnotfound error.
>
> i am thinking this is because the common apps classloader which loads
> common apps classes cannot locate the inherited parent ActionForm class
> which is in struts.jar that is safely sitting in the web applications's
> web-inf/lib folder, away from any access by the "up" class loaders.
>
> there must be some mistake in how i am thinking about deployment, since
> i imagine you all want to be able to do this without copying the shared
> struts forms to every web application.
>
This is *exactly* what I suggest that you do. The same principle applies
with shared class libraries.
The reasoning for this is straightforward -- you want each individual
webapp to be as self contained as possible, to minimize deployment time
problems. For example, what if you need version "x" of a shared component
in one webapp, and version "y" in another webapp, at a particular point in
time. If you put that component in a shared directory, you're stuck --
you can only have one or the other. Including it in each webapp
individually gives you the flexibility to migrate each application to use
version "y" at its own pace, without impacting the others.
Now, putting the shared components into each webapp does *not* mean that
you should have duplicate copies of the source code. Instead, I would
suggest organizing your build system so that each shared comonent is
compiled (and built into a JAR or whatever) in its own directory. Then,
in the build script for each webapp (which should each be in their own
subdirectories), you would have an "assemble" command or something that
reaches out and grabs the desired versions of each external component that
is needed.
In the Tomcat 4 distribution, there is an Application Developer's Guide
document that describes some "best practices" at organizing your source
code repositories for webapp development, and includes a nice prebuilt Ant
build.xml file that illustrates these practices. If you grab the 4.1.0
alpha release, it even includes custom Ant tasks that can deploy and
undeploy webapps dynamically, without restarting Tomcat.
Even if you are using a different container, it's worth a look.
> regards!
>
> vijay
>
Craig McClanahan
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
