i have Web Application which should use JSF 2.0 libraries included in WEB-INF/lib... but it does not... instead of i'm getting exception because my server (JBoss 4.2) also provides JSF libraries...
How can i force my application to use .jar's from WEB-INF/lib ?
Note: When i removed JSF libs from server, my application runs as it should.
Tell JBoss that your WAR already bundles JSF by the following entry in your webapp's web.xml.
<context-param>
<param-name>org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL</param-name>
<param-value>true</param-value>
</context-param>
Why can't you use the server versions of those JARs?
You should be writing and testing your application using the same versions of the JARs that the server you deploy to is using. Synch up....I'd either upgrade JBOSS or downgrade your app.
But, if you must, perhaps this document can tell you how:
http://www.datadisk.co.uk/html_docs/java_app/jboss5/jboss5_deployment.htm
Related
I can't understand why i can use JSF in tomcat, because in this image TOMCAT don't accept JSF:
I'm using TOMCAT 7 and everything works fine. I added the dependency of JSF in pom.xml. What's the advantage in use TomEE if a use JSF in tomcat ?
You have Application Servers like Tomcat, TomEE or Websphere.
Those provide a set of Java EE-Libs like JSF, Servlets, JPA, JavaMail etc.
If you are using Tomcat, you can still using JSF by simply providing the JSF-Lib in your Application yourself.
With Maven (pom.xml), you define what your App needs, like JSF or JPA, that info is needed for compiling. Even if you use a Application Server like TomEE you'll still have to declare what you need, so the compiling works.
The only difference is the Maven Dependency Scope - if you use a Java EE Application Server, you should use the Scope provided, since the Application Server has all the Libs you'll need. If you use just Tomcat, you'll need the (default) scopecompile - that will include the Libs into your artifact (*.war-file).
If you use an Application Server, make sure, the versions in your pom.xml matches the versions used in your Application server, otherwise it could happen, that you write your Program for JSF 2.2, but your Server only supports 2.0.
When I create a web application from scratch and add jsf-api-2.2.11.jar and jsf-impl-2.2.11.jar to pom.xml (add them to apps classpath) and deploy it to Tomcat 7, JSf is initializing automatically:
INFO [j.e.r.w.j.config] - Mojarra 2.2.11 ( 20150505-0732 https://svn.java.net/svn/mojarra~svn/tags/2.2.11#14688) ..... initialized.
In older versions I used to start it declarativly by defining it in web.xml (listener+servlet). So I already commented them out and set "metadata-complete" to "true" (does that even stop classpath scanning?), but it is still loading.
In this case I dont want it to load, while leaving the Jars in classpath and i.e. the faces-config.xml in web-inf.
What is still triggering the initialization?
It's loaded via a Servlet 3.0 ServletContainerInitializer implementation in the JSF implementation JAR file (in case of Mojarra, it's the com.sun.faces.config.FacesInitializer). It will auto-register the FacesServlet on the URL patterns *.jsf, *.faces and /faces/* (JSF 2.3 will add *.xhtml to the list of URL patterns). Latest JSF 2.1 implementations and all JSF 2.2 implementations will do it when deployed to a Servlet 3.0 compatible container. For detail about this new Servlet 3.0 ServletContainerInitializer thing, head to this answer: ServletContainerInitializer vs ServletContextListener.
The right way to stop it is removing the JSF implementation from the dependencies (note that you do not need to remove the JSF API as well). You seem to not be making use of it in any way. After all, a properly designed web application should not have any JSF implementation specific dependencies. I only wonder, why exactly would you leave the JSF API in? Using a 3rd party JSF based library for non-JSF purposes? This might indicate and end up in other (architectural) problems.
Another way of stopping it is downgrading your web application to be Servlet 2.5 targeted by editing the <web-app> root declaration in web.xml accordingly to comply that version. But this has many other side effects which may not be desireable when the intent is to develop a Servlet 3.0 compatible web application.
The "listener" you're referring to is actually not necessary, it's only to workaround buggy containers with timing errors in parsing TLD files, such as early GlassFish v3 and Jetty versions. See also a.o. Configuration of com.sun.faces.config.ConfigureListener.
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'm migrating applications from WebSphere 7.0 to WebSphere 8.5. WebSphere 8.5 uses older version of MyFaces (2.0.2) than we use (2.0.7) so I've tried to configure the newer version in the same way as under WAS 7.0, that is, using shared library.
I've configured shared library with the following jars:
myfaces-api-2.0.7.jar
myfaces-impl-2.0.7.jar
commons-logging-1.1.1.jar
commons-digester-1.8.jar
commons-collections-3.2.jar
commons-codec-1.3.jar
I've checked the option Use an isolated class loader for this shared library . I've got the error:
com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E:
[Servlet Error]-[Faces Servlet]: java.lang.IllegalStateException: No
Factories configured for this Application. This happens if the
faces-initialization does not work at all - make sure that you
properly include all configuration settings necessary for a basic
faces application and that all the necessary libs are included. Also
check the logging output of your web application and your container
for any exceptions! If you did that and find nothing, the mistake
might be due to the fact that you use some special web-containers
which do not support registering context-listeners via TLD files and a
context listener is not setup in your web.xml. A typical config looks
like this;
<listener>
<listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
</listener>
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:196) at
javax.faces.webapp.FacesServlet.init(FacesServlet.java:112) at
com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:337)
The same configuration worked on WAS 7.0, with the exception that there was an additional jar configured in the shared library:
C:\IBM\SDP\runtimes\base_v7\optionalLibraries\IBM\JSFProviders\WebSphere-MyFaces20-annotation-provider.jar
What is wrong here? Do I need to specify something in place of that WebSphere-MyFaces20-annotation-provider.jar? I wasn't able to find any example of configuring such shared library for WAS 8.5. There's only that for WAS 7.0, that I've used successfully on WAS 7.0.
There is some related discussion in the WASdev forum but apparently no actual answer yet.
https://www.ibm.com/developerworks/community/forums/html/topic?id=d2261080-de03-4aef-97ce-b60c5b8a517b&ps=25
I am familiar with the classloading trouble when using JSF 2 in Websphere 7. I'd like to know if there are similar problems on other fullstack application servers. What about JBoss 5+, WebLogi 10+, etc? Are there any known issues with JSF 2 and if so, what needs to be done to get JSF 2 running on these servers?
Thx
On WebSphere 5.x up to with the current 8.x you need to set the WAR and EAR classloader to PARENT_LAST in the WAS admin console whenever you want to bundle and use your own JSF impl in /WEB-INF/lib.
On JBoss 4.x up to with the current 6.x it's sufficient to add the following context param to /WEB-INF/web.xml to suppress JBoss' builtin JSF deployer.
<context-param>
<param-name>org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL</param-name>
<param-value>true</param-value>
</context-param>
On Glassfish 2.x up to with the current 3.x you need to add the following entries to the /WEB-INF/sun-web.xml (Eclipse with Glassfish plugin should autogenerate the template file if you create a web project with target runtime set to Glassfish).
<class-loader delegate="false" />
<property name="useBundledJsf" value="true" />
On Weblogic, sorry I have no idea, I have never used it.
In WebLogic there is a shared Java EE library that is included with WebLogic for JSF 2.0. It is easy to use and referenced through a deployment descriptor.
Here is a brief how-to for the library concept Jeff mentioned.
http://blog.eisele.net/2009/07/jsf-20-beta-1-on-oracle-weblogic-10gr3.html
Seeing the latest WLS 12c it still is in place but AFAIK you will end up having to revert the web-app classloader in the future in favor of this concept.