有关JNLP中传SESSIONID为参数的问题

最新推荐文章于 2021-11-19 15:16:14 发布

mudboy

最新推荐文章于 2021-11-19 15:16:14 发布

阅读量2.1k

点赞数

分类专栏： java/j2ee 文章标签： resources servlet session encoding hashmap 浏览器

本文链接：https://blog.csdn.net/mudboy/article/details/394081

版权

java/j2ee 专栏收录该内容

27 篇文章 0 订阅

订阅专栏

现有项目组用SUN JDK1.5中自带的示例：jnlp-servlet作为WEBSTART版本管理的SERVLET。它可以很好的实现JNLP相关资源（JAR，图片等）的基于版本的管理和增量更新。并有几个类似$$codebase，$$name的可替换关键字。（原来写了一个简单的servlet，可以实现软编码，但没法提供灵活的版本控制）

但现有项目的需求更高一些，即，JNLP中需要传更多的参数，比如，服务端IP，端口，上下文，用户登录的SESSIONID等，由于jnlp-servlet有源代码，我们很快修改了JnlpFileHandler和specializeJnlpTemplate方法，并加入了这几个自定义关键字（$$host,$$port,$$newcontext,$$sessionid）。JNLP如下所示：

<?xml version="1.0" encoding="utf-8"?>

<title>My System</title>

<description>My System</description>

</information>

</resources>

<application-desc main-class="com.cfr.app.main">

<argument>$$session</argument>

<argument>$$newcontext</argument>

</application-desc>

</jnlp>

其中，SESSIONID是用其内部的request得到。

一切好象即简单和明了，工作正常，但很快就发现了严重的问题。

首先说说该应用的使用模式如下：

1、用户从网页登录系统，然后在里面点击：http://host:port/myapp/swt/index.jnlp链接。

2、启动应用（因为应用是跟当前登录SESSION直接相关的）

按照设计本意，此时，用户的应用应通过JNLP中的参数得到了该用户登录后的SESSIONID才对，但事实并非如此。这种情况只出现在WEBSTART第一次下载的时候，以后当用户重新打开浏览器登录后（此时当然是一个新的SESSION），在页面中启动WEBSTART后，发现，该SESSIONID还是以前的，并没有想象中的将新SESSIONID传了进来。

后来还是看看JnlpFileHandler中的源代码，发现主要在getJnlpFile（客户端是JRE1.5以下时调用）和getJnlpFileEx(客户端是JDK1.5以上时用)进行了相关实现。原来，它每生成一个JNLP，就将其缓存在HASHMAP中，下一次请求，如果请求的URL相关并且文件的timestamp（就是Web服务器中的jnlp文件的修改时间，可想而知，除了升级，这个文件一般不会变）一样，就从缓存中取，这样一来，我们也可以推测，按照上面的设计，如果有一个用户下载了应用，其它用户从其它机器下载到的JNLP还是第一个用户的JNLP，这是一个更加严重的问题。

由于URL是一样的，现在考虑更改时间戳，即在getJnlpFile中显式的将timesstamp改为当前的时间：

long lastModified = new java.util.Date().getTime();

这样，任何一次请求都不会从缓存中获得，而是重新生成一个，好象这能很好的解决这个问题了吧？

但事实远没有想象的那么简单。这跟WEBSTART与服务端的交互过程有关系。

WEBSTART要通过多次从服务端交互才会真正下载JNLP文件，这主要是验证一些时间等相关的属性（具体我没有看代码）。大至是三次才会真正的把JNLP下载下来（其实服务端会生成三次，真正下载的是第三个），由于我们的SESSIONID是从SERVLET内部的REQUEST中直接得到，这样一来，实际上只有第一个请求的SESSIONID是正确的（因为它是直接从浏览器中进入的），其它两个都是WEBSTART用URLConnection建立的连接，SESSIONID都是新生成的，而下载的恰恰又是第三个，这样一来，又黄了！！！