You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by "Udo Schnurpfeil (JIRA)" <ji...@apache.org> on 2012/09/11 19:02:07 UTC
[jira] [Created] (OWB-703) getBeans cache key algorithm must be
unique
Udo Schnurpfeil created OWB-703:
-----------------------------------
Summary: 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.5, 1.1.4
Environment: OWB 1.1.4, Codi 1.0.5, MyFaces 2.0.13, Tobago 1.5.7
Reporter: Udo Schnurpfeil
Priority: Critical
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] 0000009e 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
Posted by Jean-Louis MONTEIRO <je...@gmail.com>.
May that can help.
If someone wants to review it.
Jean-Louis
---------- Forwarded message ----------
From: Jean-Louis MONTEIRO (JIRA) <ji...@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] 0000009e 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
Posted by "Joe Bergmark (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13456444#comment-13456444 ]
Joe Bergmark commented on OWB-703:
----------------------------------
For some reason when I applied your patch it dropped all the new test files in the root, and I blindly moved them all together without double checking the packages. I assumed that if I made a mistake a command line mvn compile would fail. Obviously I was wrong.
I've committed a new change that makes the package match the directory, as personally I'd rather keep the tests separate. As you suggested I also made BeanCacheKey public.
> 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] 0000009e 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
Posted by "Jean-Louis MONTEIRO (JIRA)" <ji...@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] 0000009e 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
Posted by "Udo Schnurpfeil (JIRA)" <ji...@apache.org>.
[ 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.patch
This patch implements solution 2.
> 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
> Priority: Critical
> Attachments: 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] 0000009e 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
Posted by "Udo Schnurpfeil (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] 0000009e 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
Posted by "Mark Struberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] 0000009e 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
Posted by "Udo Schnurpfeil (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453924#comment-13453924 ]
Udo Schnurpfeil commented on OWB-703:
-------------------------------------
Yes, its an IBM VM :-)
> 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
> Attachments: 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] 0000009e 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] [Assigned] (OWB-703) getBeans cache key algorithm must be
unique
Posted by "Mark Struberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Struberg reassigned OWB-703:
---------------------------------
Assignee: Mark Struberg
> 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
> Attachments: 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] 0000009e 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
Posted by "Romain Manni-Bucau (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] 0000009e 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] [Resolved] (OWB-703) getBeans cache key algorithm must be
unique
Posted by "Mark Struberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Struberg resolved OWB-703.
-------------------------------
Resolution: Fixed
Fix Version/s: 1.1.6
patch applied with slight tweaks. Thanks Udo!
I also did some performance tests and they look very good.
> 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.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] 0000009e 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
Posted by "Udo Schnurpfeil (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] 0000009e 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
Posted by "Joe Bergmark (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13456432#comment-13456432 ]
Joe Bergmark commented on OWB-703:
----------------------------------
I reviewed and committed the latest patch.
Mark, you might want to review from a performance perspective and run whatever testing you ran previously. I'll leave the JIRA issue assigned to you for now.
> 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] 0000009e 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
Posted by "Mark Struberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453817#comment-13453817 ]
Mark Struberg commented on OWB-703:
-----------------------------------
Thanks Udo, will look at the patch!
Just out of curiosity. This is an IBM JVM, right?
> 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
> Attachments: 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] 0000009e 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
Posted by "Romain Manni-Bucau (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] 0000009e 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
Posted by "Jean-Louis MONTEIRO (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] 0000009e 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
Posted by "Udo Schnurpfeil (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13456438#comment-13456438 ]
Udo Schnurpfeil commented on OWB-703:
-------------------------------------
Hmmm, the BeanCacheKeyUnitTest is in the wrong directory:
org/apache/webbeans/test/annotation/binding
but the package is
org.apache.webbeans.container;
The package and directory should be the same.
Changing the package makes it not longer compilable, thats the reason why I've put it in the other package. The BeanCacheKey, is not public.
Solution 1: make BeanCacheKEy public
Solution 2: move the BeanCacheKeyUnitTest back to its original package
I don't know what OWB usually do in this case, but seems solution 1.
> 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] 0000009e 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
Posted by "Jean-Louis MONTEIRO (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] 0000009e 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
Posted by "Udo Schnurpfeil (JIRA)" <ji...@apache.org>.
[ 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] 0000009e 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
Posted by "Udo Schnurpfeil (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13456972#comment-13456972 ]
Udo Schnurpfeil commented on OWB-703:
-------------------------------------
I've just executed the unit tests on a IBM JVM successfully.
> 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] 0000009e 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
Posted by "Jean-Louis MONTEIRO (JIRA)" <ji...@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-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] 0000009e 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
Posted by "Udo Schnurpfeil (JIRA)" <ji...@apache.org>.
[ 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] 0000009e 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
Posted by "Udo Schnurpfeil (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453233#comment-13453233 ]
Udo Schnurpfeil commented on OWB-703:
-------------------------------------
By the way: Is it guarantied, that the order of the qualifiers are always the same? If not, the implementation have to consider that (1.1.3 doesn't).
> 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
> Priority: Critical
>
> 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] 0000009e 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