背景

weblogic admin server端口号7001,在启动的时候,能启动成功,但是无法访问,错误日志里有Address already in use的错误信息,这个错误信息的意思是7001端口号被占用。

你需要了解的

网卡

服务器可能有多张网卡,并且有一张默认的网卡,叫做回环网卡,名称默认一般是lo,ip地址为127.0.0.1,这个网卡不是一个硬件设备而是由软件实现,所有发送到该网卡的数据能够立即被接收,提高本地应用程序通信效率,所以如果你在一台服务器上既部署了你的应用程序也部署了数据库,那么用localhost或者127.0.0.1作为连接地址是最快的。

Read the rest of this entry

spring boot介绍

Spring Boot目前流行的java web应用开发框架,相比传统的spring开发,spring boot极大简化了配置,并且遵守约定优于配置的原则即使0配置也能正常运行,这在spring中是难以想象的。spring boot应用程序可以独立运行,框架内嵌web容器,使得web应用程序可以像本地程序一样启动和调试,十分的方便,这种设计方式也使得spring boot应用程序非常适合容器化进行大规模部署。生态方面,spring boot提供了非常丰富的组件,目前流行的java web框架基本都有spring boot版本,生态十分庞大,是目前java web开发最好的方案。

spring boot部署问题

Springboot应用程序有两种运行方式

  • 以jar包方式运行
  • 以war包方式运行

Read the rest of this entry

,

背景

某项目需要集成新系统和邮箱单点登录,邮箱是outlook,邮箱系统有自己的单点登录系统ADFS,门户单点登录使用OAM,OAM和ADFS通过SAML2.0进行单点登录。

碰到的问题是,其他系统都可以登录进去,唯独邮箱无法登录,而且老系统已经做了和邮箱的单点登录,并且可以成功登录,新系统一直无法登录。

老系统和邮箱做的是伪单点,就是在代码里通过登录oamconsole获取到cookie(也是骚操作:) ),将cookie返回给浏览器,通过这种间接的方式进行登录,新门户通过配置ohs+webgate进行单点登录。

以上是背景。

Read the rest of this entry

,

背景

某项目OSB生产环境RFC接口概率性调用失败,大概10次调用就会有一次失败,可以稳定重现,以下是该问题的一些重要信息

封装了1个简单的sap rfc查询接口,没其他逻辑,只返回结果。

  • 1. OSB生产环境节点服务器单机运行,依旧存在问题,每个单机都会出现。
  • 2. OSB生产环境配置连接SAP单个节点IP,依旧存在问题,每个SAP节点都会出现。
  • 3. 重启OSB生产环境服务器后,依然会出现问题。
  • 4. 【重点】使用JAVA写代码 去调用SAP RFC接口,不会出现这个问题。
  • 5. 【重点】OSB的测试环境调用 SAP的测试环境RFC接口,不会出现这个问题。
  • 6. 【重点】OSB的测试环境调用 SAP的生产环境RFC接口,不会出现这个问题。
  • 7. 【重点】OSB的生产环境调用 SAP的测试环境RFC接口,会出现时而请求测试的sap,时而请求生产的sap。也会出现这个not found问题。

看起来很诡异是吧,这也是给这个问题取名幽灵RFC的原因,但看现象无法做出最基本的可能性判断,没有规律可循。错误日志如下(摘取重要的片段):

Read the rest of this entry

,

概述

weblogic有三种安装方式

  • GUI方式安装,有界面引导安装,操作简单,但Linux需要安装GUI图形界面软件,本地通过VNC工具连接。
  • 静默安装,该方式可以实现自动化安装,但需要提前准备好安装所需配置文件。
  • 控制台安装,weblogic安装程序提供控制台界面安装,就算把GUI图形界面的相关配置信息用控制台的方式展现,用户通过键盘输入进行选择。

本次安装采用控制台安装方式对weblogic进行安装配置,在启动weblogic安装程序后,安装程序会自动监测当前环境,如果非GUI环境会自动进入console模式。

和GUI安装方式相比,控制台安装不需要安装VNC工具,实在是方便很多,但需要安装人员对weblogic的安装非常的熟悉,因为一切都是通过控制台进行交互。

上传介质

  • 创建介质目录
[root]
mkdir –p /u01/installer

将以下安装介质上传至服务器介质目录下

  • wls1036_generic.jar
  • jdk-7u76-linux-x64.zip

Read the rest of this entry

背景

最近在重构一个框架的代码,在重构的过程中就在想一个问题,如何做单元测试,当然,这个问题不是如何使用JUnit的问题,而且如何使做单元测试更充分,如果你有时间写几千个测试用例,这个也许不是问题,但当你的系统足够庞大,而你的人力和时间有限的情况下,如何最大限度的完成单元测试。

天上是不会掉馅饼的,有的话也只会砸到天才,砸不到普通人,我们都是普通人,不是天才,据说天才们已经想到方案了睡觉的时候,程序能不能自动查 bug,让你在睡觉的时候自动帮你查bug。如果没有完美的方案,有没有退而求其次的方案。这个就是今天要讨论的主题。

单元测试主要解决两个问题

  • 系统错误
  • 业务错误

Read the rest of this entry