GWTP deploy problem on Glassfish 4

[Shin]

Hi All,

i have problem when i deploy my application from Glassfish 3 to Glassfish 4. Anybody also have this problem?

Error occurred during deployment: Exception while loading the app : CDI deployment failure:Exception List with 3 exceptions: Exception 0 : org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [String] with qualifiers [@Default] at injection point [[BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject com.gwtplatform.dispatch.server.guice.HttpSessionSecurityCookieFilter(@SecurityCookie String, Provider<HttpSession>)] at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:403) at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:325) at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:177) at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:208) at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:519) at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:505) at org.jboss.weld.bootstrap.Val .... msg.seeServerLog

[Christian]

I've got this problem too. Did you find a solution?
Is Glassfish4 the reason and it works with Glassfish3?

The problem occurs when adding the gwtp-dispatch-server-guice-1.0.jar; I doesnt need to use something from this JAR.

[Harry Peirse]

I too have this issue on glassfish4... Any solutions or ideas yet? I will experiment... Perhaps something new for WELD has been added since glassfish 3.1.2 which doesn't agree with gwtp-guice

[Christian Goudreau]

It sounds like a clash between Guice and CDI.

The solution that I see is that you use something else than GWTP-Dispatch since it's using Google Guice. Else you can use the spring implementation instead of the Guice implementation.

--
You received this message because you are subscribed to the Google Groups "GWTP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gwt-platform...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Christian Goudreau | CEO - Président

M: 1.877.635.1585 | S: christian.goudreau

ArcBees | Blog | Facebook | LinkedIn

[Christian]

Ah okay, you gave me the right hint and now it seems to work!

I think the problem is the following: Through the new JEE7/CDI1.1 specifications used in Glassfish 4, CDI automatically scans ALL classes, if there is something to inject.

And thats the point: So CDI tries to inject something, where we want guice to inject it, and CDI fails.

So this error would come up with every application server, that implements JEE7/CDI1.1 - not only Glassfish 4.

The solution for me was, to add a file beans.xml to the META-INF directory for my EJB-project and to the META-INF directory in the gwtp-dispatch-server-guice-1.0.3.jar with the following content:

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"

       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

       xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"

       bean-discovery-mode="none">

</beans>

This disables the auto-scanning. But with this JAR there could be problems with application servers that uses JEE6/CDI1.0 ...

To add this file I created a directory META-INF with the beans.xml in the directory where the JAR is and than used the following command:

jar uvf .\gwtp-dispatch-server-guice-1.0.3.jar .\META-INF

(I also added my JAR to this post, so you could easily use this)

Interesting links for this problem:

- http://blog.frickjack.com/2013/06/cdi-and-guice-with-jsr-300-javaxinject.html

- https://code.google.com/p/guava-libraries/issues/detail?id=1433

@Christian Goudreau: Could you (or someone else from the GWTP-team) take a deeper look at this problem and find a suitable solution for GWTP? Maybe this problem would be solved, if GWTP doesnt use javax.inject.* classes.. that would probably the best solution. Alternatively you have to add this beans.xml and than provide two GWTP-packages.. one for CDI1.0 and one for CDI1.1, because application server with CDI1.0 doesnt work with this beans.xml ... :( (see here)

[Harry Peirse]

Oh great find! Thanks very much :)

[Christian]

I changed my project to use maven and using an own JAR isnt that what I really wanted.

So I searched a bit more and found a possibility, to turn off those CDI implicit injection. That could be the currently best solution to solve this error.

Simply deploy your EAR with this command:

asadmin deploy --property implicitCdiEnabled=false <archive>

(Source: https://blogs.oracle.com/theaquarium/entry/default_cdi_enablement_in_java)

As an alternative you could also disable this scanning for every deployment (that was the easier way for me using maven-glassfish-plugin):

asadmin set configs.config.server-config.cdi-service.enable-implicit-cdi=false

(Source: http://nicklimvs.wordpress.com/2013/09/23/disable-cdi-in-glassfish-4/)