DWR

Classmapping and converter ordering

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 3.0.RC2
  • Fix Version/s: 3.0.RC3
  • Component/s: Converters
  • Documentation Required:
    No
  • Description:
    Hide
    Please see:
    ExceptionConverter for java.lang.Exception is not working in DWR 3

    From the DWR users mailing list:

    theonix wrote:
    In DWR 2.0.3 I could have:
    <convert converter="exception" match="...cardorder.exceptions.InvalidTopupAmountException"></convert>
    <convert converter="exception" match="java.lang.Exception" javascript="AjaxException"></convert>
    where the converter for java.lang.Exception is after InvalidTopupAmountException.
    This doesn't work in DWR 3.0, because now the order matters. So the converter for java.lang.Exception have to be before any other exception converter.
    I changed the order in my dwr.xml and it works perfectly.

    mikewse wrote:
    I think this quirk only appears when you are using class-mapping (the javascript attribute) as that alters the order of converter lookup somewhat.
    Show
    Please see: ExceptionConverter for java.lang.Exception is not working in DWR 3 From the DWR users mailing list: theonix wrote: In DWR 2.0.3 I could have: <convert converter="exception" match="...cardorder.exceptions.InvalidTopupAmountException"></convert> <convert converter="exception" match="java.lang.Exception" javascript="AjaxException"></convert> where the converter for java.lang.Exception is after InvalidTopupAmountException. This doesn't work in DWR 3.0, because now the order matters. So the converter for java.lang.Exception have to be before any other exception converter. I changed the order in my dwr.xml and it works perfectly. mikewse wrote: I think this quirk only appears when you are using class-mapping (the javascript attribute) as that alters the order of converter lookup somewhat.

Activity

Hide
Mike Wilson added a comment - 11/Aug/11 4:51 AM

The problem was that class-mapped converters populate the converter cache before all converters have been registered during startup, leading to ordering dependencies. I have now implemented a fix that clears the converter cache when new converters are added.

Show
Mike Wilson added a comment - 11/Aug/11 4:51 AM The problem was that class-mapped converters populate the converter cache before all converters have been registered during startup, leading to ordering dependencies. I have now implemented a fix that clears the converter cache when new converters are added.

People

Dates

  • Created:
    09/Aug/11 4:14 PM
    Updated:
    11/Aug/11 4:51 AM
    Resolved:
    11/Aug/11 4:51 AM