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

Thiago H. de Paula Figueiredo edited comment on TAP5-2560 at 1/9/19 11:59 AM:
------------------------------------------------------------------------------

Hello, [~chrispoulsen]!

Thank you very much! I guess the mailing list server threw away the attachment.

By the way, would it be possible for you to test your code with the fix linked 
above instead of your Guava-based GenericUtils version? I used the code you 
posted in this ticket as the test (not yet written as a proper unit test yet), 
creating a BeanModel for FileContentUnit and then calling 
{{beanModel.add("content.mimeType")}}. It used to throw an exception before the 
fix, and now it doesn't anymore. The {{resolve(T, FileContentUnit.class)}} call 
is now returning BinaryContent instead of ContentData.

The fix was using Class.getGenericInterfaces() in addition to 
Class.getGenericSuperclasses() when trying to find the bound value of a type 
parameter. 

As much as it would be nice to not have to maintain generic reflection code in 
Tapestry itself, introducing another dependency is something I'm trying to 
avoid as long as we manage to fix the issue in a reasonable time (i.e. not 
delaying the 5.5.0 release).


was (Author: thiagohp):
Hello, [~chrispoulsen]!

Thank you very much! I guess the mailing list server threw away the attachment.

By the way, would it be possible for you to test your code with the fix linked 
above instead of your Guava-based GenericUtils version? I used the code you 
posted in this ticket as the test (not yet written as a proper unit test yet), 
creating a BeanModel for FileContentUnit and then calling 
{{beanModel.add("content.mimeType")}}. It used to throw an exception before the 
fix, and now it doesn't anymore.

As much as it would be nice to not have to maintain generic reflection code in 
Tapestry itself, introducing another dependency is something I'm trying to 
avoid as long as we manage to fix the issue in a reasonable time (i.e. not 
delaying the 5.5.0 release).

> Error in GenericsUtils affecting property access
> ------------------------------------------------
>
>                 Key: TAP5-2560
>                 URL: https://issues.apache.org/jira/browse/TAP5-2560
>             Project: Tapestry 5
>          Issue Type: Bug
>    Affects Versions: 5.4.1
>            Reporter: Chris Poulsen
>            Assignee: Thiago H. de Paula Figueiredo
>            Priority: Major
>         Attachments: generics-utils.patch
>
>
> There is an error somewhere in the GenericsUtils.resolve( TypeVariable 
> typeVariable, Type containingType ) method.
> It resolves some type variables to their lower bound instead of the correct 
> version.
> We have model classes that uses lots of generics and in some cases tapestry 
> reports that a given property expression is invalid because some lower bound 
> interface does not contain the property in the expression.
> I tried to see if I could find an easy fix, but ended up running out of time 
> and simply replaced the bodies of the 5 resolution methods in the 
> GenericsUtils with guava reflect code and then things started working as 
> expected.
> The interface setup that gives the error looks like this:
> {code}
> public interface NonTranslatableContentUnit<T extends ContentData> {
>     T getContent();
> }
> public interface BinaryContentUnit<T extends BinaryContent> extends 
> NonTranslatableContentUnit<T> {}
> public interface FileContentUnit extends BinaryContentUnit<FileContent> {}
> public interface ContentData {
>     isEmpty();
>     ...
> }
> public interface BinaryContent extends ContentData {
>     String getMimeType();
>     ...
> }   
> public interface FileContent extends BinaryContent {}
> {code}
> Then we have a property expression on a FileContentUnit like: 
> "content.mimeType" and that fails with an error that says something like 
> ContentData does not have a property MimeType.
> As far as I can tell the resolve(TypeVariable, ..) method fails to do 
> anything sensible if the Type of the "containing class" is not an instance of 
> ParameterizedType



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to