Hi,
I have made some progress with issue WELD-273. Please find diff file
attached for the first example (weld-jsf-login) and let me know if the
apporach is correct.
Originally I planned to use glassfish-embedded server, but maven
plugin does not have the option to run the server in another process
so that integration tests are not blocked by the server processing its
requests (similar thing is done with jetty and daemon parameter). I
also did not have success with cargo plugin so I switched to
glassfish-maven-plugin.
Changes description:
Defining ftest-glassfish profile:
# modified: examples/jsf/login/pom.xml
# modified: examples/pom.xml
Copy of test suite definition from jboss6x.xml. Do we really need
seperate one for each appserver?
# new file: examples/jsf/login/src/ftest/resources/glassfish3x.xml
Making the class implement Serializable interface to avoid Glassfish
deployments errors:
# modified:
examples/jsf/login/src/main/java/org/jboss/weld/examples/login/Credentials.java
Setting table name to USER_TABLE as USER is reserved word:
# modified:
examples/jsf/login/src/main/java/org/jboss/weld/examples/login/User.java
# modified: examples/jsf/login/src/main/resources/import.sql
Setting to <jta-data-source>jdbc/LoginDS</jta-data-source> so that
this is accepted by Glassfish:
# modified:
examples/jsf/login/src/main/resources/META-INF/persistence.xml
One final question:
Currently there are several apporaches toward ftest. Tomcat and JBoss
use cargo plugin while Jetty uses maven-jetty-plugin. Moreover each
profile contains the same copy of failsafe plugin configuration. Can I
simplify it somehow? How about using unified apporach to deployments?
Looking forward to feedback from you,
Marcin