WAS 8.5能正常登陆管理控制台，但不能上传项目

针对SystemOut.log日志中出现的错误信息：

[14-3-11 10:53:11:041 CST] 0000005c annotations   W com.ibm.ws.amm.scan.context.ScannerContextImpl getInputDataForClass Failed to open resource [ 1/0/org/apache/xml/resolver/helpers/Namespaces.class ] from module [ WEB-INF/lib/com.sun.tools.xjc_2.2.0.jar ]


但是这个问题是不是引起管理控制台不能访问的根源，依然是个疑问，正如多次强调：日志信息太少！

当然，我们可以按照下面的方法进行尝试：

https://www-304.ibm.com/support/docview.wss?uid=swg1PM37942

或查看\properties\amm.filter.properties

或尝试以下方法：

1) If the classes are exposed in a web module archive "WEB-INF/classes" directory, that will cause very large slowdowns.  The converse is for the classes to be in a JAR, either in a simple utility JAR directly contained by the application archive (EAR file), or for the classes to be contained within an EJBJar, or for the classes to be contained in a JAR beneath a web module archive "WEB-INF/lib" directory.

2) If javaEE5 processing is enabled for the classes, either because the classes are present in a javaEE5 enabled EJBJar or WAR, that will cause large slowdowns. The converse is for the classes to be present in a location which will not be scanned, for example, if there is a "META-INF/application.xml" for the EAR, and if all of the modules use a pre-javaEE5 version, or if all of the modules are marked as metadata-complete.
http://pic.dhe.ibm.com/infocente ... 0%6c%65%74%65%22%20
或

3) Even if javaEE5 processing is enabled, if a large subset of the classes do not require annotation scanning, that can be disabled using special properties in the application and module "META-INF/MANIFEST.MF" manifest files.
Exercise caution if you update a manifest file. Manifest files have line length limitations, and other constraints that must be adhered to.
Example:

Ignore-Scanning-Archives : ant.jar,  avalon-framework-4.2.0.jar, axis.jar, CICS.jar, xerces.jar

4) Check if the application is EE5 (in the application.xml, look for the version= tag).  If so, check if there are any WAR files inside the EAR that contain numerous JARs under WEB-INF/lib.  If those are present they can increase deployment time significantly.  There is a tuning option available to help, and it's documented here PK87053: JAVA ENTERPRISE EDITION VERSION 5 APPLICATIONS TAKE A LONG TIME TO DEPLOY http://www-01.ibm.com/support/docview.wss?uid=swg1PK87053


The following solutions are provided as a work-around in place of updating to 7.0.0.5. These solutions assume that a move to a Java EE 5 level is necessary. If the module level can be kept at a pre-Java EE 5 level, the extra annotations scanning will be completely avoided.
If a module is upgraded to a Java EE 5 level, and if the module is known to have no annotations, there is a "metadata-complete" flag in the module descriptor that disables annotations processing for the module. With this option, annotation scanning is bypassed, while Java EE 5 values might still be placed in the descriptor file. For an application which is being migrated, but for which no annotations have been added, the use of "metadata-complete" is recommended.
For example:

xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" metadata-complete="true">
Sample_App
If metadata-complete cannot be set, then if possible, it is advised to restructure the application to place utility JAR files, which are known to contain no annotations information, into shared libraries. These are not scanned for annotations.
Move the jars to the root of the EAR. Nested archives (for example, a JAR within a WAR, within an EAR) are very cumbersome to search through because of the multiple levels of compression. 收起

从SystemErr.log 日志来看，在14-3-10 18:39左右出现了OOM 的异常错误信息，还是一句话，给出的日志信息太少，也不知道是不是由于JVM 的-Xmx 最大Heap设置太小或缺省值，导致的OOM。

如果是这样的话，请尝试把WAS JVM对应的-Xmx 设大，比如设置为1536M

如果是Standalone环境的WAS，直接在WAS管理控制台上设置此WAS的JVM Heap大小。

如果是Dmgr Profile的部署环境，请把Dmgr 对应服务器的JVM Heap调大。调整路径： Web管理界面 左侧
System Administration --> Deployment Manager --> Java and Process Management --> Process Definition --> Java Virtual Machine --> Initial Heap Size 和 Maximum Heap Size ，对这两个数分别调大 收起

从SystemOut.log 日志上看，确实存在这个致命问题，但是不能确定是不是这个引起WAS 管理控制台不能正常访问问题的根源，因为SystemOut.log给出的日志太少了，不能进行相关上下文对照分析。 收起

这两个日志的时间点对不上，一个是3月10日的，一个是3月11日的，不知到有没有时间上能匹配上的日志文件。 收起

1.部署过程中oom可能会导致控制台不能正常访问，在部署程序过程中查看是否报oom错误，上传的error日志中的oom跟systemout的时间不一致，不能确定是否是oom造成的。
2.系统临时目录空间是否够大，在部署过程中需要将war解压到系统临时目录，如果目录满了，控制台也不能访问。 收起

[14-3-10 20:26:39:200 CST] 0000005a SystemErr     R java.lang.OutOfMemoryError(?): Java heap space

这个是部署应用的时间点吗??

是的话怀疑Dmgr部署内存或者Dmgr运行时内存不够用呢

建议首先加大Dmgr部署内存重新部署应用

/AppServer/deploytool/itp/ejbdeploy.sh 中修改JVM参数

其次要是在映射的时候出现问题的话,怀疑是Dmgr运行时内存不够用

System administration ---> Deployment manager ---> Java and Process Management ---> Process definition 修改Dmgr运行时JVM 收起

應該不是 web.xml 的問題。
[14-3-11 10:53:11:041 CST] 0000005c annotations   W com.ibm.ws.amm.scan.context.ScannerContextImpl getInputDataForClass Failed to open resource [ 1/0/org/apache/xml/resolver/helpers/Namespaces.class ] from module [ WEB-INF/lib/com.sun.tools.xjc_2.2.0.jar ]
應該是 com.sun.tools.xjc_2.2.0.jar 與 WAS 底層的 jar 有衝突導致的。 收起

回复 4# fordsupr


   是web.xml的问题，WAS7,把web.xml，中2.5全改成2.4就能上传了，部署、启动都成功了，访问http://IP:9080/ivt/ivtDate.jsp能访问，但就是自己部署的项目还是不能访问，404错误，还是Web.xml有喝下吗？ 收起

你的log有更换吗？还是我看错，通常布署错误的话，要先检查web.xml（IBM蛮严格的），ex:servlet版本；上下文顺序...
先根据你的was版本,google个
default，重新upload
以上,请参考看看
ps.我也是新手,路过而已 收起

回复 2# fordsupr


   能说明下是哪块冲突引起的吗？ 收起