My application is built on JSF 2.2.4 and EJB 3.2. It is not using CDI. Application is running on WildFly 8.2. Should we disable weld subsystem if CDI is not using?
It worked for me:
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<exclude-subsystems>
<subsystem name="weld" />
</exclude-subsystems>
</deployment>
<sub-deployment name="app.war">
<exclude-subsystems>
<subsystem name="weld" />
</exclude-subsystems>
</sub-deployment>
</jboss-deployment-structure>
See More On https://developer.jboss.org/message/851218
Related
I have a web application which is based on JSF 1.2 . The JSF jars are packed in the WAR library. We we try to deploy the war in JBoss EAP 7.0 , the war gets deployed successfully but the application does not run.
I found that JBoss EAP 7.0 does not support JSF 1.2 . My web application is not JSF 2.0 complaint. It will be great help if some body can list down steps to do so.
Thanks
Please try these steps:
Add a deployment-structure.xml to your project (WEB-INF/jboss-deployment-structure.xml to the WAR or META-INF/jboss-deployment-structure.xml to the EAR) with the exclusions:
<exclusions>
<module name="javax.faces.api" slot="main" />
<module name="com.sun.jsf-impl" slot="main" />
<module name="org.jboss.as.jsf-injection" slot="main" />
</exclusions>
Import all dependecies in pom.xml, what jsf need. Like that:
<dependency>
<groupId>javax.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>1.2-b19</version>
</dependency>
<dependency>
<groupId>javax.faces</groupId>
<artifactId>jsf-impl</artifactId>
<version>1.2-b19</version>
</dependency>
<dependency>
<groupId>com.sun.facelets</groupId>
<artifactId>jsf-facelets</artifactId>
<version>1.1.11</version>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<version>1.1.0</version>
</dependency>
Actually this combination worked for me on EAP 7 version of JBOSS 7.1.5 servers.
This way I was able to load jsf1.2 jars from my WEB-INF/lib folder rather than what was supplied by JBOSS 7.1.5.
I had a EAR file which had the WAR file.
Web.xml:
<context-param>
<param-name>org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL</param-name>
<param-value>true</param-value>
</context-param>
In ear META-INF/jboss-deployment-structure.xml
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<ear-subdeployments-isolated>true</ear-subdeployments-isolated>
<deployment>
<exclusions>
<module name="javax.faces.api" slot="main" />
<module name="com.sun.jsf-impl" slot="main" />
</exclusions>
</deployment>
<sub-deployment name="yourwarfilename.war">
<exclusions>
<module name="javax.faces.api" slot="main" />
<module name="com.sun.jsf-impl" slot="main" />
</exclusions>
</sub-deployment>
</jboss-deployment-structure>
I'm trying to use the last version of libs in my project. But Jboss EAP 6.2 already have some old libs, so i created a jboss-deployment-structure.xml and move to 'WEB-INF/' folder. See the file:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<deployment>
<exclusions>
<module name="com.sun.jsf-impl" slot="1.2"/>
<module name="javax.faces.api" slot="1.2" />
<module name="org.jboss.weld.core"/>
</exclusions>
</deployment>
</jboss-deployment-structure>
In my pom.xml i added some libs that i need:
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>2.2.13</version>
</dependency>
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-impl</artifactId>
<version>2.2.13</version>
</dependency>
<dependency>
<groupId>org.jboss.weld</groupId>
<artifactId>weld-core</artifactId>
<version>2.3.5.Final</version>
</dependency>
<dependency>
<groupId>org.omnifaces</groupId>
<artifactId>omnifaces</artifactId>
<version>2.4</version>
</dependency>
The jboss should ignore jsf 1.2 and weld provided and use my libs in pom.xml, right ? But when i start the jboss i got the following error:
Caused by: java.lang.NoSuchMethodError: com.sun.faces.util.Util.isCdiOneOneOrGreater()Z
So i changed my jboss-deployment-structure.xml to this:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<deployment>
<exclude-subsystems>
<subsystem name="jsf-impl"/>
<subsystem name="weld"/>
</exclude-subsystems>
</deployment>
</jboss-deployment-structure>
Now, console don't show error but when i try access my jsf page i got 404 page not found.
I have a multimodule maven project with JavaFX up and running. I can create an jar file containing all classes that is executable through a maven assembly, so I know the packaged bundle works.
For conveniance I want to create a native bundle/executable using the javafx-maven-plugin
<profile>
<id>build-installer</id>
<properties>
<native.output.dir>${project.build.directory}/jfx/native/${project.build.finalName}</native.output.dir>
<native.output.dir.app>${native.output.dir}/app</native.output.dir.app>
<native.output.dir.security>${native.output.dir}/runtime/jre/lib/security</native.output.dir.security>
<native.app.jar>${native.output.dir.app}/${project.build.finalName}-jfx.jar</native.app.jar>
</properties>
<dependencies>
<dependency>
<groupId>ch.sahits.game</groupId>
<artifactId>OpenPatricianDisplay</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>com.zenjava</groupId>
<artifactId>javafx-maven-plugin</artifactId>
<version>8.1.2</version>
<configuration>
<mainClass>ch.sahits.game.OpenPatrician</mainClass>
<verbose>true</verbose>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>native</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<id>create zip archive</id>
<phase>install</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<echo>Creating self-contained zip</echo>
<zip destfile="${project.build.directory}/OpenPatrician-${project.version}.zip" basedir="${native.output.dir}" />
</target>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
This works fine on Windows, creates an exe file that can be run. However executing the same thing on Linux, Maven runs through but the executable fails to start properly with these two messages:
OpenPatricianDisplay-0.5.0-SNAPSHOT No main class specified
OpenPatricianDisplay-0.5.0-SNAPSHOT Failed to launch JVM
Taking a look at the cfg files of the Windows and Linux bundle shows that they are different. When replacing the Linux one with the one from Windows a different errors is created. So I do not think the fact that they are different is the cause.
Creating a single module JavaFX demo app with the plugin on Linux works. To figure out if it is the Maven plugin or the underlying packager, I tried the following the Ant examples. The Hello World example works fine (chapter 10.4.1) however when trying the example with external jar files (chapter 10.4.3) even the build fails:
BUILD FAILED
/home/andi/eclipse/intellij/jdk1.8.0_60/demo/javafx_samples/src/Ensemble8/build.xml:34: You must specify at least one fileset to be packed.
The build.xml
<?xml version="1.0" encoding="UTF-8" ?>
<project name="Ensemble8 JavaFX Demo Application" default="default" basedir="."
xmlns:fx="javafx:com.sun.javafx.tools.ant">
<property name="JAVA_HOME" value="/usr/lib/jvm/java-8-oracle"/>
<path id="CLASSPATH">
<pathelement location="lib/lucene-core-3.2.0.jar"/>
<pathelement location="lib/lucene-grouping-3.2.0.jar"/>
<pathelement path="classes"/>
</path>
<property name="build.src.dir" value="src"/>
<property name="build.classes.dir" value="classes"/>
<property name="build.dist.dir" value="dist"/>
<target name="default" depends="clean,compile">
<taskdef resource="com/sun/javafx/tools/ant/antlib.xml"
uri="javafx:com.sun.javafx.tools.ant"
classpath="${JAVA_HOME}/lib/ant-javafx.jar"/>
<fx:application id="ensemble8"
name="Ensemble8"
mainClass="ensemble.EnsembleApp"/>
<fx:resources id="appRes">
<fx:fileset dir="${build.dist.dir}" includes="ensemble8.jar"/>
<fx:fileset dir="lib"/>
<fx:fileset dir="${build.classes.dir}"/>
</fx:resources>
<fx:jar destfile="${build.dist.dir}/ensemble8.jar">
<fx:application refid="ensemble8"/>
<fx:resources refid="appRes"/>
</fx:jar>
<fx:deploy outdir="." embedJNLP="true"
outfile="ensemble8"
nativeBundles="all">
<fx:application refId="ensemble8"/>
<fx:resources refid="appRes"/>
<fx:info title="Ensemble8 JavaFX Demo Application"
vendor="Oracle Corporation"/>
</fx:deploy>
</target>
<target name="clean">
<mkdir dir="${build.classes.dir}"/>
<mkdir dir="${build.dist.dir}"/>
<delete>
<fileset dir="${build.classes.dir}" includes="**/*"/>
<fileset dir="${build.dist.dir}" includes="**/*"/>
</delete>
</target>
<target name="compile" depends="clean">
<javac includeantruntime="false"
srcdir="${build.src.dir}"
destdir="${build.classes.dir}"
fork="yes"
executable="${JAVA_HOME}/bin/javac"
source="1.8"
debug="on"
classpathref="CLASSPATH">
</javac>
<!-- Copy resources to build.classes.dir -->
<copy todir="${build.classes.dir}">
<fileset dir="src/app/resources"/>
<fileset dir="src/generated/resources"/>
<fileset dir="src/samples/resources"/>
</copy>
</target>
</project>
So it looks the examples are not up to date with Java 1.8.0_60. The only difference to the build.xml from the example is the path to the JAVA_HOME.
Does anyone have an idea on:
a) how to approach the issue with the ant build to prove/disprove that the packager is the problem or
b) even better have some insights into what might be the problem when running the maven plugin.
Environment:
Linux Mint 17.2 KDE
JDK 1.8.0_60
Ant 1.9.3
Maven 3.0.5
javafx-maven-plugin 8.1.4
This is at least a partial answer to the issue with the build for ant. As it turns out the documentation is outdated, but I figured it out when taking a look at the Ant task definition.
The <fx:jar> elements requires some more children for it to work:
<fx:application id="ensemble8"
name="Ensemble8"
mainClass="ensemble.EnsembleApp"/>
<fx:resources id="appRes">
<fx:fileset dir="${build.dist.dir}" includes="ensemble8.jar"/>
<fx:fileset dir="lib"/>
<fx:fileset dir="${build.classes.dir}"/>
</fx:resources>
<fx:jar destfile="${build.dist.dir}/ensemble8.jar">
<fx:application refid="ensemble8"/>
<fx:resources refid="appRes"/>
<fx:fileset dir="${build.classes.dir}"/>
<!-- Customize jar manifest (optional) -->
<manifest>
<attribute name="Implementation-Vendor" value="Samples Team"/>
<attribute name="Implementation-Version" value="1.0"/>
<attribute name="Main-Class" value="ensemble.EnsembleApp" />
</manifest>
</fx:jar>
Especially the <manifest> and the <fx:fileset>. With that in place I can create the demo application as native bundle that is executable.
EDIT: The original issue with the javafx-maven-plugin turns out to be a problem in the packager itself and the lookup of the configuration file. Updating to version 8.1.5 and adding <bundler>linux.app</bundler> in the <configuration> is a workaround until the issue is fixed in the JDK.-
I've been Using Eclipse/Ant for some time and decided to take a look at Netbeans/Maven for my JSF development. Along the way, I thought I'd try to use a version of Mojarra that is newer than the one I have installed in glassfish/modules. I can't seem to get that to work, and since I'm new to both Maven and Netbeans, I'm not sure if it's something with those, or something else.
I've made a very simple app which uses a backing bean to print out the Mojarra version from the index page:
Info.java:
#Named
#RequestScoped
public class Info
{
public String getVersion()
{
return FacesContext.class.getPackage().getImplementationVersion();
}
}
index.xhtml:
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://xmlns.jcp.org/jsf/html">
<h:body>
<h:outputText value="The Mojarra version is #{info.version}" />
</h:body>
</html>
When I run this, I see the page contents of
The Mojarra version is 2.2.5
as I'd expect (I put the 2.2.5 jar into glassfish/modules some time back). I then added the dependency for Mojarra 2.2.7 that I found from the Mojarra Web Site:
<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.faces</artifactId>
<version>2.2.x</version>
</dependency>
with "x" replaced by "7". The resulting POM file looks like this (most of it is boilerplate from Netbeans):
POM.xml:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany</groupId>
<artifactId>mavenproject1</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>war</packaging>
<name>mavenproject1</name>
<properties>
<endorsed.dir>${project.build.directory}/endorsed</endorsed.dir>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-web-api</artifactId>
<version>7.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.faces</artifactId>
<version>2.2.7</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
<compilerArguments>
<endorseddirs>${endorsed.dir}</endorseddirs>
</compilerArguments>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.3</version>
<configuration>
<failOnMissingWebXml>false</failOnMissingWebXml>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<outputDirectory>${endorsed.dir}</outputDirectory>
<silent>true</silent>
<artifactItems>
<artifactItem>
<groupId>javax</groupId>
<artifactId>javaee-endorsed-api</artifactId>
<version>7.0</version>
<type>jar</type>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
When I run the app, there is no difference in the output, it still shows version 2.2.5. I found this article with an answer from #BalusC that mentions Glassfish must be explicitly told to override the installed version of faces to use an alternate version deployed with the app, by putting this in WEB-INF/glassfish-web.xml for early versions of GF3:
<class-loader delegate="false" />
<property name="useBundledJsf" value="true" />
Even though I'm using GF4, I thought I'd give it a try, and added a glassfish-web.xml with this:
glassfish-web.xml:
<glassfish-web-app error-url="">
<class-loader delegate="false" />
<property name="useBundledJsf" value="true" />
</glassfish-web-app>
The result is a page that has shows the message with an empty version string:
The Mojarra version is
The GF log also indicates no errors. The .war file that is created includes WEB-INF/lib/javax.faces-2.2.7.jar, so I suspect the problem has something to do with the GF configuration, rather than the Netbeans/Maven packaging.
I know I can download the 2.2.7 jar and put it in the glassfish/modules directory (which is how I began using 2.2.5). But the ultimate goal is to try alternate versions of JSF in an app-specific way (ideally, by just changing Maven coordinates for the JSF dependency), rather than change the GF install. Is there anyway to do this through configuration of the app and without altering the GF install?
Update 9/14/2015:
I built a new Netbeans project:
GlassFish 4.1 (out of the box), which has Mojarra 2.2.7, by default.
NB Maven/Web Application project, with JSF 2.2 Framework.
Modified the index.xhtml file as shown above.
Added a Info.java class, containing the contents, above (javax.enterprise.context.RequestScoped, javax.inject.Named).
Added a WEB-INF/glassfish-web.xml and added the lines shown above.
Added the dependency to the pom.xml file as shown above, but using javax.faces version 2.2.12.
Essentially, I'm getting the same result. If the useBundledJsf property setting is not in the glassfish-web.xml file, the version displays as 2.2.7 (even though the war file has 2.2.12 in it). And if the useBundledJsf property setting is there, along with the change to the class-loader to "false", the version is blank.
I also installed Mojarra 2.2.10 by changing the javax.faces file in the glassfish install to use 2.2.10. When I do that, I get the same results -- either the version is empty, or it shows 2.2.10 (2.2.12 is still configured, and in the war in both cases).
An alternative solution can be to try Payara 4.1.1.154 as it comes bundled with Mojarra 2.2.12
I think this can be a good solution for your needs.
This section details the modules that have been updated since the last release (4.1.153).
Mojarra 2.2.12
Webservices 2.3.2-b608
JAXB 2.2.12-b141219.1637
JAXB-API 2.2.13-b141020.1521
Weld 2.2.16.Final
Tyrus 1.11
JBatch 1.0.1-b09
Grizzly 2.3.23
HK2 2.4.0-b32
Jersey 2.22
Hazelcast 3.5.2
I'm trying to extract the Omnifaces library from a .war archive to JBoss module, however, there are problems with org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type org.omnifaces.cdi.ViewScoped. Application deploys successfully but breaks on first page load.
I've read BalusC's report on problems with .wars packaged in .ear (http://balusc.blogspot.com/2013_10_01_archive.html) but I'm not sure if it applies to this situation as well since we have only .war.
When the Omnifaces library is included in .war's lib folder via Maven as a compile time dependency everything works flawlessly:
<dependency>
<groupId>org.omnifaces</groupId>
<artifactId>omnifaces</artifactId>
<version>1.7</version>
</dependency>
Setting the dependency to provided scope, creating a JBoss module and appending the jboss-deployment structure to:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="org.omnifaces" export="true" meta-inf="import"/>
<!-- i tried multiple export and meta-inf combinations -->
</dependencies>
</deployment>
</jboss-deployment-structure>
module.xml:
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.0" name="org.omnifaces">
<resources>
<resource-root path="omnifaces-1.7.jar"/>
</resources>
<dependencies>
<module name="javaee.api"/>
<module name="javax.api"/>
<module name="javax.faces.api" />
</dependencies>
</module>
Is it possible to use Omnifaces this way, as a JBoss module?
OmniFaces is as being a JSF utility library designed as WAR module, not as EAR or appserver module.