本章介绍 Sun Java System Application Server 9.1 软件的已知问题和相应的解决方法。如果汇总说明未指明特定平台,则所有平台都可能出现此问题。本部分信息按以下内容进行组织:
本节介绍已知的管理问题和相应的解决方法。
默认情况下,在 $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 不存在,则每次创建新域时,都必须执行此操作。
无法使用 backup-domain 和 restore-domain 命令镜像同一 Application Server 安装上的域,这是由于使用不同于原始名称的其他名称不能恢复域,即使 asadmin restore-domain 命令提供了重命名域的选项。重命名备份域似乎已成功,但尝试启动重命名的域却会失败,因为没有更改域配置中的条目,并且 startserv 和 stopserv 仍然使用原始域名来设置路径。
用于 restore-domain 的域名必须与用于原始 backup-domain 命令的域名相同。Application Server 8.1 中的 backup-domain 和 restore-domain 命令仅用于在同一台计算机上备份和恢复同一个域。
J2SE 1.4.x, 5.0 或更高版本可以在 Application Server 上进行配置。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 虚拟机中启动新的 jmx-connector 服务器。此过程的副作用是会对管理功能造成不利影响,并且 Application Server 管理控制台和命令行界面可能会产生异常结果。出现此问题的原因在于内置 jmx-connector 服务器与新的 jmx-connector 服务器之间存在一些冲突。
如果使用 jconsole(或任何其他 JMX 兼容客户机),请考虑重新使用标准的 JMX Connector Server,它在 Application Server 启动时启动。
当服务器启动时,server.log 中将显示类似于以下所示的内容。您可以连接到其中指定的 JMXService URL,并在成功提供证书后执行相同的管理/配置操作,例如:
[#|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 9.1 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 的值。
将现有的 <as_install>/bin/asant 脚本重命名为 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 脚本。
Application Server 文档中未介绍 .asadmintruststore 文件。如果服务器管理员的主目录中不包含此文件,在升级该服务器上的某些应用程序时可能会出现严重错误。
如果可能,应该由安装服务器的用户运行 asadmin start-domain domain1 命令。
如果不是由该用户运行的,应将 .asadmintruststore 从安装用户的主目录移动或复制到运行用户的主目录中。
请注意,如果将该文件从安装用户的主目录移动(而非复制)到运行用户的主目录,可能会出现错误 6309079、6310428 和 6312869 所述的应用程序升级问题,原因是升级/安装用户(通常是 Java ES 中的超级用户)的主目录中不再具有 .asadminstruststore 文件。
Application Server 群集实例的默认 MQ 集成模式为 LOCAL。如果将 Application Server 安装在长(即 "not short")位置 (PATH) 上,当群集实例启动时,imqbrokerscv.exe 会崩溃。此问题是 imqbrokersvc 中的内存分配问题。
必须将群集实例的 JMS 服务类型从默认的 LOCAL 更改为 REMOTE。在此配置中,所有实例都指回 DAS 代理。请遵照下面的说明,以 REMOTE 模式配置群集。
使用 REMOTE 模式时,所有实例都使用一个代理 (DAS),因此当 Application Server 群集启动时,不会创建任何代理群集。有关更多信息,请参见 http://www.glassfishwiki.org/gfwiki/attach/OnePagersOrFunctionalSpecs/as-mq-integration-gfv2.txt 这一页上的第 4.1 条,第 iii 部分中的 "Auto-clustering"。上述功能将不可用!
根据您的环境修改端口和密码文件。请注意,在以下说明中,群集名称为 racluster,DAS 管理端口为 5858,DAS JMS 端口为 7676。
修改群集配置,将 JMS 类型更改为 REMOTE。
$AS91_HOME/bin/asadmin.bat set --port 5858 --user admin --passwordfile \ $AS91_HOME/bin/password_file racluster.jms-service.type=REMOTE |
创建对应于 DAS JMS 主机的 JMS 主机。
$AS91_HOME/bin/asadmin.bat create-jms-host --port 5858 --user admin --passwordfile \ $AS91_HOME/bin/password_file --target racluster --mqhost localhost --mqport 7676 \ --mquser admin --mqpassword admin dashost |
将默认的 JMS 主机设置为在上一步骤中创建的 DAS JMS 主机。
$AS91_HOME/bin/asadmin.bat set --port 5858 --user admin --passwordfile \ $AS91_HOME/bin/password_file racluster.jms-service.default-jms-host=dashost |
转至“配置”-> "cluster_name-config" ->“Java 消息服务”->“JMS 主机”。
单击“新建”以创建新的 JMS 主机,将其命名为 dashost。
输入对应于 DAS JMS 服务的配置设置,默认设置如下所示:
主机名:localhost
端口:7676
管理员用户:admin
密码:admin
根据您的 DAS JMS 服务修改这些设置。
导航回“Java 消息服务”选项卡,并将 JMS 服务类型更改为 REMOTE(默认为 LOCAL)。
从 "default-jms-host" 下拉式列表中,选择 "dashost"。
保存更改,然后启动节点代理或群集。
当尝试使用某些不支持的浏览器显示“日志统计信息监视”页中的图表时,可能会抛出以下错误:
Error loading jmaki.widgets.jmaki.charting.line.Widget : id=form1:jmaki_chart11 Script: http://easqelx5.red.iplanet.com:4848/resources/jmaki/charting/ \ line/component.js (line:5437). Message: area.initialize is not a function |
使用支持的浏览器。有关 Application Server 9.1 支持的浏览器的列表,请参阅浏览器。
默认管理端口已在过去三个主要 Application Server 发行版中都有所不同。具体而言,7.x、8.x 和 9.x 中的默认管理端口如下所示:
AS 7.x:4848
AS 8.x:4849
AS 9.x:4848
这不是错误,但是一个需要注意的事项。默认管理端口只是一个建议端口。希望在以后的 Application Server 版本中将保留默认 4848 端口。
本节介绍 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 文件中。
本节介绍已知的应用程序客户机问题和相应的解决方法。
如果在您的客户机 JAR 中具有顶层 JAR 文件(在此情况下,为 reporter.jar),则当您部署客户机 JAR 时,该 JAR 的 MANIFEST 文件将覆盖客户机 JAR 的 MANIFEST 文件。
目前尚无解决方法。
应用程序客户机始终尝试连接到 localhost:3700。问题在于在调用客户机代码之前,需要读取多个系统属性。
将以下各项设置为系统属性(JAVA_CMD 中的 -D)。请勿在应用程序客户机代码中设置它们:
org.omg.CORBA.ORBInitialHost = server_instance_host org.omg.CORBA.ORBInitialPort = server_instance_port |
如果在 64 位 Linux 上运行,则启动域时,会出现以下异常。问题在于 jdk1.5.0_11/jre/lib/ext/ 下缺少 sunpkcs11.jar。
这是 64 位 Linux 中的已知 JDK 错误,将在 JDK 1.5.0_13 中得以修正。
在多个选择器上注册 SocketChannel 时,执行 socketChannel.keyFor(lastRegisteredSelector) 会返回 null 而不是 SelectionKey。
此问题与 JDK 错误 (6562829) 相关,希望在 6.0 U3 中得以修正。Application Server 9.1 中已包括解决方法,因此,在调用 keyFor API 之前打开选择器。这样可使 keyFor 继续作用,直至 JDK 错误得以修正。
本节介绍已知的捆绑的 Sun JDBC 驱动程序问题和相应的解决方法。
如果应用程序在一个事务中生成 3000 个以上 PreparedStatement 对象,DB2 可能会发生以下错误:
[sunm][DB2 JDBC 驱动程序] 无更多可用语句。请重新创建具有较大 dynamicSections 值的软件包。
将以下属性添加到连接池定义中,以使驱动程序可以重新绑定具有较大动态段值的 DB2 软件包:
createDefaultPackage=true replacePackage=true dynamicSections=1000
有关配置连接池的详细信息,请参见《Sun Java System Application Server 9.1 Administration Guide》。
可能抛出的与上述 PrepardStatement 错误相关的另一条错误消息为:
[sunm][DB2 JDBC 驱动程序][DB2] 虚拟存储或数据库资源不可用。
增大 DB2 服务器的配置参数 APPLHEAPSZ。最佳值为 4096。
隔离级别为 TRANSACTION_SERIALIZABLE。如果应用程序使用隔离级别 TRANSACTION_SERIALIZABLE 并使用上面建议的某个参数,该应用程序可能会在获取连接时挂起。
要为连接设置所需的隔离级别,必须以同一隔离级别创建相应的连接池。有关说明,请参见《Sun Java System Application Server 9.1 Administration Guide》。
重新引导主机系统或 Solaris 区域或者启动 Application Server 之后,捆绑的 Java DB 数据库无法自动重新启动。这不是错误,而是任何捆绑的应用程序或第三方应用程序的预期行为。问题在于必须在 Application Server 实例之前启动 Java DB。
重新引导主机或 Solaris 区域之后,请务必在启动 Application Server 之前启动 Java DB,例如:
/opt/SUNWappserver/appserver/bin/asadmin start-database |
有关 asadmin 命令选项的更多信息,请参阅《Sun Java System Application Server 9.1 Quick Start Guide》中的“Application Server Administration Tools”。
本节介绍已知的文档问题和相应的解决方法。
缺少多个 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。
Id:
6615557
摘要:
本地化联机帮助的“内容”选项卡下丢失 3 页
说明:
本地化联机帮助丢失“内容”选项卡下的以下 3 个已本地化页面:
- 资源 -> JavaMail Session -> 管理 JavaMail Session 目标
- 资源 -> 连接器 -> 编辑连接池属性
- 连接器 -> 编辑连接持属性 -> 管理安全映射
解决方法:
请使用这些页面的英文版联机帮助。
本节介绍已知的高可用性数据库 (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 的值至少为每个主机的节点数的六倍。
使用 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) 在所有参与的主机上都相同。
在具有多个网络接口的主机上运行管理代理时,如果所有网络接口不是在同一子网中,则 createdomain 命令可能会失败:
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 标识)中的所有文件和目录。必须先在所有主机上执行此操作,然后才能用新配置文件重新启动代理。
在 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:必须提供密码才能连接到管理代理”。
有时,服务器上的资源争用问题可能会导致管理客户机断开连接。在重新连接时,可能会返回误导性的错误消息“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。
路径为 "/" 的 Cookie 与在 "/" 以外的上下文根目录中部署的高度可用 Web 应用程序(使用内存复制作为其持久性类型)的 Cookie 发生冲突,从而使高度可用的 Web 应用程序无法维护任何 HTTP 会话状态。通常,当使用同一浏览器访问管理 GUI(部署在 "/" 中)和高度可用的 Web 应用程序时,可能会出现这种情况。
通过其他浏览器访问部署在 "/" 中的 Web 应用程序。
负载平衡器使用 Windows IIS 6 时需要 SASL32.DLL 和 ZLIB.DLL 文件。当前在 <appsrver-install>/lib 下没有这些文件。
将这两个 DLL 文件手动复制到 <appserver-install>/lib 中。可以从以下网址下载这些文件:
http://download.java.net/javaee5/external/<OS>/aslb/jars/aslb-9.1-MS4-b5.jar |
其中 <OS> 表示所需的平台,可以是以下值之一:
SunOS
SunOS_X86
Linux
WINNT
在全局区域中安装或卸载具有高可用性软件包的 Application Server 时,会出现两个问题:
在所有区域中都安装 HA 软件包,这可能不是所希望的。
卸载时,将从所有区域中删除 HA、MQ、JDK 软件包,这可能不是所希望的。
从局部根区域中安装或卸载时,不会出现此问题。
从局部根区域而不是全局区域执行安装和卸载。
当使用内存复制作为其持久性类型时,部署在 "/" 中的高度可用的 Web 应用程序无法维护任何 HTTP 会话。
将使用内存复制作为其持久性类型的高度可用的 Web 应用程序部署到 "/" 以外的上下文根目录中。如果要使此类 Web 应用程序位于 "/" 中,可以将其指定为 Web 应用程序已部署到的虚拟服务器的默认 Web 模块。
在 Solaris 上针对 Apache 安装 Application Server 负载平衡器期间,安装程序将更新 apachectl 脚本中的 LD_LIBRARY_PATH。但是,安装程序未正确写入 /usr/lib/mps 路径。在 Solaris 上,如果 LD_LIBRARY_PATH 中没有此路径,则 Apache 安全性实例将无法启动。
只有 Solaris 平台存在此问题。要解决此问题,请将 /opt/SUNWappserver/appserver/lib/lbplugin/lib 添加到 LD_LIBRARY_PATH。
无论 domain.xml 中保存了哪些内容,在“群集/实例”常规页上,“启用负载平衡”按钮都始终处于启用状态。
对于群集实例,请选择“实例”选项卡,然后在下拉菜单中单击“停止”操作。
对于独立实例,请确保实例正在运行,然后在实例的“常规”屏幕上单击“停止”按钮。
(仅 Solaris)在具有 HADB 的 SPARC Solaris 10 上安装 Application Server 9.1 之后,启动 Application Server 并尝试安装具有 Registry Server 的 JES 5 UR1 时,可能会出现以下错误:
Dependency Error: Installation can not proceed because the version of HA Session Store 4.4.3 detected on this host is incomplete , and a compatible version is required by Servervice Registry Deployment Support. |
在 Solaris 计算机上,不能使用 Application Server 9.1 IFR 从 JES 5 UR1 安装 Registry Server。必须使用 pkgadd 命令从以下 JES5 UR1 分发目录手动安装 Registry Server 软件包:
<path>/<OS>/Products/registry-svr/Packages |
(仅 Internet Explorer 6)当尝试从 Internet Explorer 6 导出负载平衡器配置文件 (loadbalancer.xml) 时,浏览器会显示错误消息,表示找不到 sun-loadbalancer_1_2.dtd DTD 文件。
要保存此文件,请使用以下解决方法:
在 Internet Explorer 中,在“负载平衡器”页上单击“导出”。
将显示“XML page cannot be displayed”消息。
单击错误框,然后从 Internet Explorer 中选择“文件”->“另存为”。
将 loadbalancer.xml 文件保存到所选目录中。
本节介绍已知的安装问题和相应的解决方法。
已在多种 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 |
在 Windows Vista 上安装捆绑的 SDK 时,可能会遇到错误“Unsupported Installation Platform Detected”。但是,安装却成功而没有出现任何问题。
这实际上并不是问题。Application Server 在 Windows Vista 上运行,此错误消息将在以后的产品版本中删除。
如果 Application Server productregistry 文件包含共享组件配置,则 Application Server 卸载过程无法正确更新 productregistry 文件,您将无法在后续安装中使用无提示模式,除非重命名或删除 productregistry 文件。按照设计,productregistry 文件中的共享组件条目保持不变,但是会导致与后续无提示安装发生混淆。
通过卸载日志文件报告卸载成功之后,先删除 productregistry 文件,然后再运行后续安装。要检验先前的卸载是否已成功完成,请在 <install_dir> 中查找 appserv_uninstall.class 文件。如果卸载成功,此文件将不会存在。
如果卸载失败,请勿删除 productregistry。
在 Solaris 上,productregistry 文件位于 /var/sadm/install 中;在 Linux 上,位于 /var/tmp 中。
在稀疏局部区域中安装 Application Server 时,如果未先安装 Message Queue (MQ),安装便会失败。安装程序尝试安装 MQ,随后整个安装失败。
在稀疏局部区域中安装 Application Server 之前,必须在全局区域中手动安装 MQ。此问题有两种解决方法:
通过包含 Application Server 9.1 IFR 安装的媒体,在全局区域中手动安装 MQ 4.1,以获得最新的 MQ 软件包。
使用与您的平台相对应的安装程序:
mq4_1-installer-SunOS.zip mq4_1-installer-SunOS_X86.zip mq4_1-installer-Linux_X86.zip mq4_1-installer-WINNT.zip |
解压缩位并运行安装程序。
安装程序将位于 mq4_1-installer 目录中。
在全局区域中安装任何 IFR 安装组件。此操作将检查 GZ 中的 MQ 版本,确定是否需要将其升级到 Application Server9.1 IFR 中捆绑的版本。均等选择并安装样例应用程序组件将 MQ 升级到 IFR 版本。
在全局区域中运行 Application Server 安装,但是仅选择样例组件。
样例组件安装也会在所有区域中安装 MQ 和 Application Server 共享组件。
再次运行 Application Server 安装,这次是在局部稀疏区域中。
安装应该顺利完成,不出现任何问题。
使用 —console 选项(命令行模式)运行 Application Server 9.1 IFR 安装程序时,系统会对您进行以下提示:
Do you want to upgrade from previous Application Server version? |
遗憾的是,IFR 安装程序不支持此升级,因此该提示是错误的。如果您对该提示回答是“是”,则安装将正常进行,但是不会出现表明已执行完整安装而不是升级的指示。
如果要升级 Application Server 安装,请使用升级工具。
要运行有关 Sun Java System Application Server 9.1 的《Java EE Tutorial》,请执行以下任务:
按照“关于本教程”一章的“关于示例”一节中的描述编辑文件示例 /common/build.properties 时,还要将端口 4848 更改为 4849。
Application Server 9.1 中的默认管理端口也是 4848。有关更多信息,请参见默认端口在每个 AS 主要发行版中都有所不同 (6566481)。
使用 Deploytool 时,在部署示例之前添加服务器 localhost:4849。
使用管理控制台创建资源时,使用“目标”选项卡将服务器指定为目标。如果使用命令行或 asant 目标,则该服务器为默认目标,无需其他操作。
在《The Java EE 5 Tutorial》中的第 32 章 “Java EE Examples Using the JMS API”,《The Java EE 5 Tutorial》中的“An Application Example That Consumes Messages from a Remote Server”,此示例不再起作用。MDB 无法接收消息。在两个系统之间发送消息的其他两个示例仍正确运行(《The Java EE 5 Tutorial》中的“Running JMS Client Programs on Multiple Systems”和《The Java EE 5 Tutorial》中的“An Application Example That Deploys a Message-Driven Bean on Two Servers”)。
将在以后的 Application Server 内部版本中得以修复。
如果 java.util.Arrays.asList() API 用于将 Object[] 转换为 Collection,则 JDK 将返回不可复制的 java.util.ArrayList 的实现。这将导致以下异常:
The method invocation of the method [protected native java.lang.Object java.lang.Object.clone() throws java.lang.CloneNotSupportedException] on the object [[pkg.A id = xxx]], of class [class java.util.Arrays$ArrayList], triggered an exception. Internal Exception: java.lang.reflect.InvocationTargetException Target Invocation Exception: java.lang.CloneNotSupportedException: java.util.Arrays$ArrayList |
将在 https://glassfish.dev.java.net/issues/show_bug.cgi?id=556 中跟踪此问题。
使用其构造函数创建其他集合,例如:
myCollection = new ArrayList(java.util.Arrays.asList(a)) |
本节介绍已知的生命周期管理问题和相应的解决方法。
将 ejb-timer-service 属性 minimum-delivery-interval 设置为 9000 之后,尝试将 ejb-timer-service 属性 redelivery-interval-in-mills 设置为 7000 会导致 set 命令失败,并出现以下错误:
[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 |
使用其他的值将导致产生错误。
如果要尝试使用 default-config 查看 JMS 物理目的地,将会出现错误消息。
这是预期行为。在 Application Server 9.1 中,default-config 是配置信息的模板,因此,无法针对 default-config 执行 JMS 操作(例如 list 和 create)。但是,可以针对群集或独立实例的配置执行这些 JMS 操作。
(仅 Windows 2003)在 Windows 2003 系统上,当执行丰富访问功能时,会出现内存泄漏。出现此问题是因为 Win32 非分页池不断增长,最终破坏整个 TCP/IP 栈。出现故障后,TCP/IP 栈将保持可恢复状态,并且仅可通过重新引导 Windows 2003 系统对其进行恢复。
这是 Microsoft 问题(问题编号:SRX070906600011),已具有可用于此问题的修补程序。有关更多信息,请与 Microsoft 支持联系。
除了上述的修补程序之外,此问题还有两种解决方法。
通过配置 domain.xml http-listener 属性 blocking-enabled="true" 使用 Grizzly 阻塞模式,或者添加以下 http-listener 属性:
<property name="blocking" value="true"/> |
使用 Windows Vista 或 Windows XP。
本节介绍已知的日志记录问题和相应的解决方法。
为 JVM 设置 java.security.debug 选项会导致服务器实例的启动停止并死锁;例如,在 domain.xml 中进行以下设置将导致出现此问题:
<jvm-options>-Djava.security.debug=access,failure</jvm-options> |
目前尚无解决方法。请避免设置此标志。
本节介绍已知的 Java Message Queue 问题和相应的解决方法。
多种问题均可导致在与时间相关的情况下重新连接失败。
可以通过以下方法解决这些问题:
重新启动相关的代理
重新启动相关的 Application Server 实例
在 Linux 系统上,创建具有群集配置文件的域之后,可能会遇到 java.lang.OutOfMemoryError: heap space 错误,并且服务器实例可能会因为 MQ 代理未启动而无法重新启动。出现此情况之后,系统便永不会恢复。问题在于 /etc/hosts 文件配置错误;具体而言,服务器主机名称正在指向回送地址 127.0.0.1。
按照设计,MQ 代理群集无法在网络设备配置为指向回送地址的情况下启动。这不是错误。解决方法是确保 Application Server 主机的 /etc/hosts 文件不指向 127.0.0.1。
本节介绍已知的监视问题和相应的解决方法。
查看 HTTP 服务的某些元素的监视统计信息时,显示的某些值与当前值并不对应或始终为 0。特别是,以下 HTTP 服务统计信息并不提供适用于 Application Server 的信息,应该被忽略:
http-service
load1MinuteAverage
load5MinuteAverage
load15MinuteAverage
rateBytesTransmitted
rateBytesReceived
pwc-thread-pool(元素)
在以后的版本中,将删除这些监视器并将其替换为更适当的信息。
从管理 GUI 打开 JNDI 浏览器时,会抛出许多异常。
目前尚无解决方法。
本节介绍与 Application Server 9.1 产品附带的样例代码相关的已知问题和相应的解决方法。
文档没有明确说明在执行 asadmin 部署指令之后,需要在运行 MQ 故障转移样例应用程序之前创建 JMS 资源。
抛出的错误如下:
/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 |
在 Windows 上,升级到 Application Server 9.1 之后,样例和 JES5 Portal 样例将争用 Derby 端口 1527。具体而言,Application Server 9.1 将自动在具有 APP:APP 的端口 0.0.0.0:1527 上启动 JavaDB,但是 JES5 Portal JavaDB 要绑定到具有 portal:portal 的 hostnameIP:1527。
此错误所描述的问题已在 JES 5 错误 6472173 中出现。错误 6472173 的解决方法在《Sun Java Enterprise System 5 Installation Guide for Microsoft Windows》有所记录。
使用以下命令启动 Derby 数据库:
<JES installation dir>\appserver\bin\asadmin start-database --dbhome <JES installation dir>\portal\data\derby |
本节介绍与 Application Server 及 Web 应用程序安全性和证书相关的已知问题和相应的解决方法。
SSL 终止不起作用;如果为 SSL 终止配置了负载平衡器(硬件),则 Application Server 会在重定向过程中将协议从 https 更改为 http。
在硬件负载平衡器与 Application Server 之间添加软件负载平衡器。
由于 JVM 错误,在 HTTP 侦听器上将 security-enabled 设置为 true 时,某些 JDK 版本会出现泄漏问题。具体而言,产生此错误的步骤如下:
在 HTTP 侦听器上,将 security-enabled 设置为 true:
<http-listener acceptor-threads="1" address="0.0.0.0" blocking-enabled="false" default-virtual-server="server" enabled="true" family="inet" id=" http-listener-1" port="8080" security-enabled="true" server-name="" xpowered-by="true"> |
对在快速查找测试结束时停止域做出注释。
运行快速查找测试。
检查套接字使用情况:
netstat -an | grep 8080 |
以下显示的是处于使用状态的内容:
*.8080 *.* 0 0 49152 0 LISTEN *.8080 *.* 0 0 49152 0 BOUND |
此问题在 Glassfish 站点 https://glassfish.dev.java.net/issues/show_bug.cgi?id=849 上也有记录。
升级到最新的 JDK 版本。
本节介绍已知的升级实用程序问题和相应的解决方法。
从 Application Server Enterprise Edition 8 升级到 Application Server Enterprise Edition 8.1 时,不会直接升级在自定义路径而非 install_dir/domains 目录中创建的域。
如果运行升级实用程序并将 install_dir 标识为源安装目录,升级进程只升级在 install_dir/domains 目录下创建的域。在其他位置创建的域不会被升级。
启动升级进程前,将所有域目录从不同位置复制到 install_dir/domains 目录中。
此问题已在多个 Linux 系统上出现,是 Java Desktop System 2 最常见的问题,而且在 Red Hat 分发中也发现了此问题。
在最终安装程序屏幕上单击“启动升级工具”按钮后,安装程序无法启动升级工具以完成升级过程,并且无限期挂起,而不会返回命令提示符。
如果使用命令行安装模式来运行就地升级,将不会遇到此问题。
如果您以 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-ee/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>
升级工具将覆盖所有服务器实例的任何现有的 index.html 文件。
在运行升级工具之前,备份现有的 index.html 文件,稍后恢复这些文件。
从 Application Server 8.0PE 升级到 9.1 时,会抛出错误,说明服务器没有名为 null 的系统连接器,并且出现 sbs-manual 中所示的无效用户信息。即使在更改硬编码值之后,也会出现相同的错误消息。出现这种情况是因为 8.0 中的 domain.xml 在 9.1 中已更改。
仅在从 8.0 PE 升级到 9.1 时才会遇到此错误。解决方法是先升级到 8.1、8.2 或 9.0,然后升级到 9.1。
执行就地升级时,如果源中有多个域,则即使升级过程被中止,安装程序也会调用升级工具。以 GUI 模式进行调用时,便会出现这种情况。
以 CLI 模式进行就地安装,当安装过程结束时,在安装程序提示您选择升级工具时退出。这不会删除域目录中的任何域。应该从 bin 目录手动调用升级工具。
以 GUI 模式进行就地安装时,对域根目录中的域进行备份,以免在安装过程中丢失任何域。当安装过程结束时,在安装程序提示您调用升级工具时退出。如果域已经丢失,请将所有备份域复制到域目录。手动启动升级工具以执行升级。
从 AS 8.2 升级到 9.1 时,9.1 安装中不会继承 8.2 安装中的主密码。这随后会导致在下次管理登录时出现验证错误。
Application Server 9.1 中的默认管理密码为 changeit。从 8.2 升级之后,要在登录到 9.1 服务器时避免出现问题,请执行以下三种操作之一:
在执行升级之前,将 8.2 管理密码更改为 changeit。
在升级过程中,请勿接受默认管理密码,而是明确输入要使用的密码。
使用默认密码登录到 9.1,然后立即更改此密码。
升级工具无法升级数据库或任何形式数据库表,以后也不会支持此类升级。将传输资源引用配置,Application Server 应该继续使用原始数据库和表。如果要更改数据库或传输数据库表,请使用可用于使用中的数据库的工具。
执行以下步骤以迁移 MQ 存储:
请在关闭 AS 8.2 及运行 AS9.1 升级工具之后,首次启动 AS9.1 之前执行以下步骤。如果已在 IFR 安装/升级之后启动了 AS 9.1,请勿执行这些步骤,因为它们可能会破坏 MQ 消息存储的稳定性。
将整个 domains/domain1/imq 子目录从 AS 8.x domains 目录复制到 AS 9.1 domains 目录。
确保目录和文件归要运行 Application Server 的用户所有。
执行上述步骤之后,便可启动 Application Server 9.1,并且 Application Server 9.1. domains 目录中的 MQ 存储将从其 JES5 U1 格式迁移到 MQ 4.1 格式。请注意,执行此过程或者在 AS 9.1 启动 MQ4.1 时,将保留 AS 8.2 下的原始 JES5 U1 MQ 存储,不对其进行修改。
从 JES5 (Application Server 8.2) 升级到 Application Server 9.1 时,Portal Server Community 样例不再起作用,并且会抛出许多 javax.faces.application.ApplicationFactory 错误。
如果使用 JES5 Portal Server 安装 Application Server 8.2,则不支持从 Application Server 8.2 升级到 9.1。在 Application Server 升级到 9.1 之前,需要将 Portal Server 升级到 Java ES 5 Update 1。
在 Linux 平台上,使用 IFR 安装程序从 Application Server 8.2 升级到 9.1 时,如果选择“安装 JDK”选项,则在成功完成安装之后,大多数 JES 组件停止运行。
此问题仅影响在 Linux 平台上进行的 Application Server 9.1 IFR 安装,并且仅当选择“安装 JDK”选项时才会产生影响。要解决此问题,请在安装之后,立即将 /usr/jdk/entsys-j2se 手动链接到 /usr/java/jdk1.5.0_12 目录。
在 Windows 上执行 Application Server 9.1 IFR 升级时,就地备份未正确与 asupdate.bat 窗体值集成。具体而言,如果在 ASupdate.bat GUI 屏幕中输入错误的信息,然后单击“下一步”,则升级安装程序将尝试检测它是否为就地升级。如果是,则在升级之前,会将 domain1 移至备份目录。继续升级时,由于信息不正确,会显示错误消息。当您尝试立即更正此错误时,会抛出路径错误,因为 domain1 已被移动。
将源目录更改为 {current source path}/backup 中的 domain1_ {timestamp} 目录,或者使用“取消”按钮退出安装程序并再次启动。
(仅 Windows)如果在程序目录路径中使用特殊字符或 DOS 样式的短名称安装了早期版本的 Application Server,则在以后仍使用这些目录路径名称就地升级到 Application Server 9.1 时,会导致升级失败。
例如,如果将 Application Server 8.2 安装在以下目录中:
C:\Program Files (x86)\dirs\appserver c:\progra~2\dirs\appserver |
尝试执行就地升级到 9.1 将失败,因为安装程序无法将短名称或特殊字符转换为所需的长名称格式。
安装 Application Server 时,强烈建议路径名称不要包含特殊字符或 DOS 样式的短名称截断(例如 progra~2),因为它会妨碍后续的升级安装。如果存在这样的安装,请在升级之前使用长路径名称重新安装,或者在全新的目录中安装新版本的 Application Server。
升级 Application Server 之后,<jsp:forward> 标记在 Authenticate.jsp 中未按预期那样发挥作用。<jsp:forward> 调用在服务器日志中生成一个错误,并在 WebUI 中显示空白页。问题在于 Authenticate.jsp 中的 <jsp:forward> 需要 <jsp:forward page="${redirectPage}"/> 之类的页面属性,但是,正在被传送的值却是相对路径(例如 /registry/thin/{pagename}.jsp),即使 Authenticate.jsp 是纯 JSP 页,此类路径也无效。
完成 Application Server 升级之后,请使用 asadmin 工具运行以下命令,以在 domain.xml 中设置 <auth-realm>:
转至 <appserver9.1-install-dir>/bin 并运行以下命令:
./asadmin delete-auth-realm --host localhost --port 6489 certificate |
这将删除旧的 auth-realm 证书(如果存在)。
运行以下命令:
./asadmin create-auth-realm --terse=false --echo=true --interactive=true \ --user admin --host localhost --port 6489 --classname \ com.sun.enterprise.security.auth.realm.certificate.CertificateRealm \ --property assign-groups=have.client.cert certificate |
这将创建具有 assign-groups 属性的新的 <auth-realm>。
停止并重新启动 Application Server registry 域。
在非英语语言中运行 asupgrade GUI 时,没有针对所选的非英语语言对 GUI 联机帮助进行本土化。
目前尚无解决方法。已计划使用所有非英语目标语言对联机帮助进行本地化。
本节介绍已知的 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 会无法通过依照 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 9.1 添加了对 Sun Java System Application Server Enterprise Edition 7.1 中可用的 auth-passthrough 插件功能所提供的功能的支持。但是,在 Application Server 9.1 中,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 中,可以在代理 Application Server 实例上配置 auth-passthrough 插件功能,以使该实例上所部署的所有应用程序可以直接获得远程客户机的信息,就像代理 Application Server 实例直接收到请求那样,而不是通过运行 service-passthrough 插件的中间 Web 服务器接收。
在 Application Server 9.1 中,可以通过将 domain.xml 中 <http-service> 元素的 authPassthroughEnabled 属性设置为 TRUE,来启用 auth-passthrough 功能,如下所示:
<property name="authPassthroughEnabled" value="true"/> |
Application Server Enterprise Edition 7.1 中 auth-passthrough 插件功能的安全性注意事项同样也适用于 Application Server 9.1 中的 authPassthroughEnabled 属性。由于 authPassthroughEnabled 使得能够覆盖可用于进行验证的信息(例如发出请求的 IP 地址或 SSL 客户机证书),因此,仅允许信任的客户机或服务器连接到 authPassthroughEnabled 设置为 TRUE 的 Application Server 9.1 实例是非常重要的。作为一项预防措施,建议仅将公司防火墙之后的服务器的 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 证书。
只有在 Linux 系统上将 Sun Java System Web Server 与 Application Server 9.1 和负载平衡器一起使用时才会出现此问题。在此情况下,安装 Application Server 和负载平衡器之后,Web Server 可能无法启动,因为 libicui18n.so.2 和 libicuuc.so.2 发生冲突。这些库同时位于 /opt/sun/private/lib 和 /opt/sun/appserver/lib 中。
要使用的正确的库只能位于 /opt/sun/appserver/lib 中,因为 lbplugin 根据这些库生成。一旦从 /opt/sun/private/lib 中删除这两个库,Web Server 便应该能够顺利启动,不会出现任何错误。
或者,如果不希望从 /opt/sun/private/lib 中删除这些库,可以在 Web Server startserv 脚本的 LD_LIBRARY_PATH 中,将 /opt/sun/appserver/lib 放在 /opt/sun/private/lib 之前;也就是将:
# Add instance-specific information to LD_LIBRARY_PATH for Solaris and Linux LD_LIBRARY_PATH="${SERVER_LIB_PATH}:${SERVER_JVM_LIBPATH}:${LD_LIBRARY_PATH}: /opt/sun/appserver/lib:/opt/sun/appserver/lbplugin/lib"; export LD_LIBRARY_PATH |
替换为:
# Add instance-specific information to LD_LIBRARY_PATH for Solaris and Linux LD_LIBRARY_PATH="/opt/sun/appserver/lib:/opt/sun/appserver/lbplugin/lib: ${SERVER_LIB_PATH}:${SERVER_JVM_LIBPATH}:${LD_LIBRARY_PATH}"; export LD_LIBRARY_PATH |
本节介绍已知的 Web 容器问题和相应的解决办法。
当使用 Java EE SDK b33d 附带的 JDK 1.6 运行 JAX—WS 测试时,可能会遇到问题。测试将立即中止,并出现以下消息:
[wsimport] Exception in thread "main" java.lang.NoClassDefFoundError: \ com/sun/tools/ws/WsImport |
即使 webservices-tools.jar 不包含 com/sun/tools/ws/WsImport.class、com/sun/tools/ws/ant/WsImport.class 和 com/sun/tools/ws/ant/WsImport2.class,也会发生此错误。而且,同一个测试工作区可以使用 1.5.0-10 JDK 运行,而不会出现任何问题。
在运行 JAX-WS 测试之前,将 webservices-api.jar 复制到 $JAVA_HOME/jre/lib/endorsed。
JAXR 使用 SAAJ 将 SOAP 消息发送到注册表。在非 IFR 的情况下,SAAJ impl 类位于 lib/webservices-rt.jar 下。在 IFR 的情况下,SAAJ 类仍位于 lib/webservices-rt.jar 下。此外,saaj-impl.jar 位于 /usr/share/lib 目录中。此 jar 文件由 Application Server 拾取,并且其优先级高于 webservices-rt.jar 中的类。此 jar 文件不具有将 SOAP 消息发送到 Web 服务注册表所需的必要安全权限。此打包应该修改为向 /usr/share/lib 目录下的 jar 授予权限,或者与 /usr/share/lib jar 无关。
将以下内容添加到 server.policy 文件:
grant codeBase "file:/usr/share/lib/saaj-impl.jar" { permission java.security.AllPermission; }; |