2017-05-10 2 views
0

Ich erhalte eine URL zu einer Datei in einem JAR innerhalb eines (entpackten) WAR, der in Liberty 16.0.0.4 läuft. Der Code ist in etwa:Websphere Liberty: Die URL zu einer Datei in einem WAR hat keinen korrekten letzten Zeitstempel

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

Die URL der Form ist

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

ich für den Dateizeitstempel suchen, weil es verwendet wird etags, Cache-Steuerung usw. Statt zu erzeugen, erhalte ich der Zeitstempel für die Datei someLIB.jar. Der Zeitstempel des Jar ist bedeutungslos und ändert sich ständig, sowohl während der Veröffentlichung von Eclipse in der Entwicklung als auch während unserer automatisierten Builds.

Ist das nicht ein Fehler? Gibt es eine Problemumgehung?

Antwort

1

Das Protokoll wsjar versucht, dasselbe vom Benutzer sichtbare Verhalten wie das Protokoll jar zu haben. Der einzige beabsichtigte Unterschied besteht darin, die Caching- und Windows-Dateifreigabe-Sperren besser zu steuern. Das Protokoll jar gibt den Zeitstempel der JAR zurück, nicht den Eintrag, also macht das Protokoll wsjar dasselbe, also ist das kein Fehler. Theoretisch könnten Sie versuchen, ein RFE einzureichen, um eine Option für nicht standardmäßiges Verhalten hinzuzufügen, aber es ist unklar, ob es tatsächlich implementiert werden würde.

Als Workaround können Sie Ihren Build anpassen, um eine zusätzliche Datei im JAR zu speichern, die die Zeitstempel aller anderen Dateien enthält, oder Sie können ETag so ändern, dass eine schwache Validierung anstelle einer starken Validierung verwendet wird. (Andere könnten vorschlagen, die URL wsjar zu analysieren und die JAR selbst zu öffnen, aber es ist ziemlich fragil, sich auf die Syntax anderer JARs zu verlassen.)

Verwandte Themen