本章介绍有关 Sun Java System Application Server Enterprise Edition 8.2 软件的已知问题和相应的解决方法。如果汇总说明未指明特定平台,则所有平台都可能出现此问题。本部分信息按以下内容进行组织:
本节介绍已知的管理问题和相应的解决方法。
默认情况下,在 $INSTALL/lib/package-appclient.xml 中有一个用于 domain1(由 asenv.conf 来指向)的 AS_ACC_CONFIG 变量的硬编码值。如果删除 domain1 并创建新域,将不会用新域名更新 AS_ACC_CONFIG 变量,从而导致 package-appclient 脚本失败。
执行以下操作之一:
保持 domain1 不变,围绕它创建其他域。
删除 domain1 并用新域名替换 $INSTALL/lib/package-appclient.xml 中用于 domain1 的硬编码值。如果 domain1 不存在,则每次创建新域时,都必须执行此操作。
如果在已安装负载平衡器插件的 Application Server 版本(例如 7.1EE)上安装负载平衡插件,则 8.2EE 插件将无提示替换任何现有负载平衡器(即使已创建可在其中运行此插件的新服务器实例)。
默认情况下,插件文件将安装在 install_dir/plugins/lbplugin 目录下,这表示每个版本的 Application Server 仅可以使用一个版本的插件。请注意,控制台安装程序会显示消息,表明将进行卸载,但有时很容易将此消息忽略。
并非任何用户都会遇到此问题。如果遇到此问题,请删除旧的 Application Server 版本并进行新安装而非升级安装。
与 Application Server 7.x 相比,对 Application Server 8.2 中的 asadmin 命令进行了某些更改。例如,在 7.x 中,用于启动服务器实例的命令为:
asadmin start-instance |
在 8.2 中,等效命令为:
asadmin start-domain --user admin domain1 |
有关最新的 asadmin 命令语法的完整信息,请参阅以下文档:
《Sun Java System Application Server Enterprise Edition 8.2 管理指南》
《Sun Java System Application Server Enterprise Edition 8.2 Reference Manual》
《Sun Java System Application Server Enterprise Edition 8.2 Upgrade and Migration Guide》
从 JES2/Application Server 7. x 升级到 JES5/Application Server 8.2 时,由于默认端口已更改,因此可能会遇到不兼容问题或错误。
有关 Application Server 8.2 中使用的默认端口列表,请参阅本说明前面部分中的其他要求。
无法使用 backup-domain 和 restore-domain 命令镜像同一 Application Server 安装上的域,这是由于使用不同于原始名称的其他名称不能恢复域,即使 asadmin restore-domain 命令提供了重命名域的选项。重命名备份域似乎已经成功,但尝试启动重命名的域却会失败,因为没有更改域配置中的条目,并且 startserv 和 stopserv 仍然使用原始域名来设置路径。
用于 restore-domain 的域名必须与用于原始 backup-domain 命令的域名相同。Application Server 8.2 中的 backup-domain 和 restore-domain 命令仅用于在同一台计算机上备份和恢复同一个域。
可以在 Application Server 上配置 J2SE 1.4.x, 5.0 或更高版本。J2SE 5.0 平台的完整功能是可以启动 JMX 代理。在服务器启动时,如果您明确设置了系统属性,此功能将被激活。
示例值包括:
name="com.sun.management.jmxremote" value="true" name="com.sun.management.jmxremote.port" value="9999" name="com.sun.management.jmxremote.authenticate" value="false" name="com.sun.management.jmxremote.ssl" value="false"
在配置了 JMX 属性并启动服务器之后,将在 Application Server VM 中启动新的 jmx-connector 服务器。此过程的副作用是会对管理功能造成不利影响,并且 Application Server 管理 GUI 和 CLI 可能会产生异常结果。出现此问题的原因在于内置 jmx-connector 服务器与新的 jmx-connector 服务器之间存在一些冲突。
如果使用 jconsole(或任何其他 JMX 兼容客户机),请考虑重新使用标准的 JMX Connector Server,它在 Application Server 启动时启动。
当服务器启动时,server.log 中将显示类似于以下所示的内容。您可以连接到其中指定的 JMXServiceURL,并在成功提供证书后执行相同的管理/配置操作,例如:
[#|2004-11-24T17:49:08.203-0800|INFO|sun-appserver-ee8.1|javax.enterprise. system.tools.admin|_ThreadID=10;|ADM1501: Here is the JMXServiceURL for the JMXConnectorServer: [service:jmx:rmi:///jndi/rmi://hostname:8686/management/ rmi-jmx-connector]. This is where the remote administrative clients should connect using the JSR 160 JMX Connectors.|#]
有关更多信息,请参阅《Sun Java System Application Server 8.2 Administration Guide》。
如果您以用户 "A" 身份登录后运行 asadmin restore-domain 命令,这些脚本将以权限 744 (rwxr--r--
) 结束。如果随后尝试以用户 "B" 的身份(即使 "B" 为超级用户)启动或停止域,则会因为只有 "A" 可以执行脚本而失败。
更改脚本的权限:
chmod 755 appserv/domains/domain-name/bin/* |
如果某个应用程序具有可导出 Web 服务 URL 的 EJB 模块,则在用该应用程序设置负载平衡器配置时,Web 服务环境中的超级用户不会包含在结果文件 loadbalancer.xml 中。
编辑 loadbalancer.xml 文件,按如下所示添加缺少的 Web 模块:
<web-module context-root="context-root-name" disable-timeout-in-minutes="30" enabled="true"/> |
用作为 EJB 提供的 Web 服务环境中的超级用户名称替换 context-root-name 的值。
Application Server 域/服务器未使用由相关配置的 java-config 元素的 java-home 属性指向的 JDK。
对于安装的给定服务器,appserver-installation-dir/config/asenv.conf 文件确定了 Application Server 进程针对所有域使用的 JDK 。该文件中的属性 AS_JAVA 确定了所使用的 JDK,此属性是在安装时设置的。如果安装完成后,Application Server 进程使用的是其他 JDK,则可以将该值改为指向所需的 JDK。请注意,安装的此服务器中的所有域均会受此更改影响。
不会检查对 asenv.conf 文件的手动更改的有效性,因此更改时应谨慎行事。修改 AS_JAVA 的值时,请检查产品文档以了解最低的 JDK 版本要求。
此问题由错误的 %CONFIG_HOME% 值引起。
重命名现有 asant.bak。
将 <as_install>/lib/install/templates/ee(适用于 SE/EE 版本)中的 asant.template 文件复制到 <as_install>/bin/ 目录中,并将其重命名为 asant。
编辑新复制的 <as_install>/bin/asant 脚本,用 <as_install>/config 替换 %CONFIG_HOME% 标记。
如果对原始 asant.bak 文件进行了任何手动更改,请将其并入新的 asant 脚本。
如果服务器管理员的主目录中不包含此文件,在升级该服务器上的某些应用程序时可能会出现严重错误。
如果可能,应该由安装服务器的用户运行 asadmin start-domain domain1 命令。
如果不是由该用户运行的,应将 .asadmintruststore 从安装用户的主目录移动或复制到运行用户的主目录中。
请注意,如果将该文件从安装用户的主目录移动(而非复制)到运行用户的主目录,可能会出现错误 6309079、6310428 和 6312869 所述的应用程序升级问题,原因是升级/安装用户(通常是 Java ES 中的超级用户)的主目录中不再具有 .asadminstruststore 文件。
域的主密码包含百分比 (%) 字符时,域无法启动。
域的主密码不应包含百分比字符 (%)。创建新域或更改现有域的主密码时亦如此。
创建安全的 http-listener 并安装 lbplugin 后,将修改 webserver_instance_dir/config 下的 magnus.conf 和 obj.conf 文件,并删除 lbplugin 的内容。
安装程序修改了 Application Server 上的 magnus.conf 和 obj.conf 配置文件,这些文件是负载平衡器安装程序插件的一部分。如果登录到 Application Server 管理控制台,并尝试为已安装负载平衡器的实例管理实例配置,则 Application Server 将显示警告消息,报告已检测到在配置中进行了手动编辑。事实上,此警告是指安装程序所做的更改。
验证安装程序所做的更改是否被覆写。
本节介绍 Apache Web 服务器和负载平衡器插件的已知问题和相应的解决方法。
在编译和生成 openssl 时,请使用以下命令:
cd openssl-0.9.7e config make |
另外,对于 Apache 1.3,mod_ssl 源的目录名称会因使用的 Apache 版本而异。例如,对于 Apache 1.3.33,该名称为 mod_ssl-2.8.22-1.3.33。
要运行 Apache 安全性,就必须使用证书。有关从证书授权机构获取证书的说明,请参见 modssl 常见问题解答 中有关证书的信息。
在 Solaris 上,如果 Application Server 由超级用户安装,则必须以超级用户的身份启动 Apache Web 服务器。必须以超级用户的身份来安装 Java Enterprise System 软件。对于 Apache 2.0,在以超级用户的身份启动后,Apache 会切换到您指定的另一用户并以该用户的身份运行。可在 /conf/httpd.conf 文件中指定该用户。要以超级用户的身份启动,在很多系统中都必须编辑 httpd.conf 文件以指定正确的组。将行:
Group #-1 |
替换为:
Group nobody |
有关用户/组使用的信息包含在 httpd.conf 文件中。
在安装 Apache 2.0 和负载平衡器插件后,请按如下说明编辑 ssl.conf 和 sll-std.conf:
将行:
<VirtualHost _default_:9191>
替换为:
<VirtualHost machine_name:9191>
其中 machine_name 是计算机的名称,9191 是安全端口号。
本节介绍已知的应用程序客户机问题和相应的解决方法。
如果在您的客户机 JAR 中具有顶层 JAR 文件(在此情况下,为 reporter.jar),则当您部署客户机 JAR 时,该 JAR 的 MANIFEST 文件将覆盖客户机 JAR 的 MANIFEST 文件。
目前尚无解决方法。
不再支持动态内容技术,例如 CGI-bin 和 SHTML。
请改为使用 JSP 和 Web 服务技术。
本节介绍已知的捆绑的 Sun JDBC 驱动程序问题和相应的解决方法。
要为连接设置所需的隔离级别,必须以同一隔离级别创建相应的连接池。有关配置连接池的详细信息,请参见《Sun Java System Application Server Enterprise Edition 8.2 管理指南》。
如果应用程序在一个事务中生成超过 3000 个 PreparedStatement 对象,DB2 可能会出现以下错误:
[sunm][DB2 JDBC 驱动程序] 无更多可用语句。请重新创建具有较大 dynamicSections 值的软件包。
将以下属性添加到连接池定义中,以使驱动程序可以重新绑定具有较大动态段值的 DB2 软件包:
createDefaultPackage=true replacePackage=true dynamicSections=1000
有关配置连接池的详细信息,请参见《Sun Java System Application Server Enterprise Edition 8.2 管理指南》。
可能抛出的与上述 PrepardStatement 错误相关的另一条错误消息为:
[sunm][DB2 JDBC 驱动程序][DB2] 虚拟存储或数据库资源不可用。
增大 DB2 服务器的配置参数 APPLHEAPSZ。最佳值为 4096。
隔离级别为 TRANSACTION_SERIALIZABLE。如果应用程序使用隔离级别 TRANSACTION_SERIALIZABLE 并使用上面建议的某个参数,该应用程序可能会在获取连接时挂起。
要为连接设置所需的隔离级别,必须以同一隔离级别创建相应的连接池。有关说明,请参见《Sun Java System Application Server Enterprise Edition 8.2 管理指南》。
如果两个并行事务正在运行并且其中一个已回滚,则在使用准备好的语句进行更新时,结合使用 TRANSACTION_SERIALIZABLE 隔离级别和 Sybase Adaptive Server 的捆绑 Sun 驱动程序的应用程序可能会挂起。连接回滚失败,系统显示以下消息,并且已回滚的连接不能再使用:
java.sql.SQLException:[sunm][Sybase JDBC 驱动程序] 由于线的争用而无法提交请求
Sybase Adaptive Server 不支持 TRANSACTION_REPEATABLE_READ 隔离级别。但是在查询 DatabaseMetaData 时,捆绑的 Sun 驱动程序会返回数据库支持此隔离级别的内容。使用此隔离级别的应用程序将失败。
使用捆绑的 Sun 驱动程序的应用程序无法设置 TRANSACTION_READ_UNCOMMITTED 隔离级别。在首次访问 DataBaseMetaData 时,应用程序会抛出以下异常:
java.sql.SQLException:[sunm][Sybase JDBC 驱动程序][Sybase] 优化程序无法找到唯一的索引,它可以使用该索引对表 "sybsystemprocs.dbo.spt_server_info" 执行隔离级别 0 扫描。
目前尚无解决方法。
使用 SUN JDBC Oracle 数据源 (com.sun.sql.jdbcx.oracle.OracleDataSource) 时,对 JDBC 连接池设置以下属性:
<property name="serverType" value="dedicated"/>
属性的值取决于 Oracle 服务器侦听器的配置方式。如果它配置为“共享”模式,上述值必须更改为 "dedicated"。
从 JDBC 10.2 驱动程序开始,如果 CLASSPATH 中包含多个 JDBC jar 文件,则可能导致 java.lang.SecurityException: Sealing violation exception。
以下 Oracle 文档 ID 中包含来自 Oracle 的详细解释:
Note:405446.1 Subject: JDBC Driver 10.2 Uses Sealed JAR files and May Cause SecurityException Sealing Violation
(Oracle 的建议)请确保 CLASSPATH 仅包含一个 JDBC 驱动程序 JAR 文件。
本节介绍已知的 J2EE 连接器体系结构问题和相应的解决方法。
此方案中,已在 DAS 和连接器连接池中部署了独立或嵌入式连接器模块,并且已为该部署的模块创建了资源。在重新启动 DAS 实例后,如果将 cascade 设置为 false,取消部署连接器模块的操作将失败并且会出现以下异常:
[#|2004-10-31T19:52:23.049-0800|INFO|sun-appserver-ee8.1|javax.enterprise.system .core|_ThreadID=14;|CORE5023:卸载应用程序时出错 [foo]|#]
在重新启动 DAS 实例后,使用级联的取消部署(将 cascade 选项设置为 true)来取消部署独立连接器和嵌入式连接器。
由于在命令行中使用 asadmin create-jms-resource 命令创建新的 JMS 资源时无法指定最小池大小和最大池大小,因此认为 asadmin 命令仅可以使用默认池大小的值(最小值为 8,最大值为 32)来创建资源。但事实并非如此。相反,从命令行结果创建资源将导致最小池大小和最大池大小的默认值分别为 1 和 250。
通过命令行创建 JMS 资源后,使用管理控制台修改最小池大小和最大池大小的值。
本节介绍已知的文档问题和相应的解决方法。
缺少多个 AMX 接口和方法的 Javadoc 或该 Javadoc 不正确:
ConnectorConnectionPoolStats 和 AltJDBCConnectionPoolStats 中缺少用于获取 NumConnAcquired 和 NumConnReleased 统计信息的 getter 方法。这些 getter 方法将以 getNumConnAcquired() 和 getNumConnReleased() 的形式添加到将来的版本中。
在 EJBCacheStats 中调用以下方法时将抛出异常:getPassivationSuccesses()、getExpiredSessionsRemoved()、getPassivationErrors() 和 getPassivations()。在以后的版本中将修复此问题。
服务器启动后,可能需要几秒钟才能注册和使用所有的 AMX MBean。在以后的版本中,将可以确定完全装入 AMX MBean 的时间。
常数 XTypes.CONNNECTOR_CONNECTION_POOL_MONITOR 拼写错误 ("NNN")。在以后的版本中将纠正此问题。
线程 main 中会抛出以下异常:java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher。
建议不要对 Application Server 外的对象使用捆绑的 ANT。
《Sun Java System Application Server Enterprise Edition 8.2 Performance Tuning Guide》错误地介绍了有关日志选项的以下内容:
管理 GUI 提供了以下两个日志记录选项:
选项 1 – 将 stdout (System.out.print) 内容记录到事件日志中
选项 2 – 将 stderr (System.err.print) 内容记录到事件日志中
Application Server Enterprise Edition 8.2 中不再存在这些日志选项。
Application Server Enterprise Edition 8.2 的文档《Sun Java System Application Server Enterprise Edition 8.2 Performance Tuning Guide》中的“HTTP File Cache”一节介绍了 HTTP 文件高速缓存功能。但是,Application Server Enterprise Edition 8.2 中不包括此功能。请注意,已在 Application Server 9.0 中重新引入了此功能。
由于存在其他错误(可能为 6295215),《Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide》中的“Obtaining a Physical Connection from a Wrapped Connection”一节中提供的代码不正确。 具体来说,以下行:
Connection drivercon = ds.getConnection(con); |
现在应该为:
Connection drivercon = ((com.sun.gjc.spi.DataSource)ds).getConnection(con); |
本节介绍已知的高可用性数据库 (HADB) 问题和相应的解决方法。
使用两个子网上的双网络进行配置的 HADB 可以在 Solaris SPARC 上正常工作。但是,由于操作系统或网络驱动程序在某些硬件平台上的问题,已发现在 Solaris x86 和 Linux 平台上并不总是能够正确处理双网络。这就导致 HADB 出现以下问题:
在 Linux 上,发送消息时某些 HADB 进程会被阻塞。这将导致 HADB 节点重新启动以及进行网络分区操作。
在 Solaris x86 上,网络故障后会出现一些问题,导致无法切换到其他网络接口。但并不总是会发生这种情况,因此最好还是使用两个网络。这些问题在 Solaris 10 上已部分解决。
不支持链路聚合。
在 Windows 2003 上,HADB 不支持双网络 (ID 5103186)。
创建新数据库可能会失败并出现以下错误,说明可用的共享内存段太少:
HADB-E-21054:系统资源不可用:HADB-S-05512:用关键字 "xxxxx" 连接共享内存段失败,操作系统状态=24,操作系统错误消息:打开的文件太多。
请确认已配置共享内存且配置能正常工作。特别是在 Solaris 8 上,请检查文件 /etc/system,然后确定变量 shmsys:shminfo_shmseg 的值至少为每个主机的节点数的六倍。
HADB 4.3-0.16 及更高版本被配置为在创建并附加到其共享内存段时使用锁定共享内存(使用 SHM_SHARE_MMU 标志)。使用此标志实质上是将共享内存段锁定到物理内存中,防止它们被调出。这很容易导致在低端计算机上安装时出现问题。
因此,如果开发者的计算机装有 512MB 的内存,并且在使用 Application Server 7.0 EE 时具有大量的可用交换空间,然后安装了 7.1 EE 或更高版本,则该开发者在配置默认的 clsetup 群集时会遇到问题(将创建两个 HADB 节点,每个节点的 devicesize 为 512,这将导致没有足够的物理 RAM,无法支持这两个节点所需的共享内存)。
在同时使用 Application Server 和 HADB 时,请确保具有推荐的内存量。有关更多信息,请参见HADB 要求和支持的平台。
使用 hadbm set 增大设备或缓冲区大小时,管理系统会在创建数据库或添加节点时检查资源可用性,但在更改设备或主内存缓冲区大小时则不会检查是否有足够的可用资源。
在增大 devicesize 或 buffersize 配置属性之前,确认所有主机上都有足够的可用磁盘空间/内存空间。
不能在不同主机上的不同位置使用相同名称注册同一个软件包;例如:
hadbm registerpackage test --packagepath=/var/install1 --hosts europa11 Package successfully registered. hadbm registerpackage test --packagepath=/var/install2 --hosts europa12 hadbm:Error 22171: A software package has already been registered with the package name test. |
HADB 不支持数据库群集中节点之间的异构路径。确保 HADB 服务器的安装目录 (--packagepath) 在所有参与的主机上都相同。
在具有多个网络接口的主机上运行管理代理时,如果所有网络接口不是在同一子网中,则 create domain 命令可能会失败:
hadbm:Error 22020: The management agents could not establish a domain, please check that the hosts can communicate with UDP multicast. |
管理代理将(如果不是采用其他配置)使用 UDP 多址广播的“第一个”接口(“第一个”接口由 java.net.NetworkInterface.getNetworkInterfaces() 的结果定义)。
最佳解决方法是告诉管理代理要使用哪个子网(在配置文件中设置 ma.server.mainternal.interfaces,例如,ma.server.mainternal.interfaces=10.11.100.0)。此外,也可以配置子网之间的路由器,以便路由多址广播数据包(管理代理使用多址广播地址 228.8.8.8)。
在重试管理代理的新配置之前,可能需要清除管理代理系统信息库。停止域中的所有代理,并删除系统信息库目录(由管理代理配置文件中的 repository.dr.path 标识)中的所有文件和目录。必须先在所有主机上执行此操作,然后才能用新配置文件重新启动代理。
删除 HADB 实例后,接下来尝试使用 configure-ha-cluster 命令创建新实例会失败。问题在于 ha_install_dir/rep/* 和 ha_install_dir/config/hadb/instance_name 中保留了原始 HADB 实例的旧目录。
在删除 HADB 实例后务必手动删除这些目录。
在 Solaris 10 Opteron 上,使用 hadbm 命令启动、停止或重新配置 HADB 可能会失败或挂起,并产生以下错误消息:
hadbm:Error 22009: The command issued had no progress in the last 300 seconds. HADB-E-21070: The operation did not complete within the time limit, but has not been cancelled and may complete at a later time. |
如果 clu_noman_srv 进程所使用的文件 (nomandevice) 存在不一致的读/写操作,就可能出现这种情况。通过在 HADB 历史文件中查找以下消息,可以检测到此问题:
n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Child process noman3 733 does not respond. n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Have not heard from it in 104.537454 sec. n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Child process noman3 733 did not start. |
以下解决方法未经验证,原因是此问题尚未手动再现。但是,对受影响的节点运行此命令应该能解决此问题。
hadbm restartnode --level=clear nodeno dbname |
请注意,该节点的所有设备都将重新初始化。在重新初始化之前可能必须停止该节点。
在运行 Solaris 8 且装有多个 NIC 卡的主机上启动时,如果混合启用了 IPv6 卡和 IPv4 卡,管理代理可能会终止并产生异常“IPV6_MULTICAST_IF 失败”。
将环境变量 JAVA_OPTIONS 设置为 -Djava.net.preferIPv4Stack=true;例如:
export JAVA_OPTIONS="-Djava.net.preferIPv4Stack=true" |
此外,也可以使用 Solaris 9 或更高版本,这些版本不会出现此问题。
在 Red Hat Enterprise Linux 3.0 的 64 位版本中有一个错误,使 clu_trans_srv 进程在执行异步 I/O 时以不可中断模式结束。这意味着 kill -9 不起作用,必须重新引导操作系统。
使用 Red Hat Enterprise Linux 3.0 的 32 位版本。
当密码存储在 hadb 中时,其中的大写字母会转换成小写字母。
请勿使用包含大写字母的密码。
降级到先前的 HADB 版本时,管理代理会失败并产生不同的错误代码。
可以降级 HADB 数据库,但如果已经对系统信息库对象进行更改,则无法降级管理代理。在降级后,必须仍然使用来自最新 HADB 版本的管理代理。
对于 HADB c 软件包 (Solaris: SUNWhadbc, Linux: sun-hadb-c) <m.n.u-p> 版的安装/删除,symlink /opt/SUNWhadb/<m> 在创建后不会有任何改动。因此,可能会存在孤立的 symlink。
除非正在使用 symlink,否则请在安装前或卸载后将其删除。
在 Solaris 10 上,在全局区域中使用 ma-initd 脚本停止管理代理,也会在局部区域中停止管理代理。
请勿在全局区域和局部区域中都安装管理代理。
有时,服务器上的资源争用问题可能导致管理客户机断开连接。重新连接时,可能会返回以下误导性的错误消息:“hadbm:错误 22184:必须提供密码才能连接到管理代理”。
检查服务器上是否存在资源问题,采取适当的措施(例如添加更多资源),然后重试操作。
与 Java Enterprise System 一起安装(以超级用户的身份)仅允许超级用户管理 HADB。
要管理 HADB,请始终以超级用户的身份登录。
IP 地址类似于 0.0.0.0 的特殊用途的接口不应注册为可供管理代理中的 HADB 节点使用的接口。如果用户使用主机名称而不是 IP 地址发出 hadbm create 命令,将 HADB 节点设置到这些接口上,则注册这些接口可能会导致出现此问题。此后,节点将无法通信,从而导致 create 命令挂起。
在具有多个接口的主机上使用 hadbm create 时,始终明确使用 DDN 表示法来指定 IP 地址。
在具有某些配置和负载的 Windows 平台上,操作系统中可能会出现大量的重汇编失败。已经发现 20 多个节点的配置在并行运行多个表扫描 (select *) 时有此问题。症状可能是事务频繁地异常中止,修复或恢复会持续很长时间才能完成,系统的各个部分会频繁超时。
要修复此问题,可将 Windows 注册表变量 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 设置为高于默认值 100 的值。建议将此值增大到 0x1000 (4096)。有关更多信息,请参见 Microsoft 支持页中的文章 811003。
当计算机处于负载状态时可能会出现此情况,此时屏蔽机制会失败,并且部分正在输入的密码会公开出来。这会导致较小的安全风险,密码应该始终以屏蔽方式显示。
将密码保存在其各自的密码文件中(从 Application Server 8.1 开始通常推荐的方法),并使用 --adminpassword 或 --dbpasswordfile 选项引用这些文件。
将 Application Server 安装到 Solaris 全局区域的 /usr/SUNWappserver 中后,与此 Application Server 实例一起安装的 HADB 组件在稀疏本地区域中不可用。
此问题在于 HADB 安装到全局区域的 /opt/SUNWhadb 中,而从稀疏本地区域不可读取此目录。遗憾的是,JES5 中的 HADB 包不可重定位。
由于 Application Server HADB 组件不可重定位,因此 HADB 组件必须分别安装在您要通过其访问 HADB 的每个稀疏本地区域中。
本节介绍已知的安装问题和相应的解决方法。
已在多种 Linux 系统上发现此问题。此问题在 Java Desktop System 2 上最常见,但在 Linux Red Hat 分发上也发现了此问题。
在安装程序的最后一个屏幕上单击完成按钮后,安装程序无法启动包含产品“关于”页面或产品注册页面的浏览器窗口,并且安装程序将无限期地挂起而不返回命令提示符。
通过在启动安装程序的终端窗口中按 Ctrl+C 组合键来退出安装程序。执行此操作后,有时会启动包含产品“关于”页面或注册页面的浏览器窗口。如果不显示此窗口,请启动浏览器并输入以下 URL 以查看“关于”页面:
file://install_dir/docs-ee/about.html |
如果您还选择了用于注册产品的安装选项,请点击产品“关于”页面上提供的指向注册页面的链接。
刚刚在 Windows 上安装 Application Server Enterprise Edition 之后,Message Queue 代理启动失败,并显示一条消息,说明目录 drive:\as\domains\domain1\imq 不存在。
请注意,如果在启动 domain1 后启动该代理,则 Application Server 将创建该目录,因此不会出现上述问题。
在创建代理之前创建 var_home_dir_location:
$imqbrokerd -varhome var_home_dir_location |
例如:
$imqbrokerd -varhome D:\as\domains\domain1\imq |
如果 Red Hat Linux Advanced Server (RHLAS) 3.0 或 4.0 系统上尚未安装 compat-libstdc++ 库,则在该系统上安装 Application Server Enterprise Edition 8.2 将失败。Application Server 要求 RHLAS 系统上具有 compat-libstdc++ 库,但默认情况下尚未安装此库。请注意,只有在 RHLAS 系统上才会出现此问题。
在安装 Application Server 软件之前,从 http://rpm.pbone.net/index.php3/stat/4/idpl/843376/com/compat-libstdc++-7.3-2.96.118.i386.rpm.html 中下载并安装 compat-libstdc++ RPM。
在 64 位模式下运行 Application Server Enterprise Edition 8.2 和 Web Server 7.0 时,尝试运行 64 位版的负载平衡器插件失败,并显示以下错误:
failure: CORE2253: Error running Init function load-modules: dlopen of /export/home/mareks/opt/webserver7/plugins/lbplugin/bin/libpassthrough.so failed (ld.so.1: webservd: fatal: /export/home/mareks/opt/webserver7/plugins/ lbplugin/bin/libpassthrough.so: wrong ELF class: ELFCLASS32) failure: server initialization failed |
此问题在于 Application Server Enterprise Edition 8.2 没有 64 位负载平衡器插件,而 64 位 Web Server 需要 64 位插件。
您可以通过使用以下命令来确定 Web Server 是在 64 位模式还是 32 位模式下运行:
wadm get-config-prop --user=admin --config=xxx --password-file=xxx platform |
没有计划用于 Application Server Enterprise Edition 8.2 的 64 位负载平衡器。要解决此问题,请使用 Web Server 7.0 反向代理功能,或将 Web Server 7.0 配置为在 32 位模式下运行。有关说明,请参阅 Web Server 文档。
在 Windows 2000 中的默认位置安装 Application Server 8.2 时,如果运行 asant deploy,可能会遇到以下错误:
$ C:/Sun/JavaES5/appserver/bin/asant deploy The input line is too long. The syntax of the command is incorrect. |
此问题在于 Windows 2000 中的命令行不能超过 1000 个字符,并且根据系统配置,默认的 ANT_OPTS 环境可能导致 asant deploy 命令行过长。此问题仅针对 Windows 2000。
在 Windows 2000 上,将 Application Server 安装在较短的目录路径中,例如 C:\JES5_AS。
在 Windows 上使用 JES 5 b12 时,如果在所选组件安装面板的顶层选择 Application Server,则默认情况下也会选择节点代理子组件。随后,安装过程将创建一个节点代理,以及一个属于此节点代理的名为 AppServer1 的服务器实例。这是正确的行为。
但是,如果取消选定节点代理子组件,安装过程仍在 common.properties 文件中为该域创建一个 AppServer1 实例;例如:
domain.name=domain1 appserver.instance=AppServer1 |
随后尝试使用 asant 部署应用程序将失败。
编辑 common.propeties 文件,用 appserver.instance=server 替换 appserver.instance=AppServer1。
由于存在其他错误(可能为 6295215),《Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide》中的“Obtaining a Physical Connection from a Wrapped Connection”一节中提供的代码不正确。 具体来说,以下行:
Connection drivercon = ds.getConnection(con); |
现在应该为:
Connection drivercon = ((com.sun.gjc.spi.DataSource)ds).getConnection(con); |
在此版本软件中,Application Server 不支持网络文件系统 (Network File System, NFS)。
无。
要在 Sun Java System Application Server Enterprise Edition 8.2 上运行 J2EE 1.4 Tutorial,请执行以下任务:
按照“关于本教程”一章的“关于示例”一节中所述编辑文件示例 /common/build.properties 时,还要将端口 4848 改为 4849。
使用 Deploytool 时,在部署示例之前添加服务器 localhost:4849。
使用管理控制台创建资源时,使用“目标”选项卡将服务器指定为目标。如果使用命令行或 asant 目标,则该服务器为默认目标,无需其他操作。
本节介绍已知的生命周期管理问题和相应的解决方法。
[echo] Doing admin task set [exec] [Attribute(id=redelivery-interval-internal-in-millis) : Redelivery- Interval (7,000) should be greater than or equal to Minimum-delivery- interval-in-millis (9,000)] [exec] CLI137 Command set failed.
minimum-delivery-interval 是传送相同周期计时器之间的最小时间间隔。
redelivery-interval-in-mills 是计时器服务在 ejbTimeout 失败后再次尝试传送之前等待的时间。
问题在于描述重新传送时间间隔属性与最小传送时间间隔属性之间关系的逻辑不正确,使您无法使用 GUI 或 CLI 来设置使最小传送时间间隔大于重新传送时间间隔的任何值。
必须始终将 minimum-delivery-interval-in-millis 设置为等于或大于 ejb-timer-service 属性 redelivery-interval-in-millis。Application Server 在确认 redelivery-interval-in-millis 的值是否大于 minimum-delivery-interval-in-millis 的值时使用了错误的验证检查,这是产生上述问题的原因。
使用这些属性的默认值,如下所示:
minimum-delivery-interval(default)=7000 redelivery-interval-in-millis(default)=5000
使用其他的值将导致产生错误。
本节介绍已知的日志记录问题和相应的解决方法。
为 JVM 设置 java.security.debug 选项会导致服务器实例的启动停止并死锁;例如,在 domain.xml 中进行以下设置将导致出现此问题:
<jvm-options\>-Djava.security.debug=access,failure</jvm-options\>
目前尚无解决方法。请避免设置此标志。
与 7.x 相比,Sun Java System 8.2 中的默认日志记录和服务器实例位置已更改。
有关更多信息,请参阅《Sun Java System Application Server Enterprise Edition 8.2 管理指南》或《Sun Java System Application Server Enterprise Edition 8.2 Upgrade and Migration Guide》。
本节介绍已知的 Java Message Queue 问题和相应的解决方法。
多种问题均可导致在与时间相关的情况下重新连接失败。
可以通过以下方法解决这些问题:
重新启动相关的代理
重新启动相关的 Application Server 实例
由于最近的更改,当异步消息侦听器是 app-client 容器中唯一的活动线程时,其余 appclient 虚拟机将作为守护进程存在。对于以前在 ACC 中执行异步接收的应用程序,此行为是一种退化。此问题将影响设置 JMS 消息侦听器并退出主线程的应用程序客户机。
不退出主线程。等待消息侦听器通知主线程,然后再终止主线程。
本节介绍已知的监视问题和相应的解决方法。
使用“监视级别”设置页将“连接器服务”或“连接器连接池”的监视级别更改为“低”或“高”,然后保存,在域的 domain.xml 文件中,这两个监视级别都未更改。但是,如果要将 JMS 服务的监视级别更改为“低”或“高”并保存,“连接器服务”和“连接器连接池”的值同时也将更改。从命令行中运行等效命令时,此问题不会出现。
仅使用“监视级别”页中的 JMS 服务组件来更改监视级别。
查看 HTTP 服务的某些元素的监视统计信息时,显示的某些值与当前值并不对应或始终为 0。特别是,以下 HTTP 服务统计信息并不提供适用于 Application Server 的信息,应该被忽略:
http-service load1MinuteAverage load5MinuteAverage load15MinuteAverage rateBytesTransmitted rateBytesReceived
pwc-thread-pool(元素)
例如:
EJBModuleMonitorMap().size() = 1 eventhough ejb module is undeployed EJBModuleMonitor().getName() = sqe_ejb_s1_01 |
EJB 模块和应用程序都存在这个问题。以编程方式(通过 MBean API)和通过 asadmin list/get 执行操作后,空的监视 MBean 仍然存在。
asadmin list -m "server.applications" 显示以下输出: server.applications.MEjbApp server.applications.__ejb_container_timer_app server.applications.adminapp server.applications.admingui server.applications.com_sun_web_ui server.applications._export_install_nov-11_domains_domain1_applications _j2ee-modules_sqe_ejb_s1_01 |
您可以查看统计信息:
bin/asadmin list -m "server.applications._export_install_nov-11_domains _domain1_applications_j2ee-modules_sqe_ejb_s1_01" server.applications._export_install_nov-11_domains_domain1_applications_ j2ee-modules_sqe_ejb_s1_01.SQEMessage server.applications._export_install_nov-11_domains_domain1_applications_ j2ee-modules_sqe_ejb_s1_01.TheGreeter |
一旦您取消部署:
_export_install_nov-11_domains_domain1_applications_j2ee-modules_sqe_ ejb_s1_01 |
如果执行 list 命令,您仍然可以看到应用程序:
asadmin list -m "server.applications" server.applications.MEjbApp server.applications.__ejb_container_timer_app server.applications._export_install_nov-11_domains_domain1_applications_ j2ee-modules_sqe_ejb_s1_01 server.applications.adminapp server.applications.admingui server.applications.com_sun_web_ui |
但它不包含任何监视统计信息:
asadmin list -m "server.applications._export_install_nov-11_domains_ domain1_applications_j2ee-modules_sqe_ejb_s1_01" Nothing to list at server.applications.-export-install-nov-11-domains- domain1-applications-j2ee-modules-sqe-ejb-s1-01. |
要获得以某个字符串开头的有效名称,请使用通配符 (' *')。例如,要列出以 server 开头的所有可监视实体的名称,请使用 list "server.*" 命令。
这是没有危害的。可以安全地重新部署模块而不会出现任何问题。未删除根监视 Mbean,但它为空。
本节介绍与 Java 数据对象和容器管理持久性有关的已知和相应的解决方案。
如果某个事务中修改(或创建)的实例之间的一系列外键相关性在数据库中导致循环相关性,则会抛出此异常。
将原来的一组操作拆分成多个事务。
本节介绍与 PointBase 有关的已知问题和相应的解决方法。
对于指向 PointBase 数据库安装的 JDBC 连接池,将 transaction-isolation-level 池属性设置为默认值 (Connection.TRANSACTION_READ_COMMITTED) 以外的任何值都会导致异常。但是,对于指向其他数据库的池,将此参数设置为非默认值不会抛出异常。
对于指向 PointBase 数据库安装的 JDBC 连接池,不要尝试设置 transaction-isolation-level。
如果同时使用网络服务器驱动程序和嵌入式驱动程序,捆绑的 PointBase 有时会抛出异常。
只使用嵌入式驱动程序或网络服务器驱动程序两者之一。
升级到 Application Server Enterprise Edition 8.2 时,更新发行版修补程序会覆写 Pointbase 默认数据库。
重新创建或重新输入升级之前存在的任何方案或数据。如果用具有生成表选项的 CMP Bean 来部署应用程序,则必须取消部署或重新部署应用程序,以便重新生成表。
本节介绍与 Application Server 8.2 产品附带的样例代码相关的已知问题和相应的解决方法。
如果从 install_dir\samples\ee-samples\failover\apps\mqfailover\docs\index.html 运行以下命令:
控制台 1
cd install_dir\samples\ee-samples asant start-mq-master-broker1 |
控制台 2
cd install_dir\samples\ee-samples asant start-mq-cluster-broker1 |
控制台 3
cd install_dir\samples\ee-samples asant start-mq-cluster-broker2 |
控制台 4
cd install_dir\samples\ee-samples asadmin start-domain domain1 |
如果已经为任何其他 Enterprise Edition 样例执行了 asant setup-one-machine-cluster-without-ha 或 asant setup-one-machine-cluster-with-ha,则请执行 asant configure-mq,否则请执行 asant setup-one-machine-cluster-and-configure-mq。在这种情况下,命令显示为成功:
start_nodeagent: [echo] Start the node agent cluster1-nodeagent [exec] Command start-node-agent executed successfully. |
但随后系统将无限期挂起。
目前尚无解决方法。此问题同样会影响在 Windows 上使用此 ant 目标的所有 Enterprise Edition 样例。一个解决方法是按 Ctrl+C 组合键退出挂起的进程,然后重新运行它。
抛出的错误如下:
/opt/SUNWappserver/domains/domain1/config/sun-acc.xml -name MQFailoverTestClient -textauth -user j2ee -password j2ee Nov 18, 2004 10:50:17 PM com.sun.enterprise.naming.NamingManagerImpl bindObjects SEVERE: NAM0006: JMS Destination object not found: jms/durable/TopicA Nov 18, 2004 10:50:18 PM com.sun.enterprise.naming.NamingManagerImpl bindObjects SEVERE: javax.naming.NameNotFoundException javax.naming.NameNotFoundException |
文档没有明确说明如果使用 asadmin deploy 命令进行了手动部署则必须手动创建 JMS 资源,并且应使用提供的 ant 目标来部署样例应用程序。
将 asant 部署目标用于 build.xml 脚本,该脚本用于创建运行应用程序所需的 JMS 资源。
在 Linux 上,部署 install_dir/samples/webservices/security 样例 (basicSSl) 时未创建证书,而抛出类似如下的错误:
generate_certs: [echo] ***Exporting certificate from NSS database [exec] Result: 1 [echo] ***Generating Java Keystore from generated certificate [exec] keytool error: java.lang.Exception: Input not an X.509 certificate [exec] Result: 1 [echo] ***Generating Java trust store from generated certificate [exec] keytool error: java.lang. Exception: Input not an X.509 certificate [exec] Result: 1 . . . generate_certs: [echo] ***Exporting server certificate from NSS database to a PKCS12 certificate file [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/ libnss3.so: version `NSS_3.9' not found (required by /opt/sun/appserver/lib/ pk12util) [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/libnss3.so: version `NSS_3.6' not found (required by /opt/sun/appserver/lib/pk12util) [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/libnss3.so: version `NSS_3.7' not found (required by /opt/sun/appserver/lib/pk12util) [exec] Result: 1 |
问题在于 NSS 库在 Linux 安装上的位置与其在 Solaris 安装上的位置不同。在 Linux 上部署时,必须确保 LD_LIBRARY_PATH 指向正确的 NSS 库。在您的环境中或在 install_dir/bin/asant shell 包装程序脚本中设置 LD_LIBRARY_PATH。
执行以下操作之一:
设置 LD_LIBRARY_PATH=/opt/sun/private/lib。
将以下行添加到 install_dir/bin/asant 脚本:
LD_LIBRARY_PATH=$AS_NSS:$LD_LIBRARY_PATH;export LD_LIBRARY_PATH |
从 Application Server Platform Edition 8.0 更新到 Application Server Enterprise Edition 8.2 后,可能在尝试访问样例页时收到 HTTP 404“找不到文件”错误。
将样例文档从 8.0 域复制到 8.2 域。
在 Solaris 全局区域中安装了 Application Server Enterprise Edition 8.2,并随后在稀疏本地区域中安装了 Application Server 域时,如果在部署过程中稀疏区域中此域的文件权限未完全开放,则可能在运行样例应用程序时遇到问题。
部署过程中,请确保 Application Server 可以检索客户机 JAR 文件 xmsClient.jar,并可以将它复制到样例位置 (/usr/SUNWappserver/appserver/samples/webservices/security/ejb/apps/xms/xmsClient.jar)。这通常由样例工具自动完成,但如果未开放 xmsClient.jar 的权限,此操作将失败。
本节介绍与 Application Server 及 Web 应用程序安全性和证书相关的已知问题和相应的解决方法。
无法使用 J2SE 5.0 运行 WebServiceSecurity 应用程序,原因是:
J2SE 5.0 PKCS11 不支持 UNWRAP 模式
J2SE 5.0 PKCS11 不支持使用 PKCS11 的 RSA/ECB/OAEPWithSHA1AndMGF1Padding
J2SE 小组已针对此错误归档“CR 6190389:为 RSA-PKCS1 和 RSA-OAEP 包装/解包机制添加支持”。
使用带有任何其他 JCE 提供者(而不是默认包含的提供者)的 J2SE 1.4.2。请注意,此配置中将不提供对硬件加速器的支持。
如果为 SSL 终止配置了负载平衡器(硬件),则 Application Server 会在重定向过程中将协议从 https 更改为 http。
在硬件负载平衡器与 Application Server 之间添加软件负载平衡器。
本节介绍已知的升级实用程序问题和相应的解决方法。
如果运行升级实用程序并将 install_dir 标识为源安装目录,升级进程只升级在 install_dir/domains 目录下创建的域。在其他位置创建的域不会被升级。
启动升级进程前,将所有域目录从不同位置复制到 install_dir/domains 目录中。
此问题已在多个 Linux 系统上出现,是 Java Desktop System 2 上最常见的问题,但在 RedHat 版本中也发现了此问题。
在最终安装程序屏幕上单击“启动升级工具”按钮后,安装程序无法启动升级工具以完成升级过程,并且无限期挂起,而不会返回命令提示符。
如果使用命令行安装模式来运行就地升级,将不会遇到此问题。
如果您以 GUI 模式运行就地升级并且遇到此问题,请通过在启动安装程序的终端窗口中按 Ctrl+C 组合键来退出安装程序。
使用以下命令从终端窗口启动升级工具:
install_dir/bin/asupgrade --source install_dir/domains --target install_dir --adminuser adminuser--adminpassword adminpassword --masterpassword changeit |
adminuser 和 adminpassword 的值应与要升级的安装所使用的值匹配。
在升级工具完成升级过程后,您还可以启动浏览器并输入以下 URL 来查看“关于”页面:
file://install_dir/docs/about.html
如果您还选择了用于注册产品的安装选项,请点击产品“关于”页面上提供的指向注册页面的链接。
将以下条目从目标 domain.xml 删除(在升级后),然后重新启动服务器:
<jvm-options>-Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot} /config/keystore.jks</jvm-options>- <jvm-options>Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot} /config/cacerts.jks</jvm-options>
从 Application Server 7.x 更新到 8.2 后,新旧版本之间可能存在端口冲突,最可能冲突的端口是 8080 和 8181。
更改 Application Server 8.2 中使用的端口以解决端口冲突问题。
对于此错误,存在两个方面:
运行使用 Derby 数据库的样例应用程序安装脚本时,Derby 数据库在它的当前目录下或在 <install_root>/bin 下创建。
样例 build Ant 脚本在当前目录下创建存储管理员密码文件的 password.txt 文件,在非超级用户以及稀疏区域的情况下,此目录不可写入。
Derby 数据库位置 – 使用 --dbhome 选项和 start-database 命令在为 --dbhome 指定的值处创建数据库。例如,以下是 start-database 的 asadmin 命令语法。
start-database [--dbhost 0.0.0.0] [--dbport 1527] [--dbhome db_directory] [--echo=false] [--verbose=false] |
password.txt 文件的位置–由于所有构建命令均会在样例目录中创建 password.txt 文件,因此根据设计,此目录应是可写入的。请确保在可写入的位置安装样例的工作副本。
使用管理员凭证而非默认凭证运行升级安装时,会出现此问题。
在使用基于文件的安装程序执行从 8.xPE 到 8.2EE 的并行升级时,请对新的 Application Server 使用以下管理员凭证:
管理员用户:admin
管理员密码:adminadmin
主密码:changeit
执行升级后,您可以根据需要更改这些密码。
升级工具无法为“源目录”字段检测现有但无效的目录输入,并使用户认为目录配置正确。
预期为在“源目录”中输入错误的路径时,弹出“目录无效”消息。如果在“源目录”中输入 /opt/SUNWappserverEE81UR2/,则将正确弹出“无效目录”消息。但是,输入 /opt/SUNWappserverEE81UR2/domains 后,即使路径无效,此工具仍继续进行升级进程而不显示警告。除行为根据输入值有所不同外,此问题类似于 ID 6440710。
从 Application Server 7 或 8.x 升级到 Application Server 8.2 时,必须首先使用文档中建议的值(对于就地升级为域根目录,对于并行升级为域目录)来编排源目录。
Application Server Enterprise Edition 8.2 安装不允许管理员用户名中使用特殊字符。如果使用了任何特殊字符,域创建将会失败。但是,请注意,管理员密码可以包含特殊字符。
从 Application Server 7 升级到 Application Server 8.2 时,请验证管理员用户名是否不包含任何特殊字符。
本节介绍已知的 Web 容器问题和相应的解决办法。
如果您在 Windows 上部署应用程序时要求预编译 JSP,则以后尝试取消部署该应用程序或重新部署该应用程序(或任何具有相同模块 ID 的应用程序)的操作将不会按预期进行。出现此问题的原因是:JSP 预编译会打开应用程序中的 JAR 文件,但不能关闭这些文件,Windows 将禁止执行取消部署或重新部署操作以避免删除或覆盖它们。
请注意,取消部署在某种程度上是成功的,因为应用程序会从 Application Server 中被逻辑删除。另外请注意,asadmin 实用程序不会返回任何错误消息,但应用程序的目录以及锁定的 jar 文件会保留在服务器中。服务器的日志文件将包含用于说明未能删除文件和应用程序的目录的消息。
在取消部署后尝试重新部署应用程序的操作会失败,这是由于服务器尝试删除现有文件和目录,而这些尝试也失败了。如果您尝试部署的应用程序所使用的模块 ID 与最初部署的应用程序的模块 ID 相同,会出现这种情况,这是由于服务器在选择目录名来保存应用程序的文件时会使用模块 ID。
如果没有先取消部署应用程序而尝试重新部署该应用程序,也将会由于同样的原因而失败。
如果尝试重新部署应用程序或在取消部署后部署它,asadmin 实用程序将返回一个类似如下的错误。
An exception occurred while running the command. The exception message is: CLI171 Command deploy failed : Deploying application in domain failed; Cannot deploy. Module directory is locked and can't be deleted. |
如果在部署应用程序时指定 --precompilejsps=false(默认设置),则不会出现此问题。请注意,第一次使用应用程序时会触发 JSP 编译,因此第一个请求的响应时间将会长于随后的请求的响应时间。
另外,请注意,如果您确实进行了预编译,则在取消部署或重新部署应用程序之前,应先停止并重新启动服务器。关闭服务器后将释放锁定的 JAR 文件,这样在重新启动服务器后,取消部署或重新部署便可以成功。
web.xml 中的可选 load-on-startup servlet 元素表示相关的 servlet 将在启动对其进行声明的 Web 应用程序期间被加载和初始化。
此元素的可选内容是一个整数,用于表示该 servlet 相对于 Web 应用程序的其他 servlet 而被装入和初始化的顺序。只要该 servlet 在包含它的 Web 应用程序启动期间被加载和初始化,空的 <load-on-startup> 就表示顺序无关紧要。
web.xml 的 Servlet 2.4 模式不再支持空的 <load-on-startup>,这意味着在使用基于 Servlet 2.4 的 web.xml 时,必须指定一个整数。如果像在 <load-on-startup/> 中一样指定空的 <load-on-startup>,则 web.xml 将无法针对 web.xml 的 Servlet 2.4 模式进行验证,从而导致 Web 应用程序的部署失败。
向下兼容性问题。指定空的 <load-on-startup> 在基于 Servlet 2.3 的 web.xml 中仍起作用。
在使用基于 Servlet 2.4 的 web.xml 时,指定 <load-on-startup>0</load-on-startup>,以表明 servlet 的装入顺序无关紧要。
已访问 JSP 页面但是无法对其进行编译,并且服务器日志包含错误消息“无法执行命令”和以下堆栈跟踪:
at org.apache.tools.ant.taskdefs.Execute$Java13CommandLauncher. exec(Execute.java:655) at org.apache.tools.ant.taskdefs.Execute. launch(Execute.java:416) at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:427) at org.apache.tools.ant.taskdefs.compilers.DefaultCompilerAdapter. executeExternalCompile(DefaultCompilerAdapter.java:448) at org.apache.tools.ant.taskdefs.compilers.JavacExternal.execute (JavacExternal.java:81) at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:842) at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:682) at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:396) |
将 JSP 编译开关 "fork" 设置为 "false"。
可以通过以下两种方式之一来实现:
在全局范围内,将 ${S1AS_HOME}/domains/domain1/config/default-web.xml 中 JspServlet 的 fork 初始化参数设置为 false:
<servlet> <servlet-name>jsp</servlet-name> <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class> .... <init-param> <param-name>fork</param-name> <param-value>false</param-value> </init-param> .... </servlet> |
在每个 Web 应用程序基础上,通过将 sun-web.xml 中的 fork JSP 配置属性设置为 false:
<sun-web-app> <jsp-config> <property name="fork" value="false" /> </jsp-config> </sun-web-app> |
以上任何一种设置都将阻止 ant 生成用于 javac 编译的新进程。
Sun Java System Application Server Enterprise Edition 8.2 添加了对 Sun Java System Application Server Enterprise Edition 7.1 附带的 auth-passthrough 插件函数所提供功能的支持。但是,在 Application Server Enterprise Edition 8.2 中,auth-passthrough 插件功能的配置有所不同。
Application Server Enterprise Edition 7.1 中的 auth-passthrough 插件功能已经在两层部署方案中带来很大帮助,其中:
Application Server 实例受公司防火墙之后的第二层防火墙的保护。
不允许客户机直接连接到 Application Server 实例。
在这种网络体系架构中,客户机连接到前端 Web 服务器,而该 Web 服务器配置有 service-passthrough 插件功能,会将 HTTP 请求转发到代理的 Application Server 实例以供处理。Application Server 只能从 Web 服务器代理接收请求,而决不会从任何客户机主机接收请求。因此,当部署在代理的 Application Server 实例上的任何应用程序查询客户机信息时,该应用程序将收到代理主机的信息(例如,当该应用程序查询客户机 IP 地址时,会收到代理主机的 IP),这是因为代理主机才是中继请求的真正发出主机。
在 Application Server Enterprise Edition 7.1 中,auth-passthrough 插件功能可在代理的 Application Server 实例上配置,以便使远程客户机信息能够直接由其上部署的所有应用程序使用,就像 Application Server 实例直接接收了请求,而不是通过运行 service-passthrough 插件的中间 Web 服务器接收请求。
在 Application Server Enterprise Edition 8.2 中,可以通过将 domain.xml 中 <http-service> 元素的 authPassthroughEnabled 属性设置为 TRUE 来启用 auth-passthrough 功能,如下所示:
<property name="authPassthroughEnabled" value="true"/> |
Application Server Enterprise Edition 7.1 中 auth-passthrough 插件功能的安全注意事项也同样适用于 Application Server Enterprise Edition 8.2 中的 authPassthroughEnabled 属性。由于 authPassthroughEnabled 使我们能够覆盖可用于验证目的的信息(如发出请求的 IP 地址或 SSL 客户机证书),因此可以确保只有受信任的客户机或服务器才能连接到将 authPassthroughEnabled 设置为 TRUE 的 Application Server Enterprise Edition 8.2 实例。作为一项预防措施,建议仅将受公司防火墙保护的服务器的 authPassthroughEnabled 设置为 TRUE,而不要将可通过 Internet 访问的服务器的 authPassthroughEnabled 设置为 TRUE。
请注意,当代理 Web 服务器已配置了 service-passthrough 插件并且将请求转发到将 authPassthroughEnabled 设置为 TRUE 的 Application Server 8.1 Update 2 实例时,Web 服务器代理上可能启用了 SSL 客户机验证,而在代理的 Application Server 8.1 Update 2 实例上却禁用了该验证。在这种情况下,代理的 Application Server 8.1 Update 2 仍会将请求当作通过了 SSL 验证,并向部署在其上的发出请求的所有应用程序提供客户机 SSL 证书。
使用 --enabled=false 标志创建 httplistener 时,侦听器无法禁用。创建侦听器时使用标志 --enabled 不起任何作用。
在启用状态下创建侦听器,之后再手动禁用它。
在 Windows 上重新部署可在部署前创建用户的应用程序时,create-file-user 命令可能会因不执行 verify_file_user_exists_common (即使已调用它)而失败,并且无法通知用户已存在。此时会停止执行 deploy 目标,部署和取消部署会失败。
首先使用 keydel 目标删除文件用户,然后再次执行 deploy 目标:
asant keydel asant deploy |