December 2009 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3828) Seam GWT servlet should no longer use deprecated SerializableException

by Jan Vorwerk (JIRA)

Seam GWT servlet should no longer use deprecated SerializableException ---------------------------------------------------------------------- Key: JBSEAM-3828 URL: https://jira.jboss.org/jira/browse/JBSEAM-3828 Project: Seam Issue Type: Patch Components: GWT Reporter: Jan Vorwerk Priority: Optional Since GWT 1.5 the usage of SerializableException has been deprecated, while Seam Remoting servlet for GWT compells its usage as a base class for serializable exceptions to be marshalled from the server to the client. See code in: org.jboss.seam.remoting.gwt.GWTService#processCall(String) // Serialize the exception back to the client if it's a declared // exception if (cause instanceof SerializableException) -- 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

14 years

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3247) Seam without hibernate: Please make org.jboss.seam.core.Validators independent from Hibernate

by Francisco Jose Peredo Noguez (JIRA)

Seam without hibernate: Please make org.jboss.seam.core.Validators independent from Hibernate ---------------------------------------------------------------------------------------------- Key: JBSEAM-3247 URL: https://jira.jboss.org/jira/browse/JBSEAM-3247 Project: Seam Issue Type: Feature Request Affects Versions: 2.0.2.GA Reporter: Francisco Jose Peredo Noguez I think org.jboss.seam.core.Validators should implement and interface, so that it could be possible to replace it with one that doesn't use org.hibernate.validator.ClassValidator I guess with that we could say that Seam can be used in a 100% free of Hibernate way I really like Hibernate, but sometimes, for really simple projects, or for projects full of interactions with stored procedures , it might be overkill or innapropiate, so it would be nice to be able to use Seam without having any Hibernate dependencies. -- 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

14 years

5
9
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3706) JEE5 Booking Example fails on Glassfish

by Dmitry Shultz (JIRA)

JEE5 Booking Example fails on Glassfish --------------------------------------- Key: JBSEAM-3706 URL: https://jira.jboss.org/jira/browse/JBSEAM-3706 Project: Seam Issue Type: Bug Components: Examples Affects Versions: 2.1.0.SP1 Environment: Leopard OS X Server, latest Glassfish installation (9.1_02 (build b04-fcs)), Seam version from todays trunk. Reporter: Dmitry Shultz Priority: Blocker 1. Buld Seam, build JEE5 Booking Example, deploy it on Glassfish using Web Interface. 2. Create new User, do login 3. Go to the Search Hotels page, put letter 'd' in the input field, press Find Hotels 4. Click on 'View Hotel' Link for top hotel, you should see the seam.debug page. -- 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

14 years, 1 month

2
4
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4443) Clustering Seam Application + Drools Serialization exception

by Karl Max (JIRA)

Clustering Seam Application + Drools Serialization exception ------------------------------------------------------------ Key: JBSEAM-4443 URL: https://jira.jboss.org/jira/browse/JBSEAM-4443 Project: Seam Issue Type: Bug Components: Drools Affects Versions: 2.2.0.GA Environment: Windows Vista, Seam 2.2.0.GA, JBoss 5.1.0.GA, Eclipse 3.5, JBoss Tools latest,Java 6 (latest) Reporter: Karl Max http://seamframework.org/Community/ClusteringSeamApplicationDroolsSeriali... I try eliminite this problem by using of drools rule agent+Drools Guvnor, but It was not scuccess I get the same exception. -- 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

14 years, 1 month

2
7
0 / 0

[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

14 years, 1 month

5
5
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

14 years, 1 month

3
4
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1839) Use HSQL to store Quartz jobs when deployed on JBoss AS

by Michael Yuan (JIRA)

Use HSQL to store Quartz jobs when deployed on JBoss AS ------------------------------------------------------- Key: JBSEAM-1839 URL: http://jira.jboss.com/jira/browse/JBSEAM-1839 Project: JBoss Seam Issue Type: Feature Request Reporter: Michael Yuan Assigned To: Michael Yuan Fix For: 2.0.0.GA Right now, Quartz jobs are stored "in-memory" and hence cannot be auto-started when the server reboots. The user can use persistence job stores by using a custom quartz property file. However, in JBoss AS, we should store jobs in the HSQL DB by default: * In the dispatcher component, we can have a "jboss=true" attribute * If this attribute is true, the QuartzDispatcher will setup Quartz tables for this particular app in the HSQL at startup, and then use the HSQL DB as persistent job store. This way, when the application deploys again, all the jobs for this application will be auto-started again. -- 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

14 years, 2 months

4
10
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2353) Quartz asynchronous events shceduled to fire while the server is shutdown fire before seam is initialized when the server is started.

by Yona Appletree (JIRA)

Quartz asynchronous events shceduled to fire while the server is shutdown fire before seam is initialized when the server is started. ------------------------------------------------------------------------------------------------------------------------------------- Key: JBSEAM-2353 URL: http://jira.jboss.com/jira/browse/JBSEAM-2353 Project: JBoss Seam Issue Type: Bug Components: Async Environment: Jboss 4.2.2.GA; Quartz scheduler. Reporter: Yona Appletree Fix For: 2.0.0.GA When the QuartzDispatcher is created, it causes any event scheduled to fire in the past to fire immediately (in a separate thread). Since QuartzDispatcher is marked @Startup, it may start before other components. If the handler of an event fired on startup relies on another component marked @Startup, it may not exist by the time the event is fired, and will therefore cause an error. I have a found a partial workaround for this issue, documented in the referenced forum thread. -- 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

14 years, 2 months

3
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1869) Example of Control Set for Quartz SEAM Interation

by Piergiuseppe Spinelli (JIRA)

Example of Control Set for Quartz SEAM Interation ------------------------------------------------- Key: JBSEAM-1869 URL: http://jira.jboss.com/jira/browse/JBSEAM-1869 Project: JBoss Seam Issue Type: Task Components: Examples Affects Versions: 2.0.0.BETA1 Environment: Any OS. JBoss2_0B project. Reporter: Piergiuseppe Spinelli Priority: Optional The attached sample is an attept to create a control interface to SEAM asynchronous method using Quartz as scheduling engine. I was asked to do this in the related forum thread: I am not sure it is near to the desired functionalities, but it could be used as a starting point (or possibly as a negative sample). The sample is very raw and I have used SEAM too short to be sure I did not make to stupid things, but if the idea is useful, I am sure other people will improve it. Notes: - The sample use quartz integrated in SEAM as it currently is: a support to asynchronous method - Quartz is used with its in-memory db, the persistent status is kept by the application usign custom Entities - Since I am a newby in SEAM, I preferred to make some custom classes for supporting CRUD operations since it was difficult to me to get the SEAM framework to do more that the simple things showed in the samples TODO: - it could be better to use some well known components library for the interface instead that my custom controls (i.e Trinidad) - the entities I made to keep the application status use a table schema very similar to the quartz schema: it could be a good idea in a future to be able to use some entity model over the quartz schema - it would be usefull to add the feature to upload the classes to be scheduler directly by the web interface, mayby using a classloader chain for supporting hot versioning. -- 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

14 years, 2 months

4
7
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-975) constraint by inclusion on remote calls object fields

by Zalder R (JIRA)

constraint by inclusion on remote calls object fields ----------------------------------------------------- Key: JBSEAM-975 URL: http://jira.jboss.com/jira/browse/JBSEAM-975 Project: JBoss Seam Issue Type: Feature Request Components: Remoting Reporter: Zalder R Assigned To: Shane Bryzak Priority: Optional I think it could be nice to define the fields of the objects returned in a "WebRemote call" with an "include" parameter (instead of the current exclude parameter). For instance : now you have : @WebRemote(exclude = {"secret"}) it would be nice to be able to define : @WebRemote(include = {"fieldIreallyNeed1", "fieldIreallyNeed2"}) The reasons for this are many : - security : if the object structure varies over time, you would not want the new fields to be available on the client side by default - in some cases it's a lot more lightweight (both in the code and in the volume of data sent) to define a minimum set of fields you want instead of the fields you don't want -- 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

14 years, 2 months

5
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues December 2009