tomcat配置https记录

执行java bin目录下的keytool程序,生成证书

 

keytool -genkey -alias tomcat -keyalg RSA

 

输入信息后生成成功,会保存在User/niyuzhe/目录下。也可以使用参数指定生成目录。

 

在tomcat中配置https:

 

<Connector port=”8443″ protocol=”org.apache.coyote.http11.Http11NioProtocol”

maxThreads=”150″ SSLEnabled=”true” scheme=”https” secure=”true”

clientAuth=”false” sslProtocol=”TLS” keystoreFile=”C:\Users\niyuzhe\.keystore” keystorePass=”changeit”/>

 

其中keystorePass一项要与上一步输入的密码内容一致

 

重启tomcat后,就可以使用https访问网站了

 

在应用的web.xml中配置:

 

<security-constraint>

<web-resource-collection>

<web-resource-name>securedapp</web-resource-name>

<url-pattern>/*</url-pattern>

</web-resource-collection>

<user-data-constraint>

<transport-guarantee>CONFIDENTIAL</transport-guarantee>

</user-data-constraint>

</security-constraint>

 

则该应用下所有访问都会自动跳转到8443端口,使用https访问。

 

如果需要在eclipse中运行,可以在eclipse的servers中修改settings.xml

 

servlet在同一域下jsession冲突问题现象记录

之前知道同一个ip或者域名下,会有session相互覆盖的问题,原因是cookie中的jsession会互相覆盖,可以通过在tomcat中修改jsessionid的cookie名称的方式解决。

今天在研究单点登录的时候突然想到,tomcat的webapps文件夹下可以随便扔war包,也就是说,tomcat是支持在同一个host下部署多个webapp程序的,这显然是在一个域中。根据经验,这样是完全可行的,因此与之前的结论有矛盾。

新建了个javaweb项目,名字叫webapp,放了一个session listener,在session create的时候打印一句日志。然后把这个项目复制了一份,名字改成webapp2。两个项目同时启动。

通过浏览器访问webapp,控制台中输出了开始session的信息。访问webapp2,控制台中也输出了开始session2的信息。按照我的预计,由于是同域,此时webapp的jsessionid cookie应该已经被覆盖了,再访问webapp应该开始一个新session。在浏览器中试了一下,发现控制台中没有打印信息。两个webapp随意交错刷新页面,都没有导致新建session。说明这个流程下,没有发生cookie互相覆盖的问题。

通过chrome查看cookie内容也印证了这一点,确实有两个不同的jsessionid,而且分别保持不变。跟之前得出的结论不符。

再仔细看了一下,发现chrome中的cookie显示界面中还有path这一项,说不行cookie不仅仅是跟域相关,还跟path相关。

于是把两个项目分别放在监听不同端口的两个tomcat中运行,但是项目的文件夹名字都改成webapp,再刷新,就开始发生cookie了。

具体现象是:

访问webapp页面,webapp启动一个session,cookie中增加一个jsessionid。

访问webapp2页面,webapp2启动一个session,cookie中增加jsessionid,由于在同一个域下,将webapp中的相应内容覆盖了。

访问webapp页面,此时浏览器提交的是webapp2的jsessionid,服务端找不到对应的session,于是又创建了session,重新在cookie中存放了jsessionid。

访问webapp2页面,类似于上一步,又创建了新的session。

大致结论:

同域的相同名称的webapp会共享cookie,不论是否在同一个端口下。(当然如果是两个不同的webapp,一定不在同一个端口下)

同域的不同名称的webapp不会共享cookie,不论是否在同一个端口下。

即:

192.168.0.100:8080/webapp1与192.168.0.100:8080/webapp2不共享jsessionid。

192.168.0.100:8080/webapp与192.168.0.100:8080/webapp共享jsessionid。

 

 

上线才知道世间的险恶——主项目中慎重启动定时任务

主项目部署在tomcat上,用quartz启了若干定时任务,处理各种后台逻辑。

突然发现数据莫名其妙的出现重复,查了半天发现是由于tomcat开了两个host,于是后台任务就启动了两遍。数据库中又没有加够唯一性约束,导致垃圾数据进入。花了好大功夫才把数据平了。

这次是配置方式出现的问题,突然想到,如果要启动多个tomcat做负载均衡……

linux下tomcat部署项目发生Name jdbc is not bound in this Context

由于框架原因,项目的包名必须为ROOT,因此需要另建一个Service。上传War包之后,不能自动解压。手动解压后上传。

上传后,无法建立数据库连接,问题如下:

  • log配置混乱,所有项目全用的是一套配置,且名称为windows标准下的绝对路径。在linux命令行中不好操作。以后项目部署时需要严格区分生产环境和运行环境的配置文件。
  • 无法自动解压war包原因不明,手动解压后,没有在tomcat的conf目录下自动建立context.xml配置文件,所以出现以上错误。手动建立后问题解决