November 2010 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3006) web:character-encoding-filter and UTF-8 not working

by Bruno Orcha Garcￃﾭa (JIRA)

web:character-encoding-filter and UTF-8 not working ---------------------------------------------------- Key: JBSEAM-3006 URL: http://jira.jboss.com/jira/browse/JBSEAM-3006 Project: Seam Issue Type: Bug Components: Core Affects Versions: 2.0.1.GA Reporter: Bruno Orcha Garcￃﾭa web:character-encoding-filter is not working. When submitting UTF-8 characters in a h:inputText (for example), the string contains invalid characters, due a bad encoding interpretation. This issue should be fixed configuring the web:character-encoding-filter to UTF-8 in component.xml, but this is not working. This filter should be the first, in the seam filter stack?. Using a filter in web.xml it's the unique solution that works currently. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

5
5
0 / 0

[JBoss JIRA] Commented: (SEAMINTL-16) Implement an interpolator for strings containing expressions

by Dan Allen (JIRA)

[ https://jira.jboss.org/browse/SEAMINTL-16?page=com.atlassian.jira.plugin.... ] Dan Allen commented on SEAMINTL-16: ----------------------------------- Ken, after this got bumped around, it has become more of an alignment than a new feature, since I know that i18n has an Interpolator already. > Implement an interpolator for strings containing expressions > ------------------------------------------------------------ > > Key: SEAMINTL-16 > URL: https://jira.jboss.org/browse/SEAMINTL-16 > Project: Seam i18n > Issue Type: Task > Components: Messages > Reporter: Dan Allen > Fix For: 3.0.0.Beta1 > > > Since Weld Extensions has adopted the EL expression resolver, it's fitting that it also provides an interpolator for strings containing EL expression. > Provide an interpolator that resolves EL expressions and position parameters in strings. This feature was available in Seam 2 [1]. Since it's not provided yet in Seam 3, we see it showing up as a utility in various modules, including the International [2] and REST [3] modules. We should consolidate this to a single, authoritative source. > It should probably be made an interface with implementations that process specific expression languages, such as EL. For instance, one implementation might interpret MVEL. Just an idea. > [1] http://anonsvn.jboss.org/repos/seam/branches/community/Seam_2_2/src/main/... > [2] https://github.com/seam/international/raw/master/impl/src/main/java/org/j... > [3] https://github.com/seam/rest/raw/master/impl/src/main/java/org/jboss/seam... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (SEAMINTL-16) Implement an interpolator for strings containing expressions

by Ken Finnigan (JIRA)

[ https://jira.jboss.org/browse/SEAMINTL-16?page=com.atlassian.jira.plugin.... ] Ken Finnigan updated SEAMINTL-16: --------------------------------- Component/s: Messages > Implement an interpolator for strings containing expressions > ------------------------------------------------------------ > > Key: SEAMINTL-16 > URL: https://jira.jboss.org/browse/SEAMINTL-16 > Project: Seam i18n > Issue Type: Task > Components: Messages > Reporter: Dan Allen > Fix For: 3.0.0.Beta1 > > > Since Weld Extensions has adopted the EL expression resolver, it's fitting that it also provides an interpolator for strings containing EL expression. > Provide an interpolator that resolves EL expressions and position parameters in strings. This feature was available in Seam 2 [1]. Since it's not provided yet in Seam 3, we see it showing up as a utility in various modules, including the International [2] and REST [3] modules. We should consolidate this to a single, authoritative source. > It should probably be made an interface with implementations that process specific expression languages, such as EL. For instance, one implementation might interpret MVEL. Just an idea. > [1] http://anonsvn.jboss.org/repos/seam/branches/community/Seam_2_2/src/main/... > [2] https://github.com/seam/international/raw/master/impl/src/main/java/org/j... > [3] https://github.com/seam/rest/raw/master/impl/src/main/java/org/jboss/seam... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JBSEAM-4719) Hibernate Search check broken in latest version of Hibernate Search

by Jeff Faath (JIRA)

Hibernate Search check broken in latest version of Hibernate Search ------------------------------------------------------------------- Key: JBSEAM-4719 URL: https://jira.jboss.org/browse/JBSEAM-4719 Project: Seam Issue Type: Bug Components: Search Affects Versions: 2.2.0.GA Reporter: Jeff Faath The check to see if Hibernate Search exists on the class path is broken and yields this error: 13:45:34,796 DEBUG [HibernatePersistenceProvider] no Hibernate Search, sorry :-( java.lang.NoSuchFieldException: VERSION This forum thread has more details: http://www.seamframework.org/Community/OrgjbossseampersistenceHibernateSe... I am seeing this with the 3.2.2.-SNAPSHOT release of Hibernate Search, but I think the 3.2.1.Final release has the same issue. Per the thread, the 3.3.0Beta1 release definitely has the issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
1
0 / 0

[JBoss JIRA] Moved: (SEAMINTL-16) Implement an interpolator for strings containing expressions

by Dan Allen (JIRA)

[ https://jira.jboss.org/browse/SEAMINTL-16?page=com.atlassian.jira.plugin.... ] Dan Allen moved WELDX-185 to SEAMINTL-16: ----------------------------------------- Project: Seam i18n (was: Weld Extensions) Key: SEAMINTL-16 (was: WELDX-185) Issue Type: Task (was: Feature Request) Affects Version/s: (was: 1.0.0.Beta1) Patch Instructions: Provide an interpolator and align it with efforts in other Seam modules. Fix Version/s: 3.0.0.Beta1 (was: TBC) > Implement an interpolator for strings containing expressions > ------------------------------------------------------------ > > Key: SEAMINTL-16 > URL: https://jira.jboss.org/browse/SEAMINTL-16 > Project: Seam i18n > Issue Type: Task > Reporter: Dan Allen > Fix For: 3.0.0.Beta1 > > > Since Weld Extensions has adopted the EL expression resolver, it's fitting that it also provides an interpolator for strings containing EL expression. > Provide an interpolator that resolves EL expressions and position parameters in strings. This feature was available in Seam 2 [1]. Since it's not provided yet in Seam 3, we see it showing up as a utility in various modules, including the International [2] and REST [3] modules. We should consolidate this to a single, authoritative source. > It should probably be made an interface with implementations that process specific expression languages, such as EL. For instance, one implementation might interpret MVEL. Just an idea. > [1] http://anonsvn.jboss.org/repos/seam/branches/community/Seam_2_2/src/main/... > [2] https://github.com/seam/international/raw/master/impl/src/main/java/org/j... > [3] https://github.com/seam/rest/raw/master/impl/src/main/java/org/jboss/seam... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (SEAMREST-2) Support validation of entire resources

by Jozef Hartinger (JIRA)

Support validation of entire resources -------------------------------------- Key: SEAMREST-2 URL: https://jira.jboss.org/browse/SEAMREST-2 Project: Seam RESTEasy Issue Type: Feature Request Components: Bean Validation Affects Versions: Alpha2 Reporter: Jozef Hartinger Provide support for the following use case: @Path("/hello") public class Resource { @QueryParam("name") @Size(min = 5, max = 15) private String name; @GET public String hello() { return "Hello " + name; } } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3897) MultipartRequest Error: 100% CPU (for 2.0.2.GA) or Missing data (for trunk)

by Bryan Brouckaert (JIRA)

MultipartRequest Error: 100% CPU (for 2.0.2.GA) or Missing data (for trunk) --------------------------------------------------------------------------- Key: JBSEAM-3897 URL: https://jira.jboss.org/jira/browse/JBSEAM-3897 Project: Seam Issue Type: Bug Components: Core Affects Versions: 2.0.2.GA, The future Environment: Seam 2.0.2.GA Reporter: Bryan Brouckaert Priority: Critical There is a fundamental error in MultipartRequest that causes 100% CPU usage in a very specific case. I had it for version 2.0.2.GA, but I saw in the code that the issue is still in the trunk. In the trunk version it will not caus 100% CPU, but the rest of the request will be ignored. The errors that cause it -------------------------------- 1) If a multipart header is longer then 2K, the class will at a certain point start reading blocks of 0 bytes. It does this because it only reads the amound of bytes that are still free in the buffer. Because the buffer is only 2 K big and a header must be entirely in the buffer in order to be processed, this can be 0 bytes if the header is bigger then 2 K. The trunk solves this by using a loop counter, while it should test if there is still place in the buffer before reading that amount of bytes. Of course, 2 K headers should not occur, but it should be detected. 2) The code assumes that the CR-LF that devides the data and the headers are in the same block of the buffer as the header itself. If this isn't the case (you must be unlucky for this to happen) the emtpy line isn't treated as the divider between headers and data but as a header itself. Because the empty lines is treated as a header, the data below it is also treated as a header. Because data can easly be more then 2 K, you get quickly into error 1. I had a case where the first 2K of the request is always the same for a specific user. Unfortuantely, the only part that did not fit in the first 2K was the viewstate, which is easly bigger then 2K. Because the boundary has a random number, the size varried slightly and for about 50% of the requests made by a certain user we got the above problem. The only thing the "fix" of the trunk would have done, is throwing an error instaid of using 100% CPU but the user would have been very unhapy. My solution to the problem ------------------------------------ I did not have time to wait for a fix, I do use seam for a very critical healthcare platform, I fixed it myself. 1) Dynamicly growning buffers in case the headers are bigger then 2K. At 128 K I throw an error, no header should be longer then that (probably that is more then frendly enough) 2) Check if a header isn't an empty line, if so threat it as the devider between the header and data. Some closure notes ---------------------------- I included the patched version (2.0.2.GA) that I'm using now. My unlucky user confirmed that it solved the problem, all his files where uploaded without any problem. The loopcount is a good idea, it is always possible that a stream keeps returning 0 bytes even if you request more then that. But I assure you, that was not the problem, the problem was that the code only requested 0 bytes. I have a 1.8 G logfile to prove it, and I will send it to you if you don't beleave me ;-) I had to add some TRACE info in order find the solution. Since nobody in his right mind has trace on by default I left it in. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

3
4
0 / 0

[JBoss JIRA] Created: (SEAMFACES-56) Update Seam Faces to use JBoss Logging

by Lincoln Baxter III (JIRA)

Update Seam Faces to use JBoss Logging -------------------------------------- Key: SEAMFACES-56 URL: https://jira.jboss.org/browse/SEAMFACES-56 Project: Seam Faces Issue Type: Feature Request Components: Build & Distribution Affects Versions: 3.0.0.Alpha3 Reporter: Lincoln Baxter III Fix For: 3.0.0.Beta1 Seam Faces needs to migrate to JBoss Logging, which is the new Seam 3 standard. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
2
0 / 0

[JBoss JIRA] Created: (SEAMFACES-53) The FlashScopedContext unnecessarily adds a fid parameter into the query string when only a single Flashcontext is active.

by Brian Leathem (JIRA)

The FlashScopedContext unnecessarily adds a fid parameter into the query string when only a single Flashcontext is active. -------------------------------------------------------------------------------------------------------------------------- Key: SEAMFACES-53 URL: https://jira.jboss.org/browse/SEAMFACES-53 Project: Seam Faces Issue Type: Patch Affects Versions: 3.0.0.Alpha3 Reporter: Brian Leathem Fix For: 3.0.0.Alpha4 Attachments: 0001-Implemented-a-map-of-FlashContexts-stored-in-the-Ses.patch The FlashScopedContext unnecessarily adds a fid parameter into the query string when only a single Flashcontext is active. This patch implements a map of FlashContexts stored in the Session, and changes the SeamExternalContext to not append a request parameter when there is only a single FlashContext sotred in the Session. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
3
0 / 0

[JBoss JIRA] Created: (SEAMFACES-54) Need a producer for the standard Faces javax.faces.context.Flash object

by Lincoln Baxter III (JIRA)

Need a producer for the standard Faces javax.faces.context.Flash object ----------------------------------------------------------------------- Key: SEAMFACES-54 URL: https://jira.jboss.org/browse/SEAMFACES-54 Project: Seam Faces Issue Type: Feature Request Components: CDI Integration Affects Versions: 3.0.0.Alpha3 Reporter: Lincoln Baxter III Assignee: Lincoln Baxter III Fix For: 3.0.0.Alpha4 Need a producer for the standard JSF flash object, not just the Seam Faces FlashContext (should seam's be renamed to RenderScoped?) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues November 2010