castor

Add naming collision strategy that uses XPATH prefices

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 1.1 M2
  • Fix Version/s: 1.1.1
  • Component/s: XML code generator
  • Labels:
    None
  • Number of attachments :
    6

Description

Add a naming collision resolution strategy (implementation) that uses XPATH prefices for class name deduction.

Attachments

  1. Text File
    patch.c1852.20070119.txt
    19/Jan/07 6:42 AM
    37 kB
    Werner Guttmann
  2. Text File
    patch.c1852.20070131.txt
    31/Jan/07 4:03 PM
    74 kB
    Werner Guttmann
  3. Text File
    patch.c1852.20070201-002.txt
    01/Feb/07 8:40 AM
    58 kB
    Werner Guttmann
  4. Text File
    patch.c1852.20070207.txt
    06/Feb/07 2:37 PM
    60 kB
    Werner Guttmann
  5. Text File
    patch.c1852.20070207-002.txt
    07/Feb/07 9:56 AM
    61 kB
    Werner Guttmann
  6. Text File
    patch.c1852.20070211.txt
    11/Feb/07 10:07 AM
    64 kB
    Werner Guttmann

Activity

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

Initial patch that shows the approach taken, but still has some (very minor) deficiencies.

Show
Werner Guttmann added a comment - Initial patch that shows the approach taken, but still has some (very minor) deficiencies.
Hide
Permalink
Werner Guttmann added a comment -

I just figured why the unmarshal() method of BondNotioanl is wrong. Have a look at SourceFactory.createUnmarshalMethods(), l994ff. At the bottom of this method, a JSourceCode instance is created that holds the method body of the unmarshal() method to be created. As a mattr of fact, this is created before class nam econflict resolution. Whilst the toString() methods of e.g. JMethod and JMethodSignature are linked to a JClass instance (whose local name we change in the strategy implementation) and thus lazily create the code, this JSource instance is created too early.

Proposal: introduce something similar to JMethodBody, that takes an arbitrary number of parameters, and that has a toString() method.

Show
Werner Guttmann added a comment - I just figured why the unmarshal() method of BondNotioanl is wrong. Have a look at SourceFactory.createUnmarshalMethods(), l994ff. At the bottom of this method, a JSourceCode instance is created that holds the method body of the unmarshal() method to be created. As a mattr of fact, this is created before class nam econflict resolution. Whilst the toString() methods of e.g. JMethod and JMethodSignature are linked to a JClass instance (whose local name we change in the strategy implementation) and thus lazily create the code, this JSource instance is created too early. Proposal: introduce something similar to JMethodBody, that takes an arbitrary number of parameters, and that has a toString() method.
Hide
Permalink
Werner Guttmann added a comment -

Next problem: the field _notional in BondComplexType should have a type of BondNotional. Unfortunately, it does not .. .

Show
Werner Guttmann added a comment - Next problem: the field _notional in BondComplexType should have a type of BondNotional. Unfortunately, it does not .. .
Hide
Permalink
Werner Guttmann added a comment -

Somehow I think we should switch towards an approach where we deal with those collisions when creating ClassInfo/FieldInfo instances. Given a new FieldInfo instance (with a name 'notional'), which we want to add to an existing ClassInfo instance, it should be easy to figure a path from this ClassInfo in question to the root class (classes generated for global types, who don't have a parent anymore). Given that path, one could maintain a registry of path to ClassInfo/FieldInfo mappings.

Show
Werner Guttmann added a comment - Somehow I think we should switch towards an approach where we deal with those collisions when creating ClassInfo/FieldInfo instances. Given a new FieldInfo instance (with a name 'notional'), which we want to add to an existing ClassInfo instance, it should be easy to figure a path from this ClassInfo in question to the root class (classes generated for global types, who don't have a parent anymore). Given that path, one could maintain a registry of path to ClassInfo/FieldInfo mappings.
Hide
Permalink
Werner Guttmann added a comment -

Completely reworked patch, adding a class name conflict resolution at the JClass level. With this patch, all CTF tests finish fine. I still have to clean out the old resolution strategy solution, as it really does not add any additional value anymore.

The new usage of a JClassRegistry is actually configurable via a new builder property.

Show
Werner Guttmann added a comment - Completely reworked patch, adding a class name conflict resolution at the JClass level. With this patch, all CTF tests finish fine. I still have to clean out the old resolution strategy solution, as it really does not add any additional value anymore. The new usage of a JClassRegistry is actually configurable via a new builder property.
Hide
Permalink
Werner Guttmann added a comment -

New and improved patch, adding code to SG.generateAllClasses() to pre-register global group definitions as well.

Show
Werner Guttmann added a comment - New and improved patch, adding code to SG.generateAllClasses() to pre-register global group definitions as well.
Hide
Permalink
Werner Guttmann added a comment -

Improved patch, where I removed some old (aka outdated) code from the original approach. The use of strategies has been simplified again to what it used to be earlier.

Show
Werner Guttmann added a comment - Improved patch, where I removed some old (aka outdated) code from the original approach. The use of strategies has been simplified again to what it used to be earlier.
Hide
Permalink
Werner Guttmann added a comment -

Updated patch, with some improvements in xPath calculation (taking types into account as well).

Show
Werner Guttmann added a comment - Updated patch, with some improvements in xPath calculation (taking types into account as well).
Hide
Permalink
Werner Guttmann added a comment -

Updated patch, where I have added code to deal with local group references as well, by simply accepting the class name as suggested. This time, generating sources for the complete FpML schema set completes successfully.

Show
Werner Guttmann added a comment - Updated patch, where I have added code to deal with local group references as well, by simply accepting the class name as suggested. This time, generating sources for the complete FpML schema set completes successfully.
Hide
Permalink
Werner Guttmann added a comment -

Improved and final patch.

Show
Werner Guttmann added a comment - Improved and final patch.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:

Time Tracking

Estimated:
1w 12h
Original Estimate - 1 week, 12 hours
Remaining:
1w 12h
Remaining Estimate - 1 week, 12 hours
Logged:
Not Specified
Time Spent - Not Specified
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.