JSF 2.1 with Payara 5

[Darren H]

Hi all, 

I've been trying to get Icefaces 3.3, which uses JSF 2.1, working on Payara 5 which ships with a newer version of JSF. I've tried bundling JSF 2.1 with the war using the useBundledJSF option plus turning the class-loader delegation off and using the whitelist-package options to get it deployed but still get problems with JSF interfacing with weld. Has anyone tried this before and got any ideas as to how to get this working? Any suggestions most welcome.

Many thanks in advance,

Darren

[Eduard Drenth]

Never tried that. Newer version of JSF should be backward compatible, see https://javaee.github.io/javaserverfaces-spec/downloads/JSF_2_3/Final/JSF_2.3.pdf about that.

What exact problems do you run into?

Perhaps explicitely declaring the jsf version you want helps?

Upgrading icefaces/jsf would ofcourse be best, but may have some impact.

Bye, Eduard

Op dinsdag 23 april 2019 19:15:09 UTC+2 schreef Darren H:

[Darren H]

Hi Eduard, 

Thanks for getting back to me. 

I've tried various things to get this to work but out of the box the application doesn't work with the server JSF version, 2.3.3, or if I bundle the specific version, 2.1.13, I know works with with the application when it was deployed in Glassfish 3.1.2.2. 

When using the server version is that as soon as a page does an ajax call (in the icefaces world this is a partial submit) then we see the error:

javax.faces.FacesException: Cannot add the same component twice: v9oeh233_icefaces_config

Looking around this normally means that com.sun.faces.config.ConfigureListener has been started twice however in this case that listener isn't included in our web.xml and I don't see any errors suggesting that it has been started twice. If I include it in the web.xml then it makes no difference we still see the error. The servlet spec set in the web.xml was also specified as 2.5 which another thread suggested would stop that listener from being auto initialised by Servlet 3.0. 

When bundling JSF I have had to also bundle the weld core jar to get it to work as well as using the whitelist-package functionality to get to a point where it will load the EJB jar project. Once it's started I can visit some of the pages in the application but as soon as I get to one that uses our custom taglib I get the following error:

java.lang.NoSuchMethodException: com.thirddegree.shared.utils.UserHasRoleTagHandler.<init>(javax.faces.view.facelets.TagConfig)

The class is definitely there and that constructor exists as it all worked on glassfish 3.1.2.2 so it's possibly something to do with class versioning but I can't seem to work out what.

For us it would be better if it worked with the latest version of JSF as it's one less thing stuck on a legacy version. 

Any ideas welcome and thanks again,

Darren

[Rudy De Busscher]

Hi Darren,

This should be in the glassfish-web.xml file in order to use a JSF implementation which is bundled with the 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="">
     <class-loader delegate="false"/>
     <property name="useBundledJsf" value="true" />
</glassfish-web-app>

No whitelisting is needed.

If this doesn't work in your case, can you open a Github Issue containing a small reproducer so that we can investigate this further?

Thanks

Rudy

[Darren H]

Hi Rudy, 

Thanks for getting back to me. I have been using those settings but needed to use the whitelist functionality as otherwise it was failing to load the ejb jar part of the application, specifically it was failing on the entity beans. 

Do you have any experience of deploying old JSF libraries against newer versions of JSF? Just wondered if you thought I'd need to bundle or if I should be able to get it working with the later version as Eduard suggested?

I'll create a small app that I can share with you. 

Many thanks,

Darren

[Rudy De Busscher]

The above glassfish-web.xml is used to demonstrate (in an actual app - hello world style) how you can make use of a JSF implementation which is embedded within your WAR file.

Using a more recent version of JSF will not work in the case of IceFaces as it is not compatible with it. (it doesn't work with JSF 2.2+)

Rudy

[eduard...@gmail.com]

Hi,

Is upgrading to icefaces 4.3 an option, it supports higher jsf (
http://www.icesoft.org/wiki/display/ICE/ICEfaces+3+to+4+Migration+Guide
)?

Bye, Eduard

> --
> You received this message because you are subscribed to the Google
> Groups "Payara Forum" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to payara-forum...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/payara-forum/f2d1d7ae-9330-45e8-b551-9f94cab3c58b%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

[Rudy De Busscher]

Hi Eduard,

It seems IceFaces only supports some specific versions of a certain JSF implementation. For example

• Oracle Mojarra JSF 2.2.1-2.2.14 (2.2.14 included).
• Oracle Mojarra JSF 2.3.5.

This indicates that they are relying on some internals and implementation specific details. 

And I don't think we have ever used Mojarra 2.3.5, so there is no Payara 5 version which works out of the box with IceFaces.

In the case of IceFaces, I think the safest option is to include a specific JSF implementation.

Rudy

[Darren H]

Hi Rudy, Eduard,

Thanks for the discussion around this. In the most part I can get things running using the bundled JSF option with version 2.1.29-11 and no class whitelisting. When I deploy the application I can see the following error and any EJB injection annotations don't get processed:

INFO:   Initializing Mojarra 2.3.3.99.payara-p5 for context '/TestBundledJSF-web'

SEVERE:   JSF1051: Service entry 'org.glassfish.faces.integration.GlassFishInjectionProvider' does not extend DiscoverableInjectionProvider.  Entry will be ignored.

SEVERE:   JSF1051: Service entry 'org.glassfish.faces.integration.GlassFishInjectionProvider' does not extend DiscoverableInjectionProvider.  Entry will be ignored.

For some reason even though I've bundled 2.1 of Mojarra the info message states it's Mojarra 2.3.3.99 being loaded, and that then tries to use the org.glassfish.faces.integration.GlassFishInjectionProvider provider when I believe it should be com.sun.faces.vendor.GlassFishInjectionProvider. I've tried to override this by setting the following entry in my web.xml but that's not worked:

    <context-param>

        <param-name>com.sun.faces.injectionProvider</param-name>

        <param-value>com.sun.faces.vendor.GlassFishInjectionProvider</param-value>

    </context-param>   

I don't seem to be able to attach my test app on this message but if you've got somewhere I can push that to then happy to do that.

If I then try and migrate the config from the test app into our actual application then other things don't work. The custom taglib causes that NoSuchMethodException, FacesContext comes back as null when programatically used in managed beans and the EJB annotations again fail. I'm still trying to isolate those things but perhaps related to the injection and facescontext issues.

Thanks for taking the time to look.

Kind regards,

Darren

[Rudy De Busscher]

Hi Darren,

If you see the info message about Mojarra 2.3.xxx being initialised then it clearly doesn't pick up your bundled implementation for some reason.

The easiest way to share your test application is by putting it in your GitHub account and share the location.

Regards

Rudy

[Darren H]

Hi Eduard, Rudy, 

I just wanted to post that I'd solved this problem thanks to both of your advice, so just wanted to say thanks.

I think what was holding me back was the libraries being loaded at the right levels. I found that some libraries were actually being loaded by the EJB tier as they were being included at the ear level rather than the war. Ultimately that was causing me the pain of it loading the JSF version that was included with Payara rather than the one that was being packaged along with the war. 

For anyone else out there trying to do this sort of thing the main steps for me ended up being:

Adding the JSF listener to the web.xml:

    <listener>

        <listener-class>

            com.sun.faces.config.ConfigureListener

        </listener-class>

    </listener> 

Adding the following to the glassfish-web.xml:

  <class-loader delegate="false"/>

  <property name="useBundledJsf" value="true"/>

Adding the following to the pom.xml:

        <dependency>

            <groupId>org.glassfish.main.web</groupId>

            <artifactId>web-core</artifactId>

            <version>5.1.0</version>

            <type>jar</type>

            <scope>provided</scope>

        </dependency>

        <dependency>

            <groupId>org.glassfish.main.web</groupId>

            <artifactId>web-glue</artifactId>

            <version>5.1.0</version>

            <type>jar</type>

            <scope>provided</scope>

        </dependency>        

So that I could add the GlassFishInjectionProvider class (attached) into my war that I grabbed from the glassfish source repository in order that the injection annotations still functioned as expected, otherwise there was an issue with regards to the naming it was using to lookup the injection provider and all my @EJB annotated backing bean properties were coming back as null values. 

There was some further juggling of libraries required due to the switching of the classloader delegation but those are specific to our code so I won't list them here. 

Now we are up and running on Payara 5 and I have to say that the experience so far has been a good one. It's great to see the things that we loved about glassfish refined even further and some great new functionality added on top. 

Thanks again,

Darren