I'm wondering whether anyone had an exprecience in deploying the DocuSign Java Client on WildFly 10?
DocuSign jvaa SDK depends on Jersey 1.19, while the wildfly 10 supports RESTEasy out of the box > is it possible to disable RESTEasy ?
Or will it be safe to use the RESTEasy as an JAX-RS implementation (instead of the Jersey 1.19)?
Thank you.
Will answer by myself: excluding the wildfky subsystem "jax-rs" in jboss-deployment-structure.xml works fine:
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<exclude-subsystems>
<subsystem name="jaxrs" />
</exclude-subsystems>
</deployment>
....
</jboss-deployment-structure>
Related
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
My application server is Glassfish 3.1.1, using Mojarra 2.0.3 FCS (as far as I know). I want my application to use JSF 2.1.2. I've already found the correct artifact to use in my maven build.
Now, how can I make sure the JSF classes are loaded from this artifact, instead of following "classical" delegation to Glassfish libvrary classloader (which will load JSF 2.0.3 and generate ClassNotFoundException for my omnifaces/richfaces additional components) ?
In general, how to override a specific Java EE artifact from an archive is application server specific. In case of GlassFish, if I'm not mistaken you can use the following in WEB-INF/glassfish-web.xml:
<glassfish-web-app error-url="">
<class-loader delegate="false" />
<property name="useBundledJsf" value="true" />
</glassfish-web-app>
What also works is replacing the jar in [glassfish home]/glassfish/modules. This is exactly what the JSF build script does as well, so it should be guaranteed to work.
Do note that if you go from something as low as 2.0.3 to a current version, you'll see that there has been a change from 2 jars to 1 jar. So in that case in [glassfish home]/glassfish/domains/domain1/config/default-web.xml and [glassfish home]/glassfish/lib/templates/default-web.xml remove the entries jsf-api.jar and jsf-impl.jar and replace them by a single javax.faces.jar.
Perhaps an even easier alternative is to download the latest version of GlassFish (3.1.2.2).
When I am using flash scope in glassfish it lives longer than one request but works fine with jetty8 and even tried the latest version of glassfish but its not working. The JSF has a jira about it and they have solved it in the next version, I have even tried that version of jars for JSF but still same problem persists in Glassfish but works fine for Jetty8. Facing this problem from many days can anyone throw some light on this??
Jetty as being a barebones servletcontainer doesn't come with any JSF implementation bundled and the one supplied along with the webapp will always be used.
Glassfish as being a fullfledged Java EE applicationserver comes with a JSF implementation bundled and the one supplied along with the webapp will by default always be ignored. If you'd like to upgrade the Glassfish-bundled JSF implementation, then you should be replacing the JAR in /glassfish/modules folder. Or, if you'd like to force Glassfish to use the webapp-supplied JSF implementation, then you should add the following entries to /WEB-INF/glassfish-web.xml (or sun-web.xml, depending on GF version used):
<class-loader delegate="false" />
<property name="useBundledJsf" value="true" />
I had the same issue. The problem was caused by Mojarra (even 2.1.11) not able to cope with HTTP chunking. By disabling it the flash was emptied as expected.
You can disable it in the admin console
Configurations
server-config
Network Config
Protocols
http-listener-[N]
HTTP tab
Chunking
i have developed an application using jsf 1.2. it worked fine with apache tomcat 6. i took the war file on production with websphere 7 and deployed the application. i recieved following error.
E com.ibm.ws.webcontainer.servlet.ServletWrapper init SRVE0100E: Uncaught init()
exception created by servlet Faces Servlet in application Products_war:
java.lang.IllegalStateException: Application was not properly initialized at startup,
could not find Factory: javax.faces.context.FacesContextFactory
my classpath file has following entries
<?xml version="1.0" encoding="UTF-8"?>
<classpath>
<classpathentry kind="src" path="src"/>
<classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER/
org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/jre6"/>
<classpathentry kind="con"
path="org.eclipse.jst.server.core.container/org.eclipse.jst.server.tomcat.runtimeTarget
/Apache Tomcat v6.0"/>
<classpathentry kind="con" path="org.eclipse.jst.j2ee.internal.web.container"/>
<classpathentry kind="con" path="org.eclipse.jst.j2ee.internal.module.container"/>
<classpathentry kind="output" path="build/classes"/>
</classpath>
i have made following tries after googling till now..
including following listener in web.xml
<listener>
<listener-class>com.sun.faces.config.ConfigureListener</listener-class>
</listener>
and removed jsf-api and jsf-impl from the lib folder of my application but to no avail.
plz help.
thanks in advance
WAS 7 already ships with JSF 1.2 bundled which can be either the "Sun RI" (Mojarra) or "MyFaces" (from Apache) implementation which is configureable in the WAS admin console. You need to remove the JSF JAR files from /WEB-INF/lib and you need to remove the listener from the web.xml.
See also:
WAS 7 developer guide - Configuring JavaServer Faces implementation
Another thing to check: We have myfaces configured as a shared library on WebSphere. In troubleshooting my local configuration I had to set the shared library to "Use an isolated class loader for this shared library"
This is identified as part of the requirements for running a third-party JSF implementer:
Be Aware: If the you want to use a third party JSF implementation that is not shipped with the product, then:
Keep the configuration set to the SUN RI.
Add the third party listener to the web.xml file that is required.
Add the third party implementation Java archive (JAR) files to the
application as an isolated shared library.
http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/tweb_jsf.html
Maybe this will help someone if the first answer doesn't work for them.
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.