Diffrent algorithms used to map uri to java package name.

• Key: TUSCANY-178
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Blocker
• Assignee: Unassigned
• Reporter: Rick Rineholt
• Component/s: Java SCA Assembly Model, Java SDO Implementation, Java SDO Tools

Description

If you have wsdl that has no sdojava:package attribute and there are no javaPackage specified in the POM for sdo generation different algorithms are used to convert URI targetnamespace for the package names of: the generated interface package name, the interface packagename at load time if dynamically generated and the SDO types that are generated to define the types used in the interface methods. There are scenarios where these only differ by case (http://www.bigbank.com/Account maps to com.bigbank.Account and com.bigbank.account) Note on windows based environment these can't be co-located.

I believe the sca-plugin and the loadtime are using: org.apache.tuscany.model.util.XMLNameUtil methods.
Have not located where mangling of SDO types are generated is.

Tuscany needs one central place where this is done. For both packagenames and class names from uri and types to be consistent. I think if SDO is doing this it is the common denominator.

This will continue to be a place of contention and methods/(class) used to do this mangling should be configurable (ie.by factory or registering with SDO ).

Comments

[Jean-Sebastien Delfino]

Raising the priority to blocker. I was trying to create Web Services test cases today and bumped into this problem right away, this problem is not just affecting the BigBank sample, it is blocking development of most of the Web Services test cases.

[Rick Rineholt]

This is not really blocking for me with the following change
http://www.mail-archive.com/tuscany-commits%40ws.apache.org/msg00997.html

The SCA generation produces namespaces that closely match axis 2.0 wsdl2java becuase tuscany plungin sets the default
which is NOW always lowercase. This leaves the
SDO generation which can be controlled using sdo package attribute in the schema element for example:
      <schema ... xmlns:sdojava="commonj.sdo/java" sdojava:package="net.x.webservice">

More background:
Currently where mangling is occurring:
 SCA this is in org.apache.tuscany.model.util.XMLNameUtil
   We entirely control this so we can change it to what we want.
 SDO
   Currently this is done in org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.validName
   However this class overides org.eclipse.xsd.ecore.XSDEcoreBuilder and only control we now
   do is overriding the method validName(String name, int casing, String prefix) which has two short
   falls; it only allows us to control the individual name parts in the package and not the whole package name.
   More importantly it is used for both mangling package name parts, class names and maybe more.
   The context that it is being called for (package/class name) at this point is not from what I seen available.
   If we want more control the only method to override is
     XSDEcoreBuilder).getEPackage(org.eclipse.xsd.XSDNamedComponent)
   But there is more to this method from what I can tell than just the package name mangling so
    we'd need to separate this out.
 Axis 2.0 WSDL2Java
  To some degree we can control the name of the package here:
     org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceGenerator when we invoke the axis2 generator
     but there are drawbacks ... this seems to just overide all uri's .. what if there are more? Seems they'll be mapped to
     the same packagename. Is this what we always want ?
     Also till I put that toLowerCase hack (XMLNameUtil) we would need to lowercase because Axis in:
    org.apache.axis2.wsdl.codegen.extension.PackageFinder.engage() always lowercase irregardless. So without this hack
     org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceGenerator.JavaInterfaceEmitter.writeInterface where the
     FileWriter.createClassFile is given the xsd mixed case packagename produces a path with mixed case where as the class
     package produced is all lower.
     If nothing is specifed then Axis uses the code in org.apache.axis2.util.URLProcessor.makePackageName but
     irregardless of what this returns it lowercases it.
    

What to do ?

 Options
  Live with hack/restriction.
  Override SDO and SCA implementation to use one source and match that algorithm with Axis2's URLProcessor.makePackageName
  Open Jira's with Axis 2.0 to allow more flexible URI package naming.

[Frank Budinsky]

There are actually two ways to control the package name for SDO codegen. 1) the sdoJava:package attribute and 2) by passing a package name to the code generator (e.g., -javaPackage net..webserivce). Would it be possible that the correct/matching name be passed to the SDO generator this way? Trying to just rely on the SDO mangling to be what we want seems bad. There are discussions going on in the SDO spec group about whether or not SDO should specify a default algorithm for this - if they do, there's no guarantee it will be exactly the matching one we want.

[Rick Rineholt]

So maybe another short term solution to this would be to move the alogrigthm that axis uses into XMLNameUtil so it's used for SCA. Get the uri of the schema in the WSDL run it through that algorithm and specify it on the SDO generation. Then all 3 would be in sync? One question that comes to mind is if specifying the packagename on invocation would it overide the sdoJava:package attribute in the schema and would that be what the user expects ? I suppose we could check for it's presences as we are looking for the schema TNS and if there do not specify it when invoking the generator (if you specify it in the wsdl schema you're own your own)

[Jean-Sebastien Delfino]

Fixed under revision r397695. Thanks Rick!

[Kelvin Goodson]

Closing old resolved JIRAs that don't have a fix version and therefore cloud queries for M3 release