[ 
https://issues.apache.org/jira/browse/LABS-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632013#action_12632013
 ] 

Simone Gianni commented on LABS-161:
------------------------------------

Also see : http://www.ibm.com/developerworks/library/j-cwt11085.html

> WEB : Wise reflection for generic handlers
> ------------------------------------------
>
>                 Key: LABS-161
>                 URL: https://issues.apache.org/jira/browse/LABS-161
>             Project: Labs
>          Issue Type: Improvement
>          Components: Magma
>            Reporter: Simone Gianni
>            Assignee: Simone Gianni
>
> It would be nice to be able to define generic web handler and generic beans, 
> the define non generic subclasses, and have Magma behave correctly with them.
> Magma uses reflection/introspection to determine data types in a number of 
> situations :
>     * Examining the type of properties in a bean to setup proper conversion
>     * Examining the parameters of a do or handle method in a webhandler to 
> perform proper conversion 
> If a generic handler is defined, and then a non generic but parametrized 
> subclass is defined, this subclass is, formally, using concrete classes and 
> not generics.
> Suppose the following :
> public class DisplayingBeanHandler<T> extends WebHandler {
>   public HtmlProducer doShow(T bean) {
>     ...
>   }
> }
> public class DisplayPersonHandler extends DisplayingBeanHandler<Person> {}
> DisplayPersonHandler? has a doShow(Person) method, at any effect.
> Unfortunately, to keep compatibility, the Java compiler will instead create a 
> synthetic method based on Object :
> public class DisplayPersonHandler extends DisplayingBeanHandler<Person> {
>   // Injected by compiler
>   public HtmlProducer doShow(Object bean) {
>     super.doShow((Person)bean);
>   }
> }
> While this ensures proper checks, reflection will see this method as using 
> Object, so Magma will not know what to convert it to.
> Where this happen, Magma has to correctly check for generics, and behave 
> correctly.
> Since there are many places (and many more in the future) requiring this kind 
> of functionality, a small "library" should be created to ease this pain. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to