In Airpal used Guice for DI framework, in my project we are using glassfish 4.1 payara server RESTful web services, Jersey version 2.21.
issue 1: if use Guice got some runtime exceptions
Error occurred during deployment: Exception while loading the app : CDI deployment failure:WELD-001409: Ambiguous dependencies for type Validator with qualifiers #Default at injection point [UnbackedAnnotatedField] #Inject private org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor.validator at org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor.validator(ValidationInterceptor.java:0) Possible dependencies: - org.apache.bval.cdi.ValidatorBean#33aeb01, - ValidatorBean [id=org.hibernate.validator.internal.cdi.ValidatorBean_default] . Please see server.log for more details.
issue2: if didn't use Guice how can bind airlift client in jersey 2.21 RESTful.
Please help me. anybody know this issue who are using Airpal+presto+glassfish4.1+jersey2.21+maven3.0
It seems that since both Guice and standard Java EE CDI use the same #Inject annotations, the CDI mechanism is triggered but fails to find dependencies, because your applcation is configured with Guice.
The simplest solution with GlassFish/Payara is to disable implicit CDI when deploying the application (there is a checkbox in Admin console when deploying, or an option to asadmin command).
You can disable CDI in the application archive in a XML descriptor too. Have a look at Payara Server docs about disabling CDI or filtering CDI scanning. Note that most options are available only in Payara Server and not in GlassFish 4.1.
The CDI is triggered either by
- putting beans.xml into you application (I don't expect you put it there, because you're using Guice, but check if it wasn't generated by your IDE for some reason)
- annotating one or more classes with annotations that trigger CDI - e.g. any EJB annotation (#Stateless, #Stateful,...)
Related
As JSF 2.3, #ManagedBean and other javax.faces.bean.* annotations are deprecated and replaced with JavaEE 6 CDI.
I successfully made a sample JSF project and deployed it to WebLogic using server implementations 'glassfish.jsf.jar' and with no implementation of JSF nor CDI in the WEB-INF/lib.
But I am afraid to be stuck with Server implementation that may be out of date in sometimes + my application behave differently during work in different application servers so I think it would be better if I have control over JSF implementation.
I spent the last 4 days for searching for a way to use a custom JSF implementation (Mojarra or MyFaces) using new CDI annotations or any other DI framework but with no luck.
I got that I must use JavaEE server implementation of JSF and CDI if I want to get rid of #ManagedAnnotations.
My question: is there a way to include my preferred implementation of JSF and CDI in my WAR that will be deployed to different application servers like WebLogic and WildFly.
Note: I found an old question from 2013 with No as an answer but I want to know is this answer still valid
Edit 02/11/2018:
I successfully install a project with embedded JSF (Mojarra) and CDI (Weld) without any problem on Tomcat Server. I think it's because Tomcat is Servlet Container so there are no conflicts.
I think my problem because of the conflict between my embedded CDI and Server implementation version of Weld. I can not find a solution to make my application is as blackbox.
I used this weblogic.xml
false
<prefer-application-packages>
<package-name>!javax.servlet.*</package-name>
</prefer-application-packages>
<prefer-application-resources>
<resource-name>!javax.servlet.*</resource-name>
</prefer-application-resources>
The other answer is sort of still valid. But there are sort of other (better) options
1 Also provide the full java-ee container as part of your app.
2 Require a minimal version of specific app servers
3 Tell customers they need at least specific versions of certain libraries
I'm trying to get a clear understanding of where #DeclareRoles annotation can be used. The API simply says:
Used by application to declare roles. It can be specified on a class.
I've used #DeclareRoles successfully with GlassFish and Payara and for them I can put #DeclareRoles anywhere; it seems those EE servers will scan and find all usages. I tried transferring some code to WebLogic 12.2.1 and started getting some role errors at deployment. I tracked the problem down to WebLogic wanting the #DeclareRoles annotation only on a Servlet class.
So should #DeclareRoles be able to put on any class and the GlassFish/Payara behavior is correct? Or should #DeclareRoles be limited only to a Servlet class and the WebLogic behavior is correct. Given WebLogic's history, I tend to think it's not doing the right thing.
After looking into this more, I found JSR-340, Servlet 3.1 specification, section 15.5.1 AND JSR-369, Servlet 4.0 specification, section 15.2.2 both state:
The #DeclareRoles annotation may only be defined in classes
implementing the javax.servlet.Servlet interface or a subclass
thereof.
So, it looks like WebLogic got this right and GlassFish/Payara behavior is outside of the spec.
According to the Java EE 7.0 & 8.0 Specifications, javax.annotation.security.DeclareRoles need only be supported by web containers and EJB containers.
In other words, the class that is annotated must be an EJB or a servlet.
I'm trying to migrate my JSF application to CDI. I have implented the following changes:
Added an empty beans.xml file to WEB-INF
Changed #ManagedBean 's to #Named
Changed All the scopes I have to CDI Scopes (Session, View, Request)
Changed all #EJB and #ManagedProperty to #Inject
However, an Omnifaces error is preventing deployment as I'm getting the following error three times:
org.jboss.weld.exceptions.DeploymentException: WELD-001409 Ambiguous dependencies for type [EagerBeansRepository] with qualifiers [#Default] at injection point [[BackedAnnotatedField] #Inject private org.omnifaces.ApplicationListener.eagerBeansRepository]. Possible dependencies [[Managed Bean [class org.omnifaces.cdi.eager.EagerBeansRepository] with qualifiers [#Any #Default], Managed Bean [class org.omnifaces.cdi.eager.EagerBeansRepository] with qualifiers [#Any #Default]]]
I have downgraded to Omnifaces 1.8.1 and the deployment was successful. Why Omnifaces 2.0 resulting in this error?
Development Environment:
Glassfish 4
Omnifaces 2.0
JSF (Mojarra 2.2.0)
WELD-000900 2.0.0 (SP1)
This exception suggests that OmniFaces JAR (specifically, the JAR containing the mentioned ambiguous class, which is in your particular case EagerBeansRepository) is duplicated in runtime classpath. Provided that the JAR is properly placed in /WEB-INF/lib of the webapp and not elsewhere, then this can happen if GlassFish work folders are not properly cleaned up before deploy. Particularly the GlassFish Eclipse plugin is known to fail in this. You'd need to manually clean up the GlassFish work folders in /glassfish/domains/[domainname].
By the way, while you're at it, I strongly recommend to upgrade to GlassFish 4.1 as well. GlassFish 4.0 has like every first GlassFish release (all the hassle to get it ready as "First Java EE X Application Server" along with every new Java EE API release) way too many childhood bugs.
I am trying to deploy an application on Websphere 8.5.5
I've created a shared library for Websphere that includes myfaces 2.2 jars and other dependencies like commons-collections.
I also made the class loader of my application as PARENT_LAST.
When I deploy the application, I get this exception:
An error occured while initializing MyFaces: Class com.ibm.ws.jsf.config.annotation.WASMyFacesAnnotationProvider is no org.apache.myfaces.spi.AnnotationProvider
java.lang.IllegalArgumentException: Class com.ibm.ws.jsf.config.annotation.WASMyFacesAnnotationProvider is no org.apache.myfaces.spi.AnnotationProvider
at org.apache.myfaces.shared.util.ClassUtils.buildApplicationObject(ClassUtils.java:557)
at org.apache.myfaces.shared.util.ClassUtils.buildApplicationObject(ClassUtils.java:524)
I was looking at running a newer version of MyFaces on WAS 8.5.5, and ran into a similar issue. It appears to be a conflict between the code IBM wrote to support its embedded version of MyFaces, and an application- or shared library-provided MyFaces.
IBM provides a way to circumvent this issue. When WAS 8.0 shipped, it provided a feature to allow select either "SunRI1.2" or "MyFaces" as the server-provided JSF. Setting the default to "SunRI1.2" would remove the server-provided MyFaces from the classpath and allow the developer to provide their own.
Select any application
Click JSP and JSF Options
In the JSF implementation section, change the drop-down to SunRI1.2
Click OK
Save configuration and restart server
My simple JSF app is running on JBoss 7 but when I deploy it to Jetty - JSF annotations are ignored, and I have to define ManagedBean in faces-config.xml to make it work because managedBean resolved to null when I submit the form. JBoss is not mentioned in pom.xml dependencies, so looks like JSF by default tied up with JBoss.
How to make project stop being close friends with JBoss?
JSF 2.0 is part of the Java EE specification so it is definitely not bound to an application server in particular.
You should check out that the version of the Web container (Jetty) supports JSF 2.0 and that you have added all the required dependencies.
Hope it helps
Francesco