March 2009 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3146) Allow Object... args in the hasPermission EL function

by Samuel Mendenhall (JIRA)

Allow Object... args in the hasPermission EL function ----------------------------------------------------- Key: JBSEAM-3146 URL: http://jira.jboss.com/jira/browse/JBSEAM-3146 Project: Seam Issue Type: Feature Request Components: Security Affects Versions: 2.1.0.A1, 2.0.3.CR1 Reporter: Samuel Mendenhall Priority: Minor So the following is possible #{identity.hasPermission('blog', 'create', arg1, arg2)} and the args can be accessed in the drl file, so we should also allow #{s:hasPermission('blog', 'create', arg1, arg2)} -- 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
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3652) Major reentrancy problem with "Page Scope" components and injection/disinjection

by Denis Forveille (JIRA)

Major reentrancy problem with "Page Scope" components and injection/disinjection -------------------------------------------------------------------------------- Key: JBSEAM-3652 URL: https://jira.jboss.org/jira/browse/JBSEAM-3652 Project: Seam Issue Type: Bug Affects Versions: 2.1.0.GA, 2.0.3.CR1, 2.0.2.SP1 Environment: WebSphere v6.1.0.17 in POJO Mode Reporter: Denis Forveille Priority: Blocker This bug is very similar to the JBSEAM-3295 bug, but for "Page Scope" components this time Under stress, we have random NPE, "conversation expired" and other strange eroors from time to time in production This is due to a flaw in the "BijectionInterceptor" class and it is quite easy to reproduce On a facelets page, we have a datatable with a list of h:commadLink, teh first page of a classic "list entities/showDetail" scheme. The controleur that manages the list is in "Page Scope" When the user clics on one of the link, then quickly clic on another link, another one etc... without waiting for the detail view to show up, we have two concurrent request addressed to the same Page Scope component (Verified by putting traces in the BijectionInterceptor class) In BijectionInterceptor, in that case, counter == 2 after line 77 meaning there is two concurrent thread running: the current thread + another one currently "using" the component The counter will be decrease for the first time on line 82, then a second time on line 129 and so, disinjection will occur on line 134. This occurs while there is another thread "using" the component, causing random NPE and other errors!!!! In fact this will happen each time counter >1, ie there is more than one "concurrent" request on the same component This alleviate some questions:- - is this normal that 2 (or more) concurrent request from the same user/conversation/page acces the same page scope component concurrently (I thought seam was taking care of this and was serializing such requests... - is this normal that on line 88, components are outjected, only when the last concurrent "user" of the component exits the interceptor and not when each request "eixts" the interceptor? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

4
13
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3845) NullPointerException in org.jboss.seam.exception.Exceptions.parse

by Ond?ej Žižka (JIRA)

NullPointerException in org.jboss.seam.exception.Exceptions.parse ----------------------------------------------------------------- Key: JBSEAM-3845 URL: https://jira.jboss.org/jira/browse/JBSEAM-3845 Project: Seam Issue Type: Bug Affects Versions: 2.1.0.SP1 Environment: JBoss EAP 4.3.0 default, JSFUnit, run using Cactus ServletTestRunner Reporter: Ond?ej Žižka Seam throws a NPE when I run a JSFUnit test case. The test may be fault, but at least the NPE should be handled. Full stack trace: ------------------------------------------------------- 15:11:11,933 ERROR [BaseXMLFilter] Exception in the filter chain javax.servlet.ServletException: org.jboss.seam.InstantiationException: Could not instantiate Seam component: org.jboss.seam.exception.exceptions at org.jboss.seam.web.ExceptionFilter.endWebRequestAfterException(ExceptionFilter.java:126) at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:70) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:177) at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:267) at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:380) at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:507) at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56) 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.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:173) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:595) Caused by: org.jboss.seam.InstantiationException: Could not instantiate Seam component: org.jboss.seam.exception.exceptions at org.jboss.seam.Component.newInstance(Component.java:2096) at org.jboss.seam.Component.getInstance(Component.java:1978) at org.jboss.seam.Component.getInstance(Component.java:1957) at org.jboss.seam.Component.getInstance(Component.java:1951) at org.jboss.seam.Component.getInstance(Component.java:1924) at org.jboss.seam.Component.getInstance(Component.java:1919) at org.jboss.seam.exception.Exceptions.instance(Exceptions.java:256) at org.jboss.seam.web.ExceptionFilter.endWebRequestAfterException(ExceptionFilter.java:114) ... 31 more Caused by: java.lang.NullPointerException at org.jboss.seam.exception.Exceptions.parse(Exceptions.java:195) at org.jboss.seam.exception.Exceptions.initialize(Exceptions.java:119) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.seam.util.Reflections.invoke(Reflections.java:22) at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:138) at org.jboss.seam.Component.callComponentMethod(Component.java:2201) at org.jboss.seam.Component.callCreateMethod(Component.java:2124) at org.jboss.seam.Component.newInstance(Component.java:2084) ... 38 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

4
11
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4038) Errors in Seam Remoting marshalling a java.util.Date in a highly concurrent environment

by Joshua Davis (JIRA)

Errors in Seam Remoting marshalling a java.util.Date in a highly concurrent environment --------------------------------------------------------------------------------------- Key: JBSEAM-4038 URL: https://jira.jboss.org/jira/browse/JBSEAM-4038 Project: Seam Issue Type: Bug Components: Remoting Affects Versions: 2.1.1.GA Reporter: Joshua Davis Assignee: Shane Bryzak We've experienced marshalling errors occasionally when passing a java.util.Date back to JavaScript there are lots of threads issuing requests. This has been tracked down to the server producing an XML response that has garbage/incorrect values in the <date> element. The problem is caused by the static 'df' variable in org.jboss.seam.remoting.wrapper.DateWrapper, which is a SimpleDateFormat. In a highly concurrent environment, calls to this SimpleDateFormat will overlap, and since SimpleDateFormat is not thread-safe, it will yield strange results. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/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-3877) Use SeamGlobalResolver in the RuleBasedPermissionResolver as it is in ManagedWorkingMemory

by Jarek Gilewski (JIRA)

Use SeamGlobalResolver in the RuleBasedPermissionResolver as it is in ManagedWorkingMemory ------------------------------------------------------------------------------------------ Key: JBSEAM-3877 URL: https://jira.jboss.org/jira/browse/JBSEAM-3877 Project: Seam Issue Type: Feature Request Components: Security Affects Versions: 2.1.1.GA Reporter: Jarek Gilewski SeamGlobalResolver is not used by RuleBasedPermissionResolver, so the global variable is not resolved. (Details on the forum) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

2
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3882) PermissionResolvers can't use injections

by Clint Popetz (JIRA)

PermissionResolvers can't use injections ---------------------------------------- Key: JBSEAM-3882 URL: https://jira.jboss.org/jira/browse/JBSEAM-3882 Project: Seam Issue Type: Bug Components: Security Reporter: Clint Popetz PermissionResolvers are seam components, and the documentation doesn't mention any restrictions on them. However, because PermissionMapper caches the resolver chain in the application, and doesn't serialize access to the resolvers themselves, PermissionResolvers must not only be stateless but also must not use injections, even of stateless components, as bijection on each resolver might be interlaced from multiple threads. This should probably be documented, as it just exposed itself as on our production server as nasty errors under load :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

2
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3437) Create protected isInitialized() and setInitialized( boolean ) methods in Credentials

by Mike Pettypiece (JIRA)

Create protected isInitialized() and setInitialized( boolean ) methods in Credentials ------------------------------------------------------------------------------------- Key: JBSEAM-3437 URL: https://jira.jboss.org/jira/browse/JBSEAM-3437 Project: Seam Issue Type: Feature Request Components: Security Affects Versions: 2.1.0.BETA1 Reporter: Mike Pettypiece It would be useful if there were protected methods isInitialized() and setInitialized( boolean ) in Credentials. I'm currently subclassing Credentials and right now I need access to the field "initialized". Having to shadow initialized (along with username and overriding it's get/setters) isn't ideal. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/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-2890) NTLM integration

by Pete Muir (JIRA)

NTLM integration ---------------- Key: JBSEAM-2890 URL: http://jira.jboss.com/jira/browse/JBSEAM-2890 Project: Seam Issue Type: Feature Request Components: Security Affects Versions: 2.1.0.A1, 2.0.2.CR1 Reporter: Pete Muir Provide deeper integration with NTLM (and similar systems?) - for example a simple component which exposes the user logged in via NTLM, and automatically pushes that info into identity? -- 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-3814) org.jboss.seam.log.LogProvider should offer variable parameter list like org.jboss.seam.log.Log to improve logging performace

by Francisco Jose Peredo Noguez (JIRA)

org.jboss.seam.log.LogProvider should offer variable parameter list like org.jboss.seam.log.Log to improve logging performace ----------------------------------------------------------------------------------------------------------------------------- Key: JBSEAM-3814 URL: https://jira.jboss.org/jira/browse/JBSEAM-3814 Project: Seam Issue Type: Feature Request Reporter: Francisco Jose Peredo Noguez This could be accomplished easily if Slf4j is used as the underlying tech for logging since it is already supported. The change could be done without any code modifications and then the logging calls could be optimized gradually. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

2
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3761) Support EL for 'hash' attribute of @UserPassword

by Ingo Jobling (JIRA)

Support EL for 'hash' attribute of @UserPassword ------------------------------------------------- Key: JBSEAM-3761 URL: https://jira.jboss.org/jira/browse/JBSEAM-3761 Project: Seam Issue Type: Feature Request Components: Security Affects Versions: 2.1.0.SP1 Reporter: Ingo Jobling Would it be possible to support EL so we could do something like: @UserPassword(hash = "#{applicationProperties.get('security.password.digestAlgorithm')}") Feature request opened per reply by Shane Bryzak to Seam Forum post : http://www.seamframework.org/Community/SaltForUserPasswordInSeam21#commen... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

2
2
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues March 2009