castor

File name created containing "null" when using namingXML/prefix plus import and include

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.3.1
  • Fix Version/s: 1.3.4
  • Component/s: XML code generator
  • Labels:
    None
  • Environment:
    Java 1.6, Castor 1.3.1
  • Testcase included:
    yes
  • Number of attachments :
    3

Description

Castor XML source generation creates file named "XMLnull.java".
Castor should not generate file names that have "null" in their file name.
Test case is attached.

Apparently, this issue occurs only when all below conditions hold:

  • binding file is used with
    • defaultBindingType="type"
    • namingXML/complexTypeName/prefix is set (to "XML" in the example)
    • package specification for namespace of the imported file
  • two layers of <xsd:import> / <xsd:include> used
  • complexType / element / complexType structure in 2nd-level included XSD.

Attached test case is a simple Ant file.
Adjust the path to the libraries, then call ant.
The issue is evident when output at the end shows:
"Strange file name: src-generated/include1/XMLnull.java"

The "null" likely comes from XMLBindingComponent.java lines 779 and 892
if (_prefix != null)

{ result = _prefix + result; }

if (_suffix != null)

{ result = result + _suffix; }

Maybe it helps to check for "result != null" around this (not tested)?

Unfortunately, we have loads of XSDs which have this structure. The "XMLnull.java" files overwrite each other, so that the "last one wins". We do not want to use defaultBindingType="element" because this would mean 1000+ code changes in our code that uses the generated code. Currently we're using an older version of Castor (<1.x) where this isse does not occur.

If there's another way around this we'd be happy to learn about it. Thanks.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Matthias Gaertner added a comment -

One more detail: issue still exists when only one level of <import> is used, with no <include>. In this case, a file "src-generated/top/XMLnull.java" is created.

Show
Matthias Gaertner added a comment - One more detail: issue still exists when only one level of <import> is used, with no <include>. In this case, a file "src-generated/top/XMLnull.java" is created.
Hide
Permalink
Werner Guttmann added a comment -

I think I found the problem, which indeed is specific to using type mode together with (by definition name-less) anonymous type definitions together with a naming suffix/prefix. I will attach a patch that I think solves the problem a little bit later on for you to test.

Show
Werner Guttmann added a comment - I think I found the problem, which indeed is specific to using type mode together with (by definition name-less) anonymous type definitions together with a naming suffix/prefix. I will attach a patch that I think solves the problem a little bit later on for you to test.
Hide
Permalink
Werner Guttmann added a comment -

Initial patch for review. I still have to think about side effects with regards to using a combination of element and (complex) type prefix/suffix definitions.

Show
Werner Guttmann added a comment - Initial patch for review. I still have to think about side effects with regards to using a combination of element and (complex) type prefix/suffix definitions.
Hide
Permalink
Matthias Gaertner added a comment -

Thanks for looking into this. Will test the patch. May take some time.

Show
Matthias Gaertner added a comment - Thanks for looking into this. Will test the patch. May take some time.
Hide
Permalink
Matthias Gaertner added a comment -

After applying the patch it seems that no more XMLnull.java files are created (for our real code, not just the test case attached). Good.
I need to check now how the existing code matches the generated code, i.e. whether any castor files are absent now (with the patch) that used to have been present earlier (with previous Castor version).

Show
Matthias Gaertner added a comment - After applying the patch it seems that no more XMLnull.java files are created (for our real code, not just the test case attached). Good. I need to check now how the existing code matches the generated code, i.e. whether any castor files are absent now (with the patch) that used to have been present earlier (with previous Castor version).
Hide
Permalink
Matthias Gaertner added a comment -

Well, now somehow I get names that include two prefixes, namely the "elementName" plus the "complexTypeName" prefixes defined in <namingXML>.

So for some "Type" in XSD, I now get "XML_E_XML_C_Type.java" for <namingXML> "XML_E_" and XML_C".

I don't think this is intended? Maybe I can create a reproducer...

Show
Matthias Gaertner added a comment - Well, now somehow I get names that include two prefixes, namely the "elementName" plus the "complexTypeName" prefixes defined in <namingXML>. So for some "Type" in XSD, I now get "XML_E_XML_C_Type.java" for <namingXML> "XML_E_" and XML_C ". I don't think this is intended? Maybe I can create a reproducer...
Hide
Permalink
Matthias Gaertner added a comment -

The patch has a bad side effect. Top-level complexTypes will NOT have the prefix any longer?

See attached reproducer in castor-element-wo-prefix.zip.

The reproducer does create "XMLnull.java" when used with original Castor 1.3.1 (wrong; now without any <xsd:import> even). It creates "CityType.java" (wrong, should be "XMLCityType.java") when a patched Castor is used (patch as above).

Note that inner complexType/../element combinations do produce desired result, such as "XMLCityCode.java" (OK).

Show
Matthias Gaertner added a comment - The patch has a bad side effect. Top-level complexTypes will NOT have the prefix any longer? See attached reproducer in castor-element-wo-prefix.zip. The reproducer does create "XMLnull.java" when used with original Castor 1.3.1 (wrong; now without any <xsd:import> even). It creates "CityType.java" (wrong, should be "XMLCityType.java") when a patched Castor is used (patch as above). Note that inner complexType/../element combinations do produce desired result, such as "XMLCityCode.java" (OK).
Hide
Permalink
Matthias Gaertner added a comment -

Reproducer for comment 02Nov2010.

Show
Matthias Gaertner added a comment - Reproducer for comment 02Nov2010.

People

  • Assignee:
    Werner Guttmann
    Reporter:
    Matthias Gaertner
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: