struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "lwen.ma (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (WW-4113) Wrong cache key generated in OGNL 3.0.5/3.0.6
Date Fri, 07 Feb 2014 06:49:19 GMT

    [ https://issues.apache.org/jira/browse/WW-4113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894243#comment-13894243
] 

lwen.ma commented on WW-4113:
-----------------------------

[~lukaszlenart] Hi, We meet a bug with the new version 3.0.7. I have check the code's change,
which use className concat with the propertyName as cacheKey of a class's methed. 
It will trigger a bug when a class loaded by two different classloader, they has the same
cache key, but are different method.
We trigger the bug when we put ognl in jboss share lib, then hot redeploy a war compenent,
and find that parameters cannot be setted to struts action.


> Wrong cache key generated in OGNL 3.0.5/3.0.6
> ---------------------------------------------
>
>                 Key: WW-4113
>                 URL: https://issues.apache.org/jira/browse/WW-4113
>             Project: Struts 2
>          Issue Type: Bug
>          Components: Expression Language
>    Affects Versions: 2.3.4, 2.3.4.1, 2.3.7, 2.3.8, 2.3.12, 2.3.14, 2.3.14.1, 2.3.14.2,
2.3.14.3, 2.3.15
>            Reporter: Kevin Su
>            Assignee: Lukasz Lenart
>              Labels: patch
>             Fix For: 2.3.16
>
>
> Struts since 2.3.4 (maybe earlier as well) has dependency on ognl.OgnlRuntime 3.0.5 /
3.0.6.  OgnlRuntime 3.0.5/3.0.6 has a bug in the cache implementation to look up the getter
and setter methods.  The hashCode of the action class (in combination to the hashCode for
the name of the property) is used as a unique key into the cache of getter and setters.  
> Since hashCode can not be relied on to be unique, setting the property on the target
action class may fail because the wrong method from another action is returned.
> The latest implemenation of OgnlRuntime in Apache commons has the proper implementation.

> We are currently using our own patched version of 3.0.6 to work around the issue.  However,
we'll like to see this resolved so we don't need to maintain our own private version of Ognl.
 
> Is there a plan to migrate the dependency to the Apache commons distribution of Ognl?
If not, we'll be happy to share our fix.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message