1.执行config.sh文件时,找不到JDK的目录(修改JAVA_HOME),报错如下:
[weblogic@web1 bin]$ ./config.sh
./config.sh: line 103: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65.x86_64/bin/java: No such file or directory
解决方案:本质上.,JAVA_HOME变量赋值错误的问题,没有正确的赋予JDK的路径。
在config.sh中发现如下代码:
# set up common environment
. "${WL_HOME}/common/bin/commEnv.sh"
说明JAVA_HOME可能是在commEnv.sh中配置的,可以用which java命令获取正确的java并在commEnv.sh中修正:
[root@192 bin]# which java
/usr/bin/java
将config.sh中的
2.安全自检失败
错误提示如下:
**** Domain Creation Failed! java.lang.SecurityException: The provider self-integrity check failed. ****
解决方案:
可能是JDK版本与Weblogic的版本不兼容,本文Weblogic的版本是10.3.6,最好使用JDK6。
首先删除原有的所有openJDK,安装OracleJDK,可以执行如下命令查找当前存在的JDK版本
sudo rpm -qa | grep openjdk
版本是6u45,重新安装domain,并安装过程中指明JDK的路径(如果系统没有提供给你JDK的路径),需要自己寻找,一般来说位于如下的路径:
/usr/lib/jvm/
/usr/java/
本文所在位置如下:
3.服务启动,但无法访问控制台,一般来说是防火墙的问题,可以执行如下命令关闭防火墙并防止因为重启而重新开启:
以 root 用户身份登录到 CentOS 7 虚拟机。
执行以下命令以停止防火墙服务:
systemctl stop firewalld
执行以下命令以禁用防火墙服务,以确保在系统重新启动后防火墙不会自动启动:
systemctl disable firewalld
验证防火墙是否已成功停止。执行以下命令检查防火墙状态:
systemctl status firewalld
如果防火墙已成功停止,你将看到类似以下输出:
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
Active: inactive (dead)
如果状态显示为 inactive (dead),则表示防火墙已成功停止。
4.文件部署问题1,当把一个webApp的项目文件夹上传到weblogic时,使用下述命令打包war包:
jar -cvf yourapp.war *
当把该war包部署到weblogic并访问上下文路径时,出现如下错误:
From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:
10.4.4 403 Forbidden
The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
解决方法:不要用命令打包,而用IDE进行打包,具体操作博客:
idea如何打war包
打包后上传尝试部署。
5.文件部署问题2,当试图把一个webApp.war部署到weblogic时,出现如下图所示的错误:
后台显示的错误日志如下,即unmarshaller failed:
这很可能是web.xml文件的问题,后经查证,IDEA自动生成的xml文件的头文件不能被weblogic所使用:
将上述头文件修改为:
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
现在可以部署并运行了!
某些导致部署失败或者启动失败的问题
————————————————————————————————————————————
1.有中文名导致的部署失败,可能会出现以下的错误:
####<2023-9-1 下午04时39分51秒 CST> <Warning> <DeploymentService> <hxapptest2> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1693557591367> <BEA-290065> <Deployment service servlet encountered an Exception while handling the deployment datatransfer message for request id "1,693,557,419,554" from server "vhl_policy_server131". Exception is: "java.net.ProtocolException: Exceeded stated content-length of: '-1592243392' bytes
2.如果部署失败的话,去启动项目会报类似**No application files exist at …**的错误
unable to access application source information in '/opt/product/oracle/local/managedservers/mydomain/servers/serverA/stage/apputil/apputil.war'
for application 'apputil’.
The specific error is: [Deployer:149158] No application files
exist at '/opt/product/oracle/local/managedservers/mydomain/servers/serverA/stage/apputil/apputil.war'
此时要去查看日志,判断部署的过程中哪里出了问题导致部署失败。
3.如果是数据库账号权限的问题,可能找不到某些字段,可能会出现下述的问题:
Error creating bean with name 'connectionFactory' defined in ServletContext resource
[/WEB-INF/spring-rabbitmq.xml]: Initialization of bean failed; nested exception is
org.springframework.beans.TypeMismatchException: Failed to convert property value of
type [java.lang.String] to required type [int] for property 'port'; nested exception
is java.lang.NumberFormatException: For input string: "${spring.rabbitmq.port}"
也就是找不到spring.rabbitmq.port字段的值,而该字段的值可能存在某个数据库中,通过在后台代码中嵌入SQL语句查询得到。那么你配置的数据源中的用户名和密码很可能没有权限去访问该数据库,导致返回了空值,导致NumberFormatException。
解决方案:
1.查看数据源连接的数据库是否符合后台代码嵌入SQL的访问位置
2.查看当前配置数据源的用户名和密码是否有足够的权限去访问某张表,例如用户名为read的账户,无法对表table进行修改,只能通过select * from user.table来访问table,而用户名为user的账户,可以直接执行 select * from table。而后台代码嵌入的sql是:
select * from table
所以如果你把数据源的用户名和配置read,可能查询不到某些在数据库中配置的字段。
源可访问性
STAGE:管理服务器把所发布的文件从原始的位置(在管理服务器上)拷贝到目标服务器的staging目录上。例如,如果采用stage模式发布一个Java EE应用到集群的三个服务器上,这个管理服务器会在集群中的每一个服务器上都拷贝一份。每一个服务器使用拷贝过来的本地的文件来发布Java EE应用。
NO_STAGE:不复制文件到节点服务器,不在weblgoic的部署目录下面生成staging目录,管理服务器(Administration Server)并不拷贝所发布文件,相反,每一个目标服务器必须通过一个单一源文件夹来访问这个文件并进行发布。目标服务器(target servers)上的stage目录在nostage模式下会被忽略。
例如,如果你发布了一个Java EE应用程序到集群中的三个服务器,那么每一个服务器必须能够访问相同的应用程序文件(从一个共享的网络目录)去发布程序。
EXTERNAL_STAGE:这个模式无法在控制台中使用,与STAGE相似,目标服务器使用本地的拷贝来发布应用。然而,管理服务器并不自动的拷贝所发布的文件到目标服务器;相反,在发布之前,你必须拷贝这些文件到每一个目标服务器的staging目录。你可以手工的执行拷贝或者用自动化脚本。