PM20577: SDOGenerator class should look at entire path to determine wheth er to uniquify

Rational Application Developer for WebSphere Software, version 7.5.5.2

APAR status

• Closed as program error.

Error description

• In JAX-RPC top down code generation with SDO facades, unpredicta
  ble class naming of Factory and Package classes may result due t
  o a sequence being included in the class name.
  
  Generated class names are named after the first part (up to the
  first dot) of the namespace in WSDL/XSD. For example, http://xxx
  .yyy.zzz is generated as XxxFactory, but when the namespace of m
  ultiple WSDL/XSD files is the same, a sequence is generated to s
  top name clashes e.g. Xxx1Factory, Xxx1Package, Xxx2Factory, Xxx
  2Package. If you edit WSDL/XSD (for example to change the order
  of XSD imports), the order in which sequence numbers are applied
   to class names changes.
  
  The problem with this is that when you regenerate your Web servi
  ce code after editing WSDL/XSD, the classnames in code generatio
  n may change from previous code generation. Application code tha
  t references the previously generated code will break and the ap
  plication code will also have to be edited.
  
  In com.ibm.ccl.ws.xml2java.sdo.core plugin's SDOGenerator class,
   there is a method called setPackageInfo. It keeps track of pack
  age names and tries to uniquify things thus resulting in Test1,
  Test2 prefixes. It needs to look at the entire path to determine
   whether or not it needs to uniquify.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  The prefix name was unnecessarily changed even though the
  classes are in different packages.  This, of course, is
  allowed in Java.   The fix is to check if the prefix is
  already used in the package.  If it is, then the new unique
  prefix will be calculated and used.
  

Problem conclusion

• The prefix name was unnecessarily changed even though the
  classes are in different packages.  This, of course, is
  allowed in Java.   The fix is to check if the prefix is
  already used in the package.  If it is, then the new unique
  prefix will be calculated and used.
  
  Fixed for Rational Application Developer v7.5.5.2
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  RATL APP DEV WI

• Fixed component ID

  5724J1901

Applicable component levels

• R750 PSN

     UP