schmidtoliver

Wenn man einen ServletFilter für die eigene Webapp baut, dann muss man drei Methoden des Interfaces implementieren: init(), doFilter() und destroy(). Der Filter wird danach in die web.xml aufgenommen und startet zusammen mit der Webapp, wobei beim Starten des Filters seine init()-Methode aufgerufen wird. So weit die Theorie. Spring ermöglicht es, Filter im ApplicationContext zu definieren und ihnen damit Zugriff auf andere Beans zu bieten. Über die Namenskonvention Filtername == BeanId wird nun nicht mehr die Filterklasse in der web.

Wenn man wie ich aus der Maven-Welt kommt, dann weiß man: Kompilate, generierte Resourcen und temporäre Dateien werden immer im target-Ordner des Projektverzeichnisses abgelegt; eingebundene Plugins und Dependencies liegen dagegen in einem Repository im Nutzerverzeichnis. Bei Grails ist das ein wenig anders. Dies musste ich feststellen, als ich auf unserem CI-Server Teamcity zwei Builds eines Grails-Projektes parallel angestoßen habe und diese beim Bauen des WARs scheiterten, weil sie das Staging-Verzeichnis nicht löschen konnten.