January 2009 - seam-issues - Jboss List Archives

[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

15 years, 8 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

15 years, 8 months

4
11
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

15 years, 8 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

15 years, 8 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

15 years, 8 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

15 years, 8 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

15 years, 8 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

15 years, 8 months

2
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3762) Make it possible to select password salt without overriding IdentityStore

by Nikolay Elenkov (JIRA)

Make it possible to select password salt without overriding IdentityStore ------------------------------------------------------------------------- Key: JBSEAM-3762 URL: https://jira.jboss.org/jira/browse/JBSEAM-3762 Project: Seam Issue Type: Feature Request Components: Security Environment: Seam 2.1 Reporter: Nikolay Elenkov Currently, JpaIdentityStore uses the username as salt when hashing the user password. If you want to use a different property as salt, you need to override JpaIdentityStore. Since the salt is usually stored together with the user principal, it would be easier to select the property used as salt by annotating it, without having to override the IdentityStore component. Using a randomly generated salt is a generally accepted practice, so it should also be possible to generate the salt value automatically when creating the user via IdentityManager's API. Suggestion: A new annotation, UserPasswordSalt, to annotate property used as salt. Attributes: * generate=true|false -- whether to generate random value * length=salt length in bits (used when generate=true) Example usage: class User { @UserPasswordSalt(generate=true, length=64) String getSalt() {..} @UserPassword(hash="sha1" String getPasswordHash() {...} } -- 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

15 years, 8 months

2
9
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3763) Make it possible to specify iteration count for salt+password hashing

by Nikolay Elenkov (JIRA)

Make it possible to specify iteration count for salt+password hashing --------------------------------------------------------------------- Key: JBSEAM-3763 URL: https://jira.jboss.org/jira/browse/JBSEAM-3763 Project: Seam Issue Type: Feature Request Components: Security Environment: Seam 2.1 Reporter: Nikolay Elenkov The current default implementation of password hashing hashes the salt and password only one time. Since having a number of iterations when generating the hash value is a generally accepted security practice (Cf. PKCS#5), it would be nice if one could specify the iteration count as a parameter to UserPassword. Suggestion: Add an 'iterationCount' attribute to the UserPassword annotation. Example usage: class User { @UserPassword(hash="sha1", iterationCount=1000) String getPasswordHash() {..} } -- 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

15 years, 8 months

2
5
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues January 2009