[kepler-dev] problem with type name mapping in WebService actor

Edward A. Lee eal at eecs.berkeley.edu
Wed May 23 00:41:58 PDT 2007

Some background here:

The reason for the change in syntax for reporting array types
is that we now have dependent types for arrays, where the size of the
array can be part of the array type.  This is very helpful for our
code generation work, but if you consistently stick with unsized
arrays, shouldn't be a problem except that the text describing the
type has changed...  The syntax for the type of an array of unsigned
bytes used to be "[unsignedByte]" but this now specifies an array
of length one (the variable "unsignedByte" is actually just 0ub).
The new syntax for an array of unspecified size is

Sorry about that...  We try hard to avoid backward incompatibilities
when changing Ptolemy II, but sometimes they are hard to avoid.


At 10:27 AM 5/22/2007, Karen L Schuchardt wrote:
>I had an old workflow that used the WebService actor.  At one point I 
>had added support for ports of type unsignedByte[].  The actor is not 
>working correctly with the latest version of kepler.  I don't know when 
>it broke as I have not updated in quite a long time.  Digging into the 
>code a bit, I found that the methods
>_setObjectArray and _sendOutput no longer match on the web service types 
>and quietly fail.
>For example, in _setObjecArray, the line of code
>else if (portPtr.getType().toString().equals("{unsignedByte}"))...
>fails to match because the type string is now actually 
>The analogous error occurs in _sendOutput. 
>The type appears to be supplied to the _createPort method and their are 
>some notes in the vicinity indicating this code was changed:
>/* Original code
>           String baseTypeStr = _getArrayBaseType(arrTypeNode);
>           */
>           /* This code updated by Zhiming Zhao*/
>              String baseTypeStr =(String)( 
>            QName nodeQname= ( 
>              /* End */
>If I hack the code to also look for the new type name, the web service 
>actor works for me.  I only have an example using the byte arrays but 
>presumably all of the array types are affected by this.
>Has anybody else noticed this problem?  I am using java 1.5 and the same 
>version of the axis client that is shipped with kepler.  I'd be willing 
>to send fixed code but I'm not sure what the preferred fix would be.  
>Let me know if I can be of more help.
>Kepler-dev mailing list
>Kepler-dev at ecoinformatics.org

Edward A. Lee
Chair of EECS and Robert S. Pepper Distinguished Professor
231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
phone: 510-642-0253, fax: 510-642-2845
eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal  

More information about the Kepler-dev mailing list