[jira] Created: (TAP5-577) TAP5-422 changes break persistent locale backwards compatibility.
TAP5-422 changes break persistent locale backwards compatibility. - Key: TAP5-577 URL: https://issues.apache.org/jira/browse/TAP5-577 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.1, 5.1.0.0 Reporter: Andy Blower Priority: Critical I think that the changes made in T5.1 for TAP5-422 break backwards compatability with T5.0's locale persistence. In T5.0 it was a simple matter to override the default cookie persistence by creating a custom implementation of the PersistentLocale service and contributing it to be used instead of the standard internal T5 implementation. The TAP5-422 changes broke backwards compatibility because anyone who's created their own implementation of PersistentLocale, or just wants the 5.0 cookie persistence behaviour, would have found that it's a lot more work and involves some heavy changes to Tapestry internals. Now with the recent changes for TAP5-418 (committed yesterday), the situation had been alleviated somewhat by allowing the the hard-wired URl locale persistence to be switched off using a new symbol. However, I think that this breaks backwards compatibility in two ways: 1) By changing the default behaviour of locale persistence so that anyone relying on the locale persistence behaviour of 5.0 will have to make changes when they upgrade to 5.1 to keep the same functionality. 2) By requiring so much work for anyone wanting to keep the 5.0 cookie persistence behaviour or define their own custom locale persistence. (In 5.0 it was easy to figure out and implement a custom locale persistence method) From my analysis of the changes made by TAP5-422 TAP5-418, I think anyone wanting non-URL based locale persistence will need to do the following when upgrading from 5.0 to 5.1: 1) Set the ENCODE_LOCALE_INTO_PATH symbol to false. 2) Create an implementation of PersistentLocale and contribute it to the IOC. (copied from the standard 5.0 code if cookie persistence is desired) 3) Create a custom filter written and created to do the same job as the 5.0 LocalizationFilter and contribute it to the IOC RequestHandler. This filter will need to call the LocalizationSetter setLocaleFromLocaleName() method instead of the old setThreadLocale() method. My suggested resolution would be to re-instate the 5.0 cookie persistence (LocalizationFilter PersistentLocaleImpl) and have the new ENCODE_LOCALE_INTO_PATH symbol default to false allowing 5.1 to work the same way as 5.0 out of the box. If the symbol is set to true, then the LocalizationFilter is disabled (not contributed to RequestHandler) and the localization setter calls in PageRenderDispatcher ComponentEventLinkEncoderImpl are enabled to allow the URL locale persisting to happen. LocalizationSetterImpl.setLocaleFromLocaleName(String localeName) would also need changing back to overriding the passed localeName if a persistent one had been set into the PersistentLocale service. (It should be noted that this is a product of my analysis of the 5.1 code, I have not found the time to actually run it and test this out - I should be able to do this in about a week and a half, but I'm currently approaching a milestone deadline. Hopefully someone else will find the time to prove or disprove my hypothesis.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-577) TAP5-422 changes break persistent locale backwards compatibility.
[ https://issues.apache.org/jira/browse/TAP5-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Blower updated TAP5-577: - Description: I think that the changes made in T5.1 for TAP5-422 break backwards compatibility with T5.0's locale persistence. In T5.0 it was a simple matter to override the default cookie persistence by creating a custom implementation of the PersistentLocale service and contributing it to be used instead of the standard internal T5 implementation. The TAP5-422 changes broke backwards compatibility because anyone who's created their own implementation of PersistentLocale, or just wants the 5.0 cookie persistence behaviour, would have found that it's a lot more work and involves some heavy changes to Tapestry internals. Now with the recent changes for TAP5-418 (committed yesterday), the situation had been alleviated somewhat by allowing the the hard-wired URl locale persistence to be switched off using a new symbol. However, I still think that this breaks backwards compatibility in two ways: 1) By changing the default behaviour of locale persistence so that anyone relying on the locale persistence behaviour of 5.0 will have to make non-trivial changes when they upgrade to 5.1 to keep the same operation. 2) By requiring so much work for anyone wanting to keep the 5.0 cookie persistence behaviour or define their own custom locale persistence. (In 5.0 it was easy to figure out and implement a custom locale persistence method) From my analysis of the changes made by TAP5-422 TAP5-418, I think anyone wanting non-URL based locale persistence will need to do the following when upgrading from 5.0 to 5.1: 1) Set the ENCODE_LOCALE_INTO_PATH symbol to false. 2) Create an implementation of PersistentLocale and contribute it to the IOC. (copied from the standard 5.0 code if the old default cookie persistence is desired) 3) Create a custom filter written and created to do the same job as the 5.0 LocalizationFilter and contribute it to the IOC RequestHandler. This filter will need to call the LocalizationSetter setLocaleFromLocaleName() method instead of the old setThreadLocale() method. My suggested resolution would be to re-instate the 5.0 cookie persistence (LocalizationFilter PersistentLocaleImpl) and have the new ENCODE_LOCALE_INTO_PATH symbol default to false allowing 5.1 to work the same way as 5.0 out of the box. If the symbol is set to true, then the LocalizationFilter is disabled (not contributed to RequestHandler) and the calls to LocalizationSetter in PageRenderDispatcher ComponentEventLinkEncoderImpl are enabled to allow the URL locale persisting to happen. LocalizationSetterImpl.setLocaleFromLocaleName(String localeName) would also need changing back to overriding the passed localeName if a persistent one had been set into the PersistentLocale service. (It should be noted that this is purely a product of my analysis of the 5.1 code, I have not found the time to actually run T5.1 and test this out - I should be able to do this in about a week and a half, but I'm currently approaching a major milestone deadline. Hopefully someone else will find the time to prove or disprove my hypothesis.) was: I think that the changes made in T5.1 for TAP5-422 break backwards compatability with T5.0's locale persistence. In T5.0 it was a simple matter to override the default cookie persistence by creating a custom implementation of the PersistentLocale service and contributing it to be used instead of the standard internal T5 implementation. The TAP5-422 changes broke backwards compatibility because anyone who's created their own implementation of PersistentLocale, or just wants the 5.0 cookie persistence behaviour, would have found that it's a lot more work and involves some heavy changes to Tapestry internals. Now with the recent changes for TAP5-418 (committed yesterday), the situation had been alleviated somewhat by allowing the the hard-wired URl locale persistence to be switched off using a new symbol. However, I think that this breaks backwards compatibility in two ways: 1) By changing the default behaviour of locale persistence so that anyone relying on the locale persistence behaviour of 5.0 will have to make changes when they upgrade to 5.1 to keep the same functionality. 2) By requiring so much work for anyone wanting to keep the 5.0 cookie persistence behaviour or define their own custom locale persistence. (In 5.0 it was easy to figure out and implement a custom locale persistence method) From my analysis of the changes made by TAP5-422 TAP5-418, I think anyone wanting non-URL based locale persistence will need to do the following when upgrading from 5.0 to 5.1: 1) Set the ENCODE_LOCALE_INTO_PATH symbol to false. 2) Create an implementation of PersistentLocale and contribute it to the IOC. (copied from the standard 5.0 code if cookie persistence is
[jira] Updated: (TAP5-577) TAP5-422 changes break persistent locale backwards compatibility.
[ https://issues.apache.org/jira/browse/TAP5-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Blower updated TAP5-577: - Description: I think that the changes made in T5.1 for TAP5-422 break backwards compatibility with T5.0's locale persistence. In T5.0 it was a simple matter to override the default cookie persistence by creating a custom implementation of the PersistentLocale service and contributing it to be used instead of the standard internal T5 implementation. The TAP5-422 changes broke backwards compatibility because anyone who's created their own implementation of PersistentLocale, or just wants the 5.0 cookie persistence behaviour, would have found that it's a lot more work and involves some heavy changes to Tapestry internals. Now with the recent changes for TAP5-418 (committed yesterday), the situation had been alleviated somewhat by allowing the the hard-wired URl locale persistence to be switched off using a new symbol. However, I still think that this breaks backwards compatibility in two ways: 1) By changing the default behaviour of locale persistence so that anyone relying on the locale persistence behaviour of 5.0 will have to make non-trivial changes when they upgrade to 5.1 to keep the same operation. 2) By requiring so much work for anyone wanting to keep the 5.0 cookie persistence behaviour or define their own custom locale persistence. (In 5.0 it was easy to figure out and implement a custom locale persistence method) From my analysis of the changes made by TAP5-422 TAP5-418, I think anyone wanting non-URL based locale persistence will need to do the following when upgrading from 5.0 to 5.1: 1) Set the ENCODE_LOCALE_INTO_PATH symbol to false. 2) Create an implementation of PersistentLocale and contribute it to the IOC. (copied from the standard 5.0 code if the old default cookie persistence is desired) 3) Create a custom filter written and created to do the same job as the 5.0 LocalizationFilter and contribute it to the IOC RequestHandler. This filter will need to call the LocalizationSetter setLocaleFromLocaleName() method instead of the old setThreadLocale() method. My suggested resolution would be to re-instate the 5.0 cookie persistence (LocalizationFilter PersistentLocaleImpl) and have the new ENCODE_LOCALE_INTO_PATH symbol default to false allowing 5.1 to work the same way as 5.0 out of the box. If the symbol is set to true, then the LocalizationFilter is disabled (not contributed to RequestHandler) and the PersistentLocale service will need to just store the locale (not set it in a cookie) for later use by LinkSourceImpl. LocalizationSetterImpl.setLocaleFromLocaleName(String localeName) would also need changing back to overriding the passed localeName if a persistent one had been set into the PersistentLocale service. There may by a much better solution than this as I've not spent much time on it, but I though I should try to be helpful as possible. (It should be noted that this is purely a product of my analysis of the 5.1 code, I have not found the time to actually run T5.1 and test this out - I should be able to do this in about a week and a half, but I'm currently approaching a major milestone deadline. Hopefully someone else will find the time to prove or disprove my hypothesis.) was: I think that the changes made in T5.1 for TAP5-422 break backwards compatibility with T5.0's locale persistence. In T5.0 it was a simple matter to override the default cookie persistence by creating a custom implementation of the PersistentLocale service and contributing it to be used instead of the standard internal T5 implementation. The TAP5-422 changes broke backwards compatibility because anyone who's created their own implementation of PersistentLocale, or just wants the 5.0 cookie persistence behaviour, would have found that it's a lot more work and involves some heavy changes to Tapestry internals. Now with the recent changes for TAP5-418 (committed yesterday), the situation had been alleviated somewhat by allowing the the hard-wired URl locale persistence to be switched off using a new symbol. However, I still think that this breaks backwards compatibility in two ways: 1) By changing the default behaviour of locale persistence so that anyone relying on the locale persistence behaviour of 5.0 will have to make non-trivial changes when they upgrade to 5.1 to keep the same operation. 2) By requiring so much work for anyone wanting to keep the 5.0 cookie persistence behaviour or define their own custom locale persistence. (In 5.0 it was easy to figure out and implement a custom locale persistence method) From my analysis of the changes made by TAP5-422 TAP5-418, I think anyone wanting non-URL based locale persistence will need to do the following when upgrading from 5.0 to 5.1: 1) Set the ENCODE_LOCALE_INTO_PATH symbol to false. 2) Create an
[jira] Issue Comment Edited: (TAP5-577) TAP5-422 changes break persistent locale backwards compatibility.
[ https://issues.apache.org/jira/browse/TAP5-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12681499#action_12681499 ] Andy Blower edited comment on TAP5-577 at 3/12/09 2:31 PM: --- Howard, I agree that using cookies to track user's persistent locale is not industry standard, but it happens to be the method used by the final public release of T5.0 which is the important point here. The fact that the default method for persisting locales is different is really only a backwards compatibility issue for anyone who's relying on the generated URLs for some reason or has issues with locale being in the URLs. (like our site which needs durable and shareable URLs regardless of a users' locale preference) To my mind this is a judgement call for you to take as it's quite a subjective aspect of backwards compatibility, assuming of course that it's easy to override the default behaviour like it was in T5.0 where you provided an easy way with a public interface. This is where I have the main (less subjective, more objective) issue... You are right that the functionality of persisting locale once set is still retained and is just done using a different method in T5.1, but only for people who haven't implemented their own PersistentLocale service. If they have then it will break on upgrading to T5.1 because the service interface (which is public and not internal) is now used in a different way by the internals - in other words the contract you made for this public interface is broken. If it were as simple as changing the symbol to false to re-enable the old contract with the public PersistentLocale service then it wouldn't be so bad, but currently it's non-trivial for someone to get their custom PersistentLocale services working in T5.1 which is why I consider backwards compatibility to be broken in this instance. Regarding your statement vast majority of users (who were not mucking about in the internals of Tapestry to customize persistent locales) - I really don't think that creating and contributing a custom implementation of a public service interface can be characterized in this way. Especially by you. I thought that this was what T5 was all about; functional out of the box, but allowing powerful customization where it just gets out of the way to let you do what you need. Have I got this wrong? I definitely have mucked about with Tapestry internals and I will have some upgrade pains due to these modification, but I knew that when I did it and you will not hear a thing from me about backwards compatibility when I've messed with internals (even if there was no other way in T5.0 to achieve what I needed to do) but that is not the case here. I think I can safely assume that you do not consider reverting the default behaviour of T5.1 to cookie locale persistence an option which is fair enough. I don't think much of cookie persistence myself so I'm certainly not bothered by it, I just hope it doesn't trip up too many others. That's my only concern, although you seem to have confidence that it wont so my fears are most likely unfounded. However, I do think the other issue of overriding the default method of locale persistence becoming so much harder in T5.1 is a major issue and does break backwards compatibility. The aim should be that if the ENCODE_LOCALE_INTO_PATH symbol is set to false, then a custom PersistentLocale service that worked with T5.0 should work the same with T5.1 so I guess the only sticking point is the lack of a LocalizationFilter in T5.1 which is enabled when the symbol is false and allows a custom PersistentLocale service written for T5.0 to work with T5.1 without a lot of hassle and migration work. This should fix the main (objective) part of this issue. As I've said before it will only really be a minor inconvenience to me personally if you don't resolve this issue - I think I know what I'm doing and have the ability to cope with this for my own work with Tapestry. was (Author: andyb): Howard, I agree that using cookies to track user's persistent locale is not industry standard, but it happens to be the method used by the final public release of T5.0 which is the important point here. The fact that the default method for persisting locales is different is really only a backwards compatibility issue for anyone who's relying on the generated URLs for some reason or has issues with locale being in the URLs. (like our site which needs durable and shareable URLs regardless of a users' locale preference) To my mind this is a judgement call for you to take as it's quite a subjective aspect of backwards compatibility, assuming of course that it's easy to override the default behaviour like it was in T5.0 where you provided an easy way with a public interface. This is where I have the main (less subjective, more objective)
[jira] Created: (TAP5-614) Spacer image should have a blank alt attribute to meet w3c accessability standards
Spacer image should have a blank alt attribute to meet w3c accessability standards -- Key: TAP5-614 URL: https://issues.apache.org/jira/browse/TAP5-614 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.0.18, 5.0.17, 5.0.16, 5.0.15, 5.1.0.2, 5.1.0.1, 5.1.0.0 Reporter: Andy Blower Priority: Minor Our User Experience Design team have raised an issue with the use of the tapestry.spacer-image in the Autocomplete mixin. It's also used by the default client side validation. The issue is that the spacer img tag is rendered with no alt attribute which is apparently a problem for these reasons: 1) Always add alt attributes to images. Alt is mandatory for accessibility and for valid (X)HTML. 2) For images that play only a decorative role in the page, use an empty alt (i.e. alt=) or a CSS background image so that reading browsers do not bother users by uttering things like spacer image. So, Tapestry needs to write a blank alt attribute when it uses a spacer gif. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-630) Blackbird error console class names are too generic and can easily conflict
[ https://issues.apache.org/jira/browse/TAP5-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Blower updated TAP5-630: - Attachment: BlackbirdIssue.jpg This is what I saw when I got an issue on our results page. We have a class called 'filters' for our search results filter panel. Blackbird error console class names are too generic and can easily conflict --- Key: TAP5-630 URL: https://issues.apache.org/jira/browse/TAP5-630 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.2 Reporter: Andy Blower Priority: Minor Attachments: BlackbirdIssue.jpg Blackbird error console class names are too generic and can easily conflict with those used by Tapestry designers. e.g. header, left, filters. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-469) ResponseCompressionAnalyzer: application/json responses should be uncompressable by default
[ https://issues.apache.org/jira/browse/TAP5-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12696993#action_12696993 ] Andy Blower commented on TAP5-469: -- I have just encountered this issue in IE6, FF3 Chrome2 on windows XP. The workaround fixes the issue as expected, but there definitely seems to be a problem here out of the box. ResponseCompressionAnalyzer: application/json responses should be uncompressable by default --- Key: TAP5-469 URL: https://issues.apache.org/jira/browse/TAP5-469 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.0 Reporter: Paudi Moriarty GZip compressed responses with Content-Type: application/json are not handled correctly by at least Firefox or IE and should be configured as uncompressable by default When the response is received in prototype's Ajax.Request response.responseText is . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-635) NPE when using a label with a radio group component
NPE when using a label with a radio group component --- Key: TAP5-635 URL: https://issues.apache.org/jira/browse/TAP5-635 Project: Tapestry 5 Issue Type: Bug Affects Versions: 5.1.0.2 Reporter: Andy Blower After three hours of detective work I've tracked this NPE to using a label with a radio group component. This works in 5.0.18, but not in 5.1.0.2. The stack trace is as follows for the example page I will attach: ERROR (RequestExceptionHandler:62 ) - Processing of request failed with uncaught exception: java.lang.NullPointerException java.lang.NullPointerException at org.apache.tapestry5.dom.AbstractMarkupModel.encodeQuoted(AbstractMarkupModel.java:94) at org.apache.tapestry5.dom.Attribute.render(Attribute.java:69) at org.apache.tapestry5.dom.Element.toMarkup(Element.java:313) at org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:835) at org.apache.tapestry5.dom.Element.toMarkup(Element.java:351) at org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:835) at org.apache.tapestry5.dom.Element.toMarkup(Element.java:351) at org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:835) at org.apache.tapestry5.dom.Element.toMarkup(Element.java:351) at org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:835) at org.apache.tapestry5.dom.Element.toMarkup(Element.java:351) at org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:835) at org.apache.tapestry5.dom.Element.toMarkup(Element.java:351) at org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:835) at org.apache.tapestry5.dom.Element.toMarkup(Element.java:351) at org.apache.tapestry5.dom.Document.toMarkup(Document.java:163) at org.apache.tapestry5.dom.Node.toMarkup(Node.java:80) at org.apache.tapestry5.internal.services.MarkupWriterImpl.toMarkup(MarkupWriterImpl.java:57) at org.apache.tapestry5.internal.services.PageResponseRendererImpl.renderPageResponse(PageResponseRendererImpl.java:67) at $PageResponseRenderer_1208672dc1e.renderPageResponse($PageResponseRenderer_1208672dc1e.java) at org.apache.tapestry5.internal.services.PageRenderRequestHandlerImpl.handle(PageRenderRequestHandlerImpl.java:63) at org.apache.tapestry5.services.TapestryModule$33.handle(TapestryModule.java:1952) at $PageRenderRequestHandler_1208672dc1f.handle($PageRenderRequestHandler_1208672dc1f.java) at $PageRenderRequestHandler_1208672dc0b.handle($PageRenderRequestHandler_1208672dc0b.java) at org.apache.tapestry5.internal.services.ComponentRequestHandlerTerminator.handlePageRender(ComponentRequestHandlerTerminator.java:48) at $ComponentRequestHandler_1208672dc0f.handlePageRender($ComponentRequestHandler_1208672dc0f.java) at org.apache.tapestry5.internal.services.PageRenderDispatcher.dispatch(PageRenderDispatcher.java:45) at $Dispatcher_1208672dc11.dispatch($Dispatcher_1208672dc11.java) at $Dispatcher_1208672dc07.dispatch($Dispatcher_1208672dc07.java) at org.apache.tapestry5.services.TapestryModule$RequestHandlerTerminator.service(TapestryModule.java:250) at org.apache.tapestry5.internal.services.RequestErrorFilter.service(RequestErrorFilter.java:26) at $RequestHandler_1208672dc08.service($RequestHandler_1208672dc08.java) at org.apache.tapestry5.services.TapestryModule$4.service(TapestryModule.java:782) at $RequestHandler_1208672dc08.service($RequestHandler_1208672dc08.java) at org.apache.tapestry5.services.TapestryModule$3.service(TapestryModule.java:771) at $RequestHandler_1208672dc08.service($RequestHandler_1208672dc08.java) at org.apache.tapestry5.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:85) at $RequestHandler_1208672dc08.service($RequestHandler_1208672dc08.java) at com.proquest.apps.corelib.AppCoreLibModule$4.service(AppCoreLibModule.java:209) at $RequestFilter_1208672dc04.service($RequestFilter_1208672dc04.java) at $RequestHandler_1208672dc08.service($RequestHandler_1208672dc08.java) at org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:90) at org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:81) at org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:85) at org.apache.tapestry5.internal.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:103) at $RequestHandler_1208672dc08.service($RequestHandler_1208672dc08.java) at $RequestHandler_1208672dbfe.service($RequestHandler_1208672dbfe.java) at
[jira] Updated: (TAP5-635) NPE when using a label with a radio group component
[ https://issues.apache.org/jira/browse/TAP5-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Blower updated TAP5-635: - Attachment: LabelBreakage.tml LabelBreakage.java A simple page that demonstrates the NPE problem. Comment out the label component and it works fine. NPE when using a label with a radio group component --- Key: TAP5-635 URL: https://issues.apache.org/jira/browse/TAP5-635 Project: Tapestry 5 Issue Type: Bug Affects Versions: 5.1.0.2 Reporter: Andy Blower Attachments: LabelBreakage.java, LabelBreakage.tml After three hours of detective work I've tracked this NPE to using a label with a radio group component. This works in 5.0.18, but not in 5.1.0.2. The stack trace is as follows for the example page I will attach: ERROR (RequestExceptionHandler:62 ) - Processing of request failed with uncaught exception: java.lang.NullPointerException java.lang.NullPointerException at org.apache.tapestry5.dom.AbstractMarkupModel.encodeQuoted(AbstractMarkupModel.java:94) at org.apache.tapestry5.dom.Attribute.render(Attribute.java:69) at org.apache.tapestry5.dom.Element.toMarkup(Element.java:313) at org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:835) at org.apache.tapestry5.dom.Element.toMarkup(Element.java:351) at org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:835) at org.apache.tapestry5.dom.Element.toMarkup(Element.java:351) at org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:835) at org.apache.tapestry5.dom.Element.toMarkup(Element.java:351) at org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:835) at org.apache.tapestry5.dom.Element.toMarkup(Element.java:351) at org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:835) at org.apache.tapestry5.dom.Element.toMarkup(Element.java:351) at org.apache.tapestry5.dom.Element.writeChildMarkup(Element.java:835) at org.apache.tapestry5.dom.Element.toMarkup(Element.java:351) at org.apache.tapestry5.dom.Document.toMarkup(Document.java:163) at org.apache.tapestry5.dom.Node.toMarkup(Node.java:80) at org.apache.tapestry5.internal.services.MarkupWriterImpl.toMarkup(MarkupWriterImpl.java:57) at org.apache.tapestry5.internal.services.PageResponseRendererImpl.renderPageResponse(PageResponseRendererImpl.java:67) at $PageResponseRenderer_1208672dc1e.renderPageResponse($PageResponseRenderer_1208672dc1e.java) at org.apache.tapestry5.internal.services.PageRenderRequestHandlerImpl.handle(PageRenderRequestHandlerImpl.java:63) at org.apache.tapestry5.services.TapestryModule$33.handle(TapestryModule.java:1952) at $PageRenderRequestHandler_1208672dc1f.handle($PageRenderRequestHandler_1208672dc1f.java) at $PageRenderRequestHandler_1208672dc0b.handle($PageRenderRequestHandler_1208672dc0b.java) at org.apache.tapestry5.internal.services.ComponentRequestHandlerTerminator.handlePageRender(ComponentRequestHandlerTerminator.java:48) at $ComponentRequestHandler_1208672dc0f.handlePageRender($ComponentRequestHandler_1208672dc0f.java) at org.apache.tapestry5.internal.services.PageRenderDispatcher.dispatch(PageRenderDispatcher.java:45) at $Dispatcher_1208672dc11.dispatch($Dispatcher_1208672dc11.java) at $Dispatcher_1208672dc07.dispatch($Dispatcher_1208672dc07.java) at org.apache.tapestry5.services.TapestryModule$RequestHandlerTerminator.service(TapestryModule.java:250) at org.apache.tapestry5.internal.services.RequestErrorFilter.service(RequestErrorFilter.java:26) at $RequestHandler_1208672dc08.service($RequestHandler_1208672dc08.java) at org.apache.tapestry5.services.TapestryModule$4.service(TapestryModule.java:782) at $RequestHandler_1208672dc08.service($RequestHandler_1208672dc08.java) at org.apache.tapestry5.services.TapestryModule$3.service(TapestryModule.java:771) at $RequestHandler_1208672dc08.service($RequestHandler_1208672dc08.java) at org.apache.tapestry5.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:85) at $RequestHandler_1208672dc08.service($RequestHandler_1208672dc08.java) at com.proquest.apps.corelib.AppCoreLibModule$4.service(AppCoreLibModule.java:209) at $RequestFilter_1208672dc04.service($RequestFilter_1208672dc04.java) at $RequestHandler_1208672dc08.service($RequestHandler_1208672dc08.java) at org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:90) at org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:81) at
[jira] Created: (TAP5-643) PageTester is using my applications module as well as the test module supplied
PageTester is using my applications module as well as the test module supplied -- Key: TAP5-643 URL: https://issues.apache.org/jira/browse/TAP5-643 Project: Tapestry 5 Issue Type: Bug Components: tapestry-test Affects Versions: 5.1.0.3, 5.1.0.2 Reporter: Andy Blower PageTester is using my applications module as well as the test module supplied on construction. There are several dispatchers and other things which are not relevant (and will not work) in a unit testing environment. All of our application tests that use PageTester now fail because of this, all we want to do is test the rendering of the page using our test modules which provide just enough scaffolding for rendering the page. I realise this is an 'improvement' that T5.1 has introduced, but it needs to be optional so I can specify my apps module only if I want it to be used or to test dispatchers etc. Without this we have many tens of developer hours worth of tests that are now useless. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-644) When using PageTester, an exception in the page is hidden by an exception rendering the exception report page (pt. 2)
When using PageTester, an exception in the page is hidden by an exception rendering the exception report page (pt. 2) - Key: TAP5-644 URL: https://issues.apache.org/jira/browse/TAP5-644 Project: Tapestry 5 Issue Type: Bug Components: tapestry-test Affects Versions: 5.1.0.3, 5.1.0.2 Reporter: Andy Blower TAP5-621 is still an issue, I now get this when using the PageTester. So the actual problem is still being hidden. I commented the other bug, but couldn't re-open it and it's not been re-opened by anyone reading the dev list so I'm raising another bug. I needed to implement getHeader() and getHeaderNames() to get my tests errors to appear. Although, it was still awkward because I was looking at the raw HTML of the T5 ExceptionReport in the debugger - could be easier. org.apache.tapestry5.internal.services.RenderQueueException: Render queue error in BeginRender[core/ExceptionReport:renderobject]: Request: method getHeaderNames() not yet implemented by TestableRequestImpl. [at classpath:org/apache/tapestry5/corelib/pages/ExceptionReport.tml, line 24] at org.apache.tapestry5.internal.services.RenderQueueImpl.run(RenderQueueImpl.java:86) at org.apache.tapestry5.internal.services.PageRenderQueueImpl.render(PageRenderQueueImpl.java:121) at $PageRenderQueue_1208c28466c.render($PageRenderQueue_1208c28466c.java) at $PageRenderQueue_1208c28466b.render($PageRenderQueue_1208c28466b.java) at org.apache.tapestry5.internal.services.MarkupRendererTerminator.renderMarkup(MarkupRendererTerminator.java:37) at org.apache.tapestry5.services.TapestryModule$27.renderMarkup(TapestryModule.java:1752) at $MarkupRenderer_1208c284670.renderMarkup($MarkupRenderer_1208c284670.java) at org.apache.tapestry5.services.TapestryModule$26.renderMarkup(TapestryModule.java:1733) at $MarkupRenderer_1208c284670.renderMarkup($MarkupRenderer_1208c284670.java) at org.apache.tapestry5.services.TapestryModule$25.renderMarkup(TapestryModule.java:1715) at $MarkupRenderer_1208c284670.renderMarkup($MarkupRenderer_1208c284670.java) at org.apache.tapestry5.services.TapestryModule$24.renderMarkup(TapestryModule.java:1701) at $MarkupRenderer_1208c284670.renderMarkup($MarkupRenderer_1208c284670.java) at org.apache.tapestry5.services.TapestryModule$23.renderMarkup(TapestryModule.java:1682) at $MarkupRenderer_1208c284670.renderMarkup($MarkupRenderer_1208c284670.java) at org.apache.tapestry5.services.TapestryModule$22.renderMarkup(TapestryModule.java:1663) at $MarkupRenderer_1208c284670.renderMarkup($MarkupRenderer_1208c284670.java) at org.apache.tapestry5.internal.test.CaptureRenderedDocument.renderMarkup(CaptureRenderedDocument.java:39) at $MarkupRenderer_1208c284670.renderMarkup($MarkupRenderer_1208c284670.java) at $MarkupRenderer_1208c28466a.renderMarkup($MarkupRenderer_1208c28466a.java) at org.apache.tapestry5.internal.services.PageMarkupRendererImpl.renderPageMarkup(PageMarkupRendererImpl.java:64) at $PageMarkupRenderer_1208c284666.renderPageMarkup($PageMarkupRenderer_1208c284666.java) at org.apache.tapestry5.internal.services.PageResponseRendererImpl.renderPageResponse(PageResponseRendererImpl.java:61) at $PageResponseRenderer_1208c28460b.renderPageResponse($PageResponseRenderer_1208c28460b.java) at org.apache.tapestry5.internal.services.DefaultRequestExceptionHandler.handleRequestException(DefaultRequestExceptionHandler.java:77) at $RequestExceptionHandler_1208c2845f5.handleRequestException($RequestExceptionHandler_1208c2845f5.java) at org.apache.tapestry5.internal.services.RequestErrorFilter.service(RequestErrorFilter.java:42) at $RequestHandler_1208c2845f8.service($RequestHandler_1208c2845f8.java) at org.apache.tapestry5.services.TapestryModule$4.service(TapestryModule.java:782) at $RequestHandler_1208c2845f8.service($RequestHandler_1208c2845f8.java) at org.apache.tapestry5.services.TapestryModule$3.service(TapestryModule.java:771) at $RequestHandler_1208c2845f8.service($RequestHandler_1208c2845f8.java) at org.apache.tapestry5.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:85) at $RequestHandler_1208c2845f8.service($RequestHandler_1208c2845f8.java) at com.proquest.apps.corelib.AppCoreLibModule$4.service(AppCoreLibModule.java:209) at $RequestFilter_1208c2845ef.service($RequestFilter_1208c2845ef.java) at $RequestHandler_1208c2845f8.service($RequestHandler_1208c2845f8.java) at org.apache.tapestry5.internal.test.EndOfRequestCleanupFilter.service(EndOfRequestCleanupFilter.java:42) at $RequestHandler_1208c2845f8.service($RequestHandler_1208c2845f8.java) at org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:90) at org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:81) at
[jira] Created: (TAP5-649) Forms containing loop components which contain no form elements still encode into t:formdata hidden field
Forms containing loop components which contain no form elements still encode into t:formdata hidden field - Key: TAP5-649 URL: https://issues.apache.org/jira/browse/TAP5-649 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.0.18, 5.1.0.3, 5.1.0.2, 5.1.0.1, 5.1.0.0 Reporter: Andy Blower Updating our app to 5.1 has caused us an issue with using loop components nested inside form components, we now need to provide a ValueEncoder whereas we didn't in 5.0.18 which just serialised the loop values into t:formdata. In many cases we have loops that don't have any input or form elements inside them, but that still need to be contained by the form tag in the HTML. The issue is that the loop component has a 'volatile' parameter to switch off the state saving, but this expects the iterator to still be available when the form is submitted, which it isn't and doesn't need to be. I think that the loop component needs the facility to be form agnostic, so that FormSupport (from the environment) is ignored / not set. My suggestion is that the volatile parameter is deprecated (can't remove for backwards compatability) and a new parameter 'formHandling' or 'formSupport' is added to the loop component which accepts three values: none, statesave, volatile. I think that this would be much clearer and concise than the current volatile boolean, which confuses everyone in my experience, but alternatively a new boolean for switching off form support would suffice. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-649) Forms containing loop components which contain no form elements still encode into t:formdata hidden field
[ https://issues.apache.org/jira/browse/TAP5-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699738#action_12699738 ] Andy Blower commented on TAP5-649: -- I should have mentioned that we have worked around this temporarily to prove that our theory was correct by creating and using a UselessEncoder class with relevant loops in forms. This encoder simply returns a blank string and cut down the t:formdata in one of our forms from 9076 bytes to a mere 832 bytes! Since none of this extra information will ever be used, this shows how much of a wasteful overhead this can be. It would be especially bad for us because we log all activity on the website including posted form submissions. I'm glad that this exception was thrown by 5.1 and highlighted the issue. Forms containing loop components which contain no form elements still encode into t:formdata hidden field - Key: TAP5-649 URL: https://issues.apache.org/jira/browse/TAP5-649 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.0.18 Reporter: Andy Blower Updating our app to 5.1 has caused us an issue with using loop components nested inside form components, we now need to provide a ValueEncoder whereas we didn't in 5.0.18 which just serialised the loop values into t:formdata. In many cases we have loops that don't have any input or form elements inside them, but that still need to be contained by the form tag in the HTML. The issue is that the loop component has a 'volatile' parameter to switch off the state saving, but this expects the iterator to still be available when the form is submitted, which it isn't and doesn't need to be. I think that the loop component needs the facility to be form agnostic, so that FormSupport (from the environment) is ignored / not set. My suggestion is that the volatile parameter is deprecated (can't remove for backwards compatability) and a new parameter 'formHandling' or 'formSupport' is added to the loop component which accepts three values: none, statesave, volatile. I think that this would be much clearer and concise than the current volatile boolean, which confuses everyone in my experience, but alternatively a new boolean for switching off form support would suffice. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-651) Documentation for if component needs expanding
Documentation for if component needs expanding -- Key: TAP5-651 URL: https://issues.apache.org/jira/browse/TAP5-651 Project: Tapestry 5 Issue Type: Improvement Components: documentation Affects Versions: 5.1.0.4 Reporter: Andy Blower Priority: Minor Use of new p:else block in the example for the if component is confusing because there's nothing to draw an ex-5.0 developer to the addition in the container tag attributes for the parameter namespace definition. It would also be nice to explain the syntax for an else block without the new container tag attribute, if there actually is a way of course. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-658) Optimizations for custom persistent locale implementations
Optimizations for custom persistent locale implementations -- Key: TAP5-658 URL: https://issues.apache.org/jira/browse/TAP5-658 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.1.0.4 Reporter: Andy Blower Priority: Minor I was wondering if having a method in LocalizationSetter that allows a Locale to be passed would be a good idea. This would remove the conversion to String and back again which occurs for every request if you are actually storing a locale with a custom persistent locale implementation. The other slight annoyance I have with this area of T5 is that PersistentLocale.set() being constantly called by the LocalizationSetter for each request, this doesn't fit in with the old way that the PersistentLocale service was used. I think that only executing persistentLocale.set(locale); (line 113) if ENCODE_LOCALE_INTO_PATH is true would be a nice little improvement/optimization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-658) Optimizations for custom persistent locale implementations
[ https://issues.apache.org/jira/browse/TAP5-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12701141#action_12701141 ] Andy Blower commented on TAP5-658: -- You're correct about the calls to PersistentLocale.set() - I have no idea why I thought it was being called for every request, it's not. I do think that the symbol could be used to stop the checks for supported locale being the first part of a URL. It's never going to be if ENCODE_LOCALE_INTO_PATH is false. Regarding LocalizationSetter, I have not rewritten CELE to handle locales, and I actually decided against doing it for our URL manipulation too - I advised the service instead which worked very nicely. (shame I couldn't just have decorated a service for 5.0 but that did it in the dispatcher...) It seems you're still conflating these two *separate* aspects of my Tapestry work: * URL manipulation, where I did mess with internals in 5.0 with full knowledge of the implications. (took less than a day to move this code to advice in T5.1, no problem at all once I figured out the best approach) * Overriding locale persistence, where I did not touch the internals and there is still a backwards compatibility issue that seems to bother no one so it's pretty irrelevant. So, what I've actually done to handle locales my own way in T5.1 is to follow the three steps from TAP5-577. 1) Set the ENCODE_LOCALE_INTO_PATH symbol to false. 2) Created an implementation of PersistentLocale and contribute it to the IOC. (same as 5.0 version we had) 3) Create a custom filter written and created to do the same job as the 5.0 LocalizationFilter and contribute it to the IOC RequestHandler. This filter will need to call the LocalizationSetter setLocaleFromLocaleName() method instead of the old setThreadLocale() method. I attached the relevant changes to our module for step 3 to TAP5-577, I don't know if you've seen that. If you take a look you can see that Locale is converted to a string just so it can be passed. I could add the functionality from LocalizationSetter to the LocalizationFilter I had to create, but that seems wrong if I've not rewritten CELE for locale functionality or anything else. I certainly could add the functionality into LocalizationFilter but that seems to be almost like if you don't want URL locales then you need to implement it all yourself which is anti-tapestry ethos I would have thought. Optimizations for custom persistent locale implementations -- Key: TAP5-658 URL: https://issues.apache.org/jira/browse/TAP5-658 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.1.0.4 Reporter: Andy Blower Priority: Minor I was wondering if having a method in LocalizationSetter that allows a Locale to be passed would be a good idea. This would remove the conversion to String and back again which occurs for every request if you are actually storing a locale with a custom persistent locale implementation. The other slight annoyance I have with this area of T5 is that PersistentLocale.set() being constantly called by the LocalizationSetter for each request, this doesn't fit in with the old way that the PersistentLocale service was used. I think that only executing persistentLocale.set(locale); (line 113) if ENCODE_LOCALE_INTO_PATH is true would be a nice little improvement/optimization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-663) Error with passing false in property expressions
Error with passing false in property expressions
Key: TAP5-663
URL: https://issues.apache.org/jira/browse/TAP5-663
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.1.0.3
Reporter: Andy Blower
Priority: Minor
I just tried out the new T5.1 property expressions for the first time and got
an error. I'm trying to replace this:
${linkTitle}
public String getLinkTitle() {
return getTitle(false);
}
With this:
${getTitle(false)}
Which I should be able to do according to the Grammar as far as I can see,
since but I get this error when I try it:
Caused by: org.apache.tapestry5.internal.services.PropertyExpressionException:
Node false (within expression 'getTitle(false)') was type FALSE, but was
expected to be (one of) DECIMAL, DEREF, IDENTIFIER, INTEGER, INVOKE, LIST,
SAFEDEREF, STRING.
at
org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.unexpectedNodeType(PropertyConduitSourceImpl.java:925)
at
org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.subexpression(PropertyConduitSourceImpl.java:637)
at
org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createMethodInvocation(PropertyConduitSourceImpl.java:756)
at
org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createMethodInvocation(PropertyConduitSourceImpl.java:730)
at
org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createGetter(PropertyConduitSourceImpl.java:711)
at
org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createGetterAndSetter(PropertyConduitSourceImpl.java:436)
at
org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createAccessors(PropertyConduitSourceImpl.java:419)
at
org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createInstance(PropertyConduitSourceImpl.java:272)
at
org.apache.tapestry5.internal.services.PropertyConduitSourceImpl.build(PropertyConduitSourceImpl.java:1206)
at
org.apache.tapestry5.internal.services.PropertyConduitSourceImpl.create(PropertyConduitSourceImpl.java:1081)
at
$PropertyConduitSource_120d3f0182d.create($PropertyConduitSource_120d3f0182d.java)
at
org.apache.tapestry5.internal.bindings.PropBindingFactory.newBinding(PropBindingFactory.java:49)
at
$BindingFactory_120d3f0182e.newBinding($BindingFactory_120d3f0182e.java)
at
$BindingFactory_120d3f01826.newBinding($BindingFactory_120d3f01826.java)
at
org.apache.tapestry5.internal.services.BindingSourceImpl.newBinding(BindingSourceImpl.java:81)
... 107 more
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-663) Error with passing false in property expressions
[
https://issues.apache.org/jira/browse/TAP5-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Blower updated TAP5-663:
-
Affects Version/s: 5.1.0.4
Error with passing false in property expressions
Key: TAP5-663
URL: https://issues.apache.org/jira/browse/TAP5-663
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.1.0.3, 5.1.0.4
Reporter: Andy Blower
Priority: Minor
I just tried out the new T5.1 property expressions for the first time and got
an error. I'm trying to replace this:
${linkTitle}
public String getLinkTitle() {
return getTitle(false);
}
With this:
${getTitle(false)}
Which I should be able to do according to the Grammar as far as I can see,
since but I get this error when I try it:
Caused by:
org.apache.tapestry5.internal.services.PropertyExpressionException: Node
false (within expression 'getTitle(false)') was type FALSE, but was expected
to be (one of) DECIMAL, DEREF, IDENTIFIER, INTEGER, INVOKE, LIST, SAFEDEREF,
STRING.
at
org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.unexpectedNodeType(PropertyConduitSourceImpl.java:925)
at
org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.subexpression(PropertyConduitSourceImpl.java:637)
at
org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createMethodInvocation(PropertyConduitSourceImpl.java:756)
at
org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createMethodInvocation(PropertyConduitSourceImpl.java:730)
at
org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createGetter(PropertyConduitSourceImpl.java:711)
at
org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createGetterAndSetter(PropertyConduitSourceImpl.java:436)
at
org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createAccessors(PropertyConduitSourceImpl.java:419)
at
org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createInstance(PropertyConduitSourceImpl.java:272)
at
org.apache.tapestry5.internal.services.PropertyConduitSourceImpl.build(PropertyConduitSourceImpl.java:1206)
at
org.apache.tapestry5.internal.services.PropertyConduitSourceImpl.create(PropertyConduitSourceImpl.java:1081)
at
$PropertyConduitSource_120d3f0182d.create($PropertyConduitSource_120d3f0182d.java)
at
org.apache.tapestry5.internal.bindings.PropBindingFactory.newBinding(PropBindingFactory.java:49)
at
$BindingFactory_120d3f0182e.newBinding($BindingFactory_120d3f0182e.java)
at
$BindingFactory_120d3f01826.newBinding($BindingFactory_120d3f01826.java)
at
org.apache.tapestry5.internal.services.BindingSourceImpl.newBinding(BindingSourceImpl.java:81)
... 107 more
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-577) TAP5-422 changes break persistent locale backwards compatibility.
[ https://issues.apache.org/jira/browse/TAP5-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12703567#action_12703567 ] Andy Blower commented on TAP5-577: -- The process outlined by Andy doesn't really work because the ComponentEventLinkEncoder always calls the LocalizationSetter which in turn always sets the ThreadLocale; thus overriding the set made by the filter. To make it work I had to override the LocalizationSetter service to always return false, and change the filter to set the ThreadLocale directly. Nice to hear I'm not the only one bothered by this Ferdy, and you're quite correct on this - I just traced though to double check! The weird thing is what I've done at least half works... when the filter sets the locale, the messages displayed on my page are correctly localised even though the thread locale is subsequently set back to the browser default rather than our persistent locale. I have no idea why this is and I honestly haven't the time or inclination any more to look into this problem more so I'm not going to be finding out. I must have spent 20+ hours on this one issue, looking at code writing emails/issues, with absolutely no result. So I have better things to do with my time, but I definitely think that localisation has become a mess in T5.1 which is a shame since it was so nice to simply contribute a service implementation of a public interface in 5.0 and the job was done. I will be following the method you outlined, which will also mean I'll be following Howards advice from TAP5-658. (you might find that issue interesting to read also) My filter will also need the fall back to browser request locale copied from the setter, but that's no biggie. Thanks for the catch as this probably would have bitten me in the ass in a few months. TAP5-422 changes break persistent locale backwards compatibility. - Key: TAP5-577 URL: https://issues.apache.org/jira/browse/TAP5-577 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.0, 5.1.0.1 Reporter: Andy Blower Priority: Critical Attachments: T5.1persistentLocale.txt I think that the changes made in T5.1 for TAP5-422 break backwards compatibility with T5.0's locale persistence. In T5.0 it was a simple matter to override the default cookie persistence by creating a custom implementation of the PersistentLocale service and contributing it to be used instead of the standard internal T5 implementation. The TAP5-422 changes broke backwards compatibility because anyone who's created their own implementation of PersistentLocale, or just wants the 5.0 cookie persistence behaviour, would have found that it's a lot more work and involves some heavy changes to Tapestry internals. Now with the recent changes for TAP5-418 (committed yesterday), the situation had been alleviated somewhat by allowing the the hard-wired URl locale persistence to be switched off using a new symbol. However, I still think that this breaks backwards compatibility in two ways: 1) By changing the default behaviour of locale persistence so that anyone relying on the locale persistence behaviour of 5.0 will have to make non-trivial changes when they upgrade to 5.1 to keep the same operation. 2) By requiring so much work for anyone wanting to keep the 5.0 cookie persistence behaviour or define their own custom locale persistence. (In 5.0 it was easy to figure out and implement a custom locale persistence method) From my analysis of the changes made by TAP5-422 TAP5-418, I think anyone wanting non-URL based locale persistence will need to do the following when upgrading from 5.0 to 5.1: 1) Set the ENCODE_LOCALE_INTO_PATH symbol to false. 2) Create an implementation of PersistentLocale and contribute it to the IOC. (copied from the standard 5.0 code if the old default cookie persistence is desired) 3) Create a custom filter written and created to do the same job as the 5.0 LocalizationFilter and contribute it to the IOC RequestHandler. This filter will need to call the LocalizationSetter setLocaleFromLocaleName() method instead of the old setThreadLocale() method. My suggested resolution would be to re-instate the 5.0 cookie persistence (LocalizationFilter PersistentLocaleImpl) and have the new ENCODE_LOCALE_INTO_PATH symbol default to false allowing 5.1 to work the same way as 5.0 out of the box. If the symbol is set to true, then the LocalizationFilter is disabled (not contributed to RequestHandler) and the PersistentLocale service will need to just store the locale (not set it in a cookie) for later use by LinkSourceImpl. LocalizationSetterImpl.setLocaleFromLocaleName(String localeName) would also need
[jira] Commented: (TAP5-678) Allow blackbird to be disabled in production mode
[ https://issues.apache.org/jira/browse/TAP5-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12729176#action_12729176 ] Andy Blower commented on TAP5-678: -- I think it's important to be able to completely disable the blackbird console for production to avoid the unnecessary .css and .js downloads (12.1K and 7.1K) for live sites. Allow blackbird to be disabled in production mode - Key: TAP5-678 URL: https://issues.apache.org/jira/browse/TAP5-678 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.2 Reporter: Paudi Moriarty blackbird's use of F2 to show the console is interfering with our application which uses F-keys as hotkeys to access various parts of the application. It should be possible to either completely disable blackbird in production mode (avoiding unnecessary .css and .js downloads) or at least disable the console hotkey. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-769) Combination of JavaScript is flawed
Combination of JavaScript is flawed --- Key: TAP5-769 URL: https://issues.apache.org/jira/browse/TAP5-769 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Andy Blower Tapestry's JavaScript combination functionality is flawed. Each page component specifies which JS files it needs, which means that JS can be split into functional units (good for development maintenance) and only the JS that's actually needed for that page is added for the client to download. The consequence of this is that pages can have lots of JS files to download, all of which have to be downloaded before the page is loaded/rendered now that the script link tags are enforced to be back in the head section. Our results page has 34 JS files for instance. Yahoo's YSlow tool recommends that these files are combined and minified, and Tapestry includes functionality to do the first (minifying is on the TODO list I believe) as a response to this recommendation which is good. Unfortunately the implementation based on only having the JS files required for a page means that the combined JS can easily be unique for each page of a site. This means that the client browser has to download cache lots of large JS multiple times (prototype, scriptaculous, tapestry etc) which I think is probably worse than requesting them separately, but only downloading stuff once and using that for all pages. To solve this issue, Tapestry script combination should combine all of the scripts needed for the site, and not just the unique set for each page. That way only a single JS file needs to be downloaded and cached by the client browser. I'm aware that this may not be that easy given the existing way only scripts needed for the page are put on it, so an alternative solution that may be easier to implement would be to combine scripts into two files for each page. The first file would contain all of the commonly Tapestry provided JS such as prototype.js, scriptaculous.js, effects.js, tapestry.js, etc in one file that's the same for every page, and have the rest in a second file that is unique for the page but that is not likely to include very large JS files, just many little ones. A second flaw that the combination has is that if an external JS file is requested, script combination is aborted rather than just excluding the external file. One other thing that surprised me about Tapestry's script combination is the length of the generated filename, for example it's 919 characters long for a page on our site: H4sIALVW7ZLSMBTFGX0Rx$002fFrZgk7gvjDH0plBWdRho6ujjpOmt7ChTTpJmlZfBYfwVfzHUwKRRiFXUrlV0hPzs39OKf9$002bat253utdrtmf3drjwnVGowmmilMDGUpl6kmrfppvVFvkURJI80igfpU1$002br7sVu7Dv9wPx6iCJjJkfcKpKEJaKMWa1Cx4VD3C1TAKZsFqMI1bL3jcCfXsp3EoDUdQx78cwFn3C4SaiaEsfDps0bUeNJstprtoE2YjF0tLlN7nNAksWCpgGNApjSjy$002fzIUCZpcoEilPNzFLNqyfuCo4APlGNIDUrhyL2C3B76J20iBQj7PF4o0EAVmxAfx6Iv3mWgOM2r2i1BMlQQgQLBQLtMHQ2tKlGO44nJEOZkqv$002f8cSFGR4XYyGQj$002bxelS3gmVewYnu9lyNYNI6kGJWhc9FAqd$002fpNifieAmpgqGSEHDZy$002bXZYfXIT2N2HpfQxcW0o1i7K$002b6q60BeR7KRBwHNzebTfLJgURkmea6q9U99FlBivUNiapka6gBwMHC$002fGFanHpab20i8tubdB3rlpJwsNObfw02BqTfActSk9jTQDP186hi9VdWcEOuVGnyE3VulhJ5$002bw1wfm2MMwBNFDM6BqBsqfo1le8zgpb0ypJ$002bUMlz7eu$002bnlMtQp5SFoq2MyoCg8O1z2yciZzUG$002busXUvbRrT$002fI0Fgcpe4vEnuc00WgHzLeDsTL6B9e8ea2hgCrlwtYEbv3YNQOvrM2MqBjD1jC4OJ$002f$002by5jlbfxaFfVgMVppxJuA$002fTqQV47$002bYwmJ$002fc10gWby1jpihGz9Nq7MGLsi9O33yZL2NyNGzuevCQAA.js -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-769) Combination of JavaScript is flawed
[ https://issues.apache.org/jira/browse/TAP5-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Blower updated TAP5-769: - Description: I think Tapestry's JavaScript combination functionality is flawed. Each page component specifies which JS files it needs, which means that JS can be split into functional units (good for development maintenance) and only the JS that's actually needed for that page is added for the client to download. The consequence of this is that pages can have lots of JS files to download, all of which has to be downloaded before the page is loaded/rendered now that the script link tags are enforced to be back in the head section. Our search results page has 34 JS files for instance. Yahoo's YSlow tool recommends that these files are combined and minified, and Tapestry includes functionality to do the first (minifying is on the TODO list I believe) probably as a response to this recommendation which is good. Unfortunately the implementation based on only having the JS files required for a page means that the combined JS can easily be unique for most pages of a site. This means that the client browser has to download cache lots of large JS multiple times (prototype, scriptaculous, tapestry etc) as part of bigger combined files, which I think is probably worse than requesting them separately, but only downloading stuff once and using that for all pages. To solve this issue, Tapestry script combination could combine all of the scripts needed for the site, and not just the unique set for each page. That way only a single JS file needs to be downloaded and cached by the client browser. I'm aware that this may not be that easy given the existing way only scripts needed for the page are put on it, so an alternative solution that may be easier to implement would be to combine scripts into two files for each page. The first file would contain all of the commonly Tapestry provided JS such as prototype.js, scriptaculous.js, effects.js, tapestry.js, etc in one file that's the same for every page, and have the rest in a second file that is unique for the page but that is not likely to include very large JS files, just many little ones. A second flaw that the combination has is that if an external JS file is requested, script combination is aborted rather than just excluding the external file from the combination. One other thing that surprised me about Tapestry's script combination is the length of the generated filename, for example it's 919 characters long for a page on our site. was: Tapestry's JavaScript combination functionality is flawed. Each page component specifies which JS files it needs, which means that JS can be split into functional units (good for development maintenance) and only the JS that's actually needed for that page is added for the client to download. The consequence of this is that pages can have lots of JS files to download, all of which have to be downloaded before the page is loaded/rendered now that the script link tags are enforced to be back in the head section. Our results page has 34 JS files for instance. Yahoo's YSlow tool recommends that these files are combined and minified, and Tapestry includes functionality to do the first (minifying is on the TODO list I believe) as a response to this recommendation which is good. Unfortunately the implementation based on only having the JS files required for a page means that the combined JS can easily be unique for each page of a site. This means that the client browser has to download cache lots of large JS multiple times (prototype, scriptaculous, tapestry etc) which I think is probably worse than requesting them separately, but only downloading stuff once and using that for all pages. To solve this issue, Tapestry script combination should combine all of the scripts needed for the site, and not just the unique set for each page. That way only a single JS file needs to be downloaded and cached by the client browser. I'm aware that this may not be that easy given the existing way only scripts needed for the page are put on it, so an alternative solution that may be easier to implement would be to combine scripts into two files for each page. The first file would contain all of the commonly Tapestry provided JS such as prototype.js, scriptaculous.js, effects.js, tapestry.js, etc in one file that's the same for every page, and have the rest in a second file that is unique for the page but that is not likely to include very large JS files, just many little ones. A second flaw that the combination has is that if an external JS file is requested, script combination is aborted rather than just excluding the external file. One other thing that surprised me about Tapestry's script combination is the length of the generated filename, for example it's 919 characters long for a page on our
[jira] Commented: (TAP5-836) URLEventContext is not Serializable - prevents Tapestry use in a Cluster
[ https://issues.apache.org/jira/browse/TAP5-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12751395#action_12751395 ] Andy Blower commented on TAP5-836: -- Could you explain why a URLEventContext is going into the session? URLEventContext is not Serializable - prevents Tapestry use in a Cluster Key: TAP5-836 URL: https://issues.apache.org/jira/browse/TAP5-836 Project: Tapestry 5 Issue Type: Bug Environment: CentOS 5.3, Java 1.6.0_14-b08, Tomcat 5.5.27 Reporter: David Rees Priority: Critical I have a Tapestry application which I am trying to use in a Tomcat cluster. Tomcat uses Object Input/Output Streams to replicate session data, which requires that all objects added to a Session implement Serializable. In Tapestry 5.0.18 (and all later versions from what I can tell from browsing source), org.apache.tapestry5.internal.URLEventContext does not implement Serializable which prevents us from using Tapestry in a cluster. Unfortunately, this means that when we have to deploy a new version of our application, we have to forcibly log everyone out disrupting service. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-834) BaseOptimizedSessionPersistedObject does not work correctly with Tomcat Jetty
[
https://issues.apache.org/jira/browse/TAP5-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12788043#action_12788043
]
Andy Blower commented on TAP5-834:
--
It looks to me like you've implemented solution 2 from my bug report above. As
I said originally, I'm concerned that this will potentially cause hard to find
concurrency problems which is why I thought the more complicated solution was a
better option. If there are two threads handling requests for the same user
session, setting the session attribute to null without synchronisation when one
request has finished processing while the other is still being handled could
cause problems, couldn't it?
If you think that this isn't an issue, please could you explain why? Maybe I'm
missing something in my analysis here?
BaseOptimizedSessionPersistedObject does not work correctly with Tomcat
Jetty
---
Key: TAP5-834
URL: https://issues.apache.org/jira/browse/TAP5-834
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.0.18
Reporter: Andy Blower
Assignee: Howard M. Lewis Ship
Priority: Critical
Fix For: 5.2.0.0
Attachments: TAP5-834-patch.txt
OptimizedSessionPersistedObject's suggestion for implementing
isSessionPersistedObjectDirty(), as used by
BaseOptimizedSessionPersistedObject, does not work correctly with Tomcat
Jetty. (and quite possibly other servlet containers too, but we only use
Jetty Tomcat so have only confirmed it with them)
OptimizedSessionPersistedObject model relies on the servlet container session
object triggering a HttpSessionBindingEvent when an object is re-stored in
the session to reset the dirty flag. I've only looked at the source of Tomcat
5.5 and 6 but when an object is replaced in the session using setAttribute()
the new object and the existing object are compared by reference only, if
they both refer to the same object then no HttpSessionBindingEvent is
triggered.
From Tomcat StandardSession.java:
// Call the valueBound() method if necessary
if (notify value instanceof HttpSessionBindingListener) {
// Don't call any notification if replacing with the same value
Object oldValue = attributes.get(name);
if (value != oldValue) {
event = new HttpSessionBindingEvent(getSession(), name,
value);
try {
((HttpSessionBindingListener) value).valueBound(event);
} catch (Throwable t){
manager.getContainer().getLogger().error
(sm.getString(standardSession.bindingEvent), t);
}
}
}
So, using OptimizedSessionPersistedObject, there is currently no way of
setting the dirty flag to false after the object has been saved in the
session - hence we are propagating all of the SSOs across the cluster all of
the time because the dirty flag stays set to true.
I think there are two possible solutions to this issue - I prefer the first
by a large margin, but both modify the SessionImpl.restoreDirtyObjects()
method.
1) Add a new method to OptimizedSessionPersistedObject interface to reset the
dirty flag, and a corresponding method in SessionPersistedObjectAnalyzer -
implementing them as appropriate, then call the new reset method after
setting the session attribute in SessionImpl.restoreDirtyObjects().
2) Remove the session attribute before adding it in
SessionImpl.restoreDirtyObjects(). Although I have a worry that this may
potentially cause hard to find concurrency problems.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-834) BaseOptimizedSessionPersistedObject does not work correctly with Tomcat Jetty
[
https://issues.apache.org/jira/browse/TAP5-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12788796#action_12788796
]
Andy Blower commented on TAP5-834:
--
It is definitely an edge case, and maybe I'm being over paranoid. As you say
solution #1 (implemented in my patch) does change two public interfaces. I
don't consider it an issue because it's only adding a single new a method in
each case, which for people upgrading to T5.2 would be as simple as
generating/writing a method stub that do nothing to keep the same behaviour as
T5.1. I could see your point if it changed existing method signatures or
something, but I think there were much worse changes required for migrating
from 5.0-5.1, and I feel that this is better for T5 than adding
synchronization overheads. That's my opinion anyway FWIW. :-)
Thanks for the response. Never heard of Brian Goetz before though...
BaseOptimizedSessionPersistedObject does not work correctly with Tomcat
Jetty
---
Key: TAP5-834
URL: https://issues.apache.org/jira/browse/TAP5-834
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.0.18
Reporter: Andy Blower
Assignee: Howard M. Lewis Ship
Priority: Critical
Fix For: 5.2.0
Attachments: TAP5-834-patch.txt
OptimizedSessionPersistedObject's suggestion for implementing
isSessionPersistedObjectDirty(), as used by
BaseOptimizedSessionPersistedObject, does not work correctly with Tomcat
Jetty. (and quite possibly other servlet containers too, but we only use
Jetty Tomcat so have only confirmed it with them)
OptimizedSessionPersistedObject model relies on the servlet container session
object triggering a HttpSessionBindingEvent when an object is re-stored in
the session to reset the dirty flag. I've only looked at the source of Tomcat
5.5 and 6 but when an object is replaced in the session using setAttribute()
the new object and the existing object are compared by reference only, if
they both refer to the same object then no HttpSessionBindingEvent is
triggered.
From Tomcat StandardSession.java:
// Call the valueBound() method if necessary
if (notify value instanceof HttpSessionBindingListener) {
// Don't call any notification if replacing with the same value
Object oldValue = attributes.get(name);
if (value != oldValue) {
event = new HttpSessionBindingEvent(getSession(), name,
value);
try {
((HttpSessionBindingListener) value).valueBound(event);
} catch (Throwable t){
manager.getContainer().getLogger().error
(sm.getString(standardSession.bindingEvent), t);
}
}
}
So, using OptimizedSessionPersistedObject, there is currently no way of
setting the dirty flag to false after the object has been saved in the
session - hence we are propagating all of the SSOs across the cluster all of
the time because the dirty flag stays set to true.
I think there are two possible solutions to this issue - I prefer the first
by a large margin, but both modify the SessionImpl.restoreDirtyObjects()
method.
1) Add a new method to OptimizedSessionPersistedObject interface to reset the
dirty flag, and a corresponding method in SessionPersistedObjectAnalyzer -
implementing them as appropriate, then call the new reset method after
setting the session attribute in SessionImpl.restoreDirtyObjects().
2) Remove the session attribute before adding it in
SessionImpl.restoreDirtyObjects(). Although I have a worry that this may
potentially cause hard to find concurrency problems.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-959) Ajax event handler methods that return a page instance, page class or page name should cause the client to redirect to that page, but doesn't work in IE7 or 8 if the URL has
[ https://issues.apache.org/jira/browse/TAP5-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Blower updated TAP5-959: - Attachment: TAP5-959_patch.txt Ajax event handler methods that return a page instance, page class or page name should cause the client to redirect to that page, but doesn't work in IE7 or 8 if the URL has a query param --- Key: TAP5-959 URL: https://issues.apache.org/jira/browse/TAP5-959 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Environment: Internet Explorer v7 v8 Reporter: Andy Blower Priority: Minor Attachments: TAP5-959_patch.txt Ajax event handler methods that return a page instance, page class or page name should cause the client to redirect to that page, refer to TAP5-187 and TAP5-613 for those fixes. Unfortunately the mechanism doesn't work in IE7 or 8 if the URL has a query parameter added to the Link object. We have an accountid parameter (e.g. /page?account=1234) added to all render URLs using method advice which exposed this issue. The fix is pretty simple - just used window.location.href instead of .pathname Unless there's a good reason .href was not used in the first place that I'm not aware of? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-1048) Support for IE conditional stylesheets will need changes to DocumentLinkerImpl
Support for IE conditional stylesheets will need changes to DocumentLinkerImpl -- Key: TAP5-1048 URL: https://issues.apache.org/jira/browse/TAP5-1048 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Andy Blower Priority: Minor I'm having the issue described in TAP5-56, and although it's fairly easily solved using a component (see: http://markmail.org/message/aidg4w223t5yaass) or some other way, this is still not sufficient. The problem is in the ordering of the stylesheets in the final rendered HTML output. The addStylesheetsToHead() method of DocumentLinkerImpl adds the included stylesheets and then moves them before any stylesheet links already in the dom. This fails if one of the existing stylesheet links is a conditional one, as findExistingElement() doesn't find the comment. I've tried modifying the service, but because comments are Raw node, it seems impossible to put a bunch of Element nodes before one in the DOM. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1048) Support for IE conditional stylesheets will need changes to DocumentLinkerImpl
[ https://issues.apache.org/jira/browse/TAP5-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Blower updated TAP5-1048: -- Attachment: TAP5-1048-patch.txt This does fix the problem, but it's not the most satisfactory solution. Without changing the Node/Raw/Element classes I couldn't see another way to fix it. Support for IE conditional stylesheets will need changes to DocumentLinkerImpl -- Key: TAP5-1048 URL: https://issues.apache.org/jira/browse/TAP5-1048 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Andy Blower Priority: Minor Attachments: TAP5-1048-patch.txt I'm having the issue described in TAP5-56, and although it's fairly easily solved using a component (see: http://markmail.org/message/aidg4w223t5yaass) or some other way, this is still not sufficient. The problem is in the ordering of the stylesheets in the final rendered HTML output. The addStylesheetsToHead() method of DocumentLinkerImpl adds the included stylesheets and then moves them before any stylesheet links already in the dom. This fails if one of the existing stylesheet links is a conditional one, as findExistingElement() doesn't find the comment. I've tried modifying the service, but because comments are Raw node, it's difficult to put a bunch of Element nodes before one in the DOM. The only way I could think of is included as a patch - findExistingElement() can return the previous Element which can then have the link element nodes placed after rather than before. This works, but is not very satisfactory. I can't use this anyway because overriding that T5 DocumentLinkerImpl is fragile and breaks in some of our environments. I spent several hours aliasing and overriding this 'service' before I realised that DocumentLinker is not actually a service! It's in the internal.services package, but isn't actually a service - it's instantiated directly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1048) Support for IE conditional stylesheets will need changes to DocumentLinkerImpl
[ https://issues.apache.org/jira/browse/TAP5-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Blower updated TAP5-1048: -- Description: I'm having the issue described in TAP5-56, and although it's fairly easily solved using a component (see: http://markmail.org/message/aidg4w223t5yaass) or some other way, this is still not sufficient. The problem is in the ordering of the stylesheets in the final rendered HTML output. The addStylesheetsToHead() method of DocumentLinkerImpl adds the included stylesheets and then moves them before any stylesheet links already in the dom. This fails if one of the existing stylesheet links is a conditional one, as findExistingElement() doesn't find the comment. I've tried modifying the service, but because comments are Raw node, it's difficult to put a bunch of Element nodes before one in the DOM. The only way I could think of is included as a patch - findExistingElement() can return the previous Element which can then have the link element nodes placed after rather than before. This works, but is not very satisfactory. I can't use this anyway because overriding that T5 DocumentLinkerImpl is fragile and breaks in some of our environments. I spent several hours aliasing and overriding this 'service' before I realised that DocumentLinker is not actually a service! It's in the internal.services package, but isn't actually a service - it's instantiated directly. was: I'm having the issue described in TAP5-56, and although it's fairly easily solved using a component (see: http://markmail.org/message/aidg4w223t5yaass) or some other way, this is still not sufficient. The problem is in the ordering of the stylesheets in the final rendered HTML output. The addStylesheetsToHead() method of DocumentLinkerImpl adds the included stylesheets and then moves them before any stylesheet links already in the dom. This fails if one of the existing stylesheet links is a conditional one, as findExistingElement() doesn't find the comment. I've tried modifying the service, but because comments are Raw node, it seems impossible to put a bunch of Element nodes before one in the DOM. Support for IE conditional stylesheets will need changes to DocumentLinkerImpl -- Key: TAP5-1048 URL: https://issues.apache.org/jira/browse/TAP5-1048 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Andy Blower Priority: Minor Attachments: TAP5-1048-patch.txt I'm having the issue described in TAP5-56, and although it's fairly easily solved using a component (see: http://markmail.org/message/aidg4w223t5yaass) or some other way, this is still not sufficient. The problem is in the ordering of the stylesheets in the final rendered HTML output. The addStylesheetsToHead() method of DocumentLinkerImpl adds the included stylesheets and then moves them before any stylesheet links already in the dom. This fails if one of the existing stylesheet links is a conditional one, as findExistingElement() doesn't find the comment. I've tried modifying the service, but because comments are Raw node, it's difficult to put a bunch of Element nodes before one in the DOM. The only way I could think of is included as a patch - findExistingElement() can return the previous Element which can then have the link element nodes placed after rather than before. This works, but is not very satisfactory. I can't use this anyway because overriding that T5 DocumentLinkerImpl is fragile and breaks in some of our environments. I spent several hours aliasing and overriding this 'service' before I realised that DocumentLinker is not actually a service! It's in the internal.services package, but isn't actually a service - it's instantiated directly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1264) Ordering of MarkupRenderer (and PartialMarkupRender) filters can cause bad interraction between ClientBehaviorSupport and Heartbeat
[ https://issues.apache.org/jira/browse/TAP5-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12906493#action_12906493 ] Andy Blower commented on TAP5-1264: --- This seems to fix the issue. Ordering of MarkupRenderer (and PartialMarkupRender) filters can cause bad interraction between ClientBehaviorSupport and Heartbeat --- Key: TAP5-1264 URL: https://issues.apache.org/jira/browse/TAP5-1264 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.2.0, 5.2.1 Reporter: Howard M. Lewis Ship Assignee: Howard M. Lewis Ship Fix For: 5.2.1 As per discussion: http://tapestry.markmail.org/thread/sl6scyb4ccnulmgm Heartbeat should probably be near the end of the list of filters, otherwise prior filters (which put objects into the Environment scope) may have removed those objects from scope. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-1279) The stack model for JavaScript combination doesn't de-duplicate individual references
The stack model for JavaScript combination doesn't de-duplicate individual references - Key: TAP5-1279 URL: https://issues.apache.org/jira/browse/TAP5-1279 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.2.0, 5.2.1 Reporter: Andy Blower The stack mechanism doesn't seem to be removing duplicate javascript references as I expect it to. Tapestry JS has always worked on a component requesting the JS assets it needs and then Tapestry ensured that each required JS asset was added to the page once and only once, even if several components asked for the same JS asset. The stack system doesn't seem to follow this model... For example, say I have a component Comp that specifies it needs the CompJS asset, and is used on pages Page1 and Page2. If Page1 doesn't have much more to it and only needs CompJS then that's what should be included by Tapestry, since Comp @Import's CompJS. All well and good. Now, if Page2 has a lot of other components with their own JS files which are then combined into a T5 stack and requested by the page's @Import then I would not expect CompJS to be referenced on the page since it's already included in the stack file. It seems to be in T5.2.0 with my testing. Unless I'm mistaken about how this is working, then I fail to see how this stack mechanism provides much benefit over simply putting all my projects' JS into a single file and referencing that in each page. The only advantage is to split it up into easily editable chunks, I still have to manage the aggregation. I think it's going to be very easy to get duplicate JS in the rendered html page with this system. If a stack is imported which contains CompJS, and another component imports CompJS individually, just output the reference to the stack, and not CompJS. There are two ways to implement the remaining behaviour: 1) If the stack is not imported, and a component imports CompJS individually, just output the reference to CompJS. 2) If the stack is not imported, and a component imports CompJS individually, output a reference to the stack containing CompJS. This is more difficult and may be tricky if the component has been defined as being part of more than one stack. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1279) The stack model for JavaScript combination doesn't de-duplicate individual references
[ https://issues.apache.org/jira/browse/TAP5-1279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12912886#action_12912886 ] Andy Blower commented on TAP5-1279: --- Follow up to TAP5-769 The stack model for JavaScript combination doesn't de-duplicate individual references - Key: TAP5-1279 URL: https://issues.apache.org/jira/browse/TAP5-1279 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.2.0, 5.2.1 Reporter: Andy Blower The stack mechanism doesn't seem to be removing duplicate javascript references as I expect it to. Tapestry JS has always worked on a component requesting the JS assets it needs and then Tapestry ensured that each required JS asset was added to the page once and only once, even if several components asked for the same JS asset. The stack system doesn't seem to follow this model... For example, say I have a component Comp that specifies it needs the CompJS asset, and is used on pages Page1 and Page2. If Page1 doesn't have much more to it and only needs CompJS then that's what should be included by Tapestry, since Comp @Import's CompJS. All well and good. Now, if Page2 has a lot of other components with their own JS files which are then combined into a T5 stack and requested by the page's @Import then I would not expect CompJS to be referenced on the page since it's already included in the stack file. It seems to be in T5.2.0 with my testing. Unless I'm mistaken about how this is working, then I fail to see how this stack mechanism provides much benefit over simply putting all my projects' JS into a single file and referencing that in each page. The only advantage is to split it up into easily editable chunks, I still have to manage the aggregation. I think it's going to be very easy to get duplicate JS in the rendered html page with this system. If a stack is imported which contains CompJS, and another component imports CompJS individually, just output the reference to the stack, and not CompJS. There are two ways to implement the remaining behaviour: 1) If the stack is not imported, and a component imports CompJS individually, just output the reference to CompJS. 2) If the stack is not imported, and a component imports CompJS individually, output a reference to the stack containing CompJS. This is more difficult and may be tricky if the component has been defined as being part of more than one stack. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1355) Threading issue with SessionStateObjects
[ https://issues.apache.org/jira/browse/TAP5-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12935740#action_12935740 ] Andy Blower commented on TAP5-1355: --- May I ask why my original patch to fix the issue TAP5-834 is not being considered. I was pretty surprised that it was not used in the first place, but the second way of fixing the issue was chosen which had possible concurrency issues. My original words: I think there are two possible solutions to this issue - I prefer the first by a large margin, but both modify the SessionImpl.restoreDirtyObjects() method. 1) Add a new method to OptimizedSessionPersistedObject interface to reset the dirty flag, and a corresponding method in SessionPersistedObjectAnalyzer - implementing them as appropriate, then call the new reset method after setting the session attribute in SessionImpl.restoreDirtyObjects(). 2) Remove the session attribute before adding it in SessionImpl.restoreDirtyObjects(). Although I have a worry that this may potentially cause hard to find concurrency problems. The second solution was used, but the first solution (which my patch implemented) is much better. I know it adds a new method to a public interface, but this is not as much impact as changing or removing an existing method one and in this case is trivial for users to implement. There has certainly been worse backwards compatibility changes made in T5, and the benefit of this simple solution (#1 above) far outweighs the impact IMHO. It's also a lot simpler and cleaner than the solutions proposed here. Also IMHO. Just FYI the code from the patch was run in our production environment for several months before we upgraded to Tapestry 5.2 and removed my customizations. Luckily we don't seem to have run into any threading issues, well not that have caused any fuss at least. Threading issue with SessionStateObjects Key: TAP5-1355 URL: https://issues.apache.org/jira/browse/TAP5-1355 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.2.4 Reporter: Moritz Gmelin Attachments: Screenshot.png.jpg, taptest.tgz When a page request consists of multiple HTTP request (e.g. page and some dynamically generated images) and all those requests access a SessionStateObject, it happens that a new session (with an empty SSO) is created for some of the request threads. I was able to create a very simple example to recreate that problem: -A simple page that displays 20 dynamically generated images in a loop. -In the page, a SSO, holding a number value is initialized to a random number. -Each of the dynamic images read that number and draws it. -Make sure that a HTTP-Request is made for every image on the page (by adding some random number to the event link) The effect that you'll see after some reloads of the page (maybe you need to reload 30 times) is that some images will draw 0 as SSO value instead of the number set in the page @BeginRender method. Those fields will be marked in red in the demo so you can quickly see them. I definitely beleive that tapestry should take care of this. It is a use case for SSOs that is probably too common to ignore. Why can't this be automatically integrated into the ApplicationStateManager? The demo has been deployed here http://www.avetana.de/taptest/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1355) Threading issue with SessionStateObjects
[ https://issues.apache.org/jira/browse/TAP5-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12964677#action_12964677 ] Andy Blower commented on TAP5-1355: --- Surely you mean my first solution Josh? The second is essentially what Howard implemented for TAP5-834 and is giving us this problem. Threading issue with SessionStateObjects Key: TAP5-1355 URL: https://issues.apache.org/jira/browse/TAP5-1355 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.2.4 Reporter: Moritz Gmelin Attachments: Screenshot.png.jpg, taptest.tgz When a page request consists of multiple HTTP request (e.g. page and some dynamically generated images) and all those requests access a SessionStateObject, it happens that a new session (with an empty SSO) is created for some of the request threads. I was able to create a very simple example to recreate that problem: -A simple page that displays 20 dynamically generated images in a loop. -In the page, a SSO, holding a number value is initialized to a random number. -Each of the dynamic images read that number and draws it. -Make sure that a HTTP-Request is made for every image on the page (by adding some random number to the event link) The effect that you'll see after some reloads of the page (maybe you need to reload 30 times) is that some images will draw 0 as SSO value instead of the number set in the page @BeginRender method. Those fields will be marked in red in the demo so you can quickly see them. I definitely beleive that tapestry should take care of this. It is a use case for SSOs that is probably too common to ignore. Why can't this be automatically integrated into the ApplicationStateManager? The demo has been deployed here http://www.avetana.de/taptest/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1372) BaseURLSource uses getLocalPort() rather than getServerPort()
[ https://issues.apache.org/jira/browse/TAP5-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Blower updated TAP5-1372: -- Priority: Critical (was: Major) Description: Line 31 of BaseURLSourceImpl: int port = request.getLocalPort(); Which calls same method in the underlying ServletRequest. getLocalPort javadoc: Returns the Internet Protocol (IP) port number of the interface on which the request was received. getServerPort javadoc: Returns the port number to which the request was sent. It is the value of the part after : in the codeHost/code header, if any, or the server port where the client connection was accepted on. I think that the second is the one that should be used and since this port number is paired with the host returned from getServerName() rather than getLocalName(), this seems like a bug to me. Admittedly one that only causes problems in clustered load balanced environments, but it's just affected our site so it would be great if it could be fixed for 5.2 final release. A final release of Tapestry should not have a bug like this in it! Unless anyone has a convincing argument why it should be this way, of course... was: Line 31 of BaseURLSourceImpl: int port = request.getLocalPort(); Which calls same method in the underlying ServletRequest. getLocalPort javadoc: Returns the Internet Protocol (IP) port number of the interface on which the request was received. getServerPort javadoc: Returns the port number to which the request was sent. It is the value of the part after : in the codeHost/code header, if any, or the server port where the client connection was accepted on. I think that the second is the one that should be used and since this port number is paired with the host returned from getServerName() rather than getLocalName(), this seems like a bug to me. Admittedly one that will only rarely cause a problem, but it's just affected our site so it would be great if it could be fixed for 5.2.5 final release. Unless anyone has a convincing argument why it should be this way, of course... BaseURLSource uses getLocalPort() rather than getServerPort() - Key: TAP5-1372 URL: https://issues.apache.org/jira/browse/TAP5-1372 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.2.4 Reporter: Andy Blower Priority: Critical Line 31 of BaseURLSourceImpl: int port = request.getLocalPort(); Which calls same method in the underlying ServletRequest. getLocalPort javadoc: Returns the Internet Protocol (IP) port number of the interface on which the request was received. getServerPort javadoc: Returns the port number to which the request was sent. It is the value of the part after : in the codeHost/code header, if any, or the server port where the client connection was accepted on. I think that the second is the one that should be used and since this port number is paired with the host returned from getServerName() rather than getLocalName(), this seems like a bug to me. Admittedly one that only causes problems in clustered load balanced environments, but it's just affected our site so it would be great if it could be fixed for 5.2 final release. A final release of Tapestry should not have a bug like this in it! Unless anyone has a convincing argument why it should be this way, of course... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1372) BaseURLSource uses getLocalPort() rather than getServerPort()
[ https://issues.apache.org/jira/browse/TAP5-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12972148#action_12972148 ] Andy Blower commented on TAP5-1372: --- Have you seen Igor's comment on the release vote thread? I see another issue here: Request interface is a generic version of HttpServletRequest and PortletRequest. As of 5.2.0 Request has the getLocalPort() method which is not available in PortletRequest. Just in case that makes a difference to your decision. It's fixed in our product, so it's not urgent for us, I just don't want anyone else hitting the same issue and thinking less of Tapestry. BaseURLSource uses getLocalPort() rather than getServerPort() - Key: TAP5-1372 URL: https://issues.apache.org/jira/browse/TAP5-1372 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.2.4 Reporter: Andy Blower Priority: Critical Line 31 of BaseURLSourceImpl: int port = request.getLocalPort(); Which calls same method in the underlying ServletRequest. getLocalPort javadoc: Returns the Internet Protocol (IP) port number of the interface on which the request was received. getServerPort javadoc: Returns the port number to which the request was sent. It is the value of the part after : in the codeHost/code header, if any, or the server port where the client connection was accepted on. I think that the second is the one that should be used and since this port number is paired with the host returned from getServerName() rather than getLocalName(), this seems like a bug to me. Admittedly one that only causes problems in clustered load balanced environments, but it's just affected our site so it would be great if it could be fixed for 5.2 final release. A final release of Tapestry should not have a bug like this in it! Unless anyone has a convincing argument why it should be this way, of course... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] [Created] (TAP5-1563) ParallelExecutor service appears to be bound to the number of executor threads specified by THREAD_POOL_CORE_SIZE
ParallelExecutor service appears to be bound to the number of executor threads specified by THREAD_POOL_CORE_SIZE -- Key: TAP5-1563 URL: https://issues.apache.org/jira/browse/TAP5-1563 Project: Tapestry 5 Issue Type: Bug Components: tapestry-ioc Affects Versions: 5.2.4 Reporter: Andy Blower ParallelExecutor service appears to be bound to the number of executor threads specified by THREAD_POOL_CORE_SIZE rather than THREAD_POOL_MAX_SIZE, which means by default only three parallel tasks are executed at once rather than the maximum of 20. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1563) ParallelExecutor service appears to be bound to the number of executor threads specified by THREAD_POOL_CORE_SIZE
[ https://issues.apache.org/jira/browse/TAP5-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Blower updated TAP5-1563: -- Description: ParallelExecutor service is bound to the number of executor threads specified by THREAD_POOL_CORE_SIZE rather than THREAD_POOL_MAX_SIZE, which means by default only three parallel tasks are executed at once rather than the maximum of 20. This is unexpected behaviour for someone not familiar with the ThreadPoolExecutor design, which is not intuitive. The documentation of ParallelExecutor is very misleading and should be expanded to explain this correctly. This blog post I found explains it clearly: http://www.bigsoft.co.uk/blog/index.php/2009/11/27/rules-of-a-threadpoolexecutor-pool-size was: ParallelExecutor service appears to be bound to the number of executor threads specified by THREAD_POOL_CORE_SIZE rather than THREAD_POOL_MAX_SIZE, which means by default only three parallel tasks are executed at once rather than the maximum of 20. This is unexpected behaviour to someone not familiar with the ThreadPoolExecutor design, which is not intuitive. The documentation should be expanded to explain this correctly. This blog post I found explains it clearly http://www.bigsoft.co.uk/blog/index.php/2009/11/27/rules-of-a-threadpoolexecutor-pool-size ParallelExecutor service appears to be bound to the number of executor threads specified by THREAD_POOL_CORE_SIZE -- Key: TAP5-1563 URL: https://issues.apache.org/jira/browse/TAP5-1563 Project: Tapestry 5 Issue Type: Improvement Components: documentation, tapestry-ioc Reporter: Andy Blower Priority: Minor ParallelExecutor service is bound to the number of executor threads specified by THREAD_POOL_CORE_SIZE rather than THREAD_POOL_MAX_SIZE, which means by default only three parallel tasks are executed at once rather than the maximum of 20. This is unexpected behaviour for someone not familiar with the ThreadPoolExecutor design, which is not intuitive. The documentation of ParallelExecutor is very misleading and should be expanded to explain this correctly. This blog post I found explains it clearly: http://www.bigsoft.co.uk/blog/index.php/2009/11/27/rules-of-a-threadpoolexecutor-pool-size -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1563) ParallelExecutor service appears to be bound to the number of executor threads specified by THREAD_POOL_CORE_SIZE
[ https://issues.apache.org/jira/browse/TAP5-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Blower updated TAP5-1563: -- Component/s: documentation Priority: Minor (was: Major) Description: ParallelExecutor service appears to be bound to the number of executor threads specified by THREAD_POOL_CORE_SIZE rather than THREAD_POOL_MAX_SIZE, which means by default only three parallel tasks are executed at once rather than the maximum of 20. This is unexpected behaviour to someone not familiar with the ThreadPoolExecutor design, which is not intuitive. The documentation should be expanded to explain this correctly. This blog post I found explains it clearly http://www.bigsoft.co.uk/blog/index.php/2009/11/27/rules-of-a-threadpoolexecutor-pool-size was:ParallelExecutor service appears to be bound to the number of executor threads specified by THREAD_POOL_CORE_SIZE rather than THREAD_POOL_MAX_SIZE, which means by default only three parallel tasks are executed at once rather than the maximum of 20. Issue Type: Improvement (was: Bug) Affects Version/s: (was: 5.2.4) ParallelExecutor service appears to be bound to the number of executor threads specified by THREAD_POOL_CORE_SIZE -- Key: TAP5-1563 URL: https://issues.apache.org/jira/browse/TAP5-1563 Project: Tapestry 5 Issue Type: Improvement Components: documentation, tapestry-ioc Reporter: Andy Blower Priority: Minor ParallelExecutor service appears to be bound to the number of executor threads specified by THREAD_POOL_CORE_SIZE rather than THREAD_POOL_MAX_SIZE, which means by default only three parallel tasks are executed at once rather than the maximum of 20. This is unexpected behaviour to someone not familiar with the ThreadPoolExecutor design, which is not intuitive. The documentation should be expanded to explain this correctly. This blog post I found explains it clearly http://www.bigsoft.co.uk/blog/index.php/2009/11/27/rules-of-a-threadpoolexecutor-pool-size -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1600) A component that is defined inside a t:block does not appear as an embedded component, causing page-load exceptions on the event handlers for the embedded component
[
https://issues.apache.org/jira/browse/TAP5-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083067#comment-13083067
]
Andy Blower commented on TAP5-1600:
---
Your test case is not the same because you are not injecting the block into the
component so it could be conditionally returned by a method into the delegate
component. I'm not sure why you're removing part of the test case and then
saying it all works fine.
I have added this extra complexity below so you can see more what we're getting
at, but the test as detailed by Pedro breaks in the same manner.
TML:
html t:type=Border
xmlns:t=http://tapestry.apache.org/schema/tapestry_5_3.xsd;
t:delegate to=selectBlock/
t:block id=zen
t:actionlink t:id=goForBrokego for broke/t:actionlink
/t:block
t:block id=nez
t:form t:id=nezForm form content /t:form
/t:block
/html
Java:
public class ComponentInsideBlockDemo
{
@Inject
private AlertManager mgr;
@Inject
private Block zen;
@Inject
private Block nez;
private boolean xennez;
public Block getSelectedBlock() {
if (xennez) {
return zen;
} else {
return nez;
}
}
void onActionFromGoForBroke() {
mgr.info(Go For Broke Clicked);
}
@OnEvent(component = neverForm, value = EventConstants.SUBMIT)
void neverFormSubmitted()
{
mgr.info(Never Form Submitted. How?);
}
}
A component that is defined inside a t:block does not appear as an embedded
component, causing page-load exceptions on the event handlers for the
embedded component
--
Key: TAP5-1600
URL: https://issues.apache.org/jira/browse/TAP5-1600
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.3
Reporter: Howard M. Lewis Ship
Assignee: Howard M. Lewis Ship
Reported from ProQuest, but not yet verified.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1601) Under as yet unknown circumstances, a method that references a field with a conduit will not be instrumented, resulting in an NPE accessing the field itself
[
https://issues.apache.org/jira/browse/TAP5-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13437898#comment-13437898
]
Andy Blower commented on TAP5-1601:
---
Sorry was on holiday. I've looked though what you've done and it seems like it
might fix the issue we encountered. I'm not sure I can remember enough about
how we ran into it to confirm though. If I can find half a day to investigate
and confirm I will do, but i cannot guarantee this.
Under as yet unknown circumstances, a method that references a field with a
conduit will not be instrumented, resulting in an NPE accessing the field
itself
Key: TAP5-1601
URL: https://issues.apache.org/jira/browse/TAP5-1601
Project: Tapestry 5
Issue Type: Bug
Components: plastic, tapestry-core
Affects Versions: 5.3
Reporter: Howard M. Lewis Ship
Assignee: Howard M. Lewis Ship
Priority: Blocker
Labels: class-transformation, fixed-in-5.4-js-rewrite
Fix For: 5.3.5
Attachments: AtCached-issue.zip
From ProQuest, they have a component that has this code:
public class Layout {
@Inject
private ComponentResources resources;
@Cached
public Component getPage() { return resources.getContainer(); }
}
The generated bytecode for the advised method looks ok:
public getPage()Lorg/apache/tapestry5/runtime/Component;
@Lorg/apache/tapestry5/annotations/Cached;()
NEW
com/proquest/apps/onesearch/components/PageLayoutBasic$Invocation_getPage_123876a5ccf1f215
DUP
ALOAD 0
ALOAD 0
GETFIELD
com/proquest/apps/onesearch/components/PageLayoutBasic.instanceContext :
Lorg/apache/tapestry5/plastic/InstanceContext;
ALOAD 0
GETFIELD
com/proquest/apps/onesearch/components/PageLayoutBasic.methodinvocationbundle_getPage_123876a5ccf1f22d
: Lorg/apache/tapestry5/internal/plastic/MethodInvocationBundle;
INVOKESPECIAL
com/proquest/apps/onesearch/components/PageLayoutBasic$Invocation_getPage_123876a5ccf1f215.init
(Ljava/lang/Object;Lorg/apache/tapestry5/plastic/InstanceContext;Lorg/apache/tapestry5/internal/plastic/MethodInvocationBundle;)V
L0
DUP
ASTORE 1
INVOKEVIRTUAL
org/apache/tapestry5/internal/plastic/AbstractMethodInvocation.proceed
()Lorg/apache/tapestry5/plastic/MethodInvocation;
ALOAD 1
GETFIELD
com/proquest/apps/onesearch/components/PageLayoutBasic$Invocation_getPage_123876a5ccf1f215.returnValue
: Lorg/apache/tapestry5/runtime/Component;
ARETURN
L1
LOCALVARIABLE var0
Lcom/proquest/apps/onesearch/components/PageLayoutBasic$Invocation_getPage_123876a5ccf1f215;
L0 L1 1
MAXSTACK = 1
MAXLOCALS = 1
... but the bytecode for the advised method is not instrumented:
public
advised$getPage_123876a5ccf1f216()Lorg/apache/tapestry5/runtime/Component;
@Lorg/apache/tapestry5/annotations/Cached;()
ALOAD 0
GETFIELD com/proquest/apps/onesearch/components/PageLayoutBasic.resources
: Lorg/apache/tapestry5/ComponentResources;
INVOKEINTERFACE org/apache/tapestry5/ComponentResources.getContainer
()Lorg/apache/tapestry5/runtime/Component;
ARETURN
MAXSTACK = 1
MAXLOCALS = 1
... even though the necessary field conduit support method is present:
// access flags 0x1010
final getfieldvalue_resources()Lorg/apache/tapestry5/ComponentResources;
ALOAD 0
GETFIELD
com/proquest/apps/onesearch/components/PageLayoutBasic.resources_FieldConduit
: Lorg/apache/tapestry5/plastic/FieldConduit;
ALOAD 0
ALOAD 0
GETFIELD
com/proquest/apps/onesearch/components/PageLayoutBasic.instanceContext :
Lorg/apache/tapestry5/plastic/InstanceContext;
INVOKEINTERFACE org/apache/tapestry5/plastic/FieldConduit.get
(Ljava/lang/Object;Lorg/apache/tapestry5/plastic/InstanceContext;)Ljava/lang/Object;
CHECKCAST org/apache/tapestry5/ComponentResources
DUP
ALOAD 0
SWAP
PUTFIELD com/proquest/apps/onesearch/components/PageLayoutBasic.resources
: Lorg/apache/tapestry5/ComponentResources;
ARETURN
MAXSTACK = 0
MAXLOCALS = 0
... also, looking at the real class, from the client, as transformed, many
other methods containing references to the field are being transformed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-773) Select component renderer does not allow HTML entities
[ https://issues.apache.org/jira/browse/TAP5-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Blower updated TAP5-773: - Affects Version/s: 5.3.6 5.2.5 Select component renderer does not allow HTML entities -- Key: TAP5-773 URL: https://issues.apache.org/jira/browse/TAP5-773 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.3.6, 5.2.5, 5.1.0.5 Reporter: Andy Blower Labels: bulk-close-candidate All ampersands that are returned from getLabel() in an OptionModel get encoded to amp;. This makes it impossible to use any html entities (mdash; nbsp; etc) within option labels in selects. This is not that uncommon and should definitely be supported by Tapestry out of the box. It can be fixed by changing line 60 of org.apache.tapestry5.internal.util.SelectModelRender from writer.write(optionModel.getLabel()); to writer.writeRaw(optionModel.getLabel()); This would mean that ampersands will need to be encoded for option labels, but this is at least possible for a developer to do. Currently it's not possible to use entities without using a custom select component, you can't even extend the T5 Select class and override the Render nested class. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
