September 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Closed: (JBSEAM-279) Component lifetimes not guaranteed for SFSB backed components.

by Gavin King (JIRA)

[ http://jira.jboss.com/jira/browse/JBSEAM-279?page=all ] Gavin King closed JBSEAM-279. ----------------------------- Resolution: Won't Fix This is not a bug in Seam, it is merely an inconvenient set of defaults in EJB3 and Tomcat in JBoss AS. Please take this discussion elsewhere, since this issue report is not useful here. > Component lifetimes not guaranteed for SFSB backed components. > -------------------------------------------------------------- > > Key: JBSEAM-279 > URL: http://jira.jboss.com/jira/browse/JBSEAM-279 > Project: JBoss Seam > Issue Type: Bug > Components: Core > Affects Versions: 1.0.1 > Reporter: ryan dewell > > Seam does not guarantee component lifecycles for SFSB backed components. > The container controls when SFSB's are removed / timed out. When Seam accesses an SFSB that has been removed by the container, it results in an EJBNoSuchObjectException. > The JBoss specific workaround for Session scoped components is to use the @CacheConfig annotation, setting the idle timeout to match the HttpSession timeout. Similar changes would have to be made to any Conversation scoped component that uses a timeout greater than the default SFSB timeout of 5 minutes (which just happens to be the default timeout for Seam conversations). > There is no workaround for Application scoped components. Once removed by the container, EJBNoSuchObjectException's will continue to be thrown as Seam tries to access them. > Seam's context model needs to somehow guarantee that its SFSB instances aren't removed by the container before Seam is finished with them. And/or, it needs to recover from EJBNoSuchObjectException's more gracefully, especially with regards to Application scoped components for which there is no workaround. -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBSEAM-309) Debug page throws LIE when viewing entity bean with lazy collection

by Christian Bauer (JIRA)

Debug page throws LIE when viewing entity bean with lazy collection ------------------------------------------------------------------- Key: JBSEAM-309 URL: http://jira.jboss.com/jira/browse/JBSEAM-309 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 1.0.1 Reporter: Christian Bauer Priority: Minor When I click on my logged in user variable in the Session context on the Seam debug page I get a LIE for a lazy collection in that user entity bean instance. -- 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

19 years, 10 months

2
1
0 / 0

[JBoss JIRA] Created: (JBSEAM-312) seam dvd example - confirm.xhtml, order.totalAmount have to be currentOrder.totalAmount

by Torsten Krah (JIRA)

seam dvd example - confirm.xhtml, order.totalAmount have to be currentOrder.totalAmount --------------------------------------------------------------------------------------- Key: JBSEAM-312 URL: http://jira.jboss.com/jira/browse/JBSEAM-312 Project: JBoss Seam Issue Type: Bug Components: Examples Affects Versions: 1.0.1 Environment: JBoss 4.0.4 AS - Sun JDK 1.5.07 Reporter: Torsten Krah Priority: Trivial In confirm.xhtml the el expression for totalamount needs to be currentOrder.totalAmount, not order.totalAmount. kind regards Torsten -- 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

19 years, 10 months

2
1
0 / 0

[JBoss JIRA] Created: (JBSEAM-348) IssueTracker example uses nonexisting annotation (Within)

by Stephan Bublava (JIRA)

IssueTracker example uses nonexisting annotation (Within) --------------------------------------------------------- Key: JBSEAM-348 URL: http://jira.jboss.com/jira/browse/JBSEAM-348 Project: JBoss Seam Issue Type: Bug Components: Examples Reporter: Stephan Bublava Priority: Trivial org/jboss/seam/example/issues/LoggedInInterceptor.java imports org.jboss.seam.annotations.Within, which does not exist (and is also never used in the implementation). -- 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

19 years, 10 months

2
3
0 / 0

[JBoss JIRA] Updated: (JBSEAM-100) Unify datasource configuration factory with E-EJB3

by Gavin King (JIRA)

[ http://jira.jboss.com/jira/browse/JBSEAM-100?page=all ] Gavin King updated JBSEAM-100: ------------------------------ Issue Type: Feature Request (was: Bug) > Unify datasource configuration factory with E-EJB3 > -------------------------------------------------- > > Key: JBSEAM-100 > URL: http://jira.jboss.com/jira/browse/JBSEAM-100 > Project: JBoss Seam > Issue Type: Feature Request > Reporter: Christian Bauer > Priority: Trivial > Attachments: JBSEAM-100.zip > > > The org.jboss.resource.adapter.jdbc.local.LocalTxDataSource does the same as org.jboss.seam.microcontainer.DataSourceFactory - they are slightly different in configuration only. > For example: > - connectionUrl vs. connectionURL > - getDatasource vs. getDataSource > - etc. > One internal difference is the CachedConnectionManager. It is injected into the LocalTxDataSource, but instantiated in the seam.microcontainer.DataSourceFactory. > I think we should either unify, or better, kick out one of those two. -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBSEAM-333) UI Labels and displaying the hash sign #

by Lawrence Li (JIRA)

UI Labels and displaying the hash sign # ---------------------------------------- Key: JBSEAM-333 URL: http://jira.jboss.com/jira/browse/JBSEAM-333 Project: JBoss Seam Issue Type: Bug Components: JSF Affects Versions: 1.0.1 Reporter: Lawrence Li I can't seem to display the hash character In my JSP page, I have the following: <h:outputText escape="true" value="#{messages['TestNumber']}" /> In my messages.properties file, I have: TestNumber=Test # Seam cannot evaluate the EL... Cannot get value for expression '#{messages['RequestNumber.Short']}' I've also tried the Unicode character for the hash sign: TestNumber=Test \u0023 According to user raja05, the bug is due to code in Interpolator.interpolate which looks for a token after the hash sign - which in my case, is nonexistent since the hash sign is the last character in my label: FacesContext context = FacesContext.getCurrentInstance(); StringTokenizer tokens = new StringTokenizer(string, "#{}", true); StringBuilder builder = new StringBuilder(string.length()); while ( tokens.hasMoreTokens() ) { String tok = tokens.nextToken(); if ( "#".equals(tok) ) { String nextTok = tokens.nextToken(); -- 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

19 years, 10 months

4
3
0 / 0

[JBoss JIRA] Created: (JBSEAM-319) s:link does not work after JBoss restart

by Chris Hane (JIRA)

s:link does not work after JBoss restart ---------------------------------------- Key: JBSEAM-319 URL: http://jira.jboss.com/jira/browse/JBSEAM-319 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 1.1 Environment: jboss jems 4.0.4 seam 1.1 Reporter: Chris Hane On a results screen I use the s:link tag in a table. The results screen is generated from a SFSB with ScopeType.EVENT. When the user clicks on the <s:link /> action, a new screen opens up from another SFSB with ScopeType.CONVERSATION. This works great until JBoss is restarted. Once restarted, the view action (below) on an existing results screen returns the results.xhtml screen without any records and does not seem to call the SFSB editor.view that I expected. See the thread for the full description. -- 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

19 years, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (JBSEAM-315) No control over the process definition when using components "taskInstanceListForType" & "pooledTaskInstanceList"

by Aravind Kumar (JIRA)

No control over the process definition when using components "taskInstanceListForType" & "pooledTaskInstanceList" ----------------------------------------------------------------------------------------------------------------- Key: JBSEAM-315 URL: http://jira.jboss.com/jira/browse/JBSEAM-315 Project: JBoss Seam Issue Type: Bug Components: BPM Affects Versions: 1.0.1 Reporter: Aravind Kumar There may be multiple Business Processes running in the same application. with CreateProcess annotation we can instantiate process instance for a particular process definition. "taskInstanceListForType" & "pooledTaskInstanceList" components relies on TaskMgmtSession.java of JBPM to pull out the taskinstances that the current user is authorized to see. But theres no control over the precess definition. -- 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

19 years, 10 months

2
1
0 / 0

[JBoss JIRA] Created: (JBSEAM-339) Event scope container (WebRequestContext) doesn't clean the beans after destroy

by German de la Cruz (JIRA)

Event scope container (WebRequestContext) doesn't clean the beans after destroy ------------------------------------------------------------------------------- Key: JBSEAM-339 URL: http://jira.jboss.com/jira/browse/JBSEAM-339 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 1.0.1, 1.1 Environment: Jboss Seam nightly build 20060821, myfaces 1.1.4-SNAPSHOT from cvs. Tomahawk and tomahawk-snapshot 1.1.5-SNAPSHOT from cvs facelets 1.1.11 Reporter: German de la Cruz Priority: Critical Please, after the flushAndDestroyContext call, clean the destroyed bean from the event scope session (and therefore from the http request object. It produces a bug with tomahawk-sandbox and event scoped session bean. The destroyed beans are anyway invalid references and must be destroyed. I've made a very simple patch, but anyway, it can't solve the problem since some modifications in tomahawk sandbox is needed. -- 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

19 years, 10 months

2
4
0 / 0

[JBoss JIRA] Closed: (JBSEAM-136) @StartTask(pageFlow="...")

by Gavin King (JIRA)

[ http://jira.jboss.com/jira/browse/JBSEAM-136?page=all ] Gavin King closed JBSEAM-136. ----------------------------- Resolution: Done Assignee: Gavin King I understand that this problem was already fixed by a new jBPM release. > @StartTask(pageFlow="...") > -------------------------- > > Key: JBSEAM-136 > URL: http://jira.jboss.com/jira/browse/JBSEAM-136 > Project: JBoss Seam > Issue Type: Bug > Components: BPM > Reporter: Gavin King > Assigned To: Gavin King > Attachments: ToDo_jBPM_Example.zip > > > There is no test for a pageflow attached to a task. A user reports that this is broken. -- 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

19 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2006