Wicket
  1. Wicket
  2. WICKET-4414

ConverterLocator should support proxied classes

    Details

    • Type: Wish Wish
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 1.5.3, 1.5.4
    • Fix Version/s: None
    • Component/s: wicket
    • Labels:
      None
    • Environment:
      Not relevant.

      Description

      It would be nice if Wicket's default implementation of IConverter would work with proxied classes. The current implementation uses Class#getName() to locate registered classes, and it will therefore not work with enhanced classes.

      1. WICKET-4414.patch
        14 kB
        Martin Grigorov

        Activity

        Hide
        Martin Grigorov added a comment -

        Is this what you need ?

        Show
        Martin Grigorov added a comment - Is this what you need ?
        Hide
        Andre L added a comment - - edited

        The patch/test seems to work for JDK based proxies, but will it also work for for cglib/javaassist enhanced classes that you typically get from JPA relations that are configured to be lazy-loaded?

        Example:
        class Person

        { @ManyToOne(fetch = FetchType.LAZY...) Address address; }

        class Address {
        }

        Person person = a person instance loaded from a JPA EntityManager
        converterLocator.set(Address.class, ...)
        converterLocator.getConverter(person.getAddress().getClass()) //This fails as the name of the Addess class will be something like Address<javassist/EnhancerByCGLIB>.class

        A PersonAddress class that inherits Address would neither match Address since the class name is used as key in the classToConverter registry, but that is another question, should inherited classes be supported by the locator or registered explicitly? If the internal registry classToConverter used Class as a key the ConverterLocator#getConverter() could support both enhanced and inherited classes (if that is wanted).

        Show
        Andre L added a comment - - edited The patch/test seems to work for JDK based proxies, but will it also work for for cglib/javaassist enhanced classes that you typically get from JPA relations that are configured to be lazy-loaded? Example: class Person { @ManyToOne(fetch = FetchType.LAZY...) Address address; } class Address { } Person person = a person instance loaded from a JPA EntityManager converterLocator.set(Address.class, ...) converterLocator.getConverter(person.getAddress().getClass()) //This fails as the name of the Addess class will be something like Address<javassist/EnhancerByCGLIB>.class A PersonAddress class that inherits Address would neither match Address since the class name is used as key in the classToConverter registry, but that is another question, should inherited classes be supported by the locator or registered explicitly? If the internal registry classToConverter used Class as a key the ConverterLocator#getConverter() could support both enhanced and inherited classes (if that is wanted).
        Hide
        Martin Grigorov added a comment -

        I'm sorry but wicket-core should not depend on CGLIB, Javassist. ASM, ...
        You can always roll your own ConverterLocator and replace the default one.

        Show
        Martin Grigorov added a comment - I'm sorry but wicket-core should not depend on CGLIB, Javassist. ASM, ... You can always roll your own ConverterLocator and replace the default one.
        Hide
        Martin Grigorov added a comment -

        Closing as "Won't Fix" because the JDK proxies don't help much, wicket-core should not depend on CGLIB just for this minor functionality and the fact that it is quite easy to extend the default ConverterLocator and add the needed logic.

        Show
        Martin Grigorov added a comment - Closing as "Won't Fix" because the JDK proxies don't help much, wicket-core should not depend on CGLIB just for this minor functionality and the fact that it is quite easy to extend the default ConverterLocator and add the needed logic.

          People

          • Assignee:
            Martin Grigorov
            Reporter:
            Andre L
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development