IDEA 热部署插件Jrebel破解安装

  |  
阅读次数
  |  
字数 762
  |  
时长 ≈ 3 分钟

JRebel 介绍  

IDEA上原生是不支持热部署的,一般更新了 Java 文件后要手动重启 Tomcat 服务器,才能生效,浪费不少生命啊。

目前对于idea热部署最好的解决方案就是安装JRebel插件,这样不论是更新 class 类还是更新 Spring 配置文件都能做到立马生效,大大提高开发效率。但是JRebel插件是需要收费使用的,虽然插件提供了14天的试用(获取14天试用资格请点击这里:https://zeroturnaround.com/software/JRebel/trial/ ),并且试用信息的填写也是随便填上虚假信息即可,但是只有一次试用机会,就是说试用期过了就不能再通过试用的方法继续使用插件了,所以对于JRebel插件的破解还是很有必要的。
ps.没有使用最新版是因为没有找到完美破解最新版的方法,尝试过网上其他人发布的jrebel7.0及以后版本的破解,都没成功。如果有人成功了,请在评论区留言告诉我!

准备工作:JRebel6.4.3破解文件的 下载链接 密码:yef7(破解文件不支持6.4.X以上版本的JRebel插件破解)

JRebel6.4.3安装文件的官方下载链接

JRebel插件官网下载地址(多版本):

https://plugins.jetbrains.com/idea/plugin/4441-JRebel-for-intellij

注意:已安装JRebel插件的需要在settings中将插件更新到最新版后才能将其卸载(已经是最新版的可以直接卸载),在安装完破解版JRebel后就不能再更新插件,否则破解会失效。

JRebel安装与破解:

1)安装

在idea中点击file -> settings,再点击plugins -> install plugin from disk,选择JRebel插件的离线安装文件,点击确定后重启idea。

2)破解

关闭idea,打开压缩包中的破解文件夹,替换一个licence文件与两个jar包 ​:

Windows:

1)

将本机 C:\Users\你的用户名\.JRebel\JRebel.lic替换为下载的补丁包里的 JRebel.lic

2)

C:\Users\你的用户名.IntelliJIdea2017.1\config\plugins\jr-ide-idea\lib\JRebel6\JRebel.jar

3)

C:\Users\你的用户名.IntelliJIdea2017.1\config\plugins\jr-ide-idea\lib\JRebel\JRebel.jar

Mac:

需要注意下,这里的路径为

1)

将本机 ~/.jrebel/JRebel.lic替换为下载的补丁包里的 JRebel.lic;

2)

~/Library/Application Support/IntelliJIdea2018.1/jr-ide-idea/lib/JRebel6/JRebel.jar 替换为下载的补丁包里的JRebel.jar

3)

~/Library/Application Support/IntelliJIdea2018.1/jr-ide-idea/lib/JRebel/JRebel.jar 替换为下载的补丁包里的JRebel.jar

然后启动idea,在file -> settings->plugins -> JRebel中查看是否已显示激活,激活后显示valid,图标为绿色(如果没激活的话,就去试试翻qiang注册正版吧)

3)

激活后,设置JRebel,选择settings -> JRebel -> advanced 选择Jrebel 6 Agent,然后重启idea。Jrebel的其他配置按默认就好。

不使用插件的话,勾选tomcat编译热加载选项,然后修改完代码之后command+f9也可以热加载。

J2EE CXF使用springboot与xml配置的差别所导致的问题

  |  
阅读次数
  |  
字数 272
  |  
时长 ≈ 1 分钟

使用xml时使用以下配置使报文没有加上命名空间时也能正常访问接口。bean定义的前后顺序不影响程序正常注册对象。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<!-- 通过Spring创建数据绑定的类 -->
<bean id="aegisBean" class="org.apache.cxf.aegis.databinding.AegisDatabinding" />

<bean id="jaxWsServiceFactoryBean" class="org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean" scope="prototype">
<property name="wrapped" value="true" />
<property name="dataBinding" ref="aegisBean" />
</bean>

<jaxws:endpoint id="imSendWXModelMessageServicews"
implementor="#imSendWXModelMessageService" address="/imSendWXModelMessageService.ws">
<jaxws:serviceFactory>
<ref bean="jaxWsServiceFactoryBean" />
</jaxws:serviceFactory>
</jaxws:endpoint>

但是如果使用SpringBoot的话,使用注解方式配置,需要注意的是,需要使用到的类一定要放在前面先初始化。不然会没有效果。

例如下面代码红色部分。如果放在endpoint.publish()后面则不会生效。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
@Bean
public AegisDatabinding aegisDatabinding() {
return new AegisDatabinding();
}

@Bean
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
public JaxWsServiceFactoryBean jaxWsServiceFactoryBean() {
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean sf = new JaxWsServiceFactoryBean();
sf.setWrapped(true);
sf.setDataBinding(aegisDatabinding());
return sf;
}

@Bean
public Endpoint sendMessageEndpoint(SendMessageService sendMessageService) {
EndpointImpl endpoint = new EndpointImpl(sendMessageService);
endpoint.setServiceFactory(jaxWsServiceFactoryBean());
// 该部分
endpoint.publish("/imSendWXModelMessageService.ws");
return endpoint;
}

Jenkins 服务器与svn服务器时间不一致出现的问题

  |  
阅读次数
  |  
字数 331
  |  
时长 ≈ 1 分钟

1)问题描述

svn提交了一次更新包,到了jenkins提交更新的时候,第一次代码没有生效,然后重新提交了一次,第二次才生效。

2)问题排查

2.1)

首先第一反应比对了下两次更新的包文件是否一致,然后发现大小不一。
由此看出问题应该是出在jenkins,继续排查。
Jenkins 服务器与svn服务器时间不一致出现的问题-图例1

2.2)

比对了下第一次jenkins的提交时间与svn提交的时间
Jenkins 服务器与svn服务器时间不一致出现的问题-图例2
Jenkins 服务器与svn服务器时间不一致出现的问题-图例3

由此可看出,svn提交的时间是5:07,但是我jenkins提交的时间却为5:06,显然顺序不对,

但是我操作的时候确实是先提交了svn,再提交了jenkins的。

由此可以确认,应该是jenkins服务器时间比svn的慢了,导致jenkins在06分的时间段认为svn上面没有最新的更新包,

然后拿了旧的包进行部署,所以代码功能没有改变,

然后等我第二次提交更新的时候17:10早就超过了svn上面的5:07,所以拿到了最新的更新包进行更新。

功能代码才得以生效。

2.3)

所以这里要注意,jenkins时间一定要与版本控制服务器的时间一致,不然可能引发像我这样的更新失效的情况。

Java JVM常用工具

  |  
阅读次数
  |  
字数 2,886
  |  
时长 ≈ 13 分钟

1)JDK内置工具使用

1.1)jps(Java Virtual Machine Process Status Tool)

查看所有的jvm进程,包括进程ID,进程启动的路径等等。

1.2)jstack(Java Stack Trace)

① 观察jvm中当前所有线程的运行情况和线程当前状态。
② 系统崩溃了?如果java程序崩溃生成core文件,jstack工具可以用来获得core文件的java stack和native stack的信息,从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题。
③ 系统hung住了?jstack工具还可以附属到正在运行的java程序中,看到当时运行的java程序的java stack和native stack的信息, 如果现在运行的java程序呈现hung的状态,jstack是非常有用的。

1.3)jstat(Java Virtual Machine Statistics Monitoring Tool)

① jstat利用JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控,包括了对进程的classloader,compiler,gc情况;
②监视VM内存内的各种堆和非堆的大小及其内存使用量,以及加载类的数量。

1.4)jmap(Java Memory Map)

监视进程运行中的jvm物理内存的占用情况,该进程内存内,所有对象的情况,例如产生了哪些对象,对象数量;

1.5)jinfo(Java Configuration Info)

观察进程运行环境参数,包括Java System属性和JVM命令行参数。

2)具体命令使用

2.1)jstat

generalOption:

1
2
3
-help 显示帮助信息。
-version 显示版本信息
-options 显示统计选项列表。

outputOptions:

1
2
3
4
5
6
7
8
9
10
11
12
13
#参数:
-class:统计类装载器的行为
-compiler:统计HotSpot Just-in-Time编译器的行为
-gc:统计堆各个分区的使用情况
-gccapacity:统计新生区,老年区,permanent区的heap容量情况
-gccause:统计最后一次gc和当前gc的原因
-gcnew:统计gc时,新生代的情况
-gcnewcapacity:统计新生代大小和空间
-gcold:统计老年代和永久代的行为
-gcoldcapacity:统计老年代大小
-gcpermcapacity:统计永久代大小
-gcutil:统计gc时,heap情况
-printcompilation:HotSpot编译方法统计

Read More

J2EE Spring 事务的实现方式

  |  
阅读次数
  |  
字数 2,673
  |  
时长 ≈ 9 分钟

1)初步理解

理解事务之前,先讲一个你日常生活中最常干的事:转账。

1.1)场景设定

用户名 余额
A 1000
B 1000

1.2)操作

A通过支付宝给B转账200块,做这件事情会进行两个操作。
1:A账号-200
2:B账号+200

1.3)结果

1.3.1)

所以如果成功进行了一次转账操作的话,得到的数据应该是如下:

用户名 余额
A 800
B 1200

1.3.2)

但是如果是在失败的情况下,没有做事务处理的话,可能会得到一种情况就是:

用户名 余额
A 800
B 1000

从上面的数据看,A账号成功扣除了200之后,由于某些不可预测的原因,中断了交易,这时候从A账号扣除的200块并未成功加入到B账号当中。

1.4)总结

从上面的失败案例看我们理想的情况是,如果转账失败的情况下应该是A账号没有扣除200块,同时B账号也不会增加200块,即以下所示:

用户名 余额
A 1000
B 1000

所以,这里我们提出了一个概念:事务

事务就是用来解决类似问题的。事务是一系列的动作,它们综合在一起才是一个完整的工作单元,这些动作必须全部完成,如果有一个失败的话,那么事务就会回滚到 最开始的状态,仿佛什么都没发生过一样。

在企业级应用程序开发中,事务管理必不可少的技术,用来确保数据的完整性和一致性。

Read More

J2EE Druid数据库连接池被占满的排查思路

  |  
阅读次数
  |  
字数 352
  |  
时长 ≈ 1 分钟

在使用Druid作为应用数据库连接池的时候,会经常出现连接池被占满的情况,报错信息如下:

1
2
3
org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; 
nested exception is com.alibaba.druid.pool.GetConnectionTimeoutException:
wait millis 60000, active 10, maxActive 10, creating 0

在此报错信息中,我们可以看到,我们的应用不能够再创建新的连接池,因为当前应用里活跃中的连接池数量已达到可允许被创建使用的最大值10个了,
所以新的线程创建不了连接池导致报错。

一般连接池不够用的情况可大致分两种:
1.连接池数量过少,这种手动调整连接池可创建的最大数即可。
2.sql语句执行过慢,导致连接池一直被占用。

针对第二种情况,在这里提供此情况的一点排查思路:
1.使用Druid的sql监控,获取较为耗时的sql语句。
2.获取语句后,通过SQLDeveloper工具,运行查看其执行计划(SQL执行栏第三个按钮:F10)。
3.分析其执行计划,每个条件执行的时间以及查询字段有没有走索引。
4.通过分析,优化查询语句以及让其语句走索引查询达到sql优化的效果。
5.这时候再观察应用侧有没有恢复正常。

Maven 请使用 -source 8 或更高版本以启用 lambda 表达式

  |  
阅读次数
  |  
字数 213
  |  
时长 ≈ 1 分钟

在使用mvn install编译maven项目时,报了

1
“ (请使用 -source 8 或更高版本以启用 lambda 表达式)”错误,是因为设置的maven默认jdk编译版本太低的问题。

可使用两种方法解决

1)

在具体项目的pom.xml里面手动指定jdk编译版本。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<project xmlns="...">
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.3</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
</plugins>
</build>
...
</project>

2)

在maven的settings.xml里面指定全局jdk编译版本。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<profiles>
<profile>
<id>jdk-1.8</id>
<activation>
<activeByDefault>true</activeByDefault>
<jdk>1.8</jdk>
</activation>
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<maven.compiler.compilerVersion>1.8</maven.compiler.compilerVersion>
</properties>
 </profile>
</profiles>

然后,运行mvn命令就可以了。

Redis DENIED Redis is running in protected mode

  |  
阅读次数
  |  
字数 96
  |  
时长 ≈ 1 分钟

1)修改redis服务器的配置文件

1
2
3
4
vi redis.conf    

注释以下绑定的主机地址
# bind 127.0.0.1

2)修改redis服务器的参数配置

修改redis的守护进程为no ,不启用

1
2
127.0.0.1:6379> config set daemonize "no"  
OK

修改redis的保护模式为no,不启用

1
2
127.0.0.1:6379> config set protected-mode "no"  
OK