[
https://issues.apache.org/jira/browse/LABS-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632012#action_12632012
]
Simone Gianni commented on LABS-161:
------------------------------------
The algorithm should be this :
* Given that we have an abstraction layer to java.lang.reflect.Method and
relative classes around it
* When we find a method which is a bridge (.isBridge())
o Take the classes of its parameters
o Search for a method with the same signature in the superclass
o Find the markers for generics, and replace them in the signature
+ So suppose the signature becomes doSomething(int, T, V,
Object)
o Now get the generic superclass definition
+ Suppose it is extends MySuper?<Fish, Cat>
o Now get the markers for generics on the superclass
+ Suppose they are MySuper?<T,V>
o Now replace in the signature
+ So the signature is doSomething(int, Fish, Cat, Object)
o If we managed to resolve all markers, we have the method
There are a number of places where recursion could take place. I suppose that :
* MySuper? could be itself an extension of MyUltraSuper?<T,V,C> specifying
only C. In that case however, MyUltraSuper? either redefined methods, or left
them as bridges (second case).
* The super method could be a bridge itself, in that case we should recurse
up.
> 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]
