Installation

Package Hierarchy

I'm placing all my work,  thus the examples custom and logon packages are beneath my classes directory. Is this the correct procedure?

[Ted Husted] Some people like to keep the source Java files at a separate location, and then have Ant copy them over to the classes directory, but mixing the class and java files in the same folder works too.

Personally, when using a package hierarchy for my classes, I tend to just name things 

.\logon\Form.java

But, yes, you should either put your packages class files below the classes directory, or in a JAR in the lib folder. For development at least, you probably just want to put them under classes.

We put these under the WEB-INF folder so that they cannot be directly accessed by a client program (e.g. Web browser), only by the application.

Development Status

What are, and where can we obtain all of the recently contributed pieces which are under consideration, being worked on or tested. What is next item that has been decided but has not been included in any nightly build.What specific areas are we currently looking at to solve.

[Ted Husted] We try to keep a list of the pieces people contribute in the Resources area. Sadly, this is not automated, and so there can be a lag. The list on Husted dot Com is usually the most current. I'd like to build a real tracking system sometime.  

Jakarta works on a lazy-consensus basis. Any one of the Committers can decide to include a new piece in the nightly build. There doesn't need to be any joint approval before hand. So, as soon as some decided to do something, they can just do it.

There aren't any private communications between the Struts Committers; everything goes through the public Dev list. The TODO list on the site is the one and only know reference.

If someone were interested in keeping more of the Struts submissions in the spotlight, one way to go would be to add these as Enhancement to Bugzilla (under "Severity"), and then people could also vote for their favorite enhancement. If the Comitters were to vote on an enhancement, we could also log that there. 

Making contributions

Is there a specific way to submit requests for improvements to Struts?

[Ted Husted] Since this is an open-source volunteer project, the best way to have an improvement made is to submit a patch. Simple patches can be posted to Bugzilla and/or the Struts-Dev list.

For an actual feature, you can open a thread on Struts-Dev about what you want to do. Based on what happens with that, you can submit a [PROPOSAL] message there detailing your plans, to see if anyone wants to help. Ultimately, post the source code to DEV or on a Web site someplace where others can try it out. A committer can then decide to add it to the codebase. 

If none of the committers rush in, you can also call for a [VOTE] on your submission, to bring attention to it. If one or more of the committers vote +1, they would then take responsibility for adding the code.

Struts vs No Struts

[Iraklis Kourtidis] I wanted to start a small discussion on something very general: what Struts gets you over embedding scriptlets in your JSPs (i.e., Struts vs. no Struts).

Given my (limited) experience in developing a small application, what I personally see as the biggest advantage is the following:

• Action classes can run the code that would normally get executed as a  scriptlet in a JSP (or as glorified function calls through tags).
• The Action classes place a bunch of beans on the request/session.
• The JSP then runs and displays the information stored in these beans, possibly using logic:iterate.

One disadvantage that I see is that all the communication from the action classes to the JSPs happens through beans placed on the request/session. A JSP-only solution would display the information directly without making beans out of it (and without the necessary java bean classes to represent information that gets sent to a JSP in the form of a bean.)

At any rate, I like the fact that Struts makes it possible to completely remove any code from the JSP files, which makes it easier for the design staff to modify layout etc. etc. I know, you don't need Struts to do this, but in reality if you look at most JSPs out there, you'll find a ton of scriptlet code in the JSP (I've been heard of threads being started inside a JSP...) So Struts makes it easier for me to separate the presentation from the code behind it.

I am curious about how (and why) the rest of you gain from Struts.

[Ted Husted] I think the best discussion of "Why we need Struts" is summed up in Jason Hunter's. article regarding the difficulties with JSP Model 1 applications. 

< http://www.servlets.com/soapbox/problems-jsp.html >

What all this boils down to is that Struts gives you a place to stand. 

Without a controller, a Web application is a breathless stream of views. With a controller, a Web application is a series of requests and responses, as HTTP intended. The views request and an action responds with another view. Ideally, your views become scriplet-free "JavaBean Pages", that could be easily edited with a visual Java 2 Web editor (at least as soon as we get one!). 

A MVC application like Struts does force you to be more organized, and does compels you to define objects that in a model 1 application may only be implied. But the objects are still there and so is the work. It's just whether you want to spend your time defining JavaBeans or cutting and pasting code snippets between JSPs. 

Struts Offline

Is there a downloadable version of the javadoc for Struts (found online at http://jakarta.apache.org/struts/api/index.html)? I normally like to keep these things on the local disk for offline work.

[Ted Husted] Absolutely everything is in the source distribution. In fact, we update the Web site by unjarring struts-documentation application.

Does struts need to be on the classpath for a builld?

1. If you use Ant in your development environment, you don't need Struts on your classpath for compilations -- you just declare the need for it in the task. Same with the servlet API classes, and any other libraries that you compile against. 
   
   http://jakarta.apache.org/ant
   
   If you grab the Struts source distribution, you will see the "build.xml" script that is used to create the Struts distribution itself -- once you get started with Ant, you'll never go back!

There has been some confusion around the issue of placing "struts.jar" on your CLASSPATH at execution time, in a servlet container like Tomcat that makes all such libraries visible to web applications. This message is an attempt to clarify the issues, and document why this is prohibited.

• The "struts.jar" must appear on your classpath at compile time for your web application. The easiest way to make this happen is to use an Ant "build.xml" file (like Struts itself does) that sets the classpath dynamically, or create a custom shell script that sets the classpath temporarily for compiling Struts based classes.
• The "servlet.jar" file (from your servlet container) must be on your classpath at compile time as well, because your application's Action classes will refer to interfaces that are defined here.
• For reasons discussed further below, "struts.jar" MUST NOT be on your system CLASSPATH when you start your servlet container (in particular, this applies to Tomcat).
• Placing JAR files in $JAVA_HOME/jre/lib/ext (the system extensions directory for Java2) is the same as placing them
  on the classpath. In other words, you will NOT want to put "struts.jar" or "servlet.jar" there.
• For Tomcat, placing JAR files in the "lib" directory (as opposed to the WEB-INF/lib directory of your web app) causes them to be added to the CLASSPATH automatically. Therefore, you should not put struts.jar here either.

The reason that putting "struts.jar" on your classpath is a bad idea has to do with the way classloaders work in most servlet containers. The details differ between them -- but here is the scoop for Tomcat (3.x and 4.x):

• The library files that are placed on the CLASSPATH when Tomcat starts up are made visible through the "system"
  class loader.
• Each individual web application has a custom class loader created for it, which makes the classes in WEB-INF/classes
  and WEB-INF/lib visible. The "parent" class loader of this custom class loader is set to the system class loader mentioned
  above.
• When classes are loaded, the JVM starts at the bottom of the hierarchy of class loaders, with the webapp class loader, and
  works its way up the hierarchy until it finds that class. Thus, if you have struts.jar in the system classpath, classes from struts.jar will be loaded by the system class loader instead of the web app class loader.
• When a loaded class references other classes, it looks in its own class loader first, and then up the hierarchy. Under NO circumstances will it go down the hierarchy.
• Therefore, if a Struts class is loaded from the system class path, that class CANNOT see any of your application classes in WEB-INF/classes or WEB-INF/lib -- you will get ClassNotFoundException instead.

This is the reason that the Struts example application will not run when you have "struts.jar" on your CLASSPATH. The digester module of Struts is loaded from the system class path. Therefore, it cannot see the "User" class of the example app, because that class is under WEB-INF/classes.

If you find that you need to put "struts.jar" on your system classpath to make Struts work in Tomcat, that means your Tomcat install has been corrupted. If you find that your own app will not work UNLESS struts.jar is in the system classpath, there is something about your application organization that needs to be analyzed in detail.


---

Errors building Struts

I'm getting either a  

java.lang.ClassNotFoundException: org.apache.tools.ant.taskdefs.optional.TraXLiaison

or a 

java.lang.SecurityException: sealing violation

when trying to build struts.

I would recommend ALWAYS building 'ant' before  trying to build 'struts' for the first time. Why? It seems that ant customizes itself for each environment, and determines which XML parser you are using. Once I did that Struts builds without a hitch.

These problems are usually caused by more than one jaxp.jar, parser.jar, xerces.jar, or crimson.jar being available to Ant. These can be specified in several places.

The actual CLASSPATH environment variable

The ext/lib folder under your JAVA_HOME folder

The ANT_HOME/dist/lib folder

Any statements in your build.xml document.

The WEB_INF/lib folder uner your application root.

First, check your CLASSPATH to see if it references any of these. Also check the ext/lib file for your JVM installation, since JARs in this folder are automatically append to the CLASSPATH. Likewise for the ant/dist/lib - the default Ant script (or batch file) adds these JARs too.

Once you are sure that there is only one copy of every JAR you need available to Ant when it builds, obtain a fresh version of the Ant distribution, and build it yourself. 

1) Read the Build instructions for ANT, creating the ANT_HOME, and other needed environmental variables.
2) Then run bootstrap.bat - to perform the bootstrap build of ant and  build the final version of Ant.
3) Copy the ANT_HOME/dist/lib jar files to ANT_HOME/lib .
4) Make sure you read the 'struts' build guide, and have installed all required packages.
5) Change to the struts directory.
6) Then type 'build'

If this doesn't work then make sure that your CLASSPATH references only one jaxp.jar and that parser.jar isn't in your CLASSPATH

---

Installing on WebSphere 3.5.3

[Chris Assenza] After quite a bit of effort, I have finally gotten the Struts example to work flawlessly in WebSphere 3.5.3. What's funny is that I was reading your post Richard and was thinking to myself: "Gee, I've done ALL of this EXACTLY -- in fact I'm even on the same OS, just different drive letters, WHAT could be wrong??" Then it hit me, looking through your steps  below I found the one thing that was different that had completely slipped through - jaxp 1.0.1. I was using jaxp 1.1.1!! Crimson is a separate jar now, that includes the stuff from parser.jar, but it apparently does something different then 1.0.1 and it was just screwing
everything up! I downloaded 1.0.1 and got significantly further then I ever have, but ran into another problem. WebSphere reported that the public identifiers for the DTD's were malformed URLs. Luckily, I saw on another mailing list an issue with WebSphere & Struts not liking PUBLIC DTD refs, so I changed them to SYSTEM and away it flew - flawlessly. 

For those people who run into these issues (and because I have to document it for work anyway - here is Richard's list again revised with more detail on some of the bugs I encountered. (BTW, adding web to the classpath did not help me, I had to move it to the servlets directory). 

Server: Windows 2000 Server with WebSphere 3.5.3 Advanced

1. Start up the adminserver. 
2. Start up Admin Console. 
3. Use the Convert War file task to convert the struts-example.war from the struts-b1 distrib as-is. 
4. Convert to the default_server, default servlet engine and standard install directory
   (c:\websphere\appserver\hosts\default_host). 
5. Create a WEB-INF directory in the servlets dir and copy struts-config.xml, database.xml AND web.xml into it (Keep WEB-INF with all the TLD's under web - both WEB-INF directories must be present). 
6. Copy jaxp 1.0.1's (NOT 1.1.1's) jaxp.jar and parser.jar to the servlets directory of the strut-example webapp. 
7. In the servlets directory, open struts.jar with WinZip. Extract the three DTD's (struts-config_1_0.dtd, web-app_2_2.dtd and web-app_2_3.dtd) into the servlets directory making sure you use folder names (so the files extract to servlets/org/apache/struts/resources). 
8. Click on struts-example in the Admin Console under Default Server/Default Servlet Engine and click the advanced tab on the right hand side of the screen.  
9. Down where it says Default Error Page, enter /ErrorReporter and then click Apply. 
10. Start the Default Server via the Admin Console. You should see a whole bunch of ActionServlet messages in the default_host_stdout.log file with no exceptions. 
11. Via a browser accessed the app using http://localhost/struts-example/index.jsp.  
12. If it returns "Application not Available" then go back to the Admin Console, right-click on struts-example and select Restart WebApp. 
13. Once it reports success, go back to the URL above and try again - it should work flawlessly.  

For whatever reason, some installations do not like XML files that reference PUBLIC DTD's - if in looking at the default_host_stdout.log file you see errors about invalid public URL references during DTD registrations, or if your pages say "cannot find //logon or //saveRegistration (ie. action mappings) then do the following:

1. Stop Default Server 
2. Go to servlets\WEB-INF\ and edit web.xml and struts_config.xml. 
3. In the DOCTYPE declaration, change the word PUBLIC to SYSTEM and completely
   remove the line that reads "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
   from web.xml and remove "-//Apache Software Foundation//DTD Struts Configuration
   1.0//EN" from struts-config.xml. 
4. Save these changes and go back to step 10 above. 

Just as a troubleshooting guide - 

If you are getting errors like "Cannot find ActionMappings, etc..." or "Cannot find key org.apache.struts.MESSAGE" then your application is most likely still bombing on the struts-config issue that Richard discovered. The above steps SHOULD correct that leaving nothing out. If you are getting 404 errors about //logon or something not found, then you are still having XML config troubles and it is not initializing the Action servlet properly. Follow the steps above in regards to DTD's and it should work.

As a final thought, I obviously haven't gotten to test too much but I don't believe that there are ANY coding changes that need to be made to the actual struts source. Everything about getting it to work in WebSphere has been a WebSphere configuration issue thus far (and I don't think I'll be having any more). 

Thanks for your help Richard and I hope others benefit from this as well! :)

---

Errors Running Struts Applications

Can't find Message Resources key

This is usually a XML parsing issue. Either there are too many parsers, or not enough. 

First, check to see which parsers are available to your container and application, these can be specified in several of places: 

• The CLASSPATH environment variable
• The ext/lib folder under your JAVA_HOME
• The WEB_INF/lib folder under your application's root
• Any kind of lib folder your container may use

Tomcat 4 does not expose an XML parser to web applications. Thus, you'll need to do one of the following:

* Stick an XML parser into the $CATALINA_HOME/lib directory to make it available to all web apps, or
* Stick an XML parser into the /WEB-INF/lib directory of your web app.

Note that the WARs shipped with Struts do *not* have a parsers with them.

Many field engineers have reported having the best results when exposing Xerces 1.3 or later to their container.

WebLogic problem...

-------- Original Message --------
Subject: RE: Weblogic problem...
Date: Fri, 14 Dec 2001 13:40:56 -0600
From: "Reddin, Greg" <Greg.Reddin@alltel.com>
Reply-To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
To: "'Struts Users Mailing List'" <struts-user@jakarta.apache.org>

I think BEA has acknowledged a bug in that jars residing in the
Applicaiton ClassLoader (included in the EAR) won't be loaded. They
have to be included in the EJB Jars that are placed in the EAR to be
loaded and used by both EJB's and web apps. However as someone pointed
out, the Struts classes shouldn't be needed from the EJBs so you could
just include them in WEB-INF/lib. It works that way in my environment,
but I certainly don't have them included anywhere besides the web app.

Greg

> -----Original Message-----
> From: Sobkowski, Andrej [mailto:Andrej.Sobkowski@emergis.com]
> Sent: Friday, December 14, 2001 12:46 PM
> To: 'Struts Users Mailing List'
> Subject: RE: Weblogic problem...
> 
> 
> Sean,
> 
> unfortunately, there are issues when packaging an application 
> as an EAR vs
> WAR. I agree that if you only have JSP and Servlets and WEB 
> components in
> general (ie only stuff that goes into a WAR), then you're OK with
> WEB-INF/lib.
> 
> BUT if you deploy your Struts app as part of a EAR, that may 
> not work (it
> didn't for me and I wasted a few hours trying to understand why that
> @^%@$#@% app server couldn't find my struts.jar).
> 
> Check out
> http://www.onjava.com/pub/a/onjava/2001/06/26/ejb.html
> 
> It's the type of thing that can ruin an evening... :)
> 
> Andrej
> 
> PS. I agree with your sentence "EJB should not care about Struts". The
> problem is that if the app uses a single Class Loader and 
> it's the EJB's,
> then the app must have a link to the "utility JARs".
> 
> > -----Original Message-----
> > From: Sean Owen [mailto:srowen@yahoo.com]
> > Sent: Friday, December 14, 2001 12:49 PM
> > To: Struts Users Mailing List
> > Cc: ychen@jgsi.com
> > Subject: Re: Weblogic problem...
> > 
> > 
> > Adding struts.jar to the WEB-INF/lib directory within your 
> > web application
> > is the right way to make it available to your servlets and 
> > JSPs, regardless
> > of whether you deploy in an exploded directory format, as a 
> > .war, or as an
> > .ear with a web app component.
> > 
> > It's not then visible to the EJBs, since the EJB classloader 
> > is a parent of
> > the web classloader, but that shouldn't matter - EJBs don't have any
> > business using Struts classes, right?
> > 
> > Sean
> > 
> > 
> > ----- Original Message -----
> > From: "Sobkowski, Andrej" <Andrej.Sobkowski@emergis.com>
> > To: "'Struts Users Mailing List'" <struts-user@jakarta.apache.org>
> > Sent: Friday, December 14, 2001 4:40 PM
> > Subject: RE: Weblogic problem...
> > 
> > 
> > > Small addition to my previous message (sorry, I responded 
> > without reading
> > > with too much attention):
> > > - if yours is a *.war archive only, then adding struts.jar to your
> > > WEB-INF/lib directory should work. My previous suggestions 
> > are still valid
> > > but may not solve the problem.
> > > - if yours is a *.ear, then adding JARs to the WEB-INF/lib 
> > will not work
> > in
> > > Weblogic as the main ClassLoader is the one used for the 
> > EJBs (that have
> > no
> > > visibility on your WEB-INF/lib). You should then use the 
> MANIFEST.MF
> > > "Class-Path" thing.
> > >
> > > Andrej
> > >
> > > > -----Original Message-----
> > > > From: Anna Chen [mailto:ychen@jgsi.com]
> > > > Sent: Friday, December 14, 2001 11:02 AM
> > > > To: struts-user@jakarta.apache.org
> > > > Subject: Weblogic problem...
> > > >
> > > >
> > > > Hi, all
> > > >
> > > > Could you tell me why I get this kind of error? I am using
> > > > weblogic 6.1 on
> > > > UNIX and I do have struts.jar in my WEB-INF/lib
> > > >
> > > > <[WebAppServletContext(4667798,brd-admin,/brd-admin)] 
> > action: Error
> > > > creating Action instance for path '/login', class name
> > > > 'com.brandsdirect.common.login.LoginAction'
> > > > java.lang.NoClassDefFoundError: org/apache/struts/action/Action
> > > > at java.lang.ClassLoader.defineClass0(Native Method)
> > > > at 
> > java.lang.ClassLoader.defineClass(ClassLoader.java:486)
> > > > at
> > > > java.security.SecureClassLoader.defineClass(SecureClassLoader.
> > > > java:111)
> > > > at
> > > > java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
> > > > at 
> > java.net.URLClassLoader.access$100(URLClassLoader.java:56)
> > > > at 
> java.net.URLClassLoader$1.run(URLClassLoader.java:195)
> > > > at 
> > java.security.AccessController.doPrivileged(Native Method)
> > > > at 
> > java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> > > > at 
> java.lang.ClassLoader.loadClass(ClassLoader.java:297)
> > > > at
> > > > sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
> > > > at 
> java.lang.ClassLoader.loadClass(ClassLoader.java:290)
> > > > at 
> java.lang.ClassLoader.loadClass(ClassLoader.java:290)
> > > > at 
> java.lang.ClassLoader.loadClass(ClassLoader.java:253)
> > > > at
> > > > java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
> > > > at java.lang.Class.forName0(Native Method)
> > > > at java.lang.Class.forName(Class.java:120)
> > > > at
> > > > org.apache.struts.action.ActionServlet.processActionCreate(Act
> > > > ionServlet.java:1564)
> > > > at
> > > > org.apache.struts.action.ActionServlet.process(ActionServlet.j
> > > > ava:1510)
> > > > at
> > > > 
> > org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:487)
> > > > at
> > > > javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
> > > > at
> > > > javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> > > > at
> > > > weblogic.servlet.internal.ServletStubImpl.invokeServlet(Servle
> > > > tStubImpl.java:263)
> > > > at
> > > > weblogic.servlet.internal.ServletStubImpl.invokeServlet(Servle
> > > > tStubImpl.java:200)
> > > > at
> > > > weblogic.servlet.internal.WebAppServletContext.invokeServlet(W
> > > > ebAppServletContext.java:2390)
> > > > at
> > > > weblogic.servlet.internal.ServletRequestImpl.execute(ServletRe
> > > > questImpl.java:1959)
> > > > at
> > > > weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
> > > > at 
> > weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
> > > > >
> > > >
> > > > Thanks!!
> > > >
> > > > Anna