Stripes 1.5: fonctionnement sur Tomcat - meilleur moyen de contrôler les en-têtes HTTP (cache-control)?

Question

Actuellement, je suis en utilisant une version modifiée d'un filtre Servlet décrit ici:

http://onjava.com/pub/a/onjava/2004/03/03/filters.html

et ont accroché vers le haut aux bandes servlet répartiteur comme ceci:

<filter-mapping> 
     <filter-name>CacheControl</filter-name> 
     <servlet-name>StripesDispatcher</servlet-name> 
     <dispatcher>REQUEST</dispatcher> 
    </filter-mapping> 

Ce qui fonctionne: mais a l'effet de contrôler tout mon contenu - comment pourrais-je obtenir le contrôle par base JSP et/ou par méthode d'actionBean?

J'allais essayer d'étendre 'ForwardResolution' et injecter ici, mais ne semble pas être capable de le faire dans ma propre structure de paquets? (Constructeur protégé je pense).

Deux autres idées que j'avais (que je ne en particulier, comme le son de) sont les suivants:

1. Création d'une clé de cache aléatoire sur l'ensemble des pages JSP qui font appel à la ActionBean (invalidait le contrôle de cache - dans effet).
2. Passer un paramètre HTTP, que je peux ensuite vérifier dans le CacheControl Filter pour savoir s'il faut ajouter dans les en-têtes de contrôle de cache. Puis-je simplement ajouter la directive à mes JSP? Quelle est la manière recommandée de le faire.

[en aparté, il semble que mon filtre est invoqué deux fois pour chaque appel ... est-ce un effet secondaire de la façon dont je l'ai accroché un filtre à la servlet rayures peut-être?]

Answer 1

En fait - creuser en outre révélé que des bandes 1,5 a un mécanisme d'annotation pour le contrôle des en-têtes de cache HTTP:

http://www.stripesframework.org/display/stripes/News 

// contrôle du cache client. La nouvelle annotation @HttpCache peut être appliquée à une classe ActionBean et/ou à une méthode de gestion d'événement pour contrôler la façon dont le client met en cache la réponse. Les annotations sur les méthodes remplacent celles des classes et l'annotation est héritée des superclasses. Ceci est particulièrement utile pour les appels AJAX d'IE. //

Answer 2

Je vais commencer en arrière - votre filtre est invoqué deux fois, peut-être parce que la même page demande deux ressources - la page, et un CSS, par exemple. Ou fait un appel ajax. Puis, si vous voulez contrôler la ressource cache par requête, voici une solution à deux servlets seulement. Je ne sais pas les rayures, donc il pourrait y avoir un meilleur là:

• créer une classe utilitaire + méthode, par exemple CacheUtils.addCacheHeaders(response). Dans cette méthode, ajoutez tous les en-têtes de cache à la réponse. Invoquez-le où vous voulez - une ligne pour ajouter des caches. Ceci est une approche programmatique

• Définir une liste (séparée par des virgules) des URL de requête dans un init-param du filtre. La méthode init(..) analyse le param, le stocke dans une liste et n'applique le cache que si la demande actuelle uri (request.getRequestURI()) correspond à une dans la liste. C'est une approche déclarative