You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Steven Banks <SD...@vac-acc.gc.ca> on 2002/04/03 15:27:22 UTC
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" <SD...@vac-acc.gc.ca> 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" <ro...@sympatico.ca> 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" <mb...@radiants.com> wrote in message
news:9vlr4a$8bg$1@news.boulder.ibm.com...
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:SDBANKS@vac-acc.gc.ca]
Sent: Tuesday, March 26, 2002 3:04 PM
To: struts-user@jakarta.apache.org
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" <SD...@vac-acc.gc.ca> 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" <SD...@vac-acc.gc.ca> 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:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>