Eclipse WTP vs sydeo, "sirve módulos sin publicar"

103

Tengo el problema de encontrar el rendimiento del complemento sysdeo utilizando el complemento integrado WTP de eclipse.

Para realizar la migración y, por lo tanto, la comparación, instalé ambos en proyectos separados dentro de eclipse.

Noté una diferencia de productividad, de acuerdo con lo que entendí: WTP necesita publicar fuentes en una compilación de directorio para que tomcat las tenga en su disposición. Este "pulso" es largo: es necesario recargar el contexto para que las modificaciones sean visibles. (5 secos en la mayoría de yardas 15 segundos - 20 segundos en el más largo).

Sysdeo no; se dirige al directorio eclipse, por lo tanto, se construye interno en el proyecto tan pronto como se realiza una modificación mediante un archivo, eclipse se construye y estas modificaciones están disponibles de inmediato (F5 en el navegador y tenemos el resultado de inmediato).

Aquí está mi configuración de servidor:

La opción "Sirve módulos sin publicar" permite hacer exactamente lo que hace sydeo: elegir el directorio de construcción del proyecto en ejecución. Esta configuración se expresa en el archivo de contexto. (Es para poder recuperarlo que he marcado "Publicar modula contextos para separar filas XML")

Comparación de estos archivos:

  • Aquí está el archivo de contexto para generar por sysdeo
< Context path="/tatoile _syseo" reloadable="false" docBase="D:\32bit\serveur32bit\workspace\tatoile _syseo" workDir="D:\32bit\serveur32bit\workspace\tatoile _syseo\work" />
  • El contexto de archivo para generar por WTP

<? xml version = "1.0" encoding = "UTF-8"?> <Context docBase = "D: \ 32bit \ serveur32bit \ workspace \ tatoile \ web" path = "/ tatoile" reloadable = "true" source = "org .eclipse.jst.jee.server: tatoile "> <Resources className =" org.eclipse.jst.server.tomcat.loader.WtpDirContext "extraResourcePaths =" / WEB-INF / classes | D: \ 32bit \ serveur32bit \ workspace \ tatoile \ build \ classes "virtualClasspath =" D: \ 32bit \ serveur32bit \ workspace \ tatoile \ build \ classes "/> <Loader className =" org.eclipse.jst.server.tomcat.loader.WtpWebappLoader "useSystemClassLoaderAsParent =" false " virtualClasspath = "D: \ 32bit \ serveur32bit \ workspace \ tatoile \ build \ classes" /> <JarScanner scanAllDirectories = "true" /> </ Context>

Posteriormente analizar esos dos archivos es igual.

Ahora volvamos al problema. Utilizo el mismo servidor, en consecuencia, ambos archivos de contexto anteriores están definidos para este. Experiencia: Lanzo el tomcat por el plugin sysdeo, las cargas en dos contextos se hacen el uno para configurar vía WTP el otro por sysdeo. Ambas autoridades reaccionan de la misma manera, las modificaciones son inmediatas en tatoile _syseo y tatoile.

Por otro lado, lanzo tomcat a través del complemento WTP (servidor de pestañas, etc.) en eclipse, las modificaciones no se realizan de inmediato en ambos proyectos tatoile _syseo y tatoile. Nota: La recarga automática debe estar necesariamente habilitada para que se tengan en cuenta las modificaciones. (Cuando el servidor nos indica que ha recargado el contexto podemos ver las modificaciones).

ingrese la descripción de la imagen aquí

De ello deduzco que la configuración de contextos no es la razón, sino la forma en que el plugin lanza tomcat; y ahí o me seco ...

Aquí está el proyecto WTP:

ingrese la descripción de la imagen aquí

java eclipse tomcat eclipse-wtp m2e-wtp Vsplit
fuente
5
¿Tiene algún problema con Sysdeo o WTP? OTOH Seguro que WTP necesitará más tiempo para los cambios, ya que estos son los pasos que hará para volver a publicar: (1) clases de compilación (2) anular la implementación de la aplicación web antigua (3) copiar el resultado de la compilación en la carpeta de implementación de tomcat (4) tomcat iniciará automáticamente el aplicación. Mientras tanto, con sysdeo, las clases en RAM se modifican sobre la marcha tan pronto como se realizan cambios (identificados por nueva fecha en cualquier archivo de clases). Luego, hay algunas limitaciones de los cambios que no se pueden hacer sobre la marcha (cuando agrega nuevos métodos, la estructura de la clase también cambia), en este caso, dará una advertencia.
He usado tanto Sysdeo como WTP en el mismo proyecto. La diferencia más significativa que noté fue que la configuración de Sysdeo me parecía más fácil, pero esto podría estar sesgado.
Markus
2
El problema se resolvió agregando MAVEN con la implementación de WTP. Sin problemas de rendimiento. No hay problemas de rendimiento y no estoy activando "servir módulos sin publicar"
Vsplit
1
Si resolvió el problema, ¿puede publicar una respuesta?
Anubian Noob
@AnubianNoob sí cuando lo he explicado en mi publicación anterior. Resolví el problema usando la configuración de maven.
Vsplit

Respuestas:

3

La respuesta citada de @Vsplit

El problema se resolvió agregando MAVEN con la implementación de WTP. No hay problemas de rendimiento ... y no activo los módulos de servicio sin publicar

Marko
fuente
-1 Esta no es la respuesta. por favor agregue la respuesta con más detalles.
Isaac G Sivaa
1
Hola, lamento mi respuesta tardía. Pero como debe notar, no puedo resolver el problema de problema con el complemento Sysdeo. Pero estoy usando el complemento Maven con la implementación de WTP. Puede ver este tutorial de muestra youtube.com/watch?v=YeC7XQho-O0
Vsplit
2

busque en el mercado de complementos un complemento gratuito llamado m2e-wtp. Eso se encargará de los problemas de alcance proporcionados. En cuanto a las clases que no se implementan, los lugares habituales que miro son el ensamblaje de implementación y / o Java Build Path. Asegúrese de que las entradas (y los módulos dependientes) estén todas allí y ubicadas en el lugar correcto.

Shrinidhi Krishnakumar
fuente