struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: (newbie) using JAR files vs. explicit package classes
Date Mon, 01 Jul 2002 17:25:25 GMT


On Mon, 1 Jul 2002, Glen Mazza wrote:

> Date: Mon, 1 Jul 2002 08:29:56 -0500 (CDT)
> From: Glen Mazza <glenmazza@yahoo.com>
> Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> To: struts-user@jakarta.apache.org
> Subject: (newbie) using JAR files vs. explicit package classes
>
> Hello,
>
> I'm looking at how the example .WAR applications
> supplied by Struts 1.1 Beta release are expanded by
> Tomcat.
>
> Common/Shared packages, such as "struts.jar",
> "commons-digester.jar", etc. are kept unexpanded in
> the web-inf\lib directory.   However, classes specific
> to the application were expanded into separate
> directories:  e.g.,
> \classes\org\apache\struts\webapp\example\memory\MemoryUser.class,
> MemoryUserDatabase.class, etc.
>
> I'm trying to understand the reasons behind this
> deployment convention--What are the benefits of
> splitting out application-specific projects/classes
> into separate directories and .class files when
> deploying?  (i.e., Can't they be more cleanly stored
> together in a JAR file like struts.jar, etc. is?)
>

The web container already knows how to load classes from JAR files found
in WEB-INF/lib, so there is no benefit to unpacking them as you configure
your webapp.  I always just copy in the JAR files for the libraries that
are needed.

For your app classes, you have a choice -- copy them unpacked into
WEB-INF/classes, or JAR them up into a JAR file in WEB-INF/lib.  I don't
see much benefit to the latter for application classes (it just takes
extra time), so my general approach is to point the output of my java
compilations directly into the WEB-INF/classes subdirectory of the webapp
directory I'm building, so I don't even have to copy them -- let alone JAR
them up.  This makes the compile-debug-recompile development cycle go a
little bit faster.

> Thanks,
> Glen
>

Craig


--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message