[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.(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-486) Switch Tapestry's built-in JavaScript support from Prototype to jQuery
[ https://issues.apache.org/jira/browse/TAP5-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12719674#action_12719674 ] Michal Buczko commented on TAP5-486: The only thing that tapestry needs is stabilization. I'm developing my own application over 1 year in tapestry 5 with extensive use of javascript and it drives me really mad to re-implement parts of my javascripts each time when tapestry updates from 5.1.0.x to 5.1.0.x+1. And now I hear about switching from prototype to jquery! please decide here what the tapestry 5 is: stable framework for wide community or a never-ending-beta-toy for few developers. Even hardcore developer's patience has its limits. Changing the same thing 100 times because of minor updates starts to be irritating. There are lot of issues reported which are imho much more important than wasting time on swtiching from one js library to another. I would love to see tapestry described as a superb fast & stable tool, but let's be honest: who will use this framework for serious job if it changes constantly each month and number of jira tickets rises exponentially? > Switch Tapestry's built-in JavaScript support from Prototype to jQuery > -- > > Key: TAP5-486 > URL: https://issues.apache.org/jira/browse/TAP5-486 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.1.0.0 >Reporter: Howard M. Lewis Ship > > Like rats deserting a sinking ship ... > This is not a definitive requirement; I've created this issue to promote > discussion. > It's quite likely that a move like this could be accomplished quite smoothly > for users who are meerly consumers of JavaScript components; authors of > JavaScript components would have to make some changes. > Possibly we should code the jQuery stack from the get-go to NOT use the $() > method, but instead use j$(). That extra character to type could make all the > difference is allowing a smooth upgrade, where jQuery becomes the default, > but prototype/scriptaculous can still be used. > Possibly a new annotation, @PrototypeSupport for components to ensure that > the Prototype libraries are available for compatibility? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (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 ] Thiago H. de Paula Figueiredo closed TAP5-745. -- Resolution: Duplicate Duplicate of https://issues.apache.org/jira/browse/TAP5-713. Different reasons, same problem, same solution. :) > 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.(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] Updated: (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 updated TAP5-745: -- Issue Type: Bug (was: Improvement) Changed to bug, since the new WAS-CE 2.1 will not start with option "-Djavax.xml.stream.XMLInputFactory=com.ctc.wstx.stax.WstxInputFactory" > 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.(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.