I'm trying to upgrade a legacy Java EE application to Jakarta EE 8 on a Wildfly server. Most of the upgrade has gone smoothly since 8 doesn't swap the package names to jakarta yet. However, some of our code is using classes from Oracle's com.sun.faces package. These classes appear to be included in the Jakarta EE Faces API specification, but they are not included in our project when I use the following Maven dependency:
<dependency>
<groupId>jakarta.faces</groupId>
<artifactId>jakarta.faces-api</artifactId>
<version>2.3.2</version>
<scope>provided</scope>
</dependency>
To get these in the classpath, I have to use the Oracle dependency:
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-impl</artifactId>
<version>2.2.20</version>
<scope>provided</scope>
</dependency>
Obviously, we want to ditch using this package altogether at some point, but I was hoping there was a way to include this in our Jakarta migration.
The com.sun.faces.* is not part of Jakarta EE API. It's part of the Jakarta EE implementation. More precisely, it's the actual JSF implementation. Its name is "Mojarra".
You should indeed not need to have a dependency on it in your pom.xml in order to be JEE-implementation-independent (i.e. in order to be able to deploy your webapp to any JEE-compatible server without any code changes). If the code however doesn't compile when you remove it, then you apparently have somewhere a hard dependency on it, e.g. a hardcoded import or superclass referring to com.sun.faces.* package. This is indeed usually not correct.
The solution should be straight forward:
Remove that Mojarra dependency
Find all compilation errors
Fix them one by one by using the standard JSF API approach
If no one could be found, research or ask on Stack Overflow
Related
is possible remove Jhipster Dependencies in back? why is necessary or recommended???
IF I REMOVE OF POM.XML appears different compilation errors.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>io.github.jhipster</groupId>
<artifactId>jhipster-dependencies</artifactId>
<version>${jhipster-dependencies.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<!-- jhipster-needle-maven-add-dependency-management -->
</dependencies>
</dependencyManagement>
Is it possible?
Yes but you have to import all the dependencies yourself although nothing very difficult because most of them are already provided as Spring Boot starters. Looking at effective pom with mvnw help:effective-pom could help.
Then you must import maven plugins configuration.
Finally, your project will still depend on jhipster-framework library unless you extract only the classes your project needs.
Is it recommended?
For long term, managing yourself your dependencies is a good thing because major libraries like Spring Boot, Hibernate, ... support old releases for quite a long time while JHipster team supports only current major release (currently 7.x) which usually means one year.
At the beginning of your project, you will probably want to be able to follow JHipster updates. Modifying the pom.xml will make updating generated code more difficult.
Once you have written much manual code, your project is probably already too difficult to update, so cutting the dependency with JHipster will be harmless.
I found it harder to remove dependency from JHipster frontend than from backend because for instance ng-jhipster has some dependencies on Bootstrap that require some effort to remove.
I'm follow this docs this docs
and add maven depency:
<dependency>
<groupId>org.springframework.integration</groupId>
<artifactId>spring-integration-sftp</artifactId>
<version>5.0.0.M6</version>
</dependency>
<dependency>
<groupId>org.springframework.integration</groupId>
<artifactId>spring-integration-java-dsl</artifactId>
<version>1.2.3.RELEASE</version>
</dependency>
But it cannot resolve these method:
does I miss anything?
Starting with Spring Integration 5.0, whole Java DSL project is merged to the core project. So, you don't need that extra spring-integration-java-dsl dependency anymore. More over it isn't compatible with Spring Integration 5.0.
There is no any more such a handleWithAdapter() since there is no single entry point because all the namespace factories are distributed between appropriate modules.
So, right now you have to do this:
.handle(Sftp.outboundGateway(...))
See Migration Guide for more info.
And also follow back to the past from release blog post.
I need to bundle JSF implementation in my WAR file due to known bug in the original mojarra implementation.
I am not allowed to replace the JSF implementation in the modules, so i am using the useBundledJsf property.
Running Payara Version: Payara Server 4.1.1.164 #badassfish (build 28)
This versions should support useBundledJsf properly.
I have added this to my glassfish-web.xml:
<class-loader delegate="false" />
<property name="useBundledJsf" value="true" />
and added the javax.faces dependecy to my pom:
<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.faces</artifactId>
<version>2.2.13</version>
</dependency>
I am getting the following error and all injections are failing.
SEVERE: JSF1051: Service entry 'org.glassfish.faces.integration.GlassFishInjectionProvider' does not extend DiscoverableInjectionProvider. Entry will be ignored.
I have tried to add the weld-integration.jar to my project but it still produces the JSF1051 error following by:
Unable to create a new instance of 'org.jboss.weld.jsf.ConversationAwareViewHandler'
The dependency for the weld-integration i have used:
<dependency>
<groupId>org.glassfish.main.web</groupId>
<artifactId>weld-integration</artifactId>
<version>4.1.2</version>
<exclusions>
<exclusion>
<artifactId>*</artifactId>
<groupId>*</groupId>
</exclusion>
</exclusions>
There is an extra feature to make this easier in Payara Server 171 which was added specifically to make these scenarios work properly.
From the documentation:
It’s possible to configure an extreme isolation level on the class loading delegation for deployed applications. With this extreme isolation behavior, a deployed application can force the server to load only classes from libraries included on Payara Server that belong to whitelisted packages defined on its deployment descriptors.
To configure whitelist packaging you can use the <whitelist-package> element on the glassfish-web.xml (WAR artifacts) or the glassfish-application.xml (EAR artifacts). This element can be included multiple times to whitelist multiple packages. Here is an example of whitelisting both the Google Guava and Jackson packages for a WAR application:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">
<glassfish-web-app error-url="">
...
<whitelist-package>com.google.guava</whitelist-package>
<whitelist-package>com.fasterxml.jackson</whitelist-package>
</glassfish-web-app>
The whitelist syntax is simple: Define the name of the package which contains the classes in question. For example writing com.google would whitelist all Google libraries included on the server, while writing com.google.guava would only whitelist the Google Guava library instead.
Extreme Classloading Isolation
I know there are a lot of answer about these things, but I'm trying to clear my mind about jsf, mojarra, myfaces, primefaces.
Can you please confirm this summary?
JSF is the standard JAVA (by Oracle).
Mojarra (by Oracle) and Myfaces (by Apache) are two implementations of the standard JSF.
Myfaces Tomahawk is a component library as the same as PrimeFaces.
My configuration includes Java 1.8, Eclipse Luna, Apache Tomcat 8, Maven. I'm building a project with PrimeFaces.
So since Tomcat is not a Java EE Application Server, it does not include by itself an implementation of JSF, and I should add it explicitly.
On Eclipse I can include a JSF implementation using maven:
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>2.2.8-02</version>
</dependency>
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-impl</artifactId>
<version>2.2.8-02</version>
</dependency>
or Eclipse Project Facets:
the results will be exactly the same? Or I need to import both Mojarra and jsf-core, jsf-impl ?
Thank you!!
For Maven project with Eclipse, it is better to add JSF implementation in your POM file rather than using Eclipse provided JARs.
Myfaces, Primefaces and Richfaces are all JSF component libraries / frameworks but having not exactly the same features and the stability level also differs.
Other points you mentioned are correct.
I am searching the web for information regarding the usage of Oracle ADF as a component suite (and not as a development framework), alongside vanilla JSF (2.0).
I am working with a client that insists the solution uses the Oracle ADF UI components. The rest of the Fusion Middleware, however, can be completely skipped for all he cares. Therefore, I'd like to stay as close to the Java EE-JSF2 blueprints as possible, and only resort to ADF as a UI component library, as one would with PrimeFaces, for example.
So, the question - is it possible? Does ADF imposes limitations/dependencies that would prevent this scenario? Can we use it solely as a component library, or must we depend on its heavyweight framework to make them work?
It does not work; at least, not as one would expect. In short: ADF does indeed support JSF2 and Facelets, and they coexist nicely in a single application. As long as you don't mix them together.
I intended to use ADF as a component library, in a way similar to how one uses PrimeFaces or RichFaces: you add the correct dependencies, config what needs to be configured, and you're good to go. When Oracle says that ADF supports JSF2 and Facelets, this is the scenario that one would assume.
To start, you cannot use ADF components outside of a <af:document /> tag (or trinidad's counterpart); which means that content outside this tag is ignored, reducing the ability to use Facelets to a minimum. So, you'll hardly have any Facelets code on the same page where ADF components reside.
JSF + CDI integration is only available through the Mojarra implementation. Using MyFaces (the base for the current ADF version), one might make it work through updating the MyFaces jars and adding CODI, but it does not work out-of-the-box and I did not take the time to investigate it further.
To add to that, for layout management, you're stuck with the ADF way (through pageTemplateDef and pageTemplate tags), since mixing in Facelets is difficult due to the dependency on the document tag. So you see, Facelets support is there, "standard" JSF2 pages can exist in a ADF application - but to use ADF's components, you need to be in an ADF page.
To anyone that might be interested, once you populate your local maven repository using JDeveloper (as per the techniques suggested on the comments in the original question), the minimal dependencies to have ADF UI components in a web application (war) that can be run on WebLogic 12c or Glassfish with ADF essentials, are the following:
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-web-api</artifactId>
<version>6.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.oracle.adf</groupId>
<artifactId>trinidad-api</artifactId>
<version>12.1.2-0-0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.oracle.adf</groupId>
<artifactId>trinidad-impl</artifactId>
<version>12.1.2-0-0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.oracle.adf</groupId>
<artifactId>adf-richclient-api-11</artifactId>
<version>12.1.2.0.40.66.34</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.oracle.adf</groupId>
<artifactId>adf-richclient-impl-11</artifactId>
<version>12.1.2.0.40.66.34</version>
<scope>provided</scope>
</dependency>
You'll also need to add several other configuration files:
WEB-INF/adfc-config.xml
META-INF/adf-config.xml
META-INF/connections.xml
META-INF/wsm-assembly.xml
Along with further ADF boilerplate configuration on faces-config.xml and web.xml files.
So, the answer so far is:
Is it possible (to use ADF as a component library)? Yes.
Are there any limitations? There's no CDI (out of the box), and limited Facelets support. JSF2 ajax capabilities cannot be used within a ADF document - you must resort to the ADF partial page rendering, but JSF2 custom components and any ClientBehavior you may code work fine.
Is it worth the hassle? No.
Couple of months ago, Oracle ADF was supporting only JSF 1.2.
But with the release of JDeveloper 12c there are lots of new features and improvements over the IDE and over the Oracle ADF, for which there is JSF 2.0 Support now.
So, to answer your question - yes, you can use Oracle ADF with JSF2/Facelets.
If you just want a WAR through Maven do this (In JDeveloper 12c):
New Application -> Custom Application
Add the ADF Faces technology (shuttle to the right).
In the last step of the wizard choose "Use Maven".