Internal Server Terror from multi-JSF attempt

[nickarls]

I gave the WF (upstream master) multi-JSF (myfaces-2.1.12) a spin once again with the ICEfaces 3.3 showcase (removed the bundled JSF jars and edited in the chosen JSF impl in a web.xml context parameter). The result is a

Caused by: java.lang.NullPointerException
          at org.apache.myfaces.shared.renderkit.html.util.ResourceUtils.renderDefaultJsfJsInlineIfNecessary(ResourceUtils.java:231) [myfaces-impl-2.1.12.jar:2.1.12]
          at org.apache.myfaces.shared.renderkit.html.HtmlLinkRendererBase.encodeBegin(HtmlLinkRendererBase.java:131) [myfaces-impl-2.1.12.jar:2.1.12]
          at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:587) [myfaces-api-2.1.12.jar:2.1.12]
          at javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:517) [myfaces-api-2.1.12.jar:2.1.12]
          at org.apache.myfaces.view.facelets.component.RepeatRenderer.encodeChildren(RepeatRenderer.java:78) [myfaces-impl-2.1.12.jar:2.1.12]
          at org.apache.myfaces.view.facelets.component.UIRepeat.process(UIRepeat.java:909) [myfaces-impl-2.1.12.jar:2.1.12]
          at org.apache.myfaces.view.facelets.component.UIRepeat.encodeChildren(UIRepeat.java:1587) [myfaces-impl-2.1.12.jar:2.1.12]

Looking at the source

226            Resource resource = facesContext.getApplication().getResourceHandler().createResource(
227                    JSF_JS_RESOURCE_NAME, JAVAX_FACES_LIBRARY_NAME);
228            markScriptAsRendered(facesContext, JAVAX_FACES_LIBRARY_NAME, JSF_JS_RESOURCE_NAME);
229            writer.startElement(HTML.SCRIPT_ELEM, null);
230            writer.writeAttribute(HTML.SCRIPT_TYPE_ATTR, HTML.SCRIPT_TYPE_TEXT_JAVASCRIPT, null);
231            writer.writeURIAttribute(HTML.SRC_ATTR, resource.getRequestPath(), null);
232            writer.endElement(HTML.SCRIPT_ELEM);

it pretty much has to be the resource that is null, right? Any theories why? I can see ICEfaces "boot" and faces-config.xml parameters being picked up normally so I would think the JSF implementation installation in the AS was successful.

[jaikiran]

The last time we saw this, we suspected this was a TCCL issue https://community.jboss.org/thread/227926

[nickarls]

Oh, I must have resetted by brain during my vacation, forgot about that thread ;-)

[nickarls]

Continuing here since I'm testing on WildFly

I added a

   @Override
   public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException,
      ServletException
   {
      System.out.println(FacesContext.getCurrentInstance());
      ClassLoader originalTCCL = Thread.currentThread().getContextClassLoader();
      try
      {
         Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader());
         chain.doFilter(request, response);
      } finally
      {
         Thread.currentThread().setContextClassLoader(originalTCCL);
      }
   }

and I assume it's called first since I get a null for the FC but the error remains...

[nickarls]

Ping @Jaikiran. What this the test you had in mind?

[nickarls]

Pingpingpingping ;-)

[ctomc]

Did you try with latest builds?

there ware some changes in undertow & also jsf upgrade...

[jaikiran]

Nicklas Karlsson wrote:

Ping @Jaikiran. What this the test you had in mind?

Sorry, forgot to reply earlier. Yes, that's what I had in mind but if that too isn't working then at the moment I don't see what the root cause might be.

[nickarls]

Alas, I still get served a can of Fail on upstream master with myfaces 2.1.12.

Ping Stan Silvert pingpingping ;-)

[ssilvert]

I really don't think we should need to play with the TCCL.  This should just work.

Have you tried it with the default (Mojarra) JSF implementation?

The MyFaces code is looking for jsf.js.  Interesting thing is that Mojarra stores this file in the impl jar while MyFaces puts it in the API jar.  There is one difference in the way the impl and api jars are added to the deployment by the JSF subsystem.

Since you are using WildFly master, try this diff I'm attaching and let me know if that fixes the problem.

Stan

[nickarls]

It works with mojarra. I'll give the diff a spin tomorrow, thanks for the help

[nickarls]

I still get the same issue. It might be something that ICEfaces does (or some other library) since I'm testing with my full application. I would have to start with a plain JSF app and then start adding libs. But the error is kind of strange since it's so "low level"...

[ssilvert]

Nicklas Karlsson wrote:

I still get the same issue. It might be something that ICEfaces does (or some other library) since I'm testing with my full application. I would have to start with a plain JSF app and then start adding libs. But the error is kind of strange since it's so "low level"...

Yea, we just need something that recreates the condition where this createResources() returns null.  You could try executing it in your own code instead of having to debug at such a low level.

Resource resource = facesContext.getApplication().getResourceHandler().createResource(
                    JSF_JS_RESOURCE_NAME, JAVAX_FACES_LIBRARY_NAME);

[nickarls]

Confusing. A plain JSF application works. A simple ICEfaces application works (adding DeltaSpike works too). But dropping in the ICEfaces component showcase fails (like my larger app).

[rgosling]

Hi All,

Just wondering if there was any resolution on this as we are encountering the same issue as noted above.  I have done some extensive searching, but haven't found anything to date.

We are attempting to use myfaces-2.1.13.  We are in the process of a major upgrade from Jboss 4.0.5 and so forth with an existing app and are trying to limit the number of changes we need to make.  We have come to the conclusion we need to use a pure JSF 2.x implementation (we were using JSP, TLD, etc).  I have been trying to debug why resource is coming back null.  I did note in the myfaces-api-2.1.13.jar there is a jsf.js found at META-INF/resources/javax.faces....

Thanks
Rob