July 2008 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1832) Use of <a:support> tag breaks conversation in Seam-gen (and elsewhere)

by Vincent Latombe (JIRA)

Use of <a:support> tag breaks conversation in Seam-gen (and elsewhere) ---------------------------------------------------------------------- Key: JBSEAM-1832 URL: http://jira.jboss.com/jira/browse/JBSEAM-1832 Project: JBoss Seam Issue Type: Bug Components: JSF Affects Versions: 2.0.0.BETA1 Environment: Jboss 4.2.0.GA Reporter: Vincent Latombe I've seen the problem from BETA1 to HEAD To reproduce the bug, try the following : Create some seam-gen based project and generate-entities. Go to an edit page, fill some data, and click on the submit button, without clicking elsewhere (the focus must be on an edited field just before submit). Instead of validation error, or adding the new data, you should get the "The conversation ended, timed out or was processing another request" message. It seems that the validation triggered by the onblur event messes up with the validation. I have also seen the bug occuring while I was switching from one field to another quite fast (fast enough to have many validation on queue in ajax4jsf). It seems that adding <s:conversationId/> to the a:support solves this part. Here is the snippet I currently use <a:support event="onblur" bypassUpdates="true" reRender="cityCodeDecoration"> <s:conversationId/> </a:support> I tried to upgrade ajax4jsf + richfaces 3.0.1 to richfaces 3.1.0 rc2, but it didn't change anything. -- 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

16 years, 1 month

13
38
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2480) Important META tags missing from HTML generated email

by Terry (JIRA)

Important META tags missing from HTML generated email ----------------------------------------------------- Key: JBSEAM-2480 URL: http://jira.jboss.com/jira/browse/JBSEAM-2480 Project: JBoss Seam Issue Type: Bug Components: Mail Affects Versions: 2.0.0.GA Environment: Windows, Outlook, JBoss 4.2 EAP Reporter: Terry Assigned To: Pete Muir Fix For: 2.0.1.GA When sending seam mail in HTML, the head tag and some important meta tags are misssing. I think it should at least contain this tag: <head> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"/> </head> Clicking links in email sent to MS Outlook doesn't recognise them as URL, it opens windows dialog box asking to find executable to run the links. I think problem is due to missing above meta tag. Also see: http://jira.jboss.org/jira/browse/JBSEAM-2479 -- 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

16 years, 1 month

2
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2479) META Tags added to HTML HEAD in Seam HTML mail get removed

by Terry (JIRA)

META Tags added to HTML HEAD in Seam HTML mail get removed ---------------------------------------------------------- Key: JBSEAM-2479 URL: http://jira.jboss.com/jira/browse/JBSEAM-2479 Project: JBoss Seam Issue Type: Bug Components: Mail Affects Versions: 2.0.0.GA Environment: Windows, Outlook, Reporter: Terry Assigned To: Pete Muir Fix For: 2.0.1.GA the META tags added to HTML Head tag when sending Seam email in HTML get removed from the generated HTML. absence of META tags and not being able to add one causes issues in applications like outlook. <m:message> <m:from name="TISC Online" address="info(a)tisc.edu.au" /> <m:to name="#{subscriptionAdmin.recipient[0]}">#{subscriptionAdmin.recipient[1]}</m:to> <m:subject>#{subscriptionAdmin.subscriptionConfig.massMailSubject}</m:subject> <m:body> <html> <head> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"/> </head> <body> <h:outputText value="#{subscriptionAdmin.massMailMessageInterpolated}" escape="false"/> </body> </html> </m:body> </m:message> come out like: <html> <head> </head> <body> ... body contents ... </body> <html> -- 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

16 years, 1 month

2
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2889) Exception thrown by @Asynchronous method called by ThreadPoolDispatcher causes timer to suspend

by Pete Muir (JIRA)

Exception thrown by @Asynchronous method called by ThreadPoolDispatcher causes timer to suspend ----------------------------------------------------------------------------------------------- Key: JBSEAM-2889 URL: http://jira.jboss.com/jira/browse/JBSEAM-2889 Project: Seam Issue Type: Bug Components: Async Affects Versions: 2.1.0.A1, 2.0.2.CR1 Reporter: Pete Muir Assigned To: Pete Muir Not quite sure if this is ideal behaviour or not (especially if an error is thrown e.g. as part of the transaction commit as there is no way the @Asynchronous method can catch that). -- 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

16 years, 1 month

1
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2607) ThreadPoolDispatcher: exceptions from AsynchronousInvocation.call() are not logged

by Adam Warski (JIRA)

ThreadPoolDispatcher: exceptions from AsynchronousInvocation.call() are not logged ---------------------------------------------------------------------------------- Key: JBSEAM-2607 URL: http://jira.jboss.com/jira/browse/JBSEAM-2607 Project: JBoss Seam Issue Type: Feature Request Components: Async Affects Versions: 2.0.1.GA Reporter: Adam Warski Priority: Minor When using a ThreadPoolDispatcher, if an asynchronous method is called, and the AsynchronousInvocation.call() method fails (for example because of an injected bean, which isn't yet created and doesn't have @AutoCreate), the exception is not logged anywhere, making it quite hard to debug. -- 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

16 years, 1 month

3
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2594) Container issue - improved exception handling in Seam

by Shane Bryzak (JIRA)

Container issue - improved exception handling in Seam ----------------------------------------------------- Key: JBSEAM-2594 URL: http://jira.jboss.com/jira/browse/JBSEAM-2594 Project: JBoss Seam Issue Type: Task Components: Core Reporter: Shane Bryzak Fix For: 2.1.0.GA Christian brought up a list of improvements that we can make to exception handling in Seam. This container issue will be used to group these items. -- 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

16 years, 1 month

3
7
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2714) Detect swallowed exceptions

by Matt Drees (JIRA)

Detect swallowed exceptions --------------------------- Key: JBSEAM-2714 URL: http://jira.jboss.com/jira/browse/JBSEAM-2714 Project: JBoss Seam Issue Type: Feature Request Components: Exception Handling Reporter: Matt Drees Priority: Minor Sometimes exceptions are swallowed by frameworks out of Seam's control (Facelets debug component, for example does this; see http://www.seamframework.org/Community/FetchingDataLazilyOnANewPage#comme...). However, a rollback may be triggered by the throwing of such an exception, due to the RollbackInterceptor. Because the exception is swallowed, the developer has no immediate indication that an error has occurred, yet the persistence context will be cleared. It's a very frustrating experience, trust me. Could Seam use an interceptor to note when a (non-application) exception is thrown by a Seam component, and if it is not eventually handled by Seam's exception handler at the end of the request, trigger a warning & a stacktrace in the log? -- 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

16 years, 1 month

2
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2597) Exception handling - JSF swallows exceptions in certain phases

by Shane Bryzak (JIRA)

Exception handling - JSF swallows exceptions in certain phases -------------------------------------------------------------- Key: JBSEAM-2597 URL: http://jira.jboss.com/jira/browse/JBSEAM-2597 Project: JBoss Seam Issue Type: Feature Request Components: Core Reporter: Shane Bryzak Fix For: 2.1.0.GA I can't reproduce this right now but I'm sure I spent several hours with a debugger only to find out that I had a typo in a value binding and that the exception was completely swallowed during an early JSF phase (UPDATE MODEL probably). There was nothing in the log, the action phase just never executed. This is a major issue (obviously) for another subtle reason: Beginners have trouble understanding the JSF lifecycle and processing phases - I know I did. You begin to hate JSf when you don't understand why a certain phase does not execute. I'd start reproducing it by generating an NPE in a value binding setter, that should do it. -- 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

16 years, 1 month

6
12
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1183) Allow custom ExceptionHandler implementations to be inserted

by Mike Quilleash (JIRA)

Allow custom ExceptionHandler implementations to be inserted ------------------------------------------------------------ Key: JBSEAM-1183 URL: http://jira.jboss.com/jira/browse/JBSEAM-1183 Project: JBoss Seam Issue Type: Feature Request Components: Core Affects Versions: 1.1.6.GA Environment: Any Reporter: Mike Quilleash Currently you can only configure a small subset of actions to occur on an exception (redirect, http-error etc). Enhancing the exception configuration xml to allow pluggable ExceptionHandler implementations would make this a lot more flexible. e.g. pages.xml <pages>  <exception class="javax.persistence.EntityNotFoundException"> <http-error error-code="404"/> </exception>  <exception handlerClass="com.xxx.seam.CustomExceptionHandler"/> </pages> These should probably have higher precedence than standard configure-by-exception-class handlers. -- 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

16 years, 1 month

2
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2600) Exception handling - Fix the exception handling in Seam

by Shane Bryzak (JIRA)

Exception handling - Fix the exception handling in Seam ------------------------------------------------------- Key: JBSEAM-2600 URL: http://jira.jboss.com/jira/browse/JBSEAM-2600 Project: JBoss Seam Issue Type: Feature Request Components: Core Reporter: Shane Bryzak Fix For: 2.1.0.GA Currently we have at least one serious race condition in our pages.xml exception handling, related to redirect/message passing. I can reproduce (JIRA case is open) lost messages on exception redirect. Also, clean up the #{exception} and #{handledException} stuff - which might fix the issue as a side effect. I want one exception instance I can access in EL, not two. I want to be able to call getRootCause() on it to unwrap the root exception. Of course the root cause is the one I specify in pages.xml as the one that is handled, but the #{exception} should always be the wrapper. In any case, a clear and reliable (working in all situations) strategy needs to apply here. -- 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

16 years, 1 month

4
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues July 2008