[jira] Reopened: (TAP5-745) Remove Woodstox-specific Stax implementation usage
[ https://issues.apache.org/jira/browse/TAP5-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Köberl reopened TAP5-745: --- No, this is not the same problem as TAP5-713!! The problem with TAP5-713 is that there is no StAX available (e.g. on GAE) - the problem here is that Tapestry uses extensions to StAX (which it should not do). Using extensions to XML standard implementations in Java brings us back to XML hell some years ago where you had to exactly use XML parser X in version Z to make some app work. The patch provided will fix this problem (eliminating the dependency to Woodstox but not to StAX)! The patch can be easily applied (just some lines of code are changed) - a fix for TAP5-713 will need a major rewrite of the template parser! Remove Woodstox-specific Stax implementation usage -- Key: TAP5-745 URL: https://issues.apache.org/jira/browse/TAP5-745 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.0, 5.1.0.1, 5.1.0.2, 5.1.0.3, 5.1.0.4, 5.1.0.5, 5.1 Reporter: Christian Köberl Priority: Critical Attachments: TAP5-745-5.1.0.5.patch Tapestry uses some special extensions to StaX (out of Woodstox) in the template parser. This leads to the problem that Tapestry will usually not run on any application server because the appservers will use their own implementation of Stax. There is a workaround but a main stream web application framework should run on JEE compatible web and application servers without tweaking. The main problem is in org.apache.tapestry5.internal.services.TemplateParserImpl.init(TemplateParserImpl.java:44). Here, XMLInputFactory2 is asked for an instance - but XMLInputFactory2 does not implement the method newInstance. This is delegated to XMLInputFactory. So, the original XMLInputFactory is used - which returns the platform implementation of Stax. Workaround: Add the system property below to Application Server (either via startup script or admin console): -Djavax.xml.stream.XMLInputFactory=com.ctc.wstx.stax.WstxInputFactory -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-745) Remove Woodstox-specific Stax implementation usage
[ https://issues.apache.org/jira/browse/TAP5-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12720085#action_12720085 ] Thiago H. de Paula Figueiredo commented on TAP5-745: I didn't notice the patch and the solution to TAP5-713 will solve this issue, so I thought I could close this one as a duplicate. You're right about saying that a solution for TAP5-713 will take some time. I'm sorry. Remove Woodstox-specific Stax implementation usage -- Key: TAP5-745 URL: https://issues.apache.org/jira/browse/TAP5-745 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.0, 5.1.0.1, 5.1.0.2, 5.1.0.3, 5.1.0.4, 5.1.0.5, 5.1 Reporter: Christian Köberl Priority: Critical Attachments: TAP5-745-5.1.0.5.patch Tapestry uses some special extensions to StaX (out of Woodstox) in the template parser. This leads to the problem that Tapestry will usually not run on any application server because the appservers will use their own implementation of Stax. There is a workaround but a main stream web application framework should run on JEE compatible web and application servers without tweaking. The main problem is in org.apache.tapestry5.internal.services.TemplateParserImpl.init(TemplateParserImpl.java:44). Here, XMLInputFactory2 is asked for an instance - but XMLInputFactory2 does not implement the method newInstance. This is delegated to XMLInputFactory. So, the original XMLInputFactory is used - which returns the platform implementation of Stax. Workaround: Add the system property below to Application Server (either via startup script or admin console): -Djavax.xml.stream.XMLInputFactory=com.ctc.wstx.stax.WstxInputFactory -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-750) Swf files as assets don't play in firefox due to being gziped
[ https://issues.apache.org/jira/browse/TAP5-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12720398#action_12720398 ] Howard M. Lewis Ship commented on TAP5-750: --- It will be easy to add a default to not compress SWF files. Swf files as assets don't play in firefox due to being gziped - Key: TAP5-750 URL: https://issues.apache.org/jira/browse/TAP5-750 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Ben Gidley If you put a swf file as an asset on a page and then try and play that swf it won't play in firefox (other browsers IE, Opera, Safari are ok). The precise symptoms are * The SWF looks like it loads - but you just get the background colour and the main movie doesn't play * If you right click on it you will get the flashright click menu * If you right click and choose play it does play If you move the movie to an near identical path (e.g. bsset/x/xxx.swf) it will play fine. Looking in wireshark the only difference is tapestry GZIP's the swf served as an asset this then stops firefox playing the movie. If you turn GZIP off in tapestry the SWF plays again. Ideally tapestry should let you turn gzip on/off by mime type as well as globally. This would let you enable it for HTML, JS but not for binary objects where it is just a waste of CPU time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
