June 2007 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-374) Normalize the event model

by Gavin King (JIRA)

[ http://jira.jboss.com/jira/browse/JBSEAM-374?page=comments#action_12364834 ] Gavin King commented on JBSEAM-374: ----------------------------------- This stuff no longer seems so useful. Especially (1) looks nondoable now. > Normalize the event model > ------------------------- > > Key: JBSEAM-374 > URL: http://jira.jboss.com/jira/browse/JBSEAM-374 > Project: JBoss Seam > Issue Type: Feature Request > Components: Core > Reporter: Gavin King > Assigned To: Gavin King > > Currently some events can be handled by either an @Observer method, or a method binding in events.xml. Ideally we would like this to be true for ALL events, but for now our integration with JSF and jBPM is not quite that deep. Nevertheless, there are some things we could do to allow a more consistent model where everything can be handled by either a method binding or an annotated method: > (1) Rebuild the page actions functionality on top of the Seam event bus - defining standard org.jboss.seam.page.<viewId> events that can be handled via @Observer("org.jboss.seam.page./myViewId.xhtml") > (2) Introduce "outcome observers" for JSF: if I have <h:commandButton action="myOutcome"/>, allow us to handle it using @Observer("org.jboss.seam.outcome.myOutcome") > (3) Ditto for jBPM: if I have <transition name="myTransition" ... />, allow us to handle it using @Observer("org.jboss.seam.transition.myTransition") > (4) Finally, introduce annotations layered over @Observer: @RenderPage("/myViewId.xhtml"), @Outcome("myOutcome"), @Transition("myTransition") -- 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

17 years, 7 months

1
0
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1186) log API improvement

by Mikhail Grushinskiy (JIRA)

log API improvement ------------------- Key: JBSEAM-1186 URL: http://jira.jboss.com/jira/browse/JBSEAM-1186 Project: JBoss Seam Issue Type: Feature Request Components: Core Environment: all Reporter: Mikhail Grushinskiy Priority: Minor Instead of log.debug("Creating new order for user: #0 product: #1 quantity: #2", user.username(), product.name(), quantity); #0, #1, #2 why couldn't we just always use #? Parameters are already ordered. There is no need to number them in the format string, this will be just another source of errors. Another question what happens if you have more parameters after format string than #n placeholders. I think in such case these parameters should be appended at the end of the format string in output so not values are lost . -- 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

17 years, 7 months

2
1
0 / 0

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

by Gavin King (JIRA)

[ http://jira.jboss.com/jira/browse/JBSEAM-339?page=all ] Gavin King closed JBSEAM-339. ----------------------------- Resolution: Won't Fix No votes for this, and seems to be really about Tomahawk fragility. The request is over: why remove attributes from it? Fix it in Tomahawk > 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: Feature Request > Components: Core > Affects Versions: 1.0.1, 1.1.0.BETA1 > 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 > Assigned To: Gavin King > Priority: Minor > Attachments: bulk.tar.gz, path_to_flush_beans.path > > > 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

17 years, 7 months

1
0
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1188) Using the Seam exception filter without JTA throws exception

by Mike Quilleash (JIRA)

Using the Seam exception filter without JTA throws exception ------------------------------------------------------------ Key: JBSEAM-1188 URL: http://jira.jboss.com/jira/browse/JBSEAM-1188 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 1.2.1.GA Environment: Tomcat 6, no microcontainer Reporter: Mike Quilleash Upgraded to Seam 1.2.1 and the following exception gets printed to the logs when there is an exception. ERROR [org.jboss.seam.web.ExceptionFilter] [http-56000-1] (ExceptionFilter.java:136) - could not roll back transaction javax.naming.NamingException: Cannot create resource instance at org.apache.naming.factory.TransactionFactory.getObjectInstance(TransactionFactory.java:113) at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304) at org.apache.naming.NamingContext.lookup(NamingContext.java:793) at org.apache.naming.NamingContext.lookup(NamingContext.java:140) at org.apache.naming.NamingContext.lookup(NamingContext.java:781) at org.apache.naming.NamingContext.lookup(NamingContext.java:153) at org.apache.naming.SelectorContext.lookup(SelectorContext.java:137) at javax.naming.InitialContext.lookup(InitialContext.java:351) at org.jboss.seam.util.Transactions.getUserTransaction(Transactions.java:153) at org.jboss.seam.util.Transactions.isUTTransactionActiveOrMarkedRollback(Transactions.java:122) at org.jboss.seam.util.Transactions.isTransactionActiveOrMarkedRollback(Transactions.java:50) at org.jboss.seam.web.ExceptionFilter.rollbackTransactionIfNecessary(ExceptionFilter.java:128) at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:63) 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) I don't have JTA/microcontainer installed as I just want to use the exception filter for redirecting on error, rolling back transactions should be disabled/skipped in a non JTA configuration. -- 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

17 years, 7 months

3
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Closed: (JBSEAM-308) DataModel instance changes even though the backing list did not when using PAGE scope

by Gavin King (JIRA)

[ http://jira.jboss.com/jira/browse/JBSEAM-308?page=all ] Gavin King closed JBSEAM-308. ----------------------------- Fix Version/s: 1.3.0.ALPHA Resolution: Done Assignee: Gavin King I finally understood this. The proposed fix was the correct one. > DataModel instance changes even though the backing list did not when using PAGE scope > ------------------------------------------------------------------------------------- > > Key: JBSEAM-308 > URL: http://jira.jboss.com/jira/browse/JBSEAM-308 > Project: JBoss Seam > Issue Type: Bug > Components: Core > Affects Versions: 1.0 beta 1, 1.0 beta 2, 1.0, 1.0.1, 1.1.0.BETA1 > Reporter: Chris Rudd > Assigned To: Gavin King > Fix For: 1.3.0.ALPHA > > > The outjectDataModel code attempts to determine if the value changed and therefore needs to be re outjected. > When not using PAGE scope this works fine. When PAGE scope is used it always reports dirty, which causes the value to be outjected. > The issue is that if the backing value didnt change, it still gets re-wrapped and outjected instead of just re-outjected. > I noticed this when working with an @DataModel, the UIData components im using cache the DataModel to ensure that it doesnt change between the updateValues and the invokeApplication phases. So hwat ends up happening is that in the updateValues phase a property gets set on my component, causing the datamodel to be re-outjected, since the UIData has already cached the original value, it never picks up the "new" one. When I get to the invokeApplication phase and it calls an action method on the component the datamodel that the UIData updated the rowIndex on isnt the same one that seam pulls the rowIndex from to inject the @DataModelSelection. > I propose the following fix to the 1.0.0 GA code ( removed PAGE scope check from dirty assignment, added else clause to if(dirty) ): > private void outjectDataModelList(String name, Object list, ScopeType scope, DataBinder wrapper) > { > > Context context = getDataModelContext(scope); > Object existingDataModel = context.get(name); > boolean dirty = existingDataModel == null || > !wrapper.getWrappedData(existingDataModel).equals(list); //TODO: delegate to the wrapper to determine equality > > if ( dirty ) > { > if ( list != null ) > { > context.set( name, wrapper.wrap(list) ); > } > else > { > context.remove( name ); > } > } > // If page scope, outject the existingDataModel even if there was no change > else if( scope==ScopeType.PAGE ) > { > context.set( name, existingDataModel ); > } > > } -- 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

17 years, 7 months

1
0
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1301) Bugs with MockServletContext.getResourcePaths()

by Michael Youngstrom (JIRA)

Bugs with MockServletContext.getResourcePaths() ----------------------------------------------- Key: JBSEAM-1301 URL: http://jira.jboss.com/jira/browse/JBSEAM-1301 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 1.2.1.GA Reporter: Michael Youngstrom Assigned To: Michael Youngstrom Fix For: 1.3.0.BETA1 I've been doing some work with Seam integration testing lately and noticed getResourcePaths() wasn't working correctly. It appeared to never return anything beyond the webroot. So, I fixed that problem and enhanced getResourcePaths so that it could handle situations where a users directory structure may have multiple webroots (e.g. one for test and main). I changed from searching for webroot by looking for WEB-INF/web.xml files to only WEB-INF. If nobody has any objections to my implementation I'll go ahead and commit this. This is how I've rewritten getResourcePaths(): public Set getResourcePaths(String name) { Enumeration<URL> enumeration = null; try { enumeration = getClass().getClassLoader().getResources("WEB-INF"); } catch (IOException e) { throw new RuntimeException("Error finding webroot.",e); } Set<String> result = new HashSet<String>(); while(enumeration.hasMoreElements()) { URL url = enumeration.nextElement(); File rootFile = new File(url.getPath()).getParentFile(); File newFile = new File(rootFile.getPath()+name); File[] files = newFile.listFiles(); if(files != null) { addPaths( result, files, rootFile.getPath() ); } } return result; } private static void addPaths(Set<String> result, File[] files, String rootPath) { for (File file: files) { String filePath = file.getPath().substring( rootPath.length() ).replace('\\', '/'); if(file.isDirectory()) { result.add(filePath+"/"); } else { result.add(filePath); } } } -- 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

17 years, 7 months

3
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-953) Don't create HttpSession until we *really* need it

by Gavin King (JIRA)

Don't create HttpSession until we *really* need it -------------------------------------------------- Key: JBSEAM-953 URL: http://jira.jboss.com/jira/browse/JBSEAM-953 Project: JBoss Seam Issue Type: Feature Request Components: Core Reporter: Gavin King Assigned To: Gavin King Fix For: 1.2.1.GA This requires a thorough code audit. -- 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

17 years, 7 months

1
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1417) Document @Converter and @Validator

by Mike Quilleash (JIRA)

Document @Converter and @Validator ---------------------------------- Key: JBSEAM-1417 URL: http://jira.jboss.com/jira/browse/JBSEAM-1417 Project: JBoss Seam Issue Type: Task Components: Documentation Affects Versions: 1.2.1.GA Environment: Any Reporter: Mike Quilleash @Converter and @Validator annotations need documenting. -- 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

17 years, 7 months

3
4
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1427) Seam PDF must support border widths

by Mikhail Grushinskiy (JIRA)

Seam PDF must support border widths ----------------------------------- Key: JBSEAM-1427 URL: http://jira.jboss.com/jira/browse/JBSEAM-1427 Project: JBoss Seam Issue Type: Bug Components: PDF Affects Versions: 1.3.0.ALPHA, 1.3.0.BETA1, 1.3.0.BETA2, 1.3.0.GA, 1.3.1.GA Reporter: Mikhail Grushinskiy Seam PDF must support border widths -- 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

17 years, 7 months

2
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1425) Seam PDF doesn't support all colors

by Mikhail Grushinskiy (JIRA)

Seam PDF doesn't support all colors ----------------------------------- Key: JBSEAM-1425 URL: http://jira.jboss.com/jira/browse/JBSEAM-1425 Project: JBoss Seam Issue Type: Bug Components: PDF Affects Versions: 1.3.0.ALPHA, 1.3.0.BETA1, 1.3.0.BETA2, 1.3.0.GA, 1.3.1.GA Reporter: Mikhail Grushinskiy There is no way to set up arbitrary colors for cells, fonts, borders, backgrounds -- 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

17 years, 7 months

2
2
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues June 2007