jaxb
  1. jaxb
  2. JAXB-134

Schema generation dies on subclasses of java.util.Date

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0 EA1
    • Fix Version/s: not determined
    • Component/s: spec
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: PC

      Description

      When a subclass of java.util.Date has to be mapped to XML, apt dies in round 2
      with the following error:

      [apt] Problem encountered during annotation processing;
      [apt] see stacktrace below for more information.
      [apt] java.lang.ClassCastException:
      com.sun.xml.bind.v2.model.impl.BuiltinLeafInfoImpl
      [apt] at
      com.sun.xml.bind.v2.model.impl.ClassInfoImpl.getBaseClass(ClassInfoImpl.java:170)
      [apt] at
      com.sun.xml.bind.v2.model.impl.ModelBuilder.getClassInfo(ModelBuilder.java:142)
      [apt] at
      com.sun.xml.bind.v2.model.impl.ModelBuilder.getTypeInfo(ModelBuilder.java:189)
      [apt] at
      com.sun.xml.bind.v2.model.impl.TypeRefImpl.calcRef(TypeRefImpl.java:56)
      [apt] at
      com.sun.xml.bind.v2.model.impl.TypeRefImpl.getTarget(TypeRefImpl.java:33)
      [apt] at
      com.sun.xml.bind.v2.model.impl.ElementPropertyInfoImpl$1.get(ElementPropertyInfoImpl.java:38)
      [apt] at
      com.sun.xml.bind.v2.model.impl.ElementPropertyInfoImpl$1.get(ElementPropertyInfoImpl.java:41)
      [apt] at java.util.AbstractList$Itr.next(Unknown Source)
      [apt] at
      com.sun.xml.bind.v2.model.impl.ModelBuilder.getClassInfo(ModelBuilder.java:139)
      [apt] at
      com.sun.xml.bind.v2.model.impl.ModelBuilder.getTypeInfo(ModelBuilder.java:189)
      [apt] at
      com.sun.xml.bind.v2.model.impl.ModelBuilder.getTypeInfo(ModelBuilder.java:204)
      [apt] at
      com.sun.tools.xjc.api.impl.j2s.JavaCompilerImpl.bind(JavaCompilerImpl.java:54)
      [apt] at
      com.sun.tools.ws.processor.modeler.annotation.WebServiceAP.completeModel(WebServiceAP.java:395)
      [apt] at
      com.sun.tools.ws.processor.modeler.annotation.WebServiceAP.process(WebServiceAP.java:236)
      [apt] at
      com.sun.mirror.apt.AnnotationProcessors$CompositeAnnotationProcessor.process(AnnotationProcessors.java:60)
      [apt] at com.sun.tools.apt.comp.Apt.main(Apt.java:450)
      [apt] at
      com.sun.tools.apt.main.JavaCompiler.compile(JavaCompiler.java:458)
      [apt] at com.sun.tools.apt.main.Main.compile(Main.java:1075)
      [apt] at com.sun.tools.apt.main.Main.compile(Main.java:938)
      [apt] at com.sun.tools.apt.Main.processing(Main.java:95)
      [apt] at com.sun.tools.apt.Main.process(Main.java:43)
      [apt] at com.sun.tools.apt.Main.main(Main.java:34)

      The following class definitions should reproduce the error:

      ========== test/DateTime.java ==========
      package test;

      import java.util.Date;

      public class DateTime extends Date {
      public DateTime() {}
      }

      ========== test/Svc.java ==========
      package test;

      import javax.jws.*;

      @WebService public class Svc {
      @WebMethod public DateTime getDateTime()

      { return null; }

      }

        Activity

        Hide
        dtenev added a comment -

        Created an attachment (id=84)
        Test case

        Show
        dtenev added a comment - Created an attachment (id=84) Test case
        Hide
        kohsuke added a comment -

        Besides the lack of gracefull error handling in XJC, this is fundamentally a
        spec-level issue. It talks about how to handle an user bean that extends from
        another user bean, but it doesn't have a notion of how to handle an user bean
        extending from a built-in class.

        To fix the spec, I'd like to better understand what the use case is. I never saw
        anyone extending java.util.Date class. What do you do this for? What is the XML
        representation that you expect?

        Show
        kohsuke added a comment - Besides the lack of gracefull error handling in XJC, this is fundamentally a spec-level issue. It talks about how to handle an user bean that extends from another user bean, but it doesn't have a notion of how to handle an user bean extending from a built-in class. To fix the spec, I'd like to better understand what the use case is. I never saw anyone extending java.util.Date class. What do you do this for? What is the XML representation that you expect?
        Hide
        dtenev added a comment -

        The use-case is simple: a class is needed that is (locally)
        assignment-compatible with java.util.Date, with a bit of extra functionality on
        top of it. The extra functionality in question does not expose anything that
        qualifies as a bean field or property, so ultimately the sub-class should be
        visible as Date, with the only difference that values of the corresponding
        schema type must be mapped to and from instances of the sub-class.

        I am starting to see the trouble with handling extensions of special classes
        like Date in the presence of visible properties in the subclasses, but I believe
        that the case of purely functional extensions should be easy to handle. In the
        case of structural extensions (i.e. such that add structure in the way of
        visible bean properties or fields,) it would still make perfect sense to issue a
        clear warning or error message to the effect that the mapping is undefined. Of
        course, mapping such classes through custom adapters should still be possible.

        Let me just point out that the notion of a "user bean extending from a built-in
        class" sounds a bit vague. From a particular point of view, whatever your bean,
        the extension chain will have to start somewhere, and chances are, the starting
        point will be a built-in class, that is, every bean extends a built-in class.
        It might be a good idea to reformulate this particular point.

        Show
        dtenev added a comment - The use-case is simple: a class is needed that is (locally) assignment-compatible with java.util.Date, with a bit of extra functionality on top of it. The extra functionality in question does not expose anything that qualifies as a bean field or property, so ultimately the sub-class should be visible as Date, with the only difference that values of the corresponding schema type must be mapped to and from instances of the sub-class. I am starting to see the trouble with handling extensions of special classes like Date in the presence of visible properties in the subclasses, but I believe that the case of purely functional extensions should be easy to handle. In the case of structural extensions (i.e. such that add structure in the way of visible bean properties or fields,) it would still make perfect sense to issue a clear warning or error message to the effect that the mapping is undefined. Of course, mapping such classes through custom adapters should still be possible. Let me just point out that the notion of a "user bean extending from a built-in class" sounds a bit vague. From a particular point of view, whatever your bean, the extension chain will have to start somewhere, and chances are, the starting point will be a built-in class, that is, every bean extends a built-in class. It might be a good idea to reformulate this particular point.
        Hide
        Martin Grebac added a comment -

        adding keyword

        Show
        Martin Grebac added a comment - adding keyword

          People

          • Assignee:
            Martin Grebac
            Reporter:
            dtenev
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: