Ted J Schrader

Hi Jeanne,

Hmm. This could be a possibility, but it will be a while until I can check this. The reason there are no servlet mappings in the web.xml is because there aren't any servlets. Bear in mind this is legacy code that I've newly inherited. The application is written in classic ASP style.

I've got my work cut out for me. If I learn anything about the WSAD error in my trials I'll be sure to post.

Thanks,

Ted

Whoops, sorry for the omission. It's in the Web project.

Also, I have a warning in the EAR project on application.xml:

IWAE0030W The context root for web module: MyBookWeb.war in Enterprise Application project: MyBookWeb_EAR does not match the context root in web project settings of MyBookWeb.

line 3.

[edited because I forgot I already posted application.xml - Ted]
[ February 16, 2005: Message edited by: Ted J Schrader ]

Hello,

I'm getting an annoying error message in my task list in Websphere Studio:

CHKJ3017E: Web Project: MyBookWeb is mapped to an invalid Context root: MyBook in EAR Project: MyBookWeb_EAR.

MyBookWeb and MyBookWeb_EAR are separate projects: MyBookWeb is listed as a web module in MyBookWeb_EAR and runs fine inside the Websphere test environment.

Pertinent files:

web.xml

<?xml version="1.0" encoding="UTF-8"?> < !DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app id="WebApp"> <display-name>MyBook</display-name> <welcome-file-list> <welcome-file>index.html</welcome-file> <welcome-file>index.htm</welcome-file> <welcome-file>index.jsp</welcome-file> <welcome-file>default.html</welcome-file> <welcome-file>default.htm</welcome-file> <welcome-file>default.jsp</welcome-file> </welcome-file-list> <taglib> <taglib-uri>http://jakarta.apache.org/taglibs/datetime-1.0</taglib-uri> <taglib-location>/WEB-INF/lib/taglibs-datetime.jar</taglib-location> </taglib> <taglib> <taglib-uri>http://jakarta.apache.org/taglibs/string-1.0.1</taglib-uri> <taglib-location>/WEB-INF/lib/taglibs-string.jar</taglib-location> </taglib> <taglib> <taglib-uri>http://jakarta.apache.org/taglibs/utility</taglib-uri> <taglib-location>/WEB-INF/lib/utility.jar</taglib-location> </taglib> <taglib> <taglib-uri>http://jakarta.apache.org/taglibs/mailer-1.1</taglib-uri> <taglib-location>/WEB-INF/lib/taglibs-mailer.jar</taglib-location> </taglib> <resource-ref id="ResourceRef_1108494730469"> <res-ref-name>jdbc/mybook_data</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Application</res-auth> <res-sharing-scope>Unshareable</res-sharing-scope> </resource-ref> </web-app>

application.xml

<?xml version="1.0" encoding="UTF-8"?> < !DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN" "http://java.sun.com/dtd/application_1_3.dtd"> <application id="Application_ID"> <display-name>MyBookWeb_EAR</display-name> <module id="WebModule_1097242777911"> <web> <web-uri>MyBookWeb.war</web-uri> <context-root>MyBook</context-root> </web> </module> </application>

Any ideas?

Thanks.

[edited because Code UBB wasn't rewriting my tags. Ted]
[ February 15, 2005: Message edited by: Ted J Schrader ]

Hi Jeanne,

I'm hoping you would go into a bit more detail in regards to this solution being very DB/platform specific. I fail to see how I could get tied down, at least from a web-app perspective.

Here's a snippet from some sandbox code that is working for me:

// server is "myserver", libary is "tstlib". final String CONN_URL = "jdbc:as400://myserver/tstlib"; // Class.forName() good enough for the sandbox. Class.forName("com.ibm.as400.access.AS400JDBCDriver"); Connection conn = null; PreparedStatement stmt = null; ResultSet rs = null; try { // Default library set on URL as library conn = DriverManager.getConnection(connURL, "usr", "pwd"); // do stuff with stmt and rs. close them in finally, ....

I think going this route, instead of having to concatenate generated table names in my SQL, is a move towards better design. I could simply change the connection URL in a Struts or other conn-pooling-framework config file if I change libraries or even DB vendors. It would be easier to externalise most of my SQL statements to a file, if I should want to do that, because they would be final Strings, for the most part.

Help me understand your point of view. Thanks.

Okay, I haven't tried this yet (I'm writing it here for future reference for myself as well) but it looks like the library can be set in the JDBC URL.

Check out the following:

IBM Toolbox for Java: JDBC FAQ

IBM Virtual Innovation Center for Hardware

This problem also occurs when certain ports are closed and need to be opened.

I would like to mention that we can display both global errors and field-specific errors in the same page in a mutually-exclusive fashion (well, it's working with Struts 1.1b2, anyway).
Sometimes, it would be nice if we could display global errors at the top, and field-specific errors near the fields. Anyone who has tried using <html:errors /> at the top knows that all errors will be displayed, not just the global one like we want.
To lock out the field-specific errors, do this:
<html:errors property="<%= org.apache.struts.action.ActionErrors.GLOBAL_ERROR %>"/>
Then, continue with each field:
<html:errors property="title"/>
This idiom does make the assumption that the Action classes are using ActionErrors.GLOBAL_ERROR.

The following is just a quick discussion of the code's "aesthetics", so feel free to skip this part.
At first glance, the code for displaying the GLOBAL_ERROR might not look like it's the "Struts Way" (at least, it didn't to me), since the whole point of custom tags is to eliminate scriptlets. A week ago, I would have thought that it wouldn't even compile, being a JSP expression inside a custom tag. But it does, and that's always a good thing! Also, I don't consider the expression syntax <%= %> a scriptlet, which, from my impression of the Struts UserGuide, is in accord with the Struts folks.
Also, in the UserGuide is the use of "(RT EXPR)", which I think means "Run Time Expression" which means JSP expressions can be used. Don't quote me on this, though.
I hope this helps.
Ted Schrader
SCJ2P
[ December 12, 2002: Message edited by: Ted Schrader ]

Hello,
Here are the steps I took to recreate the WAS admin database when I suspected that it had become corrupted. In particular, I was running WAS 3.5 Fixpack 4, DB2 6.1. Via DB2 Control Center, I removed the WAS database. I probably should have dropped it instead.
create the WAS DB by running the script C:\WebSphere\AppServer\bin\createdb2.bat
I have heard that this script sometimes doesn't exist.
troubles after running the script:
can't create WAS because already listed in local or system directory.

Open DB2 Command Center and do the following:
Check system directory:
>> LIST DB DIRECTORY
Check local directory:
>> LIST DB DIRECTORY ON c:
If WAS listed in local but not system, do this:
>> CATALOG DB WAS
>> DROP DB WAS
Then, check system and local directories again. WAS shouldn't be listed. Try running the script again.
If WAS listed in system, do this:
>> DROP DB WAS
I hope this helps others that are struggling to remove the WAS database alias from the local database directory when it is not in the system database directory.
Regards,
Ted
SCJ2P

Hello,
In regards to my first reply to myself regarding copying all DTD documents to C:\WebSphere\AppServer\classes\:
It is a good idea to do this! Somehow, our local WAS server can't see the Internet this morning, and initialisation breaks, since it can't find the necessary DTDs. Following "Configuring WAS 3.5, Step 1" seems to make the DTDs permanently available as a local reference.
Regards,
Ted
SCJ2P

Hello again,
I'm sure anyone interested in this post would appreciate knowing that the struts-example application will most likely not run on WAS 3.5.4 (and on up to WAS 4.0).
The problem is when we click the Register or Login links, the following exception occurs:
java.lang.IllegalArgumentException: cant remove Attributes from request scope
at java.lang.RuntimeException.<init>(RuntimeException.java:49)
at java.lang.IllegalArgumentException.<init>(IllegalArgumentException.java:45)
at org.apache.jasper.runtime.PageContextImpl.removeAttribute(PageContextImpl.java:236)
at org.apache.struts.taglib.html.FormTag.doEndTag(FormTag.java:632)
at _registration_jsp_0._jspService(_registration_jsp_0.java:935)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:127)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.jasper.runtime.JspServlet$JspServletWrapper.service(JspServlet.java:396)
at org.apache.jasper.runtime.JspServlet.serviceJspFile(JspServlet.java:718)
at org.apache.jasper.runtime.JspServlet.service(JspServlet.java:872)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.ibm.servlet.engine.webapp.StrictServletInstance.doService(ServletManager.java:626)
at com.ibm.servlet.engine.webapp.StrictLifecycleServlet._service(StrictLifecycleServlet.java:160)
<truncated>
At first glance, it looks like the FormTag.doEndTag() is at fault. But, further research indicates that, in reality, PageContextImpl.removeAttribute() does not comform to specifications.
In short, the problem lies in the fact that WAS relies on a version of Jasper associated with TomCat 3.1. To work properly, a version of Jasper associated with TomCat 3.2.2 is needed. However, I have seen that people running WAS 4.0 are having the same trouble, and someone mentioned that WAS 4.0.1 has fixed the problem, but he didn't give any resources.
Basically, an upgrade of WAS is needed (still unsure about version), or patch Struts yourself and re-build it.

Ted
SCJ2P
References:
http://issues.apache.org/bugzilla/
Bugs 2123, 2259, 932.
http://groups.google.com/groups?hl=en&q=cant%20remove%20Attributes%20from%20request%20scope&group=ibm.software.websphere.*
[ October 03, 2002: Message edited by: Ted Schrader ]

Hello,
One other thing I have noticed is that I didn't have to carry out "Configuring WAS 3.5, Step 1" in the above-mentioned install notes, either.
The step in which I refer states to extract all XML DTD files from struts.jar (using folder names)and place them into the C:\WebSphere\AppServer\classes\ directory so WAS can find them with its class loader. Basically, this will create /org/apache/struts/resources/*.dtd in the /classes/ directory.
Again, I didn't do this and the struts-example seems to work fine.
Regards,
Ted Schrader
SCJ2P

Hello,
In working through installing Struts on WebSphere 3.5.4 (well, 3.5 Fixpack 4) Standard version, I used the install advice for WAS 3.5.3 Advanced found on:
http://www.distribucon.com/struts/WASInstall.htm
However, I have found that following these steps will result in a ClassNotFoundException when WAS tries to load the org.apache.struts.action.ActionServlet. This exception is very misleading (and frustrating), because, in reality, the underlying Logging and XML parsers aren't behaving properly. On the surface, it appears that WAS is completely ignoring the CLASSPATH declarations of the struts-example webapp.
I did two things differently from the steps referenced above. One is a new step, and one replaces an existing step.
The first problem is a conflicting commons-logging.jar included with struts-1.1-b1. I grabbed commons-logging 1.0.2 and replaced the existing commons-logging.jar file in the servlets directory of the struts-example webapp. The 1.0.2 version of commons-logging can be found on:
http://jakarta.apache.org/builds/jakarta-commons/release/commons-logging/v1.0.2/
After starting the host again via WAS AdminConsole, I got an XML parsing related exception:
In the std_err file:
javax.xml.parsers.ParserConfigurationException: Namespace not supported by SAXParser
In the std_out file:
javax.servlet.UnavailableException: Parsing error processing resource path /WEB-INF/struts-config.xml
Now to replace a step:
In step 6, they say to "Copy jaxp 1.0.1's jaxp.jar and parser.jar to the servlets directory of the struts-example webapp." Instead, I grabbed Apache Crimson 1.1.3. It can be found on:
http://xml.apache.org/dist/crimson/
I then placed the crimson.jar in the servlets directory of the struts-example webapp.
After starting the host again via WAS AdminConsole, the struts-example appears in my browser on:
http://localhost/struts-example/
I hope people will find this helpful since the lowest FixPack available from IBM for WAS 3.5 is FixPack 4. In all honesty, I wrote this for myself, too, in case I need to go through this process again and can't find my notes.
Regards,
Ted Schrader
SCJ2P

Hi Sri,
This won't completely solve your problem, but I had a different issue in VAJ3.5.3 vs. WAS 3.5. The problem was that VisualAge would support URL rewritting, such as
forward("/servlet/MyServlet?param1=value") .
In WAS 3.5, the servlet engine would try to find a class called MyServlet?param1=value.class. Applying FixPack 4 solved the issue.

Hello,
I have stumbled on a very frustrating error that may be of interest to others. Note that this error only occurs every once in a while.
First, the error:
COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver][DB2/NT] SQL0501N The cursor specified in a FETCH or CLOSE statement is not open. SQLSTATE=24501
Now, the old code:
public static NotificationBean getNotification(String saCode, Timestamp notificationDate, Connection conn) throws java.sql.SQLException { System.out.println("NotificationBean.getNotification: starting. conn is: "+ conn); // guard clause if(saCode == null) throw new IllegalArgumentException("NotificationBean.getNotification: SA Code cannot be null."); if(notificationDate == null) throw new IllegalArgumentException("NotificationBean.getNotification: Notification Date cannot be null."); final String GET_NOTIFICATION = "SELECT SA_CD, TRN_CD, NTFTN_DT, NTFTN_TXT, LST_UPDT_ID, LST_UPDT_TS " + "FROM NTFTN_TBL " + "WHERE SA_CD = ? AND NTFTN_DT = ?"; NotificationBean notice = null; ResultSet rs = null; PreparedStatement stmt = null; try { //set up the statement stmt = conn.prepareStatement(GET_NOTIFICATION); stmt.setString(1, saCode); stmt.setTimestamp(2, notificationDate); //execute the statement rs = stmt.executeQuery(); // navigate the result set // rs.next() makes it crash if(rs.next()) { // create and set the notification bean information notice = new NotificationBean(); notice.setSaCode(rs.getString("sa_cd")); notice.setTranCode(rs.getInt("trn_cd")); notice.setNotificationDate(rs.getTimestamp("ntftn_dt")); notice.setNotificationText(rs.getString("ntftn_txt")); notice.setLastUpdateId(rs.getString("lst_updt_id")); notice.lastUpdateTimestamp = rs.getTimestamp("lst_updt_ts"); }// end if } finally { try { stmt.close(); } catch(Exception e) { System.out.println("Exception closing statement in finally: " + e); }// end catch }// end try-finally System.out.println("NotificationBean.getNotification: ending."); return notice; }
As noted in the code, it bombs at rs.next(). On the database, the NTFTN_DT column is defined on DB2 as DATE.
Now, if I change
stmt.setTimestamp(2, notificationDate);
to
stmt.setDate(2, new java.sql.Date(notificationDate.getTime()));
it will start to work.
I've been told that even this isn't the best way to do this; just hard-code CURRENT DATE in the SQL to ensure that we are getting database date instead of server date.
Hope this helps.
Ted Schrader, SCJ2P

I've managed to sort out the problem, but I don't really understand why it worked.
First, here is some detailed information that I should have included in my first post but, for some reason, didn't. I'm using Poseidon Community Edition 1.2 running on top of JRE 1.3.1.
Also note that a known bug for this version is "the usage of non-ASCII7-characters in imported sources causes problems." The listing of known bugs can be found by clicking Help -> About Poseidon for UML: Known Bugs tab.
The .java files that I am attempting to import are generated by IBM VisualAge for Java 3.5.
And now, on with the show.
First of all, I was able to narrow down the error to one .java file. So, I imported (reverse engineer) the other three .java files one by one.
I then imported the other packages from my project into Poseidon. During this process, I turned off the option to recursively import sub-packages. I did this so it would be easier for me to track down another error should it occur. Fortunately, everything went smoothly. I have twenty distinct packages in total but it didn't take more than 15 minutes to import them.
It turns out that this one .java file was keeping me from recursively importing the entire project. Anyway, after saving the Poseidon project, I tried importing the single offensive .java file and it worked!
I don't understand why the import works now and didn't earlier. For other imports (notably servlets classes), Poseidon warns that it doesn't know about HttpServlet, HttpServletRequest, or HttpServletResponse but this doesn't keep it from successfully importing the files.
Mystery aside, if others are having problems, try this approach.
Regards,
Ted Schrader, SCJ2P