Hay muchos temas avanzados que tratar, no sé que tan llena esté la comunidad de conocedores J2EE, pero hago este foro para los que desarrollamos encerio.
A continuación voy a colocar unos puntos, no son afirmaciones, son las cosas que actualmente uso para desarrollar mis aplicaciones, por supuesto está abierto a sugerencias, y decir que se está haciendo mal, si se conoce alguna herramienta que hace mejor el trabajo que estas.
1. La mejor combinación gratuita para desarrollar:
* Sistema operativo: Linux
* IDE: Eclipse (desarrollo Java puro)
* Desarrollo de EJB, generación de interfaces Remota / Local, Home, descriptores ejb-jar.xml y especifico del application server, Ejem jboss.xml: XDoclet
* Compilación y generación de JAR EJB, utilitarios, WAR, EAR: ANT
* Páginas Web: JavaServer Faces 1.1 (MyFaces??)
* Application Server para desarrollo: JBoss (cómo se porta en producción??)
* Base de datos: Postgres, Mysql ... excelente soporte de drivers JDBC y pool de conexiones !
2. ¿Quién ha trabajado en una solución para integrar Struts-Tiles con JSF, teniendo en cuenta que JSF no tiene soporte para Tiles?? ...
De momento tengo esta solución: http://www.jsftutorials.net/tiles/jsf-tiles.html propuesta por el grupo Exadel (Fabrican plugins para eclipse creo ... la solución de este árticulo es estándar Java no requiere nada de ellos en particular).
Hay una solución hecha por IBM pero requiere integrar con el controler de Struts, pero no la veo viable porque el de Faces es más simple.
3. La solución a las librerias (Thirdparty):
Este problema común, cuál será la mejor manera de tener estas librerias? ...
* En el directorio LIB de cada WAR; EJB pegarlas y asi las coje al vuelo.
* Esta es la que tengo de momento: Las coloqué en el directorio LIB del EAR, y en cada archivo META-INF/manifest.mf de cada WAR; EJB hice una referencia:
Class-Path: lib/struts.jar lib/commons-lang.jar ....
Lo tedioso es hacer estas referencias, pero la escojí por que las librerias quedan en un solo sitio, y el proyecto EAR queda mucho más pequeño, además no hay riesgos de conflictos.
Lo que estoy diciendo puede ser falso, verdadero, puede haber otras opciones más viables para todo, de eso se trata el foro.
Te invito a participar.
A continuación voy a colocar unos puntos, no son afirmaciones, son las cosas que actualmente uso para desarrollar mis aplicaciones, por supuesto está abierto a sugerencias, y decir que se está haciendo mal, si se conoce alguna herramienta que hace mejor el trabajo que estas.
1. La mejor combinación gratuita para desarrollar:
* Sistema operativo: Linux
* IDE: Eclipse (desarrollo Java puro)
* Desarrollo de EJB, generación de interfaces Remota / Local, Home, descriptores ejb-jar.xml y especifico del application server, Ejem jboss.xml: XDoclet
* Compilación y generación de JAR EJB, utilitarios, WAR, EAR: ANT
* Páginas Web: JavaServer Faces 1.1 (MyFaces??)
* Application Server para desarrollo: JBoss (cómo se porta en producción??)
* Base de datos: Postgres, Mysql ... excelente soporte de drivers JDBC y pool de conexiones !
2. ¿Quién ha trabajado en una solución para integrar Struts-Tiles con JSF, teniendo en cuenta que JSF no tiene soporte para Tiles?? ...
De momento tengo esta solución: http://www.jsftutorials.net/tiles/jsf-tiles.html propuesta por el grupo Exadel (Fabrican plugins para eclipse creo ... la solución de este árticulo es estándar Java no requiere nada de ellos en particular).
Hay una solución hecha por IBM pero requiere integrar con el controler de Struts, pero no la veo viable porque el de Faces es más simple.
3. La solución a las librerias (Thirdparty):
Este problema común, cuál será la mejor manera de tener estas librerias? ...
* En el directorio LIB de cada WAR; EJB pegarlas y asi las coje al vuelo.
* Esta es la que tengo de momento: Las coloqué en el directorio LIB del EAR, y en cada archivo META-INF/manifest.mf de cada WAR; EJB hice una referencia:
Class-Path: lib/struts.jar lib/commons-lang.jar ....
Lo tedioso es hacer estas referencias, pero la escojí por que las librerias quedan en un solo sitio, y el proyecto EAR queda mucho más pequeño, además no hay riesgos de conflictos.
Lo que estoy diciendo puede ser falso, verdadero, puede haber otras opciones más viables para todo, de eso se trata el foro.
Te invito a participar.