castor
  1. castor
  2. CASTOR-1934

gened call to XMLFieldDescriptorImpl cnstr not using FQCN in some cases, perhaps from imported schema

    Details

    • Type: Bug Bug
    • Status: Reopened Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 1.3.4
    • Component/s: XML code generator
    • Labels:
      None
    • Testcase included:
      yes
    • Number of attachments :
      4

      Description

      Using snapshot 1.1.1-20070329.084439-9.

      I have a simple test case with two schemas, where one imports the other, and references an element defined in that schema. When I compile the code, I see the following exception:

      -----------------------
      .../wamu/xmlbinding/xx/descriptors/FooDescriptor.java:74: cannot resolve symbol
      symbol : class AccountProfile
      location: class wamu.xmlbinding.xx.descriptors.FooDescriptor
      desc = new org.exolab.castor.xml.util.XMLFieldDescriptorImpl(AccountProfile.class, "_accountProfile", "AccountProfile", org.exolab.castor.xml.NodeType.Element);
      -----------------------

      This compile error is happening because the reference of "AccountProfile.class" should be "wamu.xmlbinding.xx.AccountProfile.class". The class file exists, but it's not in the "descriptors" package, it's in the parent package.

      1. patch.c1934.20070430.txt
        1 kB
        Werner Guttmann

        Issue Links

          Activity

          Hide
          Werner Guttmann added a comment -

          Looking into CASTOR-1864 again, it looks like CASTOR-1934 will have to be committed as well, as the problem Mattthias is encountering is not related to including/importing XML schemas at all. Having said that, I appreciate your patience, and I still believe that it should be possible to avoid those unnecessary namespace to package mappings once I have committed CASTOR-1986 and CASTOR-1934. Let's see how things go ...

          Show
          Werner Guttmann added a comment - Looking into CASTOR-1864 again, it looks like CASTOR-1934 will have to be committed as well, as the problem Mattthias is encountering is not related to including/importing XML schemas at all. Having said that, I appreciate your patience, and I still believe that it should be possible to avoid those unnecessary namespace to package mappings once I have committed CASTOR-1986 and CASTOR-1934 . Let's see how things go ...
          Hide
          Werner Guttmann added a comment -

          As I am about to commit the latest patch to this issue, I wonder whether the test case could be broken down to something more minimal, as I'd like to enhance the CTF test suite.

          Show
          Werner Guttmann added a comment - As I am about to commit the latest patch to this issue, I wonder whether the test case could be broken down to something more minimal, as I'd like to enhance the CTF test suite.
          Hide
          Matthias Hanisch added a comment -

          Sorry, I can only follow all the Castor development sproadically. Today, I tried again to run the castor generation on my testbed.
          This patch is still needed, otherwise it still generates classes from imported schema.
          So - in short - the facts didn't change in the last three months.

          Show
          Matthias Hanisch added a comment - Sorry, I can only follow all the Castor development sproadically. Today, I tried again to run the castor generation on my testbed. This patch is still needed, otherwise it still generates classes from imported schema. So - in short - the facts didn't change in the last three months.
          Hide
          Matthias Hanisch added a comment -

          Correction: the patch above does not work for Java enums. They are also generated in "package types;"
          Only old-style enums seem to be put into the package associated with the schema target namespace.

          Show
          Matthias Hanisch added a comment - Correction: the patch above does not work for Java enums. They are also generated in "package types;" Only old-style enums seem to be put into the package associated with the schema target namespace.
          Hide
          Matthias Hanisch added a comment -

          Correction again: even without the patch it seems to work with old-style enums so probably fixing CASTOR-1986 helped here.
          This patch seems to be outdated because it makes things worse for my other issue CASTOR-1881.
          Nevertheless, the real Java enums still have this problem.

          Show
          Matthias Hanisch added a comment - Correction again: even without the patch it seems to work with old-style enums so probably fixing CASTOR-1986 helped here. This patch seems to be outdated because it makes things worse for my other issue CASTOR-1881 . Nevertheless, the real Java enums still have this problem.

            People

            • Assignee:
              Werner Guttmann
              Reporter:
              David M. Karr
            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: