October 2007 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2071) Introduce log attribute to exception handlers

by Shane Bryzak (JIRA)

Introduce log attribute to exception handlers --------------------------------------------- Key: JBSEAM-2071 URL: http://jira.jboss.com/jira/browse/JBSEAM-2071 Project: JBoss Seam Issue Type: Feature Request Components: Core Affects Versions: 2.0.0.CR2 Reporter: Shane Bryzak Assigned To: Shane Bryzak Priority: Minor Fix For: 2.0.x As suggested by Gavin in the forum post, we should be able to suppress logging of specific exception types. That way people can decide whether they want NotLoggedInException etc errors cluttering up their log file. <exception class="MyException" log="false"> ... </exception> -- 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, 11 months

6
8
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1634) More customizable hot redeployment

by Christian Bauer (JIRA)

More customizable hot redeployment ---------------------------------- Key: JBSEAM-1634 URL: http://jira.jboss.com/jira/browse/JBSEAM-1634 Project: JBoss Seam Issue Type: Feature Request Components: Core Reporter: Christian Bauer Priority: Minor Attachments: flexible_hot_redployment.patch The attached patch adds several things: - ability to specify the hot deployment directory as a servlet context init parameter (seam.HOT_DEPLOY_DIRECTORY) - ability to access the used RedeployableStrategy from the application context (to get the classloader, etc) - an additional descriptor (hot-components.xml) that can be used in the hot deploy directory I use this to boot Seam from an embeddable webserver with a custom parent classloader and to start Embedded JBoss with the same child classloader that Seam is using. I effectively get complete hot redeployment of all Seam components, EJBs, and persistence units. -- 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, 11 months

2
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1471) @Child annotation for GWT

by Gavin King (JIRA)

@Child annotation for GWT ------------------------- Key: JBSEAM-1471 URL: http://jira.jboss.com/jira/browse/JBSEAM-1471 Project: JBoss Seam Issue Type: Feature Request Components: Remoting Reporter: Gavin King Assigned To: Shane Bryzak The EntryPoint class is ugly boilerplate. You should be able to annotate your GWT class with @Child("theId") and it will be automagically added in when the module loads. -- 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, 11 months

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2101) Improve ConversationStack component by filtering based on view-ids

by Jacob Orshalick (JIRA)

Improve ConversationStack component by filtering based on view-ids ------------------------------------------------------------------ Key: JBSEAM-2101 URL: http://jira.jboss.com/jira/browse/JBSEAM-2101 Project: JBoss Seam Issue Type: Feature Request Affects Versions: 2.0.0.CR2 Reporter: Jacob Orshalick Priority: Minor The application I am currently developing follows the following Form scenario: 1. User selects a DataModel element for editing which takes them to view editDataModelSelection.xhtml . 2. User makes changes to the DataModelSelection. 3. User selects an associated Object for editing which takes the user to sub-view editAggregateObject.xhtml 4. User makes changes to associated object and submits those changes. 5. This takes the user back to editDataModelSelection.xhtml view where the changes to the associated object are shown updated to the DataModelSelection. 5. User submits the changes to the DataModelSelection which persists both DataModelSelection changes and associated object changes as well. A conversation is nested when the user accesses view editAggregateObject.xhtml . This allows a user to back-button to the editDataModelSelection.xhtml prior to editing the aggregate object without causing state inconsistencies between what the user sees and what actually persists on submit. The trouble is the display of breadcrumbs through the ConversationStack. When the user traverses the following path: view editDataModelSelection.xhtml -> action(editAssociatedObject) conversation nested here -> view editAggregateObject.xhtml -> action(submitChanges) -> view editDataModelSelection.xhtml In this scenario, the breadcrumbs by default are displayed as: Edit Data Model Selection | Edit Data Model Selection This makes sense due to the fact that the nested conversation has the same view-id as the outer conversation. This continues the more times the user edits an associated object. The implementation I am using filters ConversationEntries from the ConversationStack based on the view-id so that the breadcrumbs are simply displayed as: Edit Data Model Selection regardless of the nested ConversationEntries in this scenario. It is requested that the ConversationStack be filtered based on view-id to provide this as default behavior. Thanks. -- 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, 11 months

2
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1741) Seam Text links render incorrectly when no text provided

by Shane Bryzak (JIRA)

Seam Text links render incorrectly when no text provided -------------------------------------------------------- Key: JBSEAM-1741 URL: http://jira.jboss.com/jira/browse/JBSEAM-1741 Project: JBoss Seam Issue Type: Bug Reporter: Shane Bryzak -- 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, 11 months

2
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1633) Mock Log

by Bieth Bruno (JIRA)

Mock Log -------- Key: JBSEAM-1633 URL: http://jira.jboss.com/jira/browse/JBSEAM-1633 Project: JBoss Seam Issue Type: Feature Request Reporter: Bieth Bruno Priority: Minor I would like to unit test a Seam SFSB which uses an injected logger. I didn't find any MockLog so I use the logging factory like that : Code: setField( editor, "log", Logging.getLog( "test" ) ); It solves the NullPointerException and the test are working fine but when logging, the Interpolator try to access the context which doesnt exist and throws an IllegalStateException ... It may be useful to have a mockLog method in the SeamTest class which look for a @Logger annotation and inject a MockLog. The MockLog will basically print any log on the console. -- 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, 11 months

2
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1322) MutlipartRequest parser occasionally throws ArrayIndexOutOfBoundsException

by ROB b (JIRA)

MutlipartRequest parser occasionally throws ArrayIndexOutOfBoundsException -------------------------------------------------------------------------- Key: JBSEAM-1322 URL: http://jira.jboss.com/jira/browse/JBSEAM-1322 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 1.2.1.GA, 1.2.0.GA Environment: Windows Vista, Java 1.6u1, JBoss Seam 1.2.1, JBoss AS 4.0.5.GA Reporter: ROB b During an upload, the MultipartRequest checkSequence function does not to proper boundary checking on function parameters. It will occasionally (rarely actually) throw an ArrayIndexOutOfBoundsException at the high end due to the +1 offset when accessing the data array. I'm not actually sure why this +1 is there and was wondering if somehow it was a mistake. This class is a little hard to follow, so I'm not sure how everything works, but the function description seems to indicate that it is checking for the end of a byte array at a specific location which is 0-indexed, but the +1 would seem to indicate otherwise. The following exception gets thrown: java.lang.ArrayIndexOutOfBoundsException: 2048 at org.jboss.seam.web.MultipartRequest.checkSequence(MultipartRequest.java:466) at org.jboss.seam.web.MultipartRequest.parseRequest(MultipartRequest.java:333) at org.jboss.seam.web.MultipartRequest.getParam(MultipartRequest.java:507) at org.jboss.seam.web.MultipartRequest.getParameter(MultipartRequest.java:558) at org.apache.myfaces.context.servlet.RequestParameterMap.getAttribute(RequestParameterMap.java:39) at org.apache.myfaces.context.servlet.AbstractAttributeMap.get(AbstractAttributeMap.java:87) at com.sun.facelets.tag.ui.UIDebug.debugRequest(UIDebug.java:119) at com.sun.facelets.FaceletViewHandler.restoreView(FaceletViewHandler.java:305) at org.ajax4jsf.framework.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:116) at org.ajax4jsf.framework.ajax.AjaxViewHandler.restoreView(AjaxViewHandler.java:147) at org.apache.myfaces.lifecycle.LifecycleImpl.restoreView(LifecycleImpl.java:141) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:66) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:137) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:63) at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:57) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49) at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:60) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49) at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49) at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:74) at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49) at org.jboss.seam.web.SeamFilter.doFilter(SeamFilter.java:84) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.ajax4jsf.framework.ajax.xmlfilter.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:96) at org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter.doFilter(BaseFilter.java:220) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112) 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: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

3
4
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1545) Define a means to provide alternate implementations of interceptors.

by Chris Rudd (JIRA)

Define a means to provide alternate implementations of interceptors. -------------------------------------------------------------------- Key: JBSEAM-1545 URL: http://jira.jboss.com/jira/browse/JBSEAM-1545 Project: JBoss Seam Issue Type: Feature Request Components: Core Affects Versions: 1.3.0.ALPHA Reporter: Chris Rudd Priority: Minor It would be nice if interceptors could be replaced / extened by defining a replacement interceptor to use instead of a stock one. This would allow end user customization of some of the Seam functionality that must occur in the interceptors themselves. ( JBSEAM-1544 is one example where this could be used to extend the SecurityInterceptor to provide additional functionality not currently present. ) -- 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, 11 months

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1835) Improve debug logging

by Christian Bauer (JIRA)

Improve debug logging --------------------- Key: JBSEAM-1835 URL: http://jira.jboss.com/jira/browse/JBSEAM-1835 Project: JBoss Seam Issue Type: Task Reporter: Christian Bauer Priority: Blocker This should be logged at TRACE level: (http-127.0.0.1-8080-1hread) 16:24:55,596 DEBUG [Events] Processing event:org.jboss.seam.postSetVariable.org.jboss.seam.core.manager (http-127.0.0.1-8080-1hread) 16:24:55,596 DEBUG [Component] instantiating Seam component: org.jboss.seam.core.events (http-127.0.0.1-8080-1hread) 16:24:55,596 DEBUG [Component] initializing new instance of: org.jboss.seam.core.events (http-127.0.0.1-8080-1hread) 16:24:55,596 DEBUG [Component] done initializing: org.jboss.seam.core.events I have thousands of lines of these making DEBUG completely useless. I still want to see all other instantiations etc. from Component though. -- 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, 11 months

3
7
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1796) more useful logging for Controller objects

by Matt Drees (JIRA)

more useful logging for Controller objects ------------------------------------------ Key: JBSEAM-1796 URL: http://jira.jboss.com/jira/browse/JBSEAM-1796 Project: JBoss Seam Issue Type: Feature Request Affects Versions: 2.0.0.BETA1 Reporter: Matt Drees Priority: Minor When a class derived from Controller calls debug("message"), the result is something like: DEBUG 13-08 15:10:48,309 [org.jboss.seam.framework.Controller.debug():188] message The location info is useless. I can get around this by using getLog().debug("message"), which will display the correct location info. But "debug()" is just so convenient... Or at least let me set the FQCN on the underlying Log4jProvider. -- 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, 11 months

2
1
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