Is JSF available as an OSGi (Equinox) bundle? - jsf

There is a bundle for JSP/JSTL, which can be deployed on Equinox OSGi Framework and can be used by other bundles then:
org.eclipse.equinox.jsp.jstl_1.0.0.jar
Is there also a bundle for JSF, so i can use JSF components in my bundles?
I really need to solve this issue, because i have to transform an extisting JSF Web Application to an OSGi Framework suited application.
Help please!

Recent versions of Mojarra, the JSF reference implementation, and of Apache MyFaces are available as OSGi bundles from Maven Central.
There is no need to use repackaged distributions like those from SpringSource.

Yes there is an osgi bundle.
You can pick one from
springsource.com/repository/app

Related

Custom JSF Implementation With Custom DI Framework

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

Purpose of jsf-api.jar and jsf-impl.jar [duplicate]

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?

JSF and cloudControl

I'm learning Java EE and it appear to me that One of the things to Know is JSF
I'm also sing cloudControl but I haven't found a Way to Deploy a JSF Applications there.
Is there a way of deploying a JSF Applications on cloudControl ?
As mentioned in the comment, you need to provide some implementation of JSF as a dependency together with embedded jetty or tomcat runner. Here you can find some example apps for tomcat and jetty. Maybe it would be also helpful for you to have a look on our existing java guides.

Dynamic Web Project with Seam Faces

I tried to start a new dynamic Web Project with Seam-Faces(Eclipse). I created a new JSF-Facility and addeed all the jar-Files from the official Seam-Faces homepage. When i try to create a dynamic web project eclipse says that the following File ist not found:
javax.faces.FactoryFinder
What i am doing wrong ? Is ist possible to use Seam-Faces without the Seam-Framework ?
There is not a Seam Framework anymore. Seam 3 is a bunch of reusable CDI extensions that you could use. The best way to start with Seam3 modules is to use maven for library management. More info about how to configure seam-faces dependencies can be found here.
For the exception you're facing make sure there are no jsf jars in WEB-INF\lib in case you're using a Java EE server like JBoss AS or Glassfish. For more info look here.

Can we have two different jsf version in same EAR

I am using JSF1.1 for my project. The workspace includes EAR, Dynamic web module and Java projects.
Now i want to have one more Dynamic web module with JSF2.1. it is possible?
and Is this a good practice to have two different versions of JSF in the same EAR.
Yes, it is possible. Each web module within the EAR can have it's own JSF version as long as the dependencies are packaged within each WAR. You will want to ensure a parent-last classloading approach as well.

Resources