I want to use OmniFaces 1.7 in my Jave EE 7 application. My application is an EAR that contains JARs and a skinny WAR. Some of my JARs have a dependency to OmniFaces, so the OmniFaces artifact must be in the EAR but not in WEB-INF/lib in the WAR.
Here is how my EAR looks like:
EAR
+-- lib
| +-- [some 3rd party JARs]
| `-- omnifaces.jar
+-- myEJBs.jar
`-- myWAR.war
When I put it this way, OmniFaces converters (like GenericEnumConverter) are not registered with JSF and won't work. The reason for this is discussed here and here. Basically according to the JSF 2.0 Spec (section 11.5.1 Requirements for scanning of classes for annotations), only the WARs WEB-INF/lib directory is scanned.
So my question is: how should I include OmniFaces in my application?
Including it twice (in EAR/lib and WARs WEB-INF/lib) could possibly work but feels clumsy. I tried it some time ago with RichFaces 4.3.5 (same problem) which didn't work but led to IllegalArgumentException: duplicate key: class javax.faces.convert.ByteConverter.
OmniFaces is a JSF utility library with dependencies on JSF, EL and Servlet APIs, which are normally only available inside a WAR, not an EAR. Even more, your EJBs (business services in general) are not supposed to have any dependencies on specific front-end APIs such as JSF, EL and Servlet APIs. It would make them unreusable on other front-ends such as JAX-RS, Spring MVC, etc.
You need to put JSF utility and component libraries such as OmniFaces and PrimeFaces in WAR, not in EAR. See also Installation section of OmniFaces homepage:
OmniFaces is designed as a WAR library (web fragment library) and therefore can't be placed elsewhere in the webapp's runtime classpath outside WAR's own /WEB-INF/lib, such as EAR's /lib or even server's or JRE's own /lib. When OmniFaces JAR file is misplaced this way, then the webapp will be unable to find OmniFaces-bundled JSF/CDI annotated classes and throw exceptions related to this during deploy or runtime. To solve it, put back OmniFaces in WAR's /WEB-INF/lib.
See also:
JSF Service Layer
#FacesComponent on shared library
#Eager is unavailable. The EagerBeansRepository could not be obtained from CDI bean manager
Related
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?
I have a multi module maven project (a Java EE app with ear, persistence, web, ejb, api, bl and other modules), where I'd like to use Weld CDI.
When I try to inject a bean, where will Weld search for injectable beans? Will Weld search in all the modules, where a beans.xml is placed to WEB-INF or META-INF regardless from their dependencies (or dependencies matter somehow?), or will Weld be able to inject a bean from an other deployment? I tried to find a document, which describes the mechanism and boundaries of bean lookup, but I haven't found anything yet.
What you're describing is part of the overall EE spec, not the CDI spec. but yes, in general the contents of your EAR will be discovered as distinct applications (per the EE spec). This means that you may not be able to access individual beans across JARs. It is highly recommended to use WAR deployment with CDI.
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'm using Websphere 8.5 and its internal Java EE frameworks, Apache OpenWebBeans for DI & Apache MyFaces for view. I also have a JAR with some beans annotated with "#Named" (so, they're OpenWebBeans managed beans). This JAR is in the "WEB-INF/lib" directory of my web application and in the application's classpath.
I was told that I should put a "beans.xml" file in every JAR that I want the CDI implementation to find and manage beans. I did just that (there's a "beans.xml" file in the "META-INF" folder of the application and in the same folder of the JAR) and everything works flawless in Tomcat 7 (I can access my beans on JSF pages, everything gets injected and resolved without any problems, etc). I'm running Tomcat with Apache Open Web Beans 1.2 and MyFaces 2.0 JARs inside the application's "WEB-INF/lib".
Now, the problem: in Websphere, with the same configuration (without the framework JARs inside the application's "WEB-INF/lib", just my bean's JAR) I get a NoClassDefFoundError referring to a JSF class, "javax.faces.component.behavior.Behavior" everytime I try to load a page (no page loads, btw). Bizarrely, when I remove all "beans.xml" files from the application and from the JAR, everything works as expected with JSF (except OpenWebBeans bean loading and management, of course, since there's no "beans.xml" present).
I searched everywhere for this problem and can't find any clue about it. I know that this class is avaliable to websphere, since I searched the server JARs and found it at "WEBSPHERE_INSTALL\plugins\javax.j2ee.jsf.jar" (and also because without the "beans.xml", this class is found and everything works properly), but I have no clue why this JAR isn't loaded when any"beans.xml" file is present in the application's classloader. Can somebody help, please?
WebSphere really needs a WEB-INF/beans.xml file in your WAR! Otherwise WAS doesn't 'activate' CDI. This is actually not required by the spec, bnd adding this file at least isn't forbidden. It will simply make all your classes in WEB-INF/classes CDI beans.
Just having the META-INF/beans.xml in some jars around doesn't help.
That's the way WAS works, it's a minor thing once you know it. I didn't even bother to create a PMR ;)
I have made a jsf 1.1 portlet in weblogic 10.3, but in one scenario I need tomahawk library help. I just dropped the jar file and supporting ones in lib folder in WEB-INF in my portal application, but when I hit the url it gives me error of NoClassdef..... exception for classes in tomahawk jar and jsp compilation fails.
I am new to weblogic, I'll really appreciate if someoe can suggest what I might be doing wrong.
The setup is that whole application goes as ear. Ear contains app-inf and weblogic specific xml files, main portal web application goes as war inside this ear. I am using workshop that ships with weblogic portal 10.3. Well this project was migrated from weblogic portal 9.3.
Note: I dont want to but this jar in domain/lib, when I did so I dont know why it loaded my application and all the class defined in servlet startup with load-on-startups got fired well before time and none of the classes were found by server.
Jsf libraries currently used are in shared mode.
java.lang.NoClassDefFoundError means the runtime version of the class in the classpath is not the same as that at compile time.
Note: it's not a ClassNotFoundException.
Your problem is in fact multiple versions of the class being found.
Also, JSF 1.2 libraries are bundled with Weblogic server, so it can cause this exception if one of those classes is again added into the WEB-INF/lib. Which is the exact class on which the error is thrown, do you have multiple versions of Tomahawk lying around in WEB-INF and domain/lib?
Remove the extras and keep one in WEB-INF/lib only.
Update:
The docs state that Separate JSF 1.2 and JSTL 1.2 JAR files and implementation JAR files are also provided in the WL_HOME/server/lib/api.jar file.
Check for that class javax/faces/webapp/UIComponentELTag in this jar.
I still think you should use the weblogic.xml setting to force the WEB-INF/lib class to get loaded in preference to that in server/lib with
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>
Being new to weblogic and infrastructure I messed up with different versions. Figured out it was just because of incompatible jars.