Quizá sea que lo estoy usanding mal, pero struts-menu hace que se cacheen las peticiones entre una y la siguiente de forma que la aplicación no responde igual las dos veces... Bueno, al revés, hace que responda igual pero sin pasar por todas las verticales que antes sí utilizaba.
A ver si me explico. Struts-menu se inventó para usar con struts. En esto, era común configurar el ActionServlet para que no permitiese al navegador cachear las peticiones. La cosa funcionaba.
Llegados a Struts2 me dio, qué se yo, me aburría, por seguir con el plugin en lugar de pintar el menú con una JSP, cosa que puede que acabe haciendo. En struts2 para evitar la caché de los navegadores utilizan Dojo. Dojo evita la caché añadiendo parámetros distintos a los enlaces de forma que cada vez que pinchas en uno, aunque se haga la petición con el método HTTP GET (la que en realidad se cachea), será distinta y no pasará por la caché a preguntar. Es común ver en los enlaces un "[...]&nocache=22142353454578", supongo que el número saldrá de la hora de la CPU o algo de eso.
Pues struts-menu no se lo esperaba así que hubo que actualizarlo para que haga algo de esto. Ocurría que para depurar cualquier cosa tenía que pinchar una y otra vez sobre la opción de menú hasta que al navegador le daba por saltarse la caché o poner la dirección del enlace y pulsar ctrl-F5 para forzar este comportamiento.
El arreglo pasa por añadir un parámetro "nocache" a los enlaces que sea siempre distinto de forma que nunca se almacene en caché la petición provovada por una opción del menú. Por si alguien tiene el mismo problema, debería crear una clase que sobreescriba net.sf.navigator.taglib.DisplayMenuTag y añada el parámetro nocache.
@Override
protected String getPage(String page) {
String ret = super.getPage(page);
if (ret.indexOf('?') < 0 ) {
ret = ret + "?nocache=" + System.currentTimeMillis();
} else {
ret = ret + "&nocache=" + System.currentTimeMillis();
}
return ret;
}
Hay que acordarse de cambiar el tld para que apunte a la clase modificada ^^.
