0

I used the <f:websocket/> tag in my project with mojarra 2.3.3 and in project stage 'Development' everything was working fine. But when the project was deployed on our QA system with project stage 'Staging', the client produced the JS error "'mojarra' not defined". This is due to the jsf.js being loaded as a blank file. When I debugged, I found that in com.sun.faces.application.resource.ResourceHelper#getInputStreamFromClientInfo the content of the js file is copied to a GZIPOutputStream which is never finished and thus nothing is written to the wrapped ByteArrayOutputStream (ll. 234-237), resulting in the empty response to my client. In stage Development the file is delivered uncompressed.

Is this a bug or am I missing something? Is there a configuration for this? Is there a workaround?

I tried setting com.sun.faces.compressJavaScript to false with no luck. When I call GZIPOutputStream#finish() on the stream before it's written to the ByteArrayInputStream in the debugger, the content of the input stream is correct and sent to the client. I also checked mojarra 2.3.8 but the code seems to be unchanged.

I expect the client to receive the correct js code. It doesn't necessarily have to be compressed.

Addition: The project is running on a Tomcat 8.5.14 with JDK1.8.0_161 and I'm using Primefaces (6.2). I created a miminal working example here which doesn't use Primefaces. It doesn't actually push anything into the websocket channel but the relevant thing here is the JS error when the index.xhtml is loaded. It's also tested with Java 1.8_202, Tomcat 8.5.37, Mojarra 2.3.8. It's working (loading the jsf.js that is) with Mojarra 2.2.14.

BerndK
  • 21
  • 5
  • Does this only influence `f:websocket` or does it fail when using `f:ajax` too? It would be strange if it is related to just `f:websocket`. And what is your container/server? Does that make a difference? Can you create a [mcve] – Kukeltje Jan 28 '19 at 17:03
  • The project is running on Tomcat 8.5.14 and I think we didn't use `f:ajax` up to now as we use primefaces (6.2). I'll see that I add an example. – BerndK Jan 29 '19 at 09:18
  • I tested my minimal example with an `h:inputText`/`h:commandButton` and `f:ajax` and the result is the same: the jsf.js is loaded as a blank file hence an JS error. – BerndK Jan 29 '19 at 10:31
  • Ok, so it is not websocket related but plain jsf or even [Tomcat](https://www.google.com/search?client=firefox-b-ab&q=Tomcat+8.5.14+gzipoutputstream+problem) Can you check if there are results that are related? Or try 8.5.x latests (x=37?) Since there are things mentioned in releasenotes related to compression – Kukeltje Jan 29 '19 at 11:07
  • Tested with Tomcat 8.5.37, same behavior. I think, as the application itself wants to do the compression, Tomcat is not at fault here. Other problems with `jsf.js` were caused by filters or similar things, but here I know that I get to the application logic and even know a fix for the problem (finishing the GZIPOutputStream). The server responds with 200 and an "empty" (except for some header bytes) stream. – BerndK Jan 29 '19 at 13:26
  • I just wanted to exclude that double compression or something similar caused this (could even be that it still is related to some 'features' in Tomcat. And yes, it looks like the application (or the 'jsf' part in it) also wants to do compression. Can you try latest 1.8_201 JDK? I found https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8189789 which is not directly Tomcat related but rather jdk related and 1.8_171 contains a fix. (newer than your 161). Not saying it is the cause but to exclude things (normally always try latest versions!) – Kukeltje Jan 29 '19 at 13:42
  • Sure, you're absolutely right. Of course my first try was to use the newest Mojara :) Unfortunately, Java 1.8_202 + Tomcat 8.5.37 (even + Mojarra 2.3.8) doesn't change the result. – BerndK Jan 29 '19 at 14:59
  • Hhhhmmmmmm.... I'll try to reproduce tonight in my local environment but to exclude even more, can you see what Mojarra 2.2.latest does? – Kukeltje Jan 29 '19 at 15:21
  • Oh and production mode does work too? No errors there? – Kukeltje Jan 29 '19 at 15:36
  • Production mode produces the same faulty result. Mojarra 2.2(.14) however doesn't show this behavior, the `jsf.js` is loaded correctly in Production stage. Unfortunately, `f:websocket` is a JSF 2.3 feature :-/ – BerndK Jan 29 '19 at 17:07
  • I know, it was not a suggestion for actually replacing, more a step in eliminating things / narrowing things down – Kukeltje Jan 29 '19 at 17:09
  • Any success with reproducing the issue? – BerndK Feb 06 '19 at 07:37

0 Answers0