[jira] Reopened: (TAP5-745) Remove Woodstox-specific Stax implementation usage

2009-06-15 Thread JIRA

 [ 
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

2009-06-15 Thread Michal Buczko (JIRA)

[ 
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

2009-06-15 Thread Thiago H. de Paula Figueiredo (JIRA)

 [ 
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

2009-06-15 Thread JIRA

 [ 
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.