castor

Castor isn't generating specific base classes

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.1.1
  • Fix Version/s: 1.1.1
  • Component/s: XML code generator
  • Labels:
    None
  • Testcase included:
    yes
  • Number of attachments :
    3

Description

I'm using snapshot 20070305 of 1.1.1. I'm attaching a test case here using either CastorCodeGenTask or SourceGeneratorMain that fails to generate class files for base classes referenced by subclasses. It's entirely possible I'm doing something wrong, but I think I'd have to be doing something horribly wrong to cause Castor to fail to generate classes that other classes it generates are referencing.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Werner Guttmann added a comment -

David, is this actually a regression issue against an earlier version or Castor, e.g. Castor 1.1, or is this a result of you getting that far for the first time ?

Show
Werner Guttmann added a comment - David, is this actually a regression issue against an earlier version or Castor, e.g. Castor 1.1, or is this a result of you getting that far for the first time ?
Hide
Permalink
David M. Karr added a comment -

The latter. I've been stepping through the issues with the snapshot, and this is the latest issue I had. I had to spend some time getting a standalone test case that demonstrates this. I haven't tested this with earlier versions yet.

Show
David M. Karr added a comment - The latter. I've been stepping through the issues with the snapshot, and this is the latest issue I had. I had to spend some time getting a standalone test case that demonstrates this. I haven't tested this with earlier versions yet.
Hide
Permalink
David M. Karr added a comment -

However, I know we're not getting this issue with v0.9.6, although I haven't set up this specific test case to test that version. This schema is from existing code in our regular build, which uses v0.9.6.

Show
David M. Karr added a comment - However, I know we're not getting this issue with v0.9.6, although I haven't set up this specific test case to test that version. This schema is from existing code in our regular build, which uses v0.9.6.
Hide
Permalink
Werner Guttmann added a comment -

Just realized that you are using the new automatic name conflict resolution mode. For the time being, i.e. until we have an educated idea as to why this is going wrong, is there a way you could stop using this. Or would this involve writing biggish binding files ?

Show
Werner Guttmann added a comment - Just realized that you are using the new automatic name conflict resolution mode. For the time being, i.e. until we have an educated idea as to why this is going wrong, is there a way you could stop using this. Or would this involve writing biggish binding files ?
Hide
Permalink
David M. Karr added a comment -

In my estimation, this would require several hundred binding entries. Unless you somehow needed this to debug the problem, I have no intention of going there.

Show
David M. Karr added a comment - In my estimation, this would require several hundred binding entries. Unless you somehow needed this to debug the problem, I have no intention of going there.
Hide
Permalink
Werner Guttmann added a comment -

Okay, that's what I thought. In this case, please bear with us for some time being. It looks like you seem to have unearthed something very odd, breaking the algorithm implemented in JClassRegistry in a very odd way.

Show
Werner Guttmann added a comment - Okay, that's what I thought. In this case, please bear with us for some time being. It looks like you seem to have unearthed something very odd, breaking the algorithm implemented in JClassRegistry in a very odd way.
Hide
Permalink
Matthias Epheser added a comment -

the problem was that the complexType DateType his anonymous group shared the same xpath internally. this is because XPathHelper.getSchemaLocation() is doing the following with groups:

getSchemaLocation(((Group) structure).getParent(), location);

I attached a patch that makes the JClassRegistry aware of this problem. Now the group-xpath and the complexType-xpath are handled the right way and your classes are generated correctly.

Show
Matthias Epheser added a comment - the problem was that the complexType DateType his anonymous group shared the same xpath internally. this is because XPathHelper.getSchemaLocation() is doing the following with groups: getSchemaLocation(((Group) structure).getParent(), location); I attached a patch that makes the JClassRegistry aware of this problem. Now the group-xpath and the complexType-xpath are handled the right way and your classes are generated correctly.
Hide
Permalink
Matthias Epheser added a comment -

i just attached a more restrictive patch that only changes the xpath for groups which are CHOICES. The patch also checks if the choice is a global element, in this case no renaming should be performed.

Show
Matthias Epheser added a comment - i just attached a more restrictive patch that only changes the xpath for groups which are CHOICES. The patch also checks if the choice is a global element, in this case no renaming should be performed.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.