[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1849) Exception handling broken
by Christian Bauer (JIRA)
Exception handling broken
-------------------------
Key: JBSEAM-1849
URL: http://jira.jboss.com/jira/browse/JBSEAM-1849
Project: JBoss Seam
Issue Type: Bug
Components: Core
Reporter: Christian Bauer
Looks like some work on the namespaces confused the exception handling:
<exception>
<redirect view-id="/message.xhtml">
<message severity="ERROR">Exception: #{org.jboss.seam.handledException.message}</message>
</redirect>
</exception>
or
<exception>
<redirect view-id="/message.xhtml">
<message severity="ERROR">Exception: #{org.jboss.seam.exception.message}</message>
</redirect>
</exception>
or (on message.xhtml):
Exception: #{org.jboss.seam.handledException}
produce:
(http-127.0.0.1-8080-2hread) 07:29:27,035 DEBUG [Exceptions] reading exception mappings from /WEB-INF/pages.xml
(http-127.0.0.1-8080-2hread) 07:29:27,039 DEBUG [Navigator] redirecting to: /message.xhtml
(http-127.0.0.1-8080-2hread) 07:29:27,041 DEBUG [FacesManager] redirecting to: /wiki/message.seam?cid=7
(http-127.0.0.1-8080-2hread) 07:29:27,043 ERROR [CachedConnectionValve] Application error: Faces Servlet did not complete its transaction
(http-127.0.0.1-8080-1hread) 07:29:27,046 TRACE [SeamPhaseListener] before phase: RESTORE_VIEW 1
(http-127.0.0.1-8080-1hread) 07:29:27,046 DEBUG [FacesLifecycle] >>> Begin JSF request
(http-127.0.0.1-8080-1hread) 07:29:27,047 DEBUG [SeamPhaseListener] beginning transaction prior to phase: RESTORE_VIEW 1
(http-127.0.0.1-8080-1hread) 07:29:27,047 DEBUG [UTTransaction] beginning JTA transaction
(http-127.0.0.1-8080-1hread) 07:29:27,048 TRACE [SeamPhaseListener] after phase: RESTORE_VIEW 1
(http-127.0.0.1-8080-1hread) 07:29:27,048 DEBUG [ConversationPropagation] Found conversation id in request parameter: 7
(http-127.0.0.1-8080-1hread) 07:29:29,048 DEBUG [Manager] No stored conversation, or concurrent call to the stored conversation
(http-127.0.0.1-8080-1hread) 07:29:29,049 DEBUG [SeamPhaseListener] committing transaction after phase: RESTORE_VIEW 1
(http-127.0.0.1-8080-1hread) 07:29:29,049 DEBUG [UTTransaction] committing JTA transaction
(http-127.0.0.1-8080-1hread) 07:29:29,050 TRACE [SeamPhaseListener] before phase: RENDER_RESPONSE 6
(http-127.0.0.1-8080-1hread) 07:29:29,050 DEBUG [SeamPhaseListener] beginning transaction prior to phase: RENDER_RESPONSE 6
(http-127.0.0.1-8080-1hread) 07:29:29,050 DEBUG [UTTransaction] beginning JTA transaction
(http-127.0.0.1-8080-1hread) 07:29:29,066 ERROR [STDERR] Aug 23, 2007 7:29:29 AM com.sun.facelets.FaceletViewHandler handleRenderException
SEVERE: Error Rendering View[/message.xhtml]
javax.el.ELException: /message.xhtml: Property 'handledException' not found on type org.jboss.seam.Namespace
at com.sun.facelets.compiler.TextInstruction.write(TextInstruction.java:48)
at com.sun.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:39)
at com.sun.facelets.compiler.UILeaf.encodeAll(UILeaf.java:149)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:892)
at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:577)
at org.ajax4jsf.framework.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108)
at org.ajax4jsf.framework.ajax.AjaxViewHandler.renderView(AjaxViewHandler.java:233)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:106)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:144)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:245)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:82)
at org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:164)
at org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:141)
at org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:90)
at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:395)
at org.jboss.seam.wiki.core.ui.WikiUrlRewriteFilter.doFilter(WikiUrlRewriteFilter.java:45)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:68)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:72)
at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:68)
at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:68)
at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:44)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:68)
at org.ajax4jsf.framework.ajax.xmlfilter.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:127)
at org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter.doFilter(BaseFilter.java:277)
at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:60)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:68)
at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:68)
at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:149)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
--
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, 5 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1206) improve i18n in seam-gen
by Pierre Raoul (JIRA)
improve i18n in seam-gen
------------------------
Key: JBSEAM-1206
URL: http://jira.jboss.com/jira/browse/JBSEAM-1206
Project: JBoss Seam
Issue Type: Feature Request
Components: Tools
Affects Versions: 1.2.1.GA
Reporter: Pierre Raoul
It would be great that seam-gen will generate crud pages and classes for an existing Entity class:
- with all the literals replaced with #{messages['key']}
- and i18n default messages generated
Herewith files of a draft version.
I used the jpaconfiguration propositions from JBSEAM-843.
It works under Eclipse: the target "updatecrud" in the project build.xml can be run from Eclipse.
Nota: to translated Enum type, test of this type had to be added. I did it through file inclusion. So it can be used with any other project specific types, e.g. in the attached zip with joda-time type.
--
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, 5 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2519) SeamTest class does not support dependent testing
by Olivier Thierry (JIRA)
SeamTest class does not support dependent testing
-------------------------------------------------
Key: JBSEAM-2519
URL: http://jira.jboss.com/jira/browse/JBSEAM-2519
Project: JBoss Seam
Issue Type: Bug
Components: Test Harness
Affects Versions: 2.0.1.CR1, 2.0.0.GA
Environment: Seam 2.0.0.GA + TestNG 5.1 + Maven Surefire plugin
Reporter: Olivier Thierry
When you use dependent testing in a test class extending SeamTest, either with dependsOnGroups or dependsOnMethods, the test crash on begin phase with the following stack trace :
begin(fr.myCompany.test.ServiceOrganisationTest) Time elapsed: 0.126 sec <<< FAILURE!
java.lang.IllegalStateException: Attempted to invoke a Seam component outside the an initialized application
at org.jboss.seam.contexts.Lifecycle.getApplication(Lifecycle.java:36)
at org.jboss.seam.contexts.Lifecycle.beginSession(Lifecycle.java:169)
at org.jboss.seam.contexts.ServletLifecycle.beginSession(ServletLifecycle.java:124)
at org.jboss.seam.mock.BaseSeamTest.begin(BaseSeamTest.java:920)
at org.jboss.seam.mock.SeamTest.begin(SeamTest.java:28)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:552)
at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:322)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:156)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:365)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:785)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:114)
at org.testng.TestRunner.privateRun(TestRunner.java:693)
at org.testng.TestRunner.run(TestRunner.java:574)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:241)
at org.testng.SuiteRunner.run(SuiteRunner.java:145)
at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:901)
at org.testng.TestNG.runSuitesLocally(TestNG.java:863)
at org.apache.maven.surefire.testng.TestNGExecutor.executeTestNG(TestNGExecutor.java:69)
at org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:78)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
--
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, 5 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2346) s:selectItems - noSelectionLabel is not hidden after first selection of a value
by Wolfgang Schwendt (JIRA)
s:selectItems - noSelectionLabel is not hidden after first selection of a value
-------------------------------------------------------------------------------
Key: JBSEAM-2346
URL: http://jira.jboss.com/jira/browse/JBSEAM-2346
Project: JBoss Seam
Issue Type: Bug
Environment: CVS-based Seam 2.0.1
Reporter: Wolfgang Schwendt
Priority: Minor
<s:selectItems> offers that the user can specify an (optional) "noSelectionLabel" to be placed at the top of the selection list. It further provides a hideNoSelectionLabel option -- if this property is true, the noSelectionLabel will be hidden when a value is selected.
And exactly the latter functionality has a bug, but only as far as the user's FIRST selection is concerned. When the users makes his _first_ selection and submits the form, then the noSelectionLabel is still displayed when the page is redisplayed by the server, no matter whether or not hideNoSelection was set to "true". However, when the users makes additional requests, the hideNoSelectionLabel functionality works correctly.
Reason for the bug: caching behavior of org.jboss.seam.ui.component.UISelectItems.getValue()
Too understand why there is a bug, consider the following scenario:
A page with <h:selectOneMenu> and <s:selectItems var="myVar" label="#{myVar.name}" value="#{resultList}" noSelectionLabel="* Your choice please *" hideNoSelectionLabel="true"/> as its child component.
When the user makes a selection and submits the form, the UISelectOne components checks during the "Process validations" JSF phase whether the submitted input value matches one of the available options (SelectItems). Consequently, the UISelectOne component calls the getValue() method of its org.jboss.seam.ui.component.UISelectItems child component in order to retrieve a list of SelectItem s. Then, if if validation was successful because a matching value was found, the user's selection is either written to the model (during JSF Update model phase) or if we don't make it to the Update model phase, because some other component had a validation error, the user's selection is stored in the value property of the UISelectOne component.
When we finally reach the "Render response" phase and the same page should be redisplayed, the UISelectOne component gets rendered again. In order to render the selection list items, org.jboss.seam.ui.component.UISelectItems.getValue() gets called another time.
But now it doesn't re-calculate its list of SelectItems. Take a look at the code:
org.jboss.seam.ui.component.UISelectItems.getValue()
@Override
public Object getValue()
{
if (value == null || originalValue == null || !originalValue.equals(super.getValue()))
{ ...
}
return value;
}
Note that "value" is not null, because during "Process validations" org.jboss.seam.ui.component.UISelectItems.getValue() was already called which lead to value being set. Therefore, getValue() returns the OLD cached list of SelectItem s, which was calculated during Process Validations and therefore still includes the noSelectionLabel! And therefore getValue() doesn't take into account that the user made a selection and that the noSelectionLabel should now be hidden.
--
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, 5 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1814) DataModel wrapped data is set to null by ManagedEntityIdentityInterceptor
by Matt Drees (JIRA)
DataModel wrapped data is set to null by ManagedEntityIdentityInterceptor
-------------------------------------------------------------------------
Key: JBSEAM-1814
URL: http://jira.jboss.com/jira/browse/JBSEAM-1814
Project: JBoss Seam
Issue Type: Bug
Affects Versions: 2.0.0.BETA1
Environment: seam cvs (20070816.1709)
Reporter: Matt Drees
Priority: Minor
The following test fails:
@Name("dataModelComponent")
@Scope(ScopeType.CONVERSATION)
public class DataModelComponent extends EntityQuery {
@Override
public String getEjbql() {
return "from java.lang.Object o";
}
}
public class DataModelComponentTest extends SeamTest{
@Test
public void test() throws Exception {
new FacesRequest() {
@Override
protected void renderResponse() throws Exception {
DataModel model = (DataModel) getValue("#{dataModelComponent.dataModel}");
assert model.getWrappedData() != null;
}
}.run();
}
}
Because the component is conversation-scoped, a ManagedEntityIdentityInterceptor is attached, which nulls the wrapped List after getDataModel() is called.
In the referenced forum, Gavin indicated he hadn't decided whether this should be expected behavior or not, and asked for a jira issue.
If it is expected behavior (I hope not), I think either EntityQuery should not have a getDataModel() attribute, or it should be documented and/or programmatically enforced that EntityQuerys should not be conversation-scoped.
--
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, 6 months