December 2007 - seam-issues - Jboss List Archives

[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, 9 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, 9 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, 9 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, 9 months

2
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2418) Cannot use non-POJO Hibernate entities with Seam-managed Session

by Dave Sunerton-Burl (JIRA)

Cannot use non-POJO Hibernate entities with Seam-managed Session ---------------------------------------------------------------- Key: JBSEAM-2418 URL: http://jira.jboss.com/jira/browse/JBSEAM-2418 Project: JBoss Seam Issue Type: Bug Affects Versions: 2.0.0.GA Environment: WinXP, JBoss4.2 Reporter: Dave Sunerton-Burl When trying to use the Map-based mode of a Hibernate session, I get the error below. First, here's the code that causes the error... final Session session = (Session) Component.getInstance("dynamicSession"); final Session mapSession = session.getSession(EntityMode.MAP); final Map record = (Map) mapSession.get("TestEntity", 10001l); ...the last line causes... java.lang.AssertionError: java.lang.IllegalArgumentException: Not an entity class: java.util.HashMap at org.jboss.seam.mock.BaseSeamTest$Request.onException(BaseSeamTest.java:475) at org.jboss.seam.mock.BaseSeamTest$Request$2.doFilter(BaseSeamTest.java:526) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83) at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:68) 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:64) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:44) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141) at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281) at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:60) 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.servlet.SeamFilter.doFilter(SeamFilter.java:158) at org.jboss.seam.mock.BaseSeamTest$Request.run(BaseSeamTest.java:514) at com.fugro.traxx.entities.DynamicEntityTest.changeMappingsAtRuntime(DynamicEntityTest.java:88) Caused by: java.lang.IllegalArgumentException: Not an entity class: java.util.HashMap at org.jboss.seam.Entity.forClass(Entity.java:208) at org.jboss.seam.persistence.PersistenceProvider.getPostLoadMethod(PersistenceProvider.java:154) at org.jboss.seam.security.Identity.checkEntityPermission(Identity.java:678) at org.jboss.seam.security.HibernateSecurityInterceptor.onLoad(HibernateSecurityInterceptor.java:35) at org.hibernate.event.def.DefaultPreLoadEventListener.onPreLoad(DefaultPreLoadEventListener.java:18) at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:125) at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:842) at org.hibernate.loader.Loader.doQuery(Loader.java:717) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224) at org.hibernate.loader.Loader.loadEntity(Loader.java:1851) at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48) at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42) at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:2992) at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:395) at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:375) at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:139) at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:195) at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:103) at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:878) at org.hibernate.impl.SessionImpl.get(SessionImpl.java:815) at com.fugro.traxx.entities.DynamicEntityTest$3.invokeApplication(DynamicEntityTest.java:104) at org.jboss.seam.mock.BaseSeamTest$Request.invokeApplicationPhase(BaseSeamTest.java:652) at org.jboss.seam.mock.BaseSeamTest$Request.emulateJsfLifecycle(BaseSeamTest.java:598) at org.jboss.seam.mock.BaseSeamTest$Request.access$300(BaseSeamTest.java:185) at org.jboss.seam.mock.BaseSeamTest$Request$2.doFilter(BaseSeamTest.java:519) ... 40 more ... Removed 22 stack frames "dynamicSession" is declared in components.xml as... <persistence:managed-hibernate-session auto-create="true" name="dynamicSession"/> The error seems to be connected to the HibernateSecurityInterceptor, which tries to get hold of a real class from the mapping (which doesn't exist - this is a non-POJO mapping). My workaround involved replacing the "org.jboss.seam.persistence.HibernateSessionFactory" with my own implementation which didn't add the interceptor (I will have to do without declarative security on the dynamic entities). -- 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, 9 months

3
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2271) Changes to the security event names totally broke loging redirection in examples and seam-gen, and docs were not updated

by Gavin King (JIRA)

Changes to the security event names totally broke loging redirection in examples and seam-gen, and docs were not updated ------------------------------------------------------------------------------------------------------------------------ Key: JBSEAM-2271 URL: http://jira.jboss.com/jira/browse/JBSEAM-2271 Project: JBoss Seam Issue Type: Bug Components: Security Reporter: Gavin King Priority: Blocker Why are we breaking pubished APIs in a point release? Why are we changing public APIs without testing? Very unprofessional! -- 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, 9 months

2
4
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, 9 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, 9 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, 9 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, 9 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues December 2007