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.
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 have started studying JSF and I would like to know what is the JAR to include within our classpath to start using JSF. Is it jsf-api or jsf-impl? Or we have to include both? And if it is both then why they are not merged?
I'll assume that you're not using a real Java EE application server like WildFly, TomEE, Payara, etc, but a barebones JSP/Servlet container like Tomcat which indeed doesn't ship with JSF out the box and you thus had to manually install it. Otherwise, all this fuss with JARs is unnecessary.
Is it jsf-api or jsf-impl? Or we have to include both?
You need both. The jsf-api.jar contains the API, which exist of almost only abstract classes and interfaces. It are the javax.faces.* types which you are importing and using in your code. The jsf-impl.jar contains the implementation, which exist of the real hard working code. The implementation is internally loaded via factories in API. It are the com.sun.faces.* classes which you are not supposed to import and use directly in your code. If you do, then you wouldn't be able to switch to a different JSF implementation, such as MyFaces.
And if it is both then why they are not merged?
There exist a merged JAR, the javax.faces.jar. You can pick this one instead of the two loose JARs.
See also:
Our JSF wiki page
JSF implementations and component libraries
Difference between Mojarra and MyFaces
In simplest terms, what is a factory?
How to properly install and configure JSF libraries via Maven?
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,...)
In a JSF/facelet page, I'm trying to call a method with an enum value as a parameter, like this:
<f:viewAction action="#{myController.myMethod('MY_ENUM_VALUE')}" />
The code is working correctly using Tomcat but when trying with Websphere, this is not working anymore and I get the following exception.
Caused by: javax.el.MethodNotFoundException: /myPage.xhtml #16,24 action="#{myController.myMethod('MY_ENUM_VALUE')}": Method not found: com.example.MyController#807f4c26.myMethod(java.lang.String)
at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:109)
I'm wondering if there is a simple solution (configuration in Websphere?) or if I should integrate a different EL implementation in my WAR to override the one of Websphere. Any other suggestion is also welcome.
Additional information:
Websphere 8.5, using Mojarra 2.2.5 implementation (override implementation of Websphere, using PARENT_LAST mode)
Using Spring (with the SpringBeanFacesELResolver configured in faces-config.xml)
I'm not packaging any special EL implementation in the EAR/WAR.
Tomcat does not provide a JSF implementation so you are free to provide any version compatible with the servler/JSP version provided by your Tomcat server.
However, WebSphere AS 8.5 is a full Java EE 6 application server that integrates JSF into the container.
Bundling libraries into a WAR that are contained in the server does not automatically override the server libraries. Java defaults to a parent-first class loading model. Some of the configuration information available in arbitrary enterprise libraries may not make sense to the container and result in undefined behavior. Additionally, deployment descriptors can specify the loading of WAR-specific libraries that are not necessarily compatible with the container.
Some containers (WebSphere among them) support parent-last class loading. This can result in so much weird behavior it should generally be avoided.
As far as I am aware there is only one documented way to support a com.sun.faces... JSF implementation and I suspect in is only temporarily there to support WAS 7 binary JSF app WAR files.
So, it is possible that you are not really overriding the platform implementation but are triggering some undefined behavior by bundling JSF libraries in the WAR file.
It is possible I've missed something about what you are doing; if so, provide more details.
So, I have a tomcat 8 + jersey 2.5.1 + weld CDI app that works very well in most cases. Where it fails is that I am unable to intercept jersey resource method calls with a CDI interceptor. This makes sense because a jersey resource class is not a CDI bean. Then, is there any way to make a CDI interceptor work in jersey? Another way to ask this question: Can a CDI bean be used as a Jersey resource?
Thanks!
EDIT:
Before I wrote my RESTful resources using Jersey, I had CDI interceptors that were used to begin and commit database transactions. I really need to follow the same or similar pattern to implement this cross-cutting transaction injection in my RESTful jersey resources. That is the main reason for asking this question.
Thanks again!
Can a CDI bean be used as a Jersey resource?
Yes, but since Jersey's DI is based on hk2 and not CDI, you need a bridge.
In glassfish such a bridge is realized by the module jersey-gf-cdi:
<dependency>
<groupId>org.glassfish.jersey.containers.glassfish</groupId>
<artifactId>jersey-gf-cdi</artifactId>
<version>2.6</version>
</dependency>
The module registers itself automatically and works on Tomcat beautifully (assuming you have correctly bootstrapped both Jersey and Weld).
Unfortunately, the versions before 2.6 relies on JNDI only, searching the provider under 'java:comp/BeanManager' which Tomcat does not allow.
A fix for this behaviour is available for 2.6 (a pull request I made some time ago), and falls back on CDI.current().getBeanManager().
I tested it on Tomcat 7 and works correctly, should work on Tomcat 8 too.
Adam Bien in one presentation recommends that you separate your Service (CDI or EJB) class from your RESTful resources class. His reason was that the RESTful class usually uses the HttpHeaders injected by Jersey yet not available in the CDI or EJB containers. The hazard is that your RESTful classes could be injected a Null reference of HttpHeaders if any CDI client like the JSF framework uses it.
Thanks to your self-answered question. You have just showed a second use case that validates Adam Bien's recommendation.
Simply keep them apart!