0

I'm getting back a URL to a file inside a JAR inside an (unzipped) WAR running in Liberty 16.0.0.4. The code is roughly:

URL url = servletContext.getResource(somePath);
URLConnection connection = url.openConnection();
long lastModified = connection.getLastModified();

The URL is of the form

"wsjar:file:/{path_to_WAR}/My.war/WEB-INF/lib/someLIB.jar!/META-INF/resources/foo/bar.txt"

I am looking for the file's timestamp, because it is used to generate etags, cache control, etc. Instead, I get the timestamp for the someLIB.jar. The jar's timestamp is meaningless and constantly changing, both during publishing from eclipse in development, and during our automated builds.

Isn't this a bug? Is there any workaround?

Randy Hudson
  • 1,600
  • 1
  • 12
  • 11

1 Answers1

1

The wsjar protocol attempts to have the same user-visible behavior as the jar protocol. The only intended difference is to allow better control of caching and Windows file share locks. The jar protocol returns the timestamp of the JAR, not the entry, so the wsjar protocol does the same, so this is not a bug. In theory, you could try to file an RFE to add an option for non-standard behavior, but it's unclear whether it would actually be implemented.

As a workaround, you could adjust your build to store an additional file in the JAR that contains the timestamps of all the other files, or you could change the ETag to use weak validation rather than strong validation. (Others might suggest to parse the wsjar URL and open the JAR yourself, but it is rather fragile to rely on the syntax of other JARs.)

Brett Kail
  • 33,593
  • 2
  • 85
  • 90