[
https://issues.apache.org/jira/browse/LUCENE-6651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14612526#comment-14612526
]
ASF subversion and git services commented on LUCENE-6651:
---------------------------------------------------------
Commit 1688913 from [~thetaphi] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1688913 ]
LUCENE-6651: Remove test completely: Cannot work (inner doPrivileged reverts
back to codebase granted permissions; no idea why it worked for me)
> Remove private field reflection (setAccessible) in AttributeImpl#reflectWith
> ----------------------------------------------------------------------------
>
> Key: LUCENE-6651
> URL: https://issues.apache.org/jira/browse/LUCENE-6651
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/other
> Affects Versions: 5.2.1
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 5.3, Trunk
>
> Attachments: LUCENE-6651-5x.patch, LUCENE-6651-MethodHandles.patch,
> LUCENE-6651.patch, LUCENE-6651.patch
>
>
> In AttributeImpl we currently have a "default" implementation of reflectWith
> (which is used by toString() and other methods) that uses reflection to list
> all private fields of the implementation class and reports them to the
> AttributeReflector (used by Solr and Elasticsearch to show analysis output).
> Unfortunately this default implementation needs to access private fields of a
> subclass, which does not work without doing Field#setAccessible(true). And
> this is done without AccessController#doPrivileged()!
> There are 2 solutions to solve this:
> - Reimplement the whole thing with MethodHandles. MethodHandles allow to
> access private fields, if you have a MethodHandles.Lookup object created from
> inside the subclass. The idea is to add a protected constructor taking a
> Lookup object (must come from same class). This Lookup object is then used to
> build methodHandles that can be executed to report the fields. Backside: We
> have to require subclasses that want this "automatic" reflection to pass a
> Lookup object in ctor's {{super(MethodHandles.lookup())}} call. This breaks
> backwards for implementors of AttributeImpls
> - The second idea is to remove the whole reflectWith default impl and make
> the method abstract. This would require a bit more work in tons of
> AttributeImpl classes, but you already have to implement something like this
> for equals/hashCode, so its just listing all fields. This would of couse
> break backwards, too. So my plan would be to implement the missing methods
> everywhere (as if it were abstract), but keep the default implementation in
> 5.x. We just would do AccessController.doPrivileged().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
