Re: [ANN] Welcome Thomas Andraschko as OpenWebBeans committer!
Congrats! 2012/9/13 Charles Moulliard ch0...@gmail.com Welcome onboard Joseph On Wed, Sep 12, 2012 at 8:34 PM, Joseph Bergmark bergm...@apache.org wrote: Welcome! On Wed, Sep 12, 2012 at 2:11 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Welcome Thomas! *Romain Manni-Bucau* *Twitter: @rmannibucau* *Blog: http://rmannibucau.wordpress.com* 2012/9/12 Mark Struberg strub...@yahoo.de Hi community! I'm happy to announce that Thomas will help us with making OWB even better. He is an expert on passivation and clustering and uses OWB in production for a few projects. Welcome Thomas! The Apache OpenWebBeans PMC -- Charles Moulliard Apache Committer / Sr. Pr. Consultant at FuseSource.com Twitter : @cmoulliard Blog : http://cmoulliard.blogspot.com
Re: Fw: [DISCUSS] release OWB-1.1.6 end of this week?
Hi, I would like to make some tests (and may be optimization) on OWB-703 before the release. I can do that tomorrow. When do you want to start the release? (Not before Friday evening?) Regards, Udo Am 12.09.12 20:03, schrieb Mark Struberg: 2nd try as my previous got eaten by the spam filter :/ - Forwarded Message - From: Mark Struberg strub...@yahoo.de To: openwebbeans-dev dev@openwebbeans.apache.org Sent: Wednesday, September 12, 2012 7:49 PM Subject: [DISCUSS] releaese OWB-1.1.6 end of this week? Hi folks! I would like to start with a hot-fix release of OWB (version 1.1.6) end of this week. Thomas, is this an ok timeframe in which you can fix the issues you needed for your production? LIeGrue, strub
[jira] [Updated] (OWB-703) getBeans cache key algorithm must be unique
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil updated OWB-703: Attachment: OWB-703-hash-cache-as-integer.patch The cached hash should be an Integer, instead of int (see OWB-703-hash-cache-as-integer.patch) getBeans cache key algorithm must be unique --- Key: OWB-703 URL: https://issues.apache.org/jira/browse/OWB-703 Project: OpenWebBeans Issue Type: Bug Affects Versions: 1.1.4, 1.1.5 Environment: OWB 1.1.4, Codi 1.0.5, MyFaces 2.0.13, Tobago 1.5.7 Reporter: Udo Schnurpfeil Assignee: Mark Struberg Priority: Critical Fix For: 1.1.6 Attachments: OWB-703-hash-cache-as-integer.patch, owb-703.patch Our application was tested in a Pre-Production environment, and it turns out a problem which occurs sometime after 2 weeks but sometimes after a short time: [9/11/12 10:46:27:288 CEST] 009e ServletWrappe E SRVE0068E: Uncaught exception thrown in one of the service methods of the servlet: FacesServlet. Exception thrown : java.lang.IllegalArgumentException: Given bean type : class org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.ViewAccessConversationExpirationEvaluatorRegistry is not applicable for the bean instance : BereitstellungModelLoaderImpl, Name:BereitstellungModelLoader, WebBeans Type:MANAGED, API Types:[java.lang.Object,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoader,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoaderImpl,java.io.Serializable], Qualifiers:[javax.inject.Named,javax.enterprise.inject.Any,javax.enterprise.inject.Default] at org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:923) at org.apache.webbeans.container.InjectableBeanManager.getReference(InjectableBeanManager.java:133) at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReference(CodiUtils.java:215) at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:179) at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:139) at org.apache.myfaces.extensions.cdi.jsf.impl.util.ConversationUtils.postRenderCleanup(ConversationUtils.java:668) at org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.render(CodiLifecycleWrapper.java:128) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1213) [...] I think the reason is, that two objects got the same key in the map. So we got wrong objects. After this exception the application must be restarted, no request works anymore. How can this happen? Problem number 1: Looking in the implementation: There will be computed a key of type Long from all given parameters. Parameters: injectionPointType, bdaBeansXMLPath, qualifiers In practice we have one injectionPointType (say t) and one qualifiers (say q) and the computed hash code will be: key = hash(t) + 29 * hash(q) assume: hash(t)=1000 and hash(q)=100 we got a key of 1000 + 29 * 100 = 3900 but that's the same like 1029 + 29 * 99 = 3900 1058 + 29 * 98 = 3900 1087 + 29 * 97 = 3900 and so on. If we got parameter with hash(t)=1029 and hash(q)=99 we have found 2 beans with the same key. With that our map is broken, because the 2nd bean will remove the 1st bean while adding (with the same key). Problem number 2: Hash codes are generally not suitable to be used as keys because there are not unique. The JavaDoc of the Object.hashCode() method says: It is not required that if two objects are unequal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. The strings org.apache.kcmdjx and java.lang.Object have the same hash code (at least in my Apple java VM). Solution: I see 3 solutions here: Solution 1: Do the same like in 1.1.3: Build a String with all information inside. Disadvantage: slow Solution 2: Create an helper object, which contains the unconverted information analog to e.g.: org.apache.myfaces.tobago.internal.context.ClientPropertiesKey This will be faster than string concatenation, but there is to create an object as well. Solution 3: Using a map which can handle more than one key. E. g. org.apache.commons.collections.map.MultiKeyMap -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OWB-703) getBeans cache key algorithm must be unique
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454702#comment-13454702 ] Romain Manni-Bucau commented on OWB-703: we could use Integer.MAX_VALUE (or min_value) as a marker too i think getBeans cache key algorithm must be unique --- Key: OWB-703 URL: https://issues.apache.org/jira/browse/OWB-703 Project: OpenWebBeans Issue Type: Bug Affects Versions: 1.1.4, 1.1.5 Environment: OWB 1.1.4, Codi 1.0.5, MyFaces 2.0.13, Tobago 1.5.7 Reporter: Udo Schnurpfeil Assignee: Mark Struberg Priority: Critical Fix For: 1.1.6 Attachments: OWB-703-hash-cache-as-integer.patch, owb-703.patch Our application was tested in a Pre-Production environment, and it turns out a problem which occurs sometime after 2 weeks but sometimes after a short time: [9/11/12 10:46:27:288 CEST] 009e ServletWrappe E SRVE0068E: Uncaught exception thrown in one of the service methods of the servlet: FacesServlet. Exception thrown : java.lang.IllegalArgumentException: Given bean type : class org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.ViewAccessConversationExpirationEvaluatorRegistry is not applicable for the bean instance : BereitstellungModelLoaderImpl, Name:BereitstellungModelLoader, WebBeans Type:MANAGED, API Types:[java.lang.Object,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoader,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoaderImpl,java.io.Serializable], Qualifiers:[javax.inject.Named,javax.enterprise.inject.Any,javax.enterprise.inject.Default] at org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:923) at org.apache.webbeans.container.InjectableBeanManager.getReference(InjectableBeanManager.java:133) at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReference(CodiUtils.java:215) at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:179) at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:139) at org.apache.myfaces.extensions.cdi.jsf.impl.util.ConversationUtils.postRenderCleanup(ConversationUtils.java:668) at org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.render(CodiLifecycleWrapper.java:128) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1213) [...] I think the reason is, that two objects got the same key in the map. So we got wrong objects. After this exception the application must be restarted, no request works anymore. How can this happen? Problem number 1: Looking in the implementation: There will be computed a key of type Long from all given parameters. Parameters: injectionPointType, bdaBeansXMLPath, qualifiers In practice we have one injectionPointType (say t) and one qualifiers (say q) and the computed hash code will be: key = hash(t) + 29 * hash(q) assume: hash(t)=1000 and hash(q)=100 we got a key of 1000 + 29 * 100 = 3900 but that's the same like 1029 + 29 * 99 = 3900 1058 + 29 * 98 = 3900 1087 + 29 * 97 = 3900 and so on. If we got parameter with hash(t)=1029 and hash(q)=99 we have found 2 beans with the same key. With that our map is broken, because the 2nd bean will remove the 1st bean while adding (with the same key). Problem number 2: Hash codes are generally not suitable to be used as keys because there are not unique. The JavaDoc of the Object.hashCode() method says: It is not required that if two objects are unequal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. The strings org.apache.kcmdjx and java.lang.Object have the same hash code (at least in my Apple java VM). Solution: I see 3 solutions here: Solution 1: Do the same like in 1.1.3: Build a String with all information inside. Disadvantage: slow Solution 2: Create an helper object, which contains the unconverted information analog to e.g.: org.apache.myfaces.tobago.internal.context.ClientPropertiesKey This will be faster than string concatenation, but there is to create an object as well. Solution 3: Using a map which can handle more than one key. E. g. org.apache.commons.collections.map.MultiKeyMap -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OWB-703) getBeans cache key algorithm must be unique
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454705#comment-13454705 ] Udo Schnurpfeil commented on OWB-703: - No! Every int value is a valid hash code. getBeans cache key algorithm must be unique --- Key: OWB-703 URL: https://issues.apache.org/jira/browse/OWB-703 Project: OpenWebBeans Issue Type: Bug Affects Versions: 1.1.4, 1.1.5 Environment: OWB 1.1.4, Codi 1.0.5, MyFaces 2.0.13, Tobago 1.5.7 Reporter: Udo Schnurpfeil Assignee: Mark Struberg Priority: Critical Fix For: 1.1.6 Attachments: OWB-703-hash-cache-as-integer.patch, owb-703.patch Our application was tested in a Pre-Production environment, and it turns out a problem which occurs sometime after 2 weeks but sometimes after a short time: [9/11/12 10:46:27:288 CEST] 009e ServletWrappe E SRVE0068E: Uncaught exception thrown in one of the service methods of the servlet: FacesServlet. Exception thrown : java.lang.IllegalArgumentException: Given bean type : class org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.ViewAccessConversationExpirationEvaluatorRegistry is not applicable for the bean instance : BereitstellungModelLoaderImpl, Name:BereitstellungModelLoader, WebBeans Type:MANAGED, API Types:[java.lang.Object,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoader,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoaderImpl,java.io.Serializable], Qualifiers:[javax.inject.Named,javax.enterprise.inject.Any,javax.enterprise.inject.Default] at org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:923) at org.apache.webbeans.container.InjectableBeanManager.getReference(InjectableBeanManager.java:133) at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReference(CodiUtils.java:215) at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:179) at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:139) at org.apache.myfaces.extensions.cdi.jsf.impl.util.ConversationUtils.postRenderCleanup(ConversationUtils.java:668) at org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.render(CodiLifecycleWrapper.java:128) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1213) [...] I think the reason is, that two objects got the same key in the map. So we got wrong objects. After this exception the application must be restarted, no request works anymore. How can this happen? Problem number 1: Looking in the implementation: There will be computed a key of type Long from all given parameters. Parameters: injectionPointType, bdaBeansXMLPath, qualifiers In practice we have one injectionPointType (say t) and one qualifiers (say q) and the computed hash code will be: key = hash(t) + 29 * hash(q) assume: hash(t)=1000 and hash(q)=100 we got a key of 1000 + 29 * 100 = 3900 but that's the same like 1029 + 29 * 99 = 3900 1058 + 29 * 98 = 3900 1087 + 29 * 97 = 3900 and so on. If we got parameter with hash(t)=1029 and hash(q)=99 we have found 2 beans with the same key. With that our map is broken, because the 2nd bean will remove the 1st bean while adding (with the same key). Problem number 2: Hash codes are generally not suitable to be used as keys because there are not unique. The JavaDoc of the Object.hashCode() method says: It is not required that if two objects are unequal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. The strings org.apache.kcmdjx and java.lang.Object have the same hash code (at least in my Apple java VM). Solution: I see 3 solutions here: Solution 1: Do the same like in 1.1.3: Build a String with all information inside. Disadvantage: slow Solution 2: Create an helper object, which contains the unconverted information analog to e.g.: org.apache.myfaces.tobago.internal.context.ClientPropertiesKey This will be faster than string concatenation, but there is to create an object as well. Solution 3: Using a map which can handle more than one key. E. g. org.apache.commons.collections.map.MultiKeyMap -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OWB-703) getBeans cache key algorithm must be unique
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454710#comment-13454710 ] Romain Manni-Bucau commented on OWB-703: you are right but well if you manage to get it ;)...but ok however why are we initializing the hashcode in lazy mode? we can do it in the constructor since we create this class to be used as a key in a map (concurrenthashmap), no? getBeans cache key algorithm must be unique --- Key: OWB-703 URL: https://issues.apache.org/jira/browse/OWB-703 Project: OpenWebBeans Issue Type: Bug Affects Versions: 1.1.4, 1.1.5 Environment: OWB 1.1.4, Codi 1.0.5, MyFaces 2.0.13, Tobago 1.5.7 Reporter: Udo Schnurpfeil Assignee: Mark Struberg Priority: Critical Fix For: 1.1.6 Attachments: OWB-703-hash-cache-as-integer.patch, owb-703.patch Our application was tested in a Pre-Production environment, and it turns out a problem which occurs sometime after 2 weeks but sometimes after a short time: [9/11/12 10:46:27:288 CEST] 009e ServletWrappe E SRVE0068E: Uncaught exception thrown in one of the service methods of the servlet: FacesServlet. Exception thrown : java.lang.IllegalArgumentException: Given bean type : class org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.ViewAccessConversationExpirationEvaluatorRegistry is not applicable for the bean instance : BereitstellungModelLoaderImpl, Name:BereitstellungModelLoader, WebBeans Type:MANAGED, API Types:[java.lang.Object,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoader,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoaderImpl,java.io.Serializable], Qualifiers:[javax.inject.Named,javax.enterprise.inject.Any,javax.enterprise.inject.Default] at org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:923) at org.apache.webbeans.container.InjectableBeanManager.getReference(InjectableBeanManager.java:133) at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReference(CodiUtils.java:215) at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:179) at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:139) at org.apache.myfaces.extensions.cdi.jsf.impl.util.ConversationUtils.postRenderCleanup(ConversationUtils.java:668) at org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.render(CodiLifecycleWrapper.java:128) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1213) [...] I think the reason is, that two objects got the same key in the map. So we got wrong objects. After this exception the application must be restarted, no request works anymore. How can this happen? Problem number 1: Looking in the implementation: There will be computed a key of type Long from all given parameters. Parameters: injectionPointType, bdaBeansXMLPath, qualifiers In practice we have one injectionPointType (say t) and one qualifiers (say q) and the computed hash code will be: key = hash(t) + 29 * hash(q) assume: hash(t)=1000 and hash(q)=100 we got a key of 1000 + 29 * 100 = 3900 but that's the same like 1029 + 29 * 99 = 3900 1058 + 29 * 98 = 3900 1087 + 29 * 97 = 3900 and so on. If we got parameter with hash(t)=1029 and hash(q)=99 we have found 2 beans with the same key. With that our map is broken, because the 2nd bean will remove the 1st bean while adding (with the same key). Problem number 2: Hash codes are generally not suitable to be used as keys because there are not unique. The JavaDoc of the Object.hashCode() method says: It is not required that if two objects are unequal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. The strings org.apache.kcmdjx and java.lang.Object have the same hash code (at least in my Apple java VM). Solution: I see 3 solutions here: Solution 1: Do the same like in 1.1.3: Build a String with all information inside. Disadvantage: slow Solution 2: Create an helper object, which contains the unconverted information analog to e.g.: org.apache.myfaces.tobago.internal.context.ClientPropertiesKey This will be faster than string concatenation, but there is to create an object as well. Solution 3: Using a map which can handle more than one key. E. g. org.apache.commons.collections.map.MultiKeyMap -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your
[jira] [Updated] (OWB-703) getBeans cache key algorithm must be unique
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Louis MONTEIRO updated OWB-703: Attachment: OWB-703-2nd-shoot.patch Here is another proposal getBeans cache key algorithm must be unique --- Key: OWB-703 URL: https://issues.apache.org/jira/browse/OWB-703 Project: OpenWebBeans Issue Type: Bug Affects Versions: 1.1.4, 1.1.5 Environment: OWB 1.1.4, Codi 1.0.5, MyFaces 2.0.13, Tobago 1.5.7 Reporter: Udo Schnurpfeil Assignee: Mark Struberg Priority: Critical Fix For: 1.1.6 Attachments: OWB-703-2nd-shoot.patch, OWB-703-hash-cache-as-integer.patch, owb-703.patch Our application was tested in a Pre-Production environment, and it turns out a problem which occurs sometime after 2 weeks but sometimes after a short time: [9/11/12 10:46:27:288 CEST] 009e ServletWrappe E SRVE0068E: Uncaught exception thrown in one of the service methods of the servlet: FacesServlet. Exception thrown : java.lang.IllegalArgumentException: Given bean type : class org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.ViewAccessConversationExpirationEvaluatorRegistry is not applicable for the bean instance : BereitstellungModelLoaderImpl, Name:BereitstellungModelLoader, WebBeans Type:MANAGED, API Types:[java.lang.Object,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoader,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoaderImpl,java.io.Serializable], Qualifiers:[javax.inject.Named,javax.enterprise.inject.Any,javax.enterprise.inject.Default] at org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:923) at org.apache.webbeans.container.InjectableBeanManager.getReference(InjectableBeanManager.java:133) at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReference(CodiUtils.java:215) at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:179) at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:139) at org.apache.myfaces.extensions.cdi.jsf.impl.util.ConversationUtils.postRenderCleanup(ConversationUtils.java:668) at org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.render(CodiLifecycleWrapper.java:128) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1213) [...] I think the reason is, that two objects got the same key in the map. So we got wrong objects. After this exception the application must be restarted, no request works anymore. How can this happen? Problem number 1: Looking in the implementation: There will be computed a key of type Long from all given parameters. Parameters: injectionPointType, bdaBeansXMLPath, qualifiers In practice we have one injectionPointType (say t) and one qualifiers (say q) and the computed hash code will be: key = hash(t) + 29 * hash(q) assume: hash(t)=1000 and hash(q)=100 we got a key of 1000 + 29 * 100 = 3900 but that's the same like 1029 + 29 * 99 = 3900 1058 + 29 * 98 = 3900 1087 + 29 * 97 = 3900 and so on. If we got parameter with hash(t)=1029 and hash(q)=99 we have found 2 beans with the same key. With that our map is broken, because the 2nd bean will remove the 1st bean while adding (with the same key). Problem number 2: Hash codes are generally not suitable to be used as keys because there are not unique. The JavaDoc of the Object.hashCode() method says: It is not required that if two objects are unequal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. The strings org.apache.kcmdjx and java.lang.Object have the same hash code (at least in my Apple java VM). Solution: I see 3 solutions here: Solution 1: Do the same like in 1.1.3: Build a String with all information inside. Disadvantage: slow Solution 2: Create an helper object, which contains the unconverted information analog to e.g.: org.apache.myfaces.tobago.internal.context.ClientPropertiesKey This will be faster than string concatenation, but there is to create an object as well. Solution 3: Using a map which can handle more than one key. E. g. org.apache.commons.collections.map.MultiKeyMap -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Fwd: [jira] [Updated] (OWB-703) getBeans cache key algorithm must be unique
May that can help. If someone wants to review it. Jean-Louis -- Forwarded message -- From: Jean-Louis MONTEIRO (JIRA) j...@apache.org Date: 2012/9/13 Subject: [jira] [Updated] (OWB-703) getBeans cache key algorithm must be unique To: dev@openwebbeans.apache.org [ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] Jean-Louis MONTEIRO updated OWB-703: Attachment: OWB-703-2nd-shoot.patch Here is another proposal getBeans cache key algorithm must be unique --- Key: OWB-703 URL: https://issues.apache.org/jira/browse/OWB-703 Project: OpenWebBeans Issue Type: Bug Affects Versions: 1.1.4, 1.1.5 Environment: OWB 1.1.4, Codi 1.0.5, MyFaces 2.0.13, Tobago 1.5.7 Reporter: Udo Schnurpfeil Assignee: Mark Struberg Priority: Critical Fix For: 1.1.6 Attachments: OWB-703-2nd-shoot.patch, OWB-703-hash-cache-as-integer.patch, owb-703.patch Our application was tested in a Pre-Production environment, and it turns out a problem which occurs sometime after 2 weeks but sometimes after a short time: [9/11/12 10:46:27:288 CEST] 009e ServletWrappe E SRVE0068E: Uncaught exception thrown in one of the service methods of the servlet: FacesServlet. Exception thrown : java.lang.IllegalArgumentException: Given bean type : class org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.ViewAccessConversationExpirationEvaluatorRegistry is not applicable for the bean instance : BereitstellungModelLoaderImpl, Name:BereitstellungModelLoader, WebBeans Type:MANAGED, API Types:[java.lang.Object,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoader,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoaderImpl,java.io.Serializable], Qualifiers:[javax.inject.Named,javax.enterprise.inject.Any,javax.enterprise.inject.Default] at org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:923) at org.apache.webbeans.container.InjectableBeanManager.getReference(InjectableBeanManager.java:133) at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReference(CodiUtils.java:215) at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:179) at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:139) at org.apache.myfaces.extensions.cdi.jsf.impl.util.ConversationUtils.postRenderCleanup(ConversationUtils.java:668) at org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.render(CodiLifecycleWrapper.java:128) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1213) [...] I think the reason is, that two objects got the same key in the map. So we got wrong objects. After this exception the application must be restarted, no request works anymore. How can this happen? Problem number 1: Looking in the implementation: There will be computed a key of type Long from all given parameters. Parameters: injectionPointType, bdaBeansXMLPath, qualifiers In practice we have one injectionPointType (say t) and one qualifiers (say q) and the computed hash code will be: key = hash(t) + 29 * hash(q) assume: hash(t)=1000 and hash(q)=100 we got a key of 1000 + 29 * 100 = 3900 but that's the same like 1029 + 29 * 99 = 3900 1058 + 29 * 98 = 3900 1087 + 29 * 97 = 3900 and so on. If we got parameter with hash(t)=1029 and hash(q)=99 we have found 2 beans with the same key. With that our map is broken, because the 2nd bean will remove the 1st bean while adding (with the same key). Problem number 2: Hash codes are generally not suitable to be used as keys because there are not unique. The JavaDoc of the Object.hashCode() method says: It is not required that if two objects are unequal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. The strings org.apache.kcmdjx and java.lang.Object have the same hash code (at least in my Apple java VM). Solution: I see 3 solutions here: Solution 1: Do the same like in 1.1.3: Build a String with all information inside. Disadvantage: slow Solution 2: Create an helper object, which contains the unconverted information analog to e.g.: org.apache.myfaces.tobago.internal.context.ClientPropertiesKey This will be faster than string concatenation, but there is to create an object as well. Solution 3: Using a map which can handle more than one key. E. g. org.apache.commons.collections.map.MultiKeyMap -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please
[jira] [Commented] (OWB-703) getBeans cache key algorithm must be unique
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454735#comment-13454735 ] Udo Schnurpfeil commented on OWB-703: - Computing the hash code in the constructor is a good idea for this class! The code is thread save automatically. But I would keep the hash code computation in a separate method to keep the code clean and comprehensible. getBeans cache key algorithm must be unique --- Key: OWB-703 URL: https://issues.apache.org/jira/browse/OWB-703 Project: OpenWebBeans Issue Type: Bug Affects Versions: 1.1.4, 1.1.5 Environment: OWB 1.1.4, Codi 1.0.5, MyFaces 2.0.13, Tobago 1.5.7 Reporter: Udo Schnurpfeil Assignee: Mark Struberg Priority: Critical Fix For: 1.1.6 Attachments: OWB-703-2nd-shoot.patch, OWB-703-hash-cache-as-integer.patch, owb-703.patch Our application was tested in a Pre-Production environment, and it turns out a problem which occurs sometime after 2 weeks but sometimes after a short time: [9/11/12 10:46:27:288 CEST] 009e ServletWrappe E SRVE0068E: Uncaught exception thrown in one of the service methods of the servlet: FacesServlet. Exception thrown : java.lang.IllegalArgumentException: Given bean type : class org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.ViewAccessConversationExpirationEvaluatorRegistry is not applicable for the bean instance : BereitstellungModelLoaderImpl, Name:BereitstellungModelLoader, WebBeans Type:MANAGED, API Types:[java.lang.Object,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoader,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoaderImpl,java.io.Serializable], Qualifiers:[javax.inject.Named,javax.enterprise.inject.Any,javax.enterprise.inject.Default] at org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:923) at org.apache.webbeans.container.InjectableBeanManager.getReference(InjectableBeanManager.java:133) at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReference(CodiUtils.java:215) at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:179) at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:139) at org.apache.myfaces.extensions.cdi.jsf.impl.util.ConversationUtils.postRenderCleanup(ConversationUtils.java:668) at org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.render(CodiLifecycleWrapper.java:128) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1213) [...] I think the reason is, that two objects got the same key in the map. So we got wrong objects. After this exception the application must be restarted, no request works anymore. How can this happen? Problem number 1: Looking in the implementation: There will be computed a key of type Long from all given parameters. Parameters: injectionPointType, bdaBeansXMLPath, qualifiers In practice we have one injectionPointType (say t) and one qualifiers (say q) and the computed hash code will be: key = hash(t) + 29 * hash(q) assume: hash(t)=1000 and hash(q)=100 we got a key of 1000 + 29 * 100 = 3900 but that's the same like 1029 + 29 * 99 = 3900 1058 + 29 * 98 = 3900 1087 + 29 * 97 = 3900 and so on. If we got parameter with hash(t)=1029 and hash(q)=99 we have found 2 beans with the same key. With that our map is broken, because the 2nd bean will remove the 1st bean while adding (with the same key). Problem number 2: Hash codes are generally not suitable to be used as keys because there are not unique. The JavaDoc of the Object.hashCode() method says: It is not required that if two objects are unequal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. The strings org.apache.kcmdjx and java.lang.Object have the same hash code (at least in my Apple java VM). Solution: I see 3 solutions here: Solution 1: Do the same like in 1.1.3: Build a String with all information inside. Disadvantage: slow Solution 2: Create an helper object, which contains the unconverted information analog to e.g.: org.apache.myfaces.tobago.internal.context.ClientPropertiesKey This will be faster than string concatenation, but there is to create an object as well. Solution 3: Using a map which can handle more than one key. E. g. org.apache.commons.collections.map.MultiKeyMap -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please
[jira] [Commented] (OWB-703) getBeans cache key algorithm must be unique
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454750#comment-13454750 ] Jean-Louis MONTEIRO commented on OWB-703: - Ok will do that and submit a new refactored patch getBeans cache key algorithm must be unique --- Key: OWB-703 URL: https://issues.apache.org/jira/browse/OWB-703 Project: OpenWebBeans Issue Type: Bug Affects Versions: 1.1.4, 1.1.5 Environment: OWB 1.1.4, Codi 1.0.5, MyFaces 2.0.13, Tobago 1.5.7 Reporter: Udo Schnurpfeil Assignee: Mark Struberg Priority: Critical Fix For: 1.1.6 Attachments: OWB-703-2nd-shoot.patch, OWB-703-hash-cache-as-integer.patch, owb-703.patch Our application was tested in a Pre-Production environment, and it turns out a problem which occurs sometime after 2 weeks but sometimes after a short time: [9/11/12 10:46:27:288 CEST] 009e ServletWrappe E SRVE0068E: Uncaught exception thrown in one of the service methods of the servlet: FacesServlet. Exception thrown : java.lang.IllegalArgumentException: Given bean type : class org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.ViewAccessConversationExpirationEvaluatorRegistry is not applicable for the bean instance : BereitstellungModelLoaderImpl, Name:BereitstellungModelLoader, WebBeans Type:MANAGED, API Types:[java.lang.Object,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoader,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoaderImpl,java.io.Serializable], Qualifiers:[javax.inject.Named,javax.enterprise.inject.Any,javax.enterprise.inject.Default] at org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:923) at org.apache.webbeans.container.InjectableBeanManager.getReference(InjectableBeanManager.java:133) at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReference(CodiUtils.java:215) at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:179) at org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:139) at org.apache.myfaces.extensions.cdi.jsf.impl.util.ConversationUtils.postRenderCleanup(ConversationUtils.java:668) at org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.render(CodiLifecycleWrapper.java:128) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1213) [...] I think the reason is, that two objects got the same key in the map. So we got wrong objects. After this exception the application must be restarted, no request works anymore. How can this happen? Problem number 1: Looking in the implementation: There will be computed a key of type Long from all given parameters. Parameters: injectionPointType, bdaBeansXMLPath, qualifiers In practice we have one injectionPointType (say t) and one qualifiers (say q) and the computed hash code will be: key = hash(t) + 29 * hash(q) assume: hash(t)=1000 and hash(q)=100 we got a key of 1000 + 29 * 100 = 3900 but that's the same like 1029 + 29 * 99 = 3900 1058 + 29 * 98 = 3900 1087 + 29 * 97 = 3900 and so on. If we got parameter with hash(t)=1029 and hash(q)=99 we have found 2 beans with the same key. With that our map is broken, because the 2nd bean will remove the 1st bean while adding (with the same key). Problem number 2: Hash codes are generally not suitable to be used as keys because there are not unique. The JavaDoc of the Object.hashCode() method says: It is not required that if two objects are unequal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. The strings org.apache.kcmdjx and java.lang.Object have the same hash code (at least in my Apple java VM). Solution: I see 3 solutions here: Solution 1: Do the same like in 1.1.3: Build a String with all information inside. Disadvantage: slow Solution 2: Create an helper object, which contains the unconverted information analog to e.g.: org.apache.myfaces.tobago.internal.context.ClientPropertiesKey This will be faster than string concatenation, but there is to create an object as well. Solution 3: Using a map which can handle more than one key. E. g. org.apache.commons.collections.map.MultiKeyMap -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
