Un día curioso, en notación típica de informático (logs, ficheros fáciles de ordenar por fecha...):
20111111_1111
20111111
20110925
Matar proceso que usa un puerto
Ahora mismo estoy trabajando en el PFC, y arrancando y parando el Tomcat integrado en Eclipse hasta la saciedad (debería usar JRebel ahora que hay una versión libre?)
Lo que me ha ocurrido es algo que pasa "a veces" sin saber porqué : al arrancar Tomcat, me dice que alguno de los puertos que necesita está ocupado. Me voy a la vista de Debug para ver si hay algo en ejecución, y la vista de Servers para ver si está levantado, y ... nada, no veo nada desde ahí.
En el monitor del sistema si veo varios procesos java, pero claro, cual matar? No quiero que se me cierre el Eclipse o cualquier otra cosa que tenga levantada en ese momento.
Googleando un poco me encuentro esto.
Básicamente, ejecutando el comando:
netstat -anp|grep :
vas a poder ver qué proceso está usando qué puerto, para lo que necesites (en mi caso, matar el proceso que se ha quedado "suelto")
A veces pasan estas cosas y no sabes porqué, pero mejor tener a mano la forma de solucionarlas sin más y poder seguir trabajando.
Lo que me ha ocurrido es algo que pasa "a veces" sin saber porqué : al arrancar Tomcat, me dice que alguno de los puertos que necesita está ocupado. Me voy a la vista de Debug para ver si hay algo en ejecución, y la vista de Servers para ver si está levantado, y ... nada, no veo nada desde ahí.
En el monitor del sistema si veo varios procesos java, pero claro, cual matar? No quiero que se me cierre el Eclipse o cualquier otra cosa que tenga levantada en ese momento.
Googleando un poco me encuentro esto.
Básicamente, ejecutando el comando:
netstat -anp|grep :
vas a poder ver qué proceso está usando qué puerto, para lo que necesites (en mi caso, matar el proceso que se ha quedado "suelto")
A veces pasan estas cosas y no sabes porqué, pero mejor tener a mano la forma de solucionarlas sin más y poder seguir trabajando.
20110525
Susto con 'mv *' en linux
Hoy he tenido un pequeño susto en mi equipo de casa, al intentar mover unos ficheros
Quería mover todos los logs a un directorio para mantener históricos, logs de mi aplicación, y he ido a teclear:
mv *.log ../_rutahistoricos_
en ese momento se me ha ido la mano y he tecleado:
mv *
y al pulsar enter... han desaparecido todos los .log y todo lo que había en ese directorio!
La mala suerte hace que, mi configuración, haga que deje las trazas en el HOME de mi usuario, con lo que se había perdido TODO mi contenido.
Perdido? No! Aquí hay un alma caritativa que dice básicamente que:
"si ejecutas 'mv *' se moveran todos los ficheros al último elemento, en caso de ser un subdirectorio, en otro caso se produce un error"
Efectivamente, en mi caso hay un directorio "workspace" (eclipse ;) ) donde estaba TODO mi home.
Curiosamente no se habían movido los directorios/ficheros ocultos.
Así que he podido recuperar todo lo que tenía, simplemente ejecutando de nuevo un mv, esta vez, con mucho cuidado!
He comprobado, además, que ejecutando mv * en un directorio cuyo último elemento no es otro directorio, se da el siguiente error:
mv: el destino, «applogxxxxxx.log», no es un directorio
Quería mover todos los logs a un directorio para mantener históricos, logs de mi aplicación, y he ido a teclear:
mv *.log ../_rutahistoricos_
en ese momento se me ha ido la mano y he tecleado:
mv *
y al pulsar enter... han desaparecido todos los .log y todo lo que había en ese directorio!
La mala suerte hace que, mi configuración, haga que deje las trazas en el HOME de mi usuario, con lo que se había perdido TODO mi contenido.
Perdido? No! Aquí hay un alma caritativa que dice básicamente que:
"si ejecutas 'mv *' se moveran todos los ficheros al último elemento, en caso de ser un subdirectorio, en otro caso se produce un error"
Efectivamente, en mi caso hay un directorio "workspace" (eclipse ;) ) donde estaba TODO mi home.
Curiosamente no se habían movido los directorios/ficheros ocultos.
Así que he podido recuperar todo lo que tenía, simplemente ejecutando de nuevo un mv, esta vez, con mucho cuidado!
He comprobado, además, que ejecutando mv * en un directorio cuyo último elemento no es otro directorio, se da el siguiente error:
mv: el destino, «applogxxxxxx.log», no es un directorio
20110507
SpringSecurity y Sitemesh : filters
A la hora de integrar SpringSecurity con Sitemesh, se me planteó un problema : al usar las tags de springsecurity, en los decoradores de sitemesh, no funcionaban.
La solución estaba a unos cuantos enlaces de Google:
aquí
La idea:
Al cambiar el orden de los filtros en el web.xml de la aplicación web, de forma que el filter de SpringSecurity actue antes que el de Sitemesh, todo funciona. Tiene sentido, ya que antes de que pueda usarse la información de SpringSecurity, debe haberse pasado por su filtro.
La solución estaba a unos cuantos enlaces de Google:
aquí
La idea:
Al cambiar el orden de los filtros en el web.xml de la aplicación web, de forma que el filter de SpringSecurity actue antes que el de Sitemesh, todo funciona. Tiene sentido, ya que antes de que pueda usarse la información de SpringSecurity, debe haberse pasado por su filtro.
20110225
Autocompletado en las JSP de Eclipse
Estoy trabajando en mi proyecto fin de carrera, y una parte del mismo es una aplicación web (como no!)
En esta parte estoy usando Spring MVC, y en la vista estoy usando JSPs ayudándome de los grandes aliados : los tags.
Para que esta ayuda sea cómoda, lo mejor es que el autocompleado (ese mágico Ctrl+Espacio) funcione correctamente. Para ello, la solución ha sido declarar en la jsp los tags a usar de la siguiente forma:
<jsp:root version="1.2"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:jsp="http://java.sun.com/JSP/Page">
... código de la JSP aquí ...
</jsp:root>
De esta manera, el editor de JSP de eclipse "se da cuenta" de los TLD de definición de estos tags, que de otra forma no lo hacía. Voilà!
En mi caso, el proyecto está usando Maven para gestión de las dependencias, por lo que los JAR necesarios no están físicamente en el lib del proyecto, sino que están en el repositorio local maven y se despliegan en el servidor de aplicaciones al publicar la aplicación web.
En esta parte estoy usando Spring MVC, y en la vista estoy usando JSPs ayudándome de los grandes aliados : los tags.
Para que esta ayuda sea cómoda, lo mejor es que el autocompleado (ese mágico Ctrl+Espacio) funcione correctamente. Para ello, la solución ha sido declarar en la jsp los tags a usar de la siguiente forma:
<jsp:root version="1.2"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:jsp="http://java.sun.com/JSP/Page">
... código de la JSP aquí ...
</jsp:root>
De esta manera, el editor de JSP de eclipse "se da cuenta" de los TLD de definición de estos tags, que de otra forma no lo hacía. Voilà!
En mi caso, el proyecto está usando Maven para gestión de las dependencias, por lo que los JAR necesarios no están físicamente en el lib del proyecto, sino que están en el repositorio local maven y se despliegan en el servidor de aplicaciones al publicar la aplicación web.
Suscribirse a:
Entradas (Atom)