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.
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 have a Spring 4.1.1, JSF 2.2.3, Primefaces 5.1 web application that run on Java 8 and Tomcat 8.
Everything worked perfectly until my colleague added the javaee-api-7.0 as a dependency for javax for ActiveMQ.
With this jar in, every ajax call doesn't submit data to the backend. For example filters on primefaces datadatable would always pass an empty value, ajax refresh wouldn't take into account processed fields, etc. If I remove the jar, everything start to work again.
Unfortunately the logs don't show any error, the output is exactly the same of when the jar is not included. I'm not sure also with which component the conflict is, I would assume JSF but I have no clue and I can't find any documentation online.
Everything worked perfectly until my colleague added the javaee-api-7.0 as a dependency for javax for ActiveMQ.
You're indeed not supposed to have that JAR in webapp's runtime classpath. This kind of library is supposed to be already provided by the target Java EE container. Examples of Java EE containers are WildFly, GlassFish, Liberty, TomEE, etc. You've there however Tomcat, which is a barebones servletcontainer supporting from the huge Java EE API only JSP, Servlet and EL APIs, on which you have to manually install every other Java EE artifact, such as JSF and JMS.
The javaee-api.jar contains ALL Java EE APIs, including the JSF API (which is of 2.2.0 version). In your case, this one apparently got precedence in classloading over the JSF API version which you already had in /WEB-INF/lib. This will only result in "odd" behavior, because the loaded JSF impl version doesn't match the loaded JSF API version.
You need to solve it differently. You need to install JMS in its own API/impl JAR files, exactly like as you already did for JSF, and thus absolutely not via a "global" javaee-api.jar file. In case of ActiveMQ, the JMS API is available in activemq-all.jar. Use that one instead. It covers everything needed in order to get ActiveMQ to run on Tomcat.
See also:
how to include javax.jms.* in eclipse?
How do I import the javax.servlet API in my Eclipse project?
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
JSF 1.1 and websphere 6.1 was working properly in my case. Once I deployed that to a websphere 7 server, I received the following error -
Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactoryat javax.faces.FactoryFinder.getFactory(FactoryFinder.java:270)
at javax.faces.webapp.FacesServlet.init(FacesServlet.java:164)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:358)
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.init(ServletWrapperImpl.java:168)
Not sure what it means, I have enabled JSF1.2 as project facet in the RAD but still keep getting the above error message and none of my jsf files are working.
EDIT
After following BalusC's comment, I see the following directories are lookup by the code (this is the o/p of url.getPath())
/C:/IBM/SDP/runtimes/base_v7/profiles/AppSrv01/properties/
/C:/IBM/SDP/runtimes/base_v7/properties/
/
/C:/IBM/SDP/runtimes/base_v7/java/lib/
/C:/IBM/SDP/runtimes/base_v7/lib/
/C:/IBM/SDP/runtimes/base_v7/deploytool/itp/plugins/com.ibm.etools.ejbdeploy/runtime/
/C:/IBM/SDP/runtimes/base_v7/installedConnectors/sib.api.jmsra.rar/
/C:/IBM/SDP/runtimes/base_v7/installedConnectors/wmq.jmsra.rar/
/C:/DETSphere10/DET_FALL9.0/DETEJB/classes/
/C:/DETSphere10/DET_FALL9.0/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/DETWEB/
There is no jsf impl in among these directories. Now I am more confused as the original lib should be present under c:\IBM\SDP\runtimes\base_v7\plugins !!
This is a typical error when there are multiple different versioned JSF libraries in the classpath. Websphere ships with builtin JSF libraries. If you'd like to use the webapp-supplied JSF libraries, then you need to set the classloading policy to module after deploying. This usually defaults to application which means that the webapp libraries are loaded by the main classloader. The main classloader may happen to have loaded the JSF API library. When its version is different from the JSF IMPL library in the webapp, then you may receive this kind of errors.
Update to help with nailing down the root cause better here are 2 suggestions:
You can reveal all used classpath roots on the local disk file system as follows:
for (URL url : Collections.list(Thread.currentThread().getContextClassLoader().getResources(""))) {
System.out.println(url.getPath());
}
Execute this in ServletContextListener#contextInitialized() or so.
(eventually after finding that out), install WinRAR, associate it with JAR file type and use its file-search facility to search for a JSF specific file like FacesContext.class and FacesContextImpl.class so that you can find all JAR's which contains the JSF API/impl. You can find out the exact JSF version by extracting the JAR and reading the MANIFEST file.
You need to keep the JSF JAR's (icu4j.jar and jsf-ibm.jar if you are using IBM's component library) in your /WEB-INF/lib folder.