我可以获取未分解 WAR 中 JAR 内文件的 URLConnection 吗？
我的 Web 应用程序的类路径中有一些资源文件（如果重要的话，在 JAR 内）。我知道我可以通过调用例如 SomeClassLoader.getResourceAsStream( "/samples/myscript.txt" ) 来访问这些资源的内容。我过去曾在分解和非分解 WAR 文件中成功测试过这一点。
但是，为了与我的应用程序中的其他一些现有类集成，我需要向该文件提供一个 URLConnection 对象。我测试并确认调用 getResource("/samples/myscript.txt").openConnection() 在 exploded WAR 中有效（此外，调试显示结果是 < code>file:/// 分解文件的 URL）。
问题：该方法也适用于非爆炸（“打包？”）战争吗？
（我目前无法轻松访问部署战争而不爆炸战争的服务器，因此我为什么要问而不是直接尝试它。此外，一些服务器（例如 Jetty、Tomcat - 即使使用 unpackWARs="false ") 允许非爆炸式部署，但在幕后他们解开了战争，有效地表现得像爆炸式部署——而且，显然，工作正常。我认为过去给我带来麻烦的服务器是 Websphere 和网络逻辑）。
I have some resource files that are in the classpath of my web application (inside a JAR, if that matters). I know I can access the contents of those resources by calling e.g. SomeClassLoader.getResourceAsStream( "/samples/myscript.txt" ). I have tested this in the past in both exploded and non-exploded WAR files with success.
However, to integrate with some other existing classes in my app, I need to provide an URLConnection object to that file. I tested and confirmed that calling getResource("/samples/myscript.txt").openConnection() works in exploded WARs (additionaly, debugging revealed that the result is a file:/// URL to the exploded file).
Question: will that method also work on non-exploded ("packaged?") WARs?
(I currently do not have easy access to a server that deploys wars without exploding them, hence why I'm asking instead of outright trying it. Also, some servers (e.g. Jetty, Tomcat -- even with unpackWARs="false") allows non-exploded deployments, but behind the scenes they unpack the war, effectively behaving like an exploded deployment -- and, evidently, working correctly. I think the servers that gave me trouble in the past were Websphere and Weblogic).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不相信是这样。为此，您必须使用 JarUrlConnection< /a> 表示 JAR URL，其基础 URL 是另一个 JAR URL。如果我尝试这样做，我得到：
“spec”是 JarUrlConnection 所称的引用 JAR 内文件的路径。似乎对于像
jar:jar:file:///outer.jar!/inner.jar!/myscript.txt这样的 URL，它首先会切断规范 em> 感叹号，然后拒绝inner.jar!/myscript.txt作为规范。实际上，我们希望它在最后一个感叹号路径处截断规范，解开内部 URL（指的是外部 JAR！）以用作基础。不幸。我想不出任何解决办法。I don't believe so. To do that, you'd have to use a JarUrlConnection for a JAR URL whose underlying URL was another JAR URL. If i try that, i get:
'spec' is what JarUrlConnection calls the path that refers to the file inside the JAR. It seems that for a URL like
jar:jar:file:///outer.jar!/inner.jar!/myscript.txt, it chops off the spec at the first exclamation mark, and then rejectsinner.jar!/myscript.txtas a spec. When really, we'd like it to chop off the spec at the last exclamation path, unwrapping the inner URL (which refers to the outer JAR!) to use as a base. Unfortunate. I can't think of any way round this.与正在尝试的操作相关的需要注意的事项：存档中的条目本身就是存档的条目，具有两层打包，并且可能具有两层压缩。任何在将中间档案保留为最外层档案内的条目的同时访问该条目的数据的尝试都必须在检索该条目之前解压缩中间档案。
要访问双重嵌套存档，需要使用两种基本技术和一种高级技术：首先，最常见的是，将中间存档提取到临时文件。其次，偶尔可以流式传输中间存档的条目，但这非常慢，除非在非常有限的情况下，否则不建议这样做。第三，一种先进的技术是不压缩中间存档，然后创建一个偏移文件，其中包含指向中间存档的最外层存档区域的指针。我不确定这是否在任何地方完成，但它可以避免其他两种技术的开销。
无论如何，访问双重嵌套条目需要相当多的额外步骤，这对于简单的协议处理程序来说有点太多了。
另请注意，这是 JavaEE 应用程序存档的常见问题，JavaEE 应用程序存档被定义为多层存档：EAR -> （JAR | WAR | RAR），WAR -> JAR 和 RAR ->罐。 JavaEE 创建三层嵌套档案。
Something to note relative to the operation which is being attempted: An entry within an archive which is itself an entry of an archive has two layers of packaging, and potentially has two layers of compression. Any attempt to access the data of the entry while leaving the intermediate archive still as an entry within the outermost archive would have to decompress the intermediate archive before retrieving the entry.
To access a doubly nested archive two basic techniques and one advanced technique are used: First, most often, the intermediate archive is extracted to a temporary file. Second, occasionally, one can stream through the entries of the intermediate archive, but this is very slow and is not advised except in very limited circumstances. Third, an advanced technique would be to not compress then intermediate archive, then create an offset file with pointers to the region of the outermost archive to the intermediate archive. I'm not sure this is done anywhere, but it would avoid the overhead of the other two techniques.
In any case, there are considerable extra steps necessary to access the doubly nested entry, which are a bit much for a simple protocol handler to do.
Note also that this is a common problem for JavaEE application archives, which are defined as multi-layer archives: EAR -> ( JAR | WAR | RAR ), WAR -> JAR, and RAR -> JAR. JavaEE creates three tiers of nested archives.