[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3413) HotDeployementStrategy rev 8925 causes Exceptions with ICEfaces server-push for Seam trunk only
by judy guglielmin (JIRA)
HotDeployementStrategy rev 8925 causes Exceptions with ICEfaces server-push for Seam trunk only
-----------------------------------------------------------------------------------------------
Key: JBSEAM-3413
URL: https://jira.jboss.org/jira/browse/JBSEAM-3413
Project: Seam
Issue Type: Bug
Components: Hot Deploy
Affects Versions: 2.1.0.CR1
Environment: ICEfaces (any version 1.6 and onwards), Seam trunk
Reporter: judy guglielmin
Any async push operation will cause the following exception to occur. reverting to 8923 resolves the problem and async push works again.
12:19:36,554 WARN [ExceptionFilter] handling uncaught exception
java.lang.NullPointerException
at org.jboss.seam.deployment.HotDeploymentStrategy.getScannedComponentClasses(HotDeploymentStrategy.java:162)
at org.jboss.seam.init.Initialization.installHotDeployableComponents(Initialization.java:698)
at org.jboss.seam.init.Initialization.redeploy(Initialization.java:685)
at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:50)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:63)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
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.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
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:262)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
at java.lang.Thread.run(Unknown Source)
--
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
15 years, 7 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3354) ELException catched in lifecycle phase RENDER_RESPONSE about: the raised exception does not have a readable property
by Julien Kronegg (JIRA)
ELException catched in lifecycle phase RENDER_RESPONSE about: the raised exception does not have a readable property
--------------------------------------------------------------------------------------------------------------------
Key: JBSEAM-3354
URL: https://jira.jboss.org/jira/browse/JBSEAM-3354
Project: Seam
Issue Type: Bug
Components: EL
Affects Versions: 2.0.0.GA
Environment: Jboss 4.2.1.GA, JDK 1.5.0_11
Reporter: Julien Kronegg
When an Exception with a specific getter pattern is raised in the ".page.xml" page, the Seam debug page is not displayed, but instead gives a 404 error and the log contains the follow trace:
22:17:09,328 WARN [lifecycle] phase(RENDER_RESPONSE 6,com.sun.faces.context.FacesContextImpl@2f1e34) threw exception: javax.el.ELException: /file:/C:/Workspace/jboss-4.2.1.GA/server/default/deploy/networking20.ear/networking20.war/WEB-INF/lib/jboss-seam-debug.jar!/META-INF/debug.xhtml: The class 'org.hibernate.exception.NestableRuntimeException' does not have a readable property 'message'. /file:/C:/Workspace/jboss-4.2.1.GA/server/default/deploy/networking20.ear/networking20.war/WEB-INF/lib/jboss-seam-debug.jar!/META-INF/debug.xhtml: The class 'org.hibernate.exception.NestableRuntimeException' does not have a readable property 'message'.
com.sun.facelets.compiler.TextInstruction.write(TextInstruction.java:48)
com.sun.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:39)
com.sun.facelets.compiler.UILeaf.encodeAll(UILeaf.java:149)
com.sun.facelets.component.RepeatRenderer.encodeChildren(RepeatRenderer.java:50)
com.sun.facelets.component.UIRepeat.process(UIRepeat.java:357)
com.sun.facelets.component.UIRepeat.encodeChildren(UIRepeat.java:617)
com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:244)
com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:249)
com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:249)
org.jboss.seam.debug.jsf.SeamDebugPhaseListener.beforePhase(SeamDebugPhaseListener.java:51)
com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:222)
com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:144)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:245)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:68)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73)
org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:44)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:154)
org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:260)
org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:366)
org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:493)
org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:60)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
java.lang.Thread.run(Thread.java:595)
This can be reproduced with the following test case:
------------------------------------------------ class A --------------------------------------
import javax.ejb.Local;
@Local
public interface A {
public String getMessage();
public String getMessage(int num);
public String getMessage2();
public String getMessage3();
public void destroy();
}
-------------------------------------------------------------------------------------------------
--------------------------------- class AAction (extends A) ----------------------------
import javax.ejb.Remove;
import javax.ejb.Stateful;
import org.hibernate.exception.NestableRuntimeException;
import org.jboss.seam.annotations.Destroy;
import org.jboss.seam.annotations.Name;
@Stateful
@Name("a")
public class AAction implements A {
public String getMessage1() { return "foobar"; }
public String getMessage1(int i) { return ""+i; }
public String getMessage2() { throw new NestableRuntimeException("xxx"); }
public String getMessage3() { throw new IndexOutOfBoundsException("xxx"); }
@Destroy
@Remove
public void destroy() {}
}
--------------------------------------------------------------------------------------------
--------------------------------------- a.xhtml ------------------------------------------
<!DOCTYPE composition PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<ui:composition xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets">
</ui:composition>
-------------------------------------------------------------------------------------------
---------------------------------------a.page.xml -------------------------------------
<page>
<action execute="#{a.getMessage2}"/>
</page>
--------------------------------------------------------------------------------------------
Depending on the "execute" field in the "a.page.xml" page, the result is not the same:
- "#{a.getMessage1}" => the A.getMessage1() method is executed normally
- "#{a.getMessage2}" => the stacktrace above is displayed in the log files and the page is breaked (error 404?)
- "#{a.getMessage3}" => the Seam debug page is displayed with a description of the exception (here, an IndexOutOfBoundsException was chosen)
The excepted behavior would be that all exceptions lead to displaying the Seam debug page.
The short story about why the "a.getMessage2" test case displays the stacktrace is the following: to generate the Seam debug page, exception message must be obtained. The raised exception (NestableRuntimeException) has a getter getMessage() and another getMessage(int), and javax.el.BeanELResolver (used to execute the EL) which uses java.beans.Introspector (the builder used to compute the list of properties) cannot recognize the getMessage() getter because the Introspector merges getMessage() and getMessage(int) into getMessage(int). Consequently, the exception appears to have no getMessage() method (from the BeanELResolver viewpoint), which causes the Seam debug page to break.
The long story is here: http://seamframework.org/Community/AnybodyHitThisBugInSeam#comment35710
IMHO, this is a problem in the javax.el.BeanELResolver (from el-api.jar), which uses the very generic and complicated java.beans.Introspector class for a very simple use of obtaining the getters and setters.
I know that its a JDK/javax.el issue, but Pete Muir suggested me to file a JIRA issue, so there it is. The difficulty behind that issue is that the BeanELResolver and Introspector are used for multiple purposes and that correcting them could imply large side effects, so it is probably why the issue has not yet been corrected in the BeanELResolver.
--
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
15 years, 7 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3484) Nested in Nested Conversation: Conversation vacuum?
by Francisco Jose Peredo Noguez (JIRA)
Nested in Nested Conversation: Conversation vacuum?
---------------------------------------------------
Key: JBSEAM-3484
URL: https://jira.jboss.org/jira/browse/JBSEAM-3484
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.0.2.SP1
Environment: Jdk 1.6u6, Tomcat 6.0.18
Reporter: Francisco Jose Peredo Noguez
If I:
1. Begin long-running conversation
2. Begin first nested conversation
3. Begin second nested conversation
4. End second nested conversation
5. Try to begin third nested conversation:
Exception: beginNested() called with no long-running conversation
Suggested Workaround:
<begin-conversation nested="true" if="#{conversation.longRunning}"/>
The problem, I think, was caused because I end the first nested conversation with <s:button propagation="end"/> but that redirects me to page that has <begin-conversation nested="true"/> on its page.xml, and without the <begin-conversation nested="true" if="#{conversation.longRunning}"/> it tries to start another nested conversation immediately (and I do not want to do that, I want to fall back to the first nested conversation, and then, if and only if a particular button is clicked create the third nested conversation).
This workaround works, but it looks somewhat anti-intuitive (IMHO the <begin-conversation nested="true" if="#{conversation.longRunning}"/> should be implicit... don't you agree?)
--
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
15 years, 7 months
[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-164) Kill all conversations
by Stuart Douglas (JIRA)
[ https://jira.jboss.org/jira/browse/JBSEAM-164?page=com.atlassian.jira.plu... ]
Stuart Douglas commented on JBSEAM-164:
---------------------------------------
The patches are a fair bit different in what they accomplish. Mine kills all conversations, including the current one, and creates a new temporary conversation context, which can be promoted to long running if so desired.
I do not think it is a good idea to send out conversationTimeout events when using killingAllOthers, as this is not a timeout event. As the event is explicitly triggered by the developer, I would just let them explicitly send out any events that they may want, or else send out some kind of conversationKilled event.
Stuart
> Kill all conversations
> ----------------------
>
> Key: JBSEAM-164
> URL: https://jira.jboss.org/jira/browse/JBSEAM-164
> Project: Seam
> Issue Type: Feature Request
> Components: Core
> Reporter: Gavin King
> Fix For: The future
>
> Attachments: kill-all-other-conversations.diff, seam-endall-patch-v1.diff
>
>
> Users want an operation to kill all conversations, and they want that to happen in the same action as beginning a new conversation.
--
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
15 years, 7 months
[jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-164) Kill all conversations
by Srinivasan Raguraman (JIRA)
[ https://jira.jboss.org/jira/browse/JBSEAM-164?page=com.atlassian.jira.plu... ]
Srinivasan Raguraman updated JBSEAM-164:
----------------------------------------
Attachment: kill-all-other-conversations.diff
Surprisingly, I have also worked on the same issue over the last two days. I have worked on this mostly based on the discussion on these thread:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=78766&postdays=0...
The other patch that posted just before looks good. I am not apposing it here, but just providing an alternate implementation for the seam committers to chose from. Or this may be additional way to achieve the same. Also this implementation differs from the last one, so I thought it will be good to submit it.
It takes the same approach as like time out of conversation, so the killed conversation will get notified with time-out events. This also takes care of the cases like, calling Conversation.killAllOthers() when there is a nested conversation is progress, or when called from a new or promoted conversation within @Begin. Added couple of test cases for it, and tested it with nested booking sample (changes made to nested booking is not attached here, as it will change the semantics of the original example)
Thanks
> Kill all conversations
> ----------------------
>
> Key: JBSEAM-164
> URL: https://jira.jboss.org/jira/browse/JBSEAM-164
> Project: Seam
> Issue Type: Feature Request
> Components: Core
> Reporter: Gavin King
> Fix For: The future
>
> Attachments: kill-all-other-conversations.diff, seam-endall-patch-v1.diff
>
>
> Users want an operation to kill all conversations, and they want that to happen in the same action as beginning a new conversation.
--
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
15 years, 7 months