JSSyntaxScannerFilter bug

[claudiobosticco]

Hello, maybe there's been a change between
SmartClient Version: SNAPSHOT_v11.1d_2016-09-22/Enterprise Deployment (built 2016-09-22)
and
SmartClient Version: SNAPSHOT_v11.1d_2016-09-27/Enterprise Deployment (built 2016-09-27)

because, when using the JSSyntaxScannerFilter with the latter version, the loading of my js files seems to hang forever.
The tomcat logs show one extra line, the last line in this fragment:

2016-09-28 17:12:43,716 INFO  RequestContext URL: '/Jtk/shared/ui/accounting/accounting.min.js', User-Agent: 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36': Safari with Accept-Encoding header 
2016-09-28 17:12:43,722 INFO  Download done streaming: /Users/bosticco/iscSDK/tools/visualBuilder/workspace/Jtk/out/artifacts/Jtk_war_exploded/shared/ui/accounting/accounting.min.js 
2016-09-28 17:12:43,723 INFO  Compression /Jtk/shared/ui/accounting/accounting.min.js: 3068 -> 1285 bytes 
2016-09-28 17:12:43,723 INFO  ProxyHttpServletResponse content-encoding set to: gzip - unwrapping response output stream (JSSyntaxScannerFilter)

It seems that the loading is normal only for the ISC_* files which do have a zipped version (mines don't).

Everything works if I disable the JSSyntaxScannerFilter.

[claudiobosticco]

It seems that the loading is normal only for the ISC_* files which do have a zipped version (mines don't).

and yes, I've verified that if I add the .gz version of my own js files, they're loaded normally.

[claudiobosticco]

Hello, did you succeeded in replicating the bug?

[claudiobosticco]

Hello, any news about this issue?

[Isomorphic]

Apologies for the delay. We tried to reproduce this, but without success yet. It is not forgotten though, so be sure, we'll follow up as soon as we have any news.

[claudiobosticco]

Hello, I have the CompressionFilter registered in my web.xml. It was listed after the JSSyntaxScannerFilter.
Now I've moved it before the JSSyntaxScannerFilter and the problem has vanished.

[Isomorphic]

Thanks for the hint. the order of servlet filters in web.xml is important. CompressionFilter should always be listed before other filters, that rely on uncompressed data, including JSSyntaxScannerFilter. We've added a note on this to Compression docs.

[claudiobosticco]

Thanks for the hint. the order of servlet filters in web.xml is important. CompressionFilter should always be listed before other filters, that rely on uncompressed data, including JSSyntaxScannerFilter. We've added a note on this to Compression docs.

noted - thanks