Tomcat 10运行项目出现java.lang.NoClassDefFoundError: javax/servlet/ServletContextListener的问题

Tomcat 9更新到Tomcat 10,运行项目,发现报错:

项目无法正常启动,看官方提示才知道,原来javax改成了jakarta了,所以找不到对应的包文件。我就不对项目进行修改,用回Tomcat 9就挺好的。

继续阅读Tomcat 10运行项目出现java.lang.NoClassDefFoundError: javax/servlet/ServletContextListener的问题

Jakarta EE - Java EE的终结者

什么是 Jakarta EE

Jakarta EE并不是新技术,他的前身就是大家熟悉的Java EE,老一辈的程序员可能还记得J2EE,是的,他们都是同一个东西,至于为什么会改来改去,这里面就有很多故事了。

1998年12月,SUN公司发布了JDK1.2,开始使用Java 2 这一名称,第二年Sun公司联合IBM、Oracle、BEA等大型企业应用系统开发商共同制订了一个基于Java组件技术的企业应用系统开发规范,名字很自然就取为Java 2 Platform Enterprise Edition简称J2EE,后面的事情大家也知道,JDK版本升的很快,J2EE名称如果跟着Java版本走必然会给开发人员造成困惑不利于该技术的推广,终于在2006年,SUN公司在发布Java 5后正式将J2EE改名为Java EE(Java Platform, Enterprise Edition),很多早期j2ee开发者虽然现在用的是最新的java ee标准但他们还是认为自己在用j2ee,当然,只是名称的改变并没有给开发者带来什么麻烦,相比之下下面这个就是要命。

2009年,Oracle宣布收购SUN,Java相关技术自然归Oracle所有,在2017年,Oracle 宣布开源 Java EE 并将项目移交给 Eclipse 基金会,但Oracle移交的很不痛快,提了很多要求,其中就包括不能再使用Java EE这个名称,虽然有点无理但Eclipse基金会还是接受了这个要求并且改名为Jakarta EE,经历了从j2ee到java ee的改名再经历一次似乎也无所谓,但要命的是Oracle要求Jakarta EE不能修改javax命名空间,这个就意味着java ee移交后代码就此封版,如果想修改代码,不好意思,请另起炉灶,所以,Oracle你移交的意义在哪?

那么从Java EE到Jakarta EE会给企业带来什么影响?下面我们一起分析。

名称的转变

这个对企业影响不大,对开发者影响也不大,你可以愉快用着Jakarta EE最新标准的同时跟同事说java ee发布新版本了。

命名空间的转变

如果你是用Maven进行开发,那么Java EE的依赖是这么定义的

我们可以看到groupId是javax,并且源码的结构如下:

所有的源码都定义在javax.*这个路径下,根据Oracle的要求Jakarta EE不能修改javax命名空间,那么Jakarta EE只能将代码中javax修改为jakarta,因此最新版本Jakarta Maven描述是长这样的:

源码目录:

可以看到除了顶层包名称不一样下面的定义都一样,那么包路径更改会有什么影响?影响非常大。

  • 所有java ee应用服务器比如Weblogic,GlassFish等如果要支持最新版本的jakarta ee就必须修改源码重新编译,并且如果支持了jakarta ee就无法支持java ee,也就是无法向前兼容,Tomcat虽然只是Servlet容器但是Servlet本身就是Java EE的一部分,因此也逃不过修改的命运。据说Tomcat可以对应用进行自动代码转换以支持jakarta,因此在不远的将来我们可以看到各种奇技淫巧去兼容jakarta,是不是想起了被IE支配的恐惧。
  • 企业如果需要用到jakarta ee最新特性必须修改现有代码,修改并不复杂,就是把代码中import javax.*替换为import jakarta.*,修改完重新编译打包部署,似乎很简单,事实上没那么简单。
  • 对企业来说,保持应用服务器处于最新版本是必须的,因为新版本可能修复了老版本的漏洞,并且性能上也可能有一定的提升,但如果升级应用服务器的同时也要修改源码代码就很大,修改的成本,带来的风险并不是所有企业都能接受的。
  • 假设修改了一个应用,那么就需要部署到新版本应用服务器上,由于新服务器不兼容老应用因此需要运维两套应用服务器,运维成本提高,两套应用服务器也可能涉及license问题,不知道各厂商要怎么解决这个问题。

总之企业面临两难的境地,要么升级改系统源码,要么保持不变不升级,要么部分升级运维两套应用服务器,刀刀都要命。

未来

在如今各种诸如spring boot框架的包装下,在应用层面已经找不到Java EE的影子了,这些框架完全有能力抛弃jakarta自己实现,对于这些框架来说,跟随jakarta的意义似乎不大。对于企业来说,拥抱spring boot已经大势所趋,Java EE又搞出这么一件事,只会更加坚定企业转型的决心。对于开发者来说,Java EE已经是古董级的技术,Spring Boot不香吗,有什么理由去用jakarta EE。Oracle似乎也是看到了Java EE行将就木就索性移交出去,还能换取Eclipse基金会的董事会席位,但我还是看不懂Oracle对Java EE致命的这一刀目的何在,weblogic和中间件也是Oracle重要的两块业务,这两块业务都依赖Java EE,这么做只会两败俱伤。

参考


java.lang.IllegalArgumentException: The AJP Connector is configured with secretRequired="true" but the secret attribute is either null or "".

ubuntu 18.04 .5 升级到 ubuntu 20.04.2 之后,发现 Tomcat 9.0.31 长时间没办法启动,观察日志,发现如下错误信息:

这个是由于在升级系统的时候,选择保留老版本的配置文件,这样就导致,如果 Tomcat 配置了通过 AJP 方式与Apache通信的情况下,会报告上面的错误信息。

新增 secretRequired 的目的是为了解决 AJP  端口暴露在公网的情况下,存在 AJP File Read/Inclusion in Apache Tomcat (CVE-2020-1938) and Undertow (CVE-2020-1745) 漏洞,由于 Tomcat AJP 协议设计上存在缺陷,攻击者通过 Tomcat AJP Connector 可以读取或包含 Tomcat 上所有 webapp 目录下的任意文件,例如可以读取 webapp 配置文件或源代码。此外在目标应用有文件上传功能的情况下,配合文件包含的利用还可以达到远程代码执行的危害。

连接方必须在连接的时候,传入正确的 secretRequired 才能与 Tomcat 通信,相当于通信需要的密码了。

网上很多人都是直接设置

来解决问题的,也就是设置 secretRequired 为空字符,但是这样会导致攻击方不需要传递密码就可以通信了,因此诱发远程攻击漏洞。

正确的做法其实是不允许远程用户直接通过 Tomcat AJP 协议通信,也就是在设置绑定的 IP 地址为本地地址 127.0.0.1。如下:

参考链接


Ubuntu Server 18.04 LTS隐藏Tomcat-9.0.16.0的版本号与操作系统类型

整体思路跟  Ubuntu 14.04隐藏Tomcat-7.0.52的版本号与操作系统类型 是一致的,但是具体的细节上存在不小的差异,还是需要记录一下。

可以看到里面的内容如下:

直接注释掉里面的内容,如下:

修改完成后,把修改完成的数据存储到catalina.jar中。

把修改后的catalina.jar放回到Tomcat的目录下面:

重启Tomcat的服务

参考链接


Ubuntu 14.04隐藏Tomcat-7.0.52的版本号与操作系统类型

在Ubuntu 16.04/18.04/20.04 LTS上安装OpenGrok-1.3.11/1.3.16/1.5.12浏览Android源码

OpenGrok 是一个快速,便于使用的源码搜索引擎与对照引擎,它能够帮助我们快速的搜索、定位、对照代码树。接下来就具体讲解 Ubuntu 16.04/18.04/20.04 LTS 环境下 OpenGrok 的安装及使用。

OpenGrok 1.3.11/1.3.16 依赖 Java 1.8 , Tomcat 8

OpenGrok 1.5.12 依赖 Java 11 , Tomcat 9

OpenGrok 1.6.0开始依赖 Java 11 , Tomcat 10

1.依旧参照 UBUNTU 13.10 APACHE 2.2 通过 AJP 整合 TOMCAT 7 中讲述的方法,进行 Tomcat 8/9Apache 2.4的配置安装,只不过路径中的 Tomcat7 目录替换成 Tomcat8 (ubuntu 20.04 默认 Tomcat9)。

2.安装 Tomcat 8 (ubuntu 18.04)

安装 Tomcat 9 (ubuntu 20.04)

3.安装 universal-ctags 用于对 C\C++ 代码的支持

给代码建立索引时,要使用到universal-ctags工具,但是一般通过apt-get安装的都是exuberant-ctags,所以要先删除原有的ctags版本,然后安装universal-ctags.

4.下载并安装OpenGrok

可以到"https://oracle.github.io/opengrok/"手工下载文件,然后上传到服务器,也可以直接用wget命令来下载,一般选择安装在"/opt"目录下面。

解压缩文件到当前目录"/opt"

创建一个软链接,方便后续的修改

链接"/opt/opengrok/lib/source.war"到 Tomcat8 的工程目录"/var/lib/tomcat8/webapps/",比如我们有多个源代码工程,建议进行链接操作。如下:

访问"http://localhost:8080/source/"确认OpenGrok是否已经安装成功,如果安装成功,出现下面的界面:OpenGrok

5.出于安全原因,禁止外网访问Tomcat的8080端口

只允许Tomcat在本地的8080端口监听即可,修改

添加 address="127.0.0.1"

重启Tomcat8

6.配置Apache2对Tomcat通过AJP进行反向代理

Apache2 的配置文件“ /etc/apache2/sites-enabled/000-default.conf” (如果开启了HTTPS,则需要同步修改 /etc/apache2/sites-enabled/000-default-le-ssl.conf 或者 /etc/apache2/sites-enabled/default-ssl.conf) 中,增加如下配置:

Tomcat8 的配置文件/var/lib/tomcat8/conf/server.xml中增加如下配置<Context path="/Android_4.2.2" docBase="Android_4.2.2/"/>,解决跳转404问题。ProxyPass后面必须携带“/”,否则就会出现404问题。

7.配置OpenGrok对源代码进行解析

设置要建立索引的源代码目录的位置,以存储在"/data/OpenGrok/Android_4.2.2"上的Android代码为例子:

注意:

由于我们使用了Apache2的反向代理才需要设置 OPENGROK_WEBAPP_CONTEXT,如果没有设置反向代理,请不要设置 OPENGROK_WEBAPP_CONTEXT 内容就是在 Apache2 中设置的 ProxyPassReverse 指定的参数。

在使用反向代理的时候如果不设置OPENGROK_WEBAPP_CONTEXT会导致在点击具体的变量定义的时候,出现404.

不使用反向代理的时候请只设置OPENGROK_INSTANCE_BASE

创建源代码索引

执行时间在40分钟左右,执行完成 。(如果通过SSH远程登录,可能会出现中途连接断开的情况,原因为某项操作比较耗时,导致长时间没有数据通信,网络超时断开。 参考 Linux SSH保持连接(解决Broken pipe))生成的索引文件在源代码的"data"目录下面,重建索引的时候需要执行如下操作,才能再次建立索引

注意,请务必删除源代码中的"prebuilts"目录,这个目录下面存储的是一系列的编译工具,在浏览代码的时候,完全用不上,但是占据的磁盘空间确是巨大的。

注意,如果服务器上面的内存比较有限,请使用如下命令进行内存限制,否则建立索引的时候,会触发内存不足的情况:

修改OpenGrok配置文件

修改其中的

为具体的工程目录"/data/OpenGrok/Android_4.2.2",修改后的配置如下:

刷新浏览器,可以看到Android_4.2.2的源码可以搜索出来了。

参考链接


升级Struts2之后报告HTTP Status 500 - java.lang.ClassNotFoundException: org.apache.jsp.index_jsp以及org.apache.jasper.JasperException: Unable to compile class for JSP

升级Struts22.3.20.1版本升级到2.5.5版本后可能报告如下错误:

也有可能发生如下错误信息:

具体信息如下图:

1422265899_66497

比较诡异的是,在Tomcat 8的环境下,是可以正常运行的,但是在Tomcat 7环境下却会报错。造成这个现象的原因就是在引入的Jar包中包含了jsp-api.jar这个Jar包,只要在最后生成的war包中排除这个文件即可。

在阿里云的Ubuntu 14.04系统上解决Tomcat 7由于OOM(Out Of Memory)而被系统杀掉的问题

最近服务器上面一直出现Tomcat莫名奇妙的被系统杀掉,后来从系统的日志中找到如下信息:

原来是系统内存不足,导致进程被杀掉了,网上搜了一下,解决方法有两个

1.限制Tomcat使用的内存

方法如下:

在文件尾部增加如下配置:

然后重启Tomcat

2.为阿里云服务器增加swap分区/swap文件,来解决物理内存不足的问题

阿里云的服务器默认没有开启交换分区,导致内存极易耗尽导致服务被杀死,解决方法就是手工增加一个交换文件,来解决这个问题。

参考链接


Tomcat 7使用AJP协议导致AJP端口被意外暴露给外网

使用Ubuntu 13.10 Apache 2.2 通过 AJP 整合 Tomcat 7中的方法配置了通过AJP协议来通过Apache进行访问的代理。

但是最近发现Tomcat有时候会崩溃掉。刚刚开始以为是正常的OOM,后来分析日志,并没有找到相关的记录,反倒是发现如下内容:

于是感觉有些奇怪,因为AJP协议应该不会发生非常频繁的通信协议错误问题。结果尝试从外网连接TomcatAjp端口8009,发现竟然可以通过telnet连接成功!!说明端口意外暴露给了外网。

那么根据The AJP Connector中的介绍说明(注意address部分),如果没有指定IP地址的话,默认是绑定任意地址,这样就导致外网也可以访问这个端口。因此出于安全考虑,我们需要增加这个address的设置,并且绑定到127.0.0.1。最终结果如下:

而我在配置的时候,恰恰少设置了address="127.0.0.1".这个这种错误有些低级啊。

IntelliJ IDEA 2016.2使用Spring 4.3.1.RELEASE,sockjs-1.1.1,stomp-1.2搭建基于Tomcat-7.0.68的WebSocket应用

接着上文IntelliJ IDEA 2016.2使用Spring 4.3.1.RELEASE搭建基于Tomcat-7.0.68的WebSocket应用

上文的最后我们说到,WebSocket是需要定时心跳的,否则会在一段时间后自动断开连接,而更重要的是,不是所有的浏览器都支持WebSocket,早期的IE 10之前的版本就是不支持的,而这一部分的设备其实是不算少的,而sockjs的出现,恰恰好来解决了这个问题。对于不支持WebSocket的浏览器,sockjs使用了多种方式来兼容这种情况,包括使用长轮询等方式,Spring更是内建支持这种方式。

下面我们看如何在上篇文章的基础上,增加对于sockjs的支持。

首先是STOMP的文档官网地址 http://stomp.github.io/
代码的地址为https://github.com/jmesnil/stomp-websocket,项目下面的lib/stomp.js就是我们想要的文件。也可以本站下载stomp.js.zip

接下来sockjs的代码地址https://github.com/sockjs/sockjs-client,项目下面的dist/sockjs-1.1.1.js就是我们想要的文件。也可以本站下载sockjs-1.1.1.js.zip

接下来我们把下载到的文件放到我们工程目录下面的web->resources->javascript目录下面,如下图:

stomp-websockjs-resources

接下来,添加我们需要的com.fasterxml.jackson.core:jackson-annotations:2.8.1,com.fasterxml.jackson.core:jackson-core:2.8.1,com.fasterxml.jackson.core:jackson-databind:2.8.1这三个jar包,增加的方式参照上一篇中对于javax.servlet:javax.servlet-api:3.1.0的操作方法。与上一篇的操作不同的是,这次添加的三个jar包,都要放到编译完成后的War包中。最后的结果如下图:
ToolsJacksonMaven

ToolsJacksonMavenWar

下面,我们开始进行代码的操作,我们在上篇文章中的src->Tools->WebSocket中新增两个源代码文件SockJsController.java,WebJsSocketConfig.java.如下图:

NewJavaSourcesForSockjs

其中的代码如下:
SockJsController.java

WebJsSocketConfig.java

然后修改WebSocket.jsp

最后,我们修改web->WEB-INF->web.xml,在其中增加

修改后的最终结果如下:

参考链接


 

Ubuntu 16.04下Tomcat 7.0.68启动服务时候报告“java.lang.NoSuchMethodError: java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;”

在使用Ubuntu16.04 安装openjdk-7-jdk介绍的方式切换Java1.7版本后,在进行代码调试的时候,Tomcat 7.0.68报告如下错误:

这说明Ubuntu 16.04下的Tomcat是在Java 8环境下面编译的,尽管我们已经切换到Java 7下面了,但是Tomcat并不能很好的执行我们的Java 7代码。这个时候的解决方法就是,编译代码的时候指定Java 7,但是在Tomcat执行的时候,指定使用Java 8来运行。

参考链接


Java error java.util.concurrent.ConcurrentHashMap.keySet