On Thu, 21 Jun 2001, William Shulman wrote:
>
> thanks Craig-
>
> I may be appealing to the wrong crowd (as I expect this stuff is all
> part of the Servlet spec), but this somehow seems to be less modular
> than I would like. It seems that the spirit or .war files is to be an
> extension of the .jar file concept, generalized to entire j2ee
> applications. When I obtain a .jar file for classes I would like to
> use -- all I need to do is place that .jar file in my CLASSPATH and I
> can use the classes. The analogy does not seem to fully carry over
> into .war files. Would it not be better if I was able to package my
> entrire application and supporting resources (html, xml, tld,
> etc.. files) and have the servlet or j2ee system know how to access
> all of those resources in a generic way, similar to the approach with
> .jar files and classes? It seems that the current approach only goes
> half way -- I can introduce a .war file and have the servlet container
> interpret its structure in some ways (making a context, recognizing
> the docroot, etc), but not in other ways (allowing my jsp files to
> import or declare taglibs contained in the .war file, or recognize classes)
>
Well, you've certainly got most of the "self contained" stuff you are
after:
* Want to use a JAR file in your app? Stick it into /WEB-INF/lib
and it is automatically available to you.
* Want to access a static resource in your app? Use
ServletContext.getResource() and you don't have to care how the
servlet container deals with it.
* Want to change the context path of your app? The details of how
to do this vary by servlet container, but it's trivially easy
(especially with Struts) to make your application independent
of what the actual context path is.
* Want to us a tag library? Somehow, you've got to create a mapping
from the URI used in your pages to the corresponding TLDs. There
are a variety of ways to do this, but I've found that explicitly
referencing TLDs in the WEB-INF directory is the least confusing.
> Is there some design reason for this that I do not understand? It
> seems things could be architected such that the steps you outline
> below are not needed.
>
For the separate TLD files themselves, there's a spec-related issue that
caused this approach.
The JSP 1.1 spec defines the concept of a tag library that is encapsulated
in a single JAR file (including the TLD, which you placed at the
META-INF/tablib.tld entry. Thus, you could just drop a tab library into
your WEB-INF/lib directory, create a URI for it in web.xml, and go.
Now, originally, Struts only had one tag library, so this strategy was
quite useful -- stick the "struts.tld" file into struts.jar, and
everything was fine. However, Struts now has four tag libraries (and the
number is likely to grow in the future). But you cannot have more than
one encapsulated TLD in a single JAR file in JSP 1.1 -- and separating
struts.jar into five JAR files doesn't really help anything.
In JSP 1.2, this changes -- you'll be able to to encapsulate all of the
Struts tag libraries in struts.jar and dispense with the separate TLD
files. But, until JSP 1.2 containers are widely deployed, we're stuck
with the 1.1 restrictions.
But the bottom line is that the architecture of web applications is
defined by the servlet spec. Therefore, Struts has to live within those
rules, just like any other web application or framework based on servlets
will have to.
> -will
>
>
Craig
