Nope. I don't see a single error. Of course, I don't see a single file, either. :-)
Mark -----Original Message----- From: Steven Banks [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 03, 2002 8:27 AM To: [EMAIL PROTECTED] Subject: RE: Installation on OS-390 and Websphere 3.5.3: - Error Application unavailable for service I have found mention is several articles that this can be caused by errors in the train.webapp and web.xml. Could anyone look at the attached and see if there are any errors? I have gone into the struts code and comented out everything in the init() routine of the ActionServlet, entered a System.out.println() statement in it, and the application will still not start. >>> "Steven Banks" <[EMAIL PROTECTED]> 03/27/02 10:54AM >>> Roger. Thanks for the response. Before trying the upgrade, I am going to try getting it to work on 3.5.3 "just call me stubborn". There is a set of notes from someone who has it working on this user group. The latest I have tried was changing a WAS start-up parameter "appserver.compliance.mode=true". The result was the the servlet does not load at all. It could not find the config file. I have since discovered that one result of the parameter change is that the location of the struts-config.xml file has to be moved as the following code from the Action Servlets initMapping routine no longer worked. When appserver.compliance.mode=false "the default value" InputStream input = getServletContext().getResourceAsStream(config); found the xml file in the following directory: u/mywebs/dev/train/WEB-INF/classes/WEB-INF/struts-config.xml When appserver.compliance.mode=true, the xml file had to be moved to /u/mywebs/dev/train/web/WEB-INF/struts-config.xml It would be nice if the main struts code would return getServletContext().getRealPath(config)); when it cannot find the config file, this would solve a lot of problems like this very quickly. Once I moved the file to this new location, the servlet starts OK, but returns the http 503 error again as soon as I try to access any file in the web application. I am going to put a call in to IBM tech support to see if they can help, but any other help here would be appreciated. Steven Steven Banks 902-368-0566 Steven Banks >>> "Roger Fortier" <[EMAIL PROTECTED]> 03/26/02 04:32PM >>> Below the dotted line is a message that was posted on IBM newsgroup for WebSphere AS400 and basically Struts will not work with Websphere 3.5.3 on AS400. You must upgrade to 3.5.4. Perhaps it's the same for websphere on OS-390? Also, check this link for a version of struts-jar that will work with Websphere 4.0. http://www.mail-archive.com/struts-user@jakarta.apache.org/msg15143.html ------------------------------------------------------------------------ --- Good News: Yes, it will work. Bad News: You may have to jump through a few hoops, depending on just what it is you intend to do in the application, how you intend to deploy, and what your AS400 configuration looks like. 3.5.5 hasn't really been out all that long, and when you consider that anything like this for the 400 always comes poking along several weeks or months after the other platforms my guess would be that higher won't be an option for a while. The way it has shaken out for me is that struts apps deploy fine on versions 3.5.3, 3.5.4, and 3.5.5 for Windows. I did do the documented hacks for the struts source and the parser.jar that are out on the Apache site. This may not be necessary in version 3.5.5, but unfortunately I haven't had adequate time to investigate it. If it isn't fixed, dock IBM several points for not walking it the way they talk it with regard to open source. But don't assume if it works on Windows it will work on the 400 - more on that later. In addition, I did have to change struts-config.xml and web.xml to use system rather than public dtd's. This was not necessary on my Windows desktop, but when I deployed to the 400 I got numerous errors when the webapp loaded. Changing the dtd ref did the trick. If your machine is behind a firewall with no internet access you'll also have to make sure the dtd can be found, so you may need to specify an internal uri. Don't worry, the system log will let you know right away if it doesn't like what you picked. I used the Struts connection pooling option because I used Tomcat as my development server, and because I want to build in some monitoring that is currently not available in WSE for the 400. I developed on Windows using the AS400 toolbox drivers, and switched over to the native DB2 drivers when moving up(Don't ask me why). I ran into some issues there where I was not able to update certain files using SQL (support posts seem to point to issues with non-journaled files), and switching back to the 400 drivers cleared it up. Not sure why, since connections using the WS connection pool and these same drivers seem to have no issues. The big news is that while I got my apps to deploy to a 3.5.4 installation on the 400, no amount of installing, finessing or tears/breastbeating could get them to run on 3.5.3. Even though they ran alright on the same number release on Windows (and Linux for that matter ). So my hunch is that as long as you are on 3.5.4 on up you are OK. But as to the line that if it runs on one it should run on the other platform versions of the same number release? Well, I never say never, and I will always concede the possibility that it could be issues on my end somewhere. But let's just think for a moment on IBM's overall consistency in this area and in overall quality of delivered software product(my own view, there are some great successes and equally great failures), and it isn't much of a stretch to conclude that there are probably is going to be some divergence. The issue you probably won't have is what I hit when I went to create a WAR from my Tomcat webapp and deploy to Websphere. Sounds simple doesn't it? Before I ran the migration tool, I figured I would make the change to my xml files so I wouldn't have to go back after the app was deployed and re-edit. No such luck - wartoxmlconfig(or the menu option in the admin) chokes unless it gets a public dtd, which if you look at what is actually going on it there will make a twisted kind of sense. You have to go back after the fact and edit it, besides copying the web-inf so it resides in both servlets and web( if that is how you have it set up ). Again, I could have done something wrong, but I tried it a couple of times with the same results, so I can say I'm relatively sure this is the case. I've had some other minor issues, but this post is getting kind of long. I'm still in the process of deploying to all environments, so I may have some more later this week. Let me know if you hit anything interesting - I'll be keeping any eye out. gn "Mallik" <[EMAIL PROTECTED]> wrote in message news:9vlr4a$8bg$[EMAIL PROTECTED]... Hi, We have been using STRUTS 1.0 on WAS 3.5.5 on Windows NT(Intel). Ultimately we have to move the application to the WAS on as400. Will WAS 3.5.5 or higher on OS/400(as400) will support STRUTS 1.0 ? Please let us know where we can get more information on this Subject. Best Regards Radiant Team. -----Original Message----- From: Steven Banks [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 26, 2002 3:04 PM To: [EMAIL PROTECTED] Subject: Re: Installation on OS-390 and Websphere 3.5.3: Was 503 Error- Now What struts.jar should I use. I tracked the error message to the ActionServlets initMapping() routine. Specifically "... // Acquire an input stream to our configuration resource InputStream input = getServletContext().getResourceAsStream(config); if (input == null) throw new UnavailableException (internal.getMessage("configMissing", config)); ..." I am currrenly using the struts-war.jar. Is there a specific version that should be used on os/390? Would anyone be willing to e-mail me the jar they are using? Thanks in advance. Steven Banks 902-368-0566 >>> "Steven Banks" <[EMAIL PROTECTED]> 03/26/02 03:04PM >>> Found part of the problem. Websphere defaults the value appserver.compliance.mode=false. This means is you do not set this value to true, you get webspheres compatibilty mode by default. Now I am getting a message: javax.servlet.UnavailableException: Missing configuration resource for path /WEB-INF/struts-config.xml struts-config.xml is in the directory: /u/vacweb/dev/train/WEB-INF/classes/WEB-INF I have listed other WAS.CONF properties below. Are there any other ones I should have? appserver.version=3.50 appserver.usesystemclasspath=false appserver.libpath= appserver.classpath=/u/ws11/as01/properties:/u/vacweb/dev/lib appserver.name=ws11 appserver.jvmpropertiesfile= appserver.loglevel=WARNING appserver.logdirectory= appserver.compliance.mode=true appserver.configviewer= appserver.jspbasehrefadd=true objectleveltrace.enabled=false ..." Steven Banks 902-368-0566 >>> "Steven Banks" <[EMAIL PROTECTED]> 03/26/02 11:20AM >>> I am having problem running a Struts Application on the OS/390. The web application starts up correctly, but when I load any URL for the Web App, the message 503 Error "Application is currently unavailable for service" is displayed. I am following the directions as per configuring Struts for WAS 3.5 on OS/390. Currently we are not using the struts jar, but have been compiling the code and then restarting the web application with many additional System.out.println messages. We found some problems with the classpath and picking up the wrong SAX parser, but it is now correct. I noticed in the installation notes for struts on WAS on windows 2000 mentions that if you get this message, you should restart the web application and tried to do that, but was told you cannot restart an individual web application on the mainframe version of WAS. We have changed all permissions in the web site to 777 and have double checked that the myapp.webapp file is stored in EBCDIC. Any help would be appreciated. Steven Banks 902-368-0566 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>