SCM-Daten ergänzt

Projekt von de.halbekunst.juplo nach de.juplo verschoben und aufgeräumt

Maven-Plugin "Hibernate 4" implementiert

JSP-Seite und Servlet ergänzt, die eine Exception werfen

Wenn es zu einer Exception kommt, nachdem die ersten Bytes der Antwort
gesendet wurden, dekodiert Jetty die Antwort offensichtlich falsch, da
es die Fehlermeldung an dem geöffneten Stream vorbei ergänzt.

Unter Tomcat hingegen, greifen die Mechanismen wie gewohnt und die
Fehler-Antwort ist korrekt GZIP-enkodiert (falls gewünscht).

TODO:
Es ist noch nicht klar, ob hier ein Fehlverhalten von Jetty vorliegt, oder
von Juplo! Das Verhalten von Tomcat wird auch zweideutig, wenn man die
länge der zu erzeugenden Nachrricht extrem verlängert: der Client erhält
dann eine unvollständige Antwort zurück, in der weder die Daten enthalten
sind, die vor der Exception eigentlich übertragen worden sein sollten, noch
die Fehlermeldung, die Tomcat nach der Exception anhängen sollte!

30x-Antworten werden nun doch (vorerst) auch dekoriert

Das Caching darf erst für cache-seconds < 0 vollständig unterdrückt werden

Denn ein "max-age"-Wert von 0 Sekunden ist ein durchaus sinnvoller
Caching-Ansatz, wenn die Seite zwar gecached werden, jedoch bei jedem
Request explizit nach Änderungen gefragt werden soll.

Spring-Beispiel um eine View mit Controller erweitert

Für Handler, die kein ETag bestimmen, darf auch kein leeres gesetzt werden

Antworten mit unterdrücktem Caching wurden nicht als komprimiert markiert

Test-Beispiele überarbeitet und nach verwendeter Technik aufgeteilt

Benennung und Ordnung der Beispiel-Module überarbeitet

Eine statische Spring-MVC-Seite zu den Beispielen hinzugefügt

Dynamische Servlet-Aufrufe zu den Test-Beispielen hinzugefügt

Statische HTML-Datei zu den Test-Beispielen hinzugefügt

Statische Test-Datei (eine CSS-Datei) zu den Test-Beispielen hinzugefügt

Last-Modified in den Beispiel-Tests auf einen "normalen" Wert gesetzt

Fehler durch mehrfaches Mappen des AcceleratorFilters auf ein URI behandelt

Wenn die selbe Filter-Instanz mehrfach auf eine URL gemappt ist, wird eine
Warnung ausgegeben und ein doppeltes Wrapping der HttpServletResponse
verhindert, weil das zu Fehlern führen würde.

Wenn unterschiedliche Filter-Instanzen auf die selbe URL gemappt sind, wird
ein 500er-Fehler erzeugt, da das mehrfache Wrapping der HttpServletResponse
sonst zu unkalkulierbaren Fehlern führen würde.

Für unbekante HTTP-Status-Codes sollte der Handler nicht abgewürgt werden

"Content-Encoding: gzip" wird jetzt bei 304 nicht mehr mit ausgegeben

Überflüssige flush()-Anweisung entfernt

Ausgabe des Contents bei 304 unterdrückt

Überflüssige Include-Überprüfung entfernt

Unnötige decorate()-Aufrufe durch AcceleratorFilter verhindert

Unnötigen Parameter in CacheControl.decorate() entfernt

Der Parameter ist wohl aus der Zeit übrig geblieben, als die CacheControl-
Instanz noch nicht über die Methode CacheControl.init() initialisiert
wurde.

Injection-Annotations in AcceleratorFilter ergänzt

Ohne die Hinzugefügte @Qualifier-Annotation für das Attribut
AcceleratorFilter.defaultBufferSize kommt es beim Laden zu einem Fehler,
wenn keine Bean mit passenden Namen vorliegt.

Logging-Filter in dem Test-Beispiel aktiviert

Grundlegende Überarbeitung des AcceleratorFilter

Es wurden diverse schwere Fehler im Zusammenhang mit der automatischen
Komprimierung von Antworten und dem Puffern der Ausgabe behoben.

AccelerationWrapper erweitert jetzt nicht mehr HttpServletResponseWrapper

Juplo-Cachecontrol-Filter konfiguriert

Modul mit Beispiel-Konfigurationen überarbeitet. Jetzt: 1 Modul pro Test

 * Altes Modul cachecontrol-examples, das für mehrere Beispile-
   Konfigurationen, bzw. -Tests gedacht war, gelöscht.
 * Modul cachecontrol-examples-jsp für Beispiel-Konfiguration und -Test einer
   reinen JSP-Anwendung angelegt.
 * Testfall JspTest in diesem Modul implementiert, der die Konfiguration
   (die auch per "mvn jetty:run" gestartet und live getestet werden kann,
   programmatisch mit Hilfe von httpunit abklopft.
 * Das Test-Modul cachecontrol-examples-jsp enthält die spezifische
   Konfiguration für juplo-cachecontrol noch nicht!

Alle Abhängigkeiten von juplo-cachecontrol auf den Scope "provided" gesetzt

HttpTestCase in das Modul test verschoben und schweren Fehler korrigiert

Schweren Denkfehler in der Klasse HttpTestCase und dem zugehörigen Response-
Wrapper behoben:
Der Servlet-Container ruft flush erst auf, wenn die Filter-Kette fertig
abgearbeitet wurde. Da hat er aber wieder nur den ursprünglichen Response
zur Verfügung und nicht mehr den Response-Wrapper, in den der Response hier
zu Test-Zwecken verpackt wurde. Dementsprechend kann der Servlet-Container
die Methode flush während der Finalisierung des Requests nur auf dem
ursprünglichen Response-Objekt aufrufen -- nicht aber auf dem Response-
Wrapper!
Wenn der Response-Wrapper also (wie hier der Fall) ein spezielles flush
benötigt, kann man sich dafür nicht auf den Servlet-Container verlassen!!
Der Flush muss explizit auf angestoßen werden, wenn der Response-Wrapper
keine Daten verschlucken soll.

Dabei:
 * Den bisher als innere Klasse implementierten Response-Wrapper in
   LoggingHttpServletResponseWrapper umbenannt und in eine eigenständige
   Klasse umgewandelt.
 * LoggingHttpServletResponseFilter implementiert, mit dem sich der
   Response-Wrapper auch in enier normalen Java-Webanwendung verwenden
   lässt, um zu Protokollieren, wie ein Response-Objekt benutzt wird.

Maven-Buildverzeichnisse vor git versteckt.

TestFall RequestSizeTest verschärft

Es wird jetzt zusätzlich geprüft, ob die Komprimierung korrekt nur dann
unterdrückt wird, wenn die gesamte Antwort leer ist (und nicht nur der
initiale Request, der geforwarded wird).

Doppelte Dekoration bei Verwendung von Filter und Interceptor unterdrückt

Abhängigkeiten in juplo-cachecontrol korrigiert

GZIPServletOutputStream puffert, um Ausgabefehler zu verhindern

TODO:
Eventuell reicht es auch, den Buffer gezielt zu leeren, anstatt hier stets
eine neue Instanz zu erzeugen!

Noch zu klären: sind die im folgenden vermerkten Fehler inzwischen
korrigiert, so dass die Anmerkungen jetzt nach dem Zusammenlegen der
Commits gelöscht werden können?!?
----------

Buggy Commit!
Die in CountingServletOutputStream eingeführte Methode finish(),
die wahrscheinlich von der finish()-Methode des Wrappers aus
aufgerufen werden sollte, wird nur von der Unterklasse
GZipServletOutputstream aufgerufen.
Der im Wrapper entfernte Aufruf der Dekoration nach der Ausführung
des Filters wird also durch diese Maßnahme gar nicht ersetzt!

BUGGY: gzip-Header wird nicht mehr unterdrückt, wenn noch Ausgabe folgen könnte

Die zur Sicherstellung der Kompression eingeführte Variable forceCompression
wird nie ausgewertet. Eventuell ein Fehler, der erst nachträglich durch das
Rebasen beim aufräumen produziert wurde.
Wenn die Variable forceCompression korrekt in den Scope private gesetzt
wäre, wäre der Fehler früher aufgefallen, da Netbeans ihn dann angemeckert
hätte...

Startskripte für Jetty und Tomcat

AccelerationWrapper.out ist jetzt nie null

Conflicts:

cachecontrol/src/main/java/de/halbekunst/juplo/cachecontrol/AcceleratorFilter.java

Schweren BUG in AccelarationFilter korrigiert
Der Dekorator wurde gar nicht mit dem Handler aufgerufen!

Modul mit Beispiel-Konfigurationen für den Einsatz von juplo-cachecontrol

TestServlet nach juplo-test verschoben

Fehler im Zusammenhang mit dem Komprimieren gepufferter Antworten korrigiert

Verwirrenden Variable-Name "controller" in CacheControl in "handle" geändert

Testfall für juplo-cachecontrol implementiert

 * Neuen Einsprungpunkt getAdditionalHeaders() in CacheMethodHandle ergänzt
 * Zugehörige Annotation @AdditionalHeaders und Logik implementiert
 * "Content-Encoding: gzip" wird jetzt via
   CacheMethodHandle.getAdditionalHeaders() erst so spät wie möglich
   gesetzt. Dadurch kann der Header (und die Komprimierung) unterdrückt
   werden, wenn die Antwort leer ist. Außerdem wird ein Fehler bei Forwards
   verhindert, wo der Header sonst wieder gelöscht wird, wenn weitergeleitet
   wird!
 * ResponsWrapper eingebaut, der die ausgegebenen Bytes zählt.

AcceleratorFilter implementiert

Der Filter belauscht das Setzen der Header und konfiguriert CacheControl
entsprechend. Auf diesem Weg lassen sich Java-Webanwendungen mit
verbessertem Caching-Verhalten ausstatten, ohne dass dafür an der Anwendung
selbst etwas geändert werden müsste.

CacheControl berücksichtigt die Regeln bzgl. starken vs. schwachen ETag's

Überflüssige Hilfsklasse DefaultCacheMethodHandle ausgebaut

CacheControl so umgebaut, dass es sich über Annotationen einbinden lässt

Version auf 1.0.1 festgetreten

Springframework-Version aktualisiert (3.0.5.RELEASE -> 3.0.6.RELEASE)

Modul "test" hinzugefügt, das Hilfsklassen für JUnit-Tests enthält

Das Modul enthält zunächst nur eine von stackoverflow.com entlehnte
klasse, die es ermöglicht, Beans mit dem Scope "request" in Spring-JUnit-
Testsfällen zu verwenden.

Optimierung in CacheControlInterceptor: unnötige Exception vermieden

Verhalten bei Seiten mit in die URL's enkodierter Session-ID korrigiert

Es macht zwar tatsächlich keinen Sinn, dass Proxies diese Seiten cachen
("Cache-Control: private"), aber Browser dürfen die Inhalte ruhig vorhalten
("Cache-Control: max-age=0" geht über das Ziel hinaus!).

Aufbau der Debug-Meldungen vereinheitlicht (URL steht stets vorne)

Fehler bei der Berechnung des Expires-Headers behoben

Wenn der Integer-Wert cacheSeconds zu groß war, kam es zu einem überlauf,
wodurch das Berechnete Datum für den Expires-Header dann 1 Sekunde vor dem
Auslieferungs-Datum lag. Durch einen Cast des Integer-Wertes zu Long vor
der Berechnung wurde dieser Fehler behoben.

Die Log-Meldungen enthalten jetzt auch den Query-String

Log-Meldungen für den ersten Zugriff und unterdrücktes Caching ergänzt

Der Quellcode wird ab sofort mitveröffentlicht

PercentCodec implementiert

Expires-Header werden jetzt schon bei cacheSeconds == 0 gesetzt

slf4j-Version aktualisiert und unnötige Abhängigkeiten entfernt

Versionsnummer auf 1.0.1-SNAPSHOT angehoben

Version auf 1.0 festgetreten

halbekunst.de als Distribution-Management-Repository eingetragen

Springframework-Version aktualisiert (3.0.4.RELEASE -> 3.0.5.RELEASE)

Unterprojekt Utils von Fotos in eigenständiges Projekt Juplo verwandelt

CacheControlInterceptor prüft ETag jetzt auch, wenn If-Modified-Since fehlt

Fehler bei ungültigem If-Modified-Since in CacheControlInterceptor behoben

 * Wenn die Implementierung von Cacheable einen ungültigen (d.h. negativen)
   Zeitstempel für Last-Modified geliefert hat, hat CacheControlInterceptor
   fälschlich stets mit 304 Not-Modified geantwortet.
 * Exception abgefangen, die CacheControlInterceptor geworfen hat, wenn der
   Request für If-Modified-Since eine Zeitangabe vor dem 1.1.1970 enthalten
   hat.

Tippfehler in einem Methoden-Namen des Interfaces Cacheable korrigiert

CacheControll-Logik in ein eigenes (separat verwendbares) Modul ausgelagert

CachingInterceptor implementiert

 * Interface Cacheable eingeführt.
 * CachingInterceptor implementiert und konfiguriert, der  die
   HTTP/1.1-Caching-Header wie gewünscht setzt, wenn der Handler
   das Interface Cacheable implementiert.