October 2007 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1556) Multiple instances of Seam PhaseListener permitted to be registered in JSF lifecycle

by Neil Griffin (JIRA)

Multiple instances of Seam PhaseListener permitted to be registered in JSF lifecycle ------------------------------------------------------------------------------------ Key: JBSEAM-1556 URL: http://jira.jboss.com/jira/browse/JBSEAM-1556 Project: JBoss Seam Issue Type: Bug Components: JSF Affects Versions: 1.2.1.GA Environment: WinXP / Liferay 4.3.0 / Tomcat 6.0.13 Reporter: Neil Griffin Background: I found this problem when trying to package-up the Seam "Registration" example as a portlet under Liferay Portal. The AbstractSeamPhaseListener class has a nice warning in the constructor, which alerts you in case more than one Seam-related PhaseListener is registered in the JSF lifecycle: private static boolean exists = false; protected AbstractSeamPhaseListener() { if (exists) log.warn("There should only be one Seam phase listener per application"); exists=true; } While this is good and helpful, the code needs to be improved to ENSURE that only one Seam-related PhaseListener is permitted to execute. Case in point: When running in a portlet environment and using MyFaces, JSF PhaseListeners get registered TWICE, due to the way MyFaces initializes itself: 1. MyFaces has a StartupServletContextListener that initializes the JSF framework (the first time). 2. The MyFacesGenericPortlet.initMyFaces() method initializes the JSF framework (a second time). Normally this would not be a big deal, but Seam has a restriction such that only one Seam-related PhaseListener may be active in the JSF Lifecycle. Because of the double-initialization that MyFaces is performing in the portlet scenario, any <phase-listener> elements found in the faces-config.xml file get registered twice! In Seam, this can cause all kinds of runtime problems. There are two ways that I can think of to fix this: 1. Only let the first PhaseListener "win", and prevent any others from executing their phase handler callbacks (even though registered in the JSF lifecycle). 2. Unregister PhaseListeners that don't win. This is hard to do though -- it can't be done in the constructor, because the PhaseListener can't unregister itself at that time, because it hasn't been added to the lifecycle yet. 2. -- 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, 10 months

2
7
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1474) Add examples with use of Facelets source tags

by Mikhail Grushinskiy (JIRA)

Add examples with use of Facelets source tags --------------------------------------------- Key: JBSEAM-1474 URL: http://jira.jboss.com/jira/browse/JBSEAM-1474 Project: JBoss Seam Issue Type: Feature Request Components: Examples Affects Versions: 1.3.0.BETA1, 1.3.0.BETA2, 1.3.0.GA, 1.3.1.GA Reporter: Mikhail Grushinskiy Add examples with use of Facelets source tags. I think Facelets source tags is very useful feature which has to be demonstrated in examples provided with Seam -- 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, 10 months

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1406) Create method to end/destroy other conversations

by Bruno E. Grossi (JIRA)

Create method to end/destroy other conversations ------------------------------------------------ Key: JBSEAM-1406 URL: http://jira.jboss.com/jira/browse/JBSEAM-1406 Project: JBoss Seam Issue Type: Feature Request Components: Core Reporter: Bruno E. Grossi In some situations we need to end/destroy other conversations different from the actual one. Manager has a private method Manager.destroyConversation(String conversationId, ContextAdaptor session) that can do it, but it private and requires a session ContextAdaptor. My suggestion to create a public method on Manager (or some other appropriate class) that receives an id the clean up that conversation. -- 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, 10 months

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1394) Null @Out attributes for stateless bean before/after method invocations

by H K (JIRA)

Null @Out attributes for stateless bean before/after method invocations ----------------------------------------------------------------------- Key: JBSEAM-1394 URL: http://jira.jboss.com/jira/browse/JBSEAM-1394 Project: JBoss Seam Issue Type: Feature Request Components: Core Reporter: H K Priority: Optional Adding the ability to null @Out attributes for stateless session beans before/after method invocations should eliminate the chances of sharing the @Out instance variables when the stateless bean is being reused by the EJB container. Perhaps the tricky part here might be dealing with exceptions thrown by the intercepted methods. A possible solution might be to null the @Out attributes not only after the invocation but also before the invocation. Of course, this should be done only for stateless session bean. -- 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, 10 months

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2178) Differ timed out session from new session

by Sheng Huang (JIRA)

Differ timed out session from new session ----------------------------------------- Key: JBSEAM-2178 URL: http://jira.jboss.com/jira/browse/JBSEAM-2178 Project: JBoss Seam Issue Type: Feature Request Components: Core Affects Versions: 2.0.0.BETA1 Environment: Windows XP SP2 Reporter: Sheng Huang It will be nice to differ session timeout from newly created session. For example, if I bookmark a page requiring login, it is desired that the application redirects me to the login page and the message "Please log in first" is fine. However, if I have been inactive for a while thus my session times out, it is preferred to display a message like "Your session times out. Please login again". I checked SeamListener and LifeCycle classes, but I cannot find a way to link timed out session with the subsequently created new session. Is this possible that Seam can raise an event or set a flag when timeout then link to the new session after user is redirected to the login page again? I greatly appreciate if you can look at the possibility or let me know if there is a workaround. Thank you very much for your help. Best regards, Sheng -- 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, 10 months

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2146) New instance of stateful session bean is created twice in the same session

by Igor Laberov (JIRA)

New instance of stateful session bean is created twice in the same session -------------------------------------------------------------------------- Key: JBSEAM-2146 URL: http://jira.jboss.com/jira/browse/JBSEAM-2146 Project: JBoss Seam Issue Type: Bug Components: EJB3, JSF Affects Versions: 2.0.0.BETA1 Environment: Win XP, JBoss 4.2.1, desktop computer, !! IE 6.0 !! Reporter: Igor Laberov The page consists of dataTable and combo box for data paging. During request, in update model phase, some session bean variable is updated in existing session bean instance. However, during invoke application phase, new instance of stateful session bean is created. No exception were logged and 'destroy' method of existing instance wasn't called. It happens only in IE6. In IE7 and FF2.0 the behavior is OK. Sniffing of HTTP request shows the difference in POST parameters: IE6 - main_form=main_form& main_form%3Adata%3A2%3Adel_=& main_form%3AselectedRemoveIndex=745& main_form%3AdeletePanelOpenedState=& javax.faces.ViewState=_id18 IE7 and FF - main_form=main_form& main_form%3Adata%3A0%3Adel_=& main_form%3AselectedRemoveIndex=589& main_form%3Aj_id97=11& main_form%3AdeletePanelOpenedState=& javax.faces.ViewState=_id9 while, as you can see it differs by one paramer - 'j_id97', which is id of combo box (that wasn't changed by user). -- 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, 10 months

2
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1204) java.lang.StringIndexOutOfBoundsException: String index out of range: -1

by Petr Ferschmann (JIRA)

java.lang.StringIndexOutOfBoundsException: String index out of range: -1 ------------------------------------------------------------------------ Key: JBSEAM-1204 URL: http://jira.jboss.com/jira/browse/JBSEAM-1204 Project: JBoss Seam Issue Type: Bug Components: Framework Affects Versions: 1.2.1.GA Environment: I am using Seam for other serlvets too (SeamFilter). Reporter: Petr Ferschmann Problem is that MockViewHandler expects that there is always . in URL (but in my case it is not). String index out of range: -1 RequestURI=/pes/userAccount/create/ Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(String.java:1762) at java.lang.String.substring(String.java:1735) at org.jboss.seam.mock.MockViewHandler.getActionURL(MockViewHandler.java:41) at org.jboss.seam.core.Manager.redirect(Manager.java:1054) at org.jboss.seam.core.Redirect.execute(Redirect.java:137) at org.jboss.seam.exceptions.DebugPageHandler.handle(DebugPageHandler.java:29) at org.jboss.seam.core.Exceptions.handle(Exceptions.java:79) at org.jboss.seam.web.ExceptionFilter.endWebRequestAfterException(ExceptionFilter.java:91) at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:73) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49) at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:79) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49) at org.jboss.seam.web.SeamFilter.doFilter(SeamFilter.java:84) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391) at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:268) at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:126) at cz.softeu.rewriter.RewriterFilter.doFilter(RewriterFilter.java:173) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:285) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:751) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:500) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475) -- 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, 10 months

3
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-854) Explicit conversation id is lost when using nested conversation

by Yevgen Bushuyev (JIRA)

Explicit conversation id is lost when using nested conversation --------------------------------------------------------------- Key: JBSEAM-854 URL: http://jira.jboss.com/jira/browse/JBSEAM-854 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 1.1.6.GA Environment: Linux localhost 2.6.3-7mdk #1 Wed Mar 17 15:56:42 CET 2004 i686 unknown unknown GNU/Linux Reporter: Yevgen Bushuyev Each click on <s:link id="action" value="Act" action="#{somethingHome.beginAction}"/> @Begin(nested=true, id="action") public String beginAction() { } leads to creation of a new ConversationEntry, which means that explicit id is ignored. -- 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, 10 months

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-672) Allow Query restrictions without value bindings

by Christian Bauer (JIRA)

Allow Query restrictions without value bindings ----------------------------------------------- Key: JBSEAM-672 URL: http://jira.jboss.com/jira/browse/JBSEAM-672 Project: JBoss Seam Issue Type: Bug Components: Framework Affects Versions: 1.1.1.GA Reporter: Christian Bauer In framework/Query.java line 164: if (valueBinding==null) { throw new IllegalArgumentException("no value binding in restriction: " + restriction); } I want to have restrictions without value bindings, e.g. in my extended EntityQuery: public List<String> getRestrictions() { List<String> restrictions = new ArrayList<String>(); restrictions.add("parentNode is null"); return restrictions; } -- 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, 10 months

5
6
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1075) Documentation enhancement for injecting Logger (make clear when static is required)

by Arjan van Bentem (JIRA)

Documentation enhancement for injecting Logger (make clear when static is required) ----------------------------------------------------------------------------------- Key: JBSEAM-1075 URL: http://jira.jboss.com/jira/browse/JBSEAM-1075 Project: JBoss Seam Issue Type: Feature Request Components: Documentation Affects Versions: 1.2.0.GA Environment: All Reporter: Arjan van Bentem Priority: Optional The documentation of @Logger in "3.6 Logging" states at http://fisheye.jboss.com/browse/JBoss/jboss-seam/doc/reference/en/modules... It doesn't matter if you declare the log variable static or not—it will work either way. I think this should be enhanced to read, for example: It doesn't matter if you declare the log variable static or not—it will work either way, except for entity beans which needs the logger to be static. ...maybe followed by an example: @Entity @Name("member") @Table(uniqueConstraints = @UniqueConstraint(columnNames = "membername")) public class Member implements Serializable { @Logger private static Log log; : public void setMemberName(String memberName) { log.info("setting memberName"); this.memberName = memberName; } : } At least, that's what I've found; when not declaring it static it will not get injected or is lost (I'm not sure which), and thus would yield a NullPointerException upon usage. Likewise, "22.2. Annotations for bijection" at http://fisheye.jboss.com/browse/JBoss/jboss-seam/doc/reference/en/modules... now states Specifies that a component field is to be injected with an instance of org.jboss.seam.log.Log. ...but maybe this could be extended to read: Specifies that a component field is to be injected with an instance of org.jboss.seam.log.Log. Remember that for entity beans the actual variable needs to be declared static. Cheers, Arjan. -- 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, 10 months

3
3
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues October 2007