[jira] [Updated] (OWB-703) getBeans cache key algorithm must be unique

2012-09-14 Thread Jean-Louis MONTEIRO (JIRA)

 [ 
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-refactored.diff

Here is the version a bit refactored as suggested.
Jean-Louis

 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, OWB-703-refactored.diff


 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

2012-09-14 Thread Mark Struberg (JIRA)

[ 
https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13455786#comment-13455786
 ] 

Mark Struberg commented on OWB-703:
---

looks good, please commit it Jean-Louis!


 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, OWB-703-refactored.diff


 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

2012-09-14 Thread Jean-Louis MONTEIRO (JIRA)

[ 
https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13455809#comment-13455809
 ] 

Jean-Louis MONTEIRO commented on OWB-703:
-

Apologise, but I can't (not a committer, then no write access I guess).

 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, OWB-703-refactored.diff


 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] [Updated] (OWB-703) getBeans cache key algorithm must be unique

2012-09-14 Thread Udo Schnurpfeil (JIRA)

 [ 
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-ordering-and-other-fixes.patch

I've made some changes and bug fixes to the BeanCacheKey class.
Also I've added 18 Unit-Tests. 11 tests are failing with the current version, 
that sounds much, but that are very rare situations.

Important changes:
 - if there are more than one qualifier, the order of the qualifiers doesn't 
influence the hashCode() and equals() result.
 - the equals() method now ignores the Nonbinding members of the qualifiers.
 - the computedHashCode() didn't use the a single qualifier, now it does.
 - the getQualifierHashCode() method in case of an long[] member, has tried to 
cast it to a Long[], but this would provoke a RuntimeException: fixed.
 - the some as above for all other primary array types.
 - the getQualifierHashCode() method must not use the qualifiers default 
hashCode() method, otherwise the Nonbinding will not ignored: fixed.
 - adding a inner class AnnotationComparator to solve the ordering issue, above.

Other changes:
 - making the fields final.
 - using final on some other places.
 - toString() method for debugging.
 - some comments and other changes.


 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-ordering-and-other-fixes.patch, 
 owb-703.patch, OWB-703-refactored.diff


 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