Issue 3994: Valuetype unmarshalling (java-rtf) Source: (Mr. Simon C. Nash, ) Nature: Uncategorized Issue Severity: Summary: The rules for valuetype unmarshalling in section 1.13.8 of the IDL to Java mapping spec need to be expanded. There are two issues with the algorithm currently described: 1. The algorithm described is based purely on the repository ID, which may either be read off the wire or passed as an argument on the read_value() call. However, if the expected type is passed as an argument on the read_value() call, then this should be taken into account in the unmarshalling algorithm. 2. In some cases, the unmarshaller does not have enough information to distinguish between a boxed valuetype (which is unmarshalled using a helper object) and a regular valuetype (which is unmarshalled using a value factory). An additional step in the unmarshalling algorithm is needed to cover these cases. Proposed resolution: In section 1.13.8, add a new bullet before the existing second bullet as follows: • If this is not successful and an expected type clz was passed on the read_value call, and if clz implements IDLEntity but not ValueBase, then unmarshal the valuetype as a boxed IDL type by calling the read method of <clz>Helper. In section 1.13.8, add a new bullet before the existing third bullet as follows: • If this is not successful and the RepositoryId is a standard repository id that starts with “IDL:”, then attempt to generate the boxed value helper class name to use by stripping off the “IDL:” header and “:<major>.<minor>” version information trailer, and replacing the “/”s that separate the module names with “.”s and appending “Helper.” In section 1.13.8, add a new bullet before the existing fourth bullet as follows: • If this is not successful and an expected type clz was passed on the read_value call, and if clz does not implement IDLEntity, then use the ValueHandler interface to read in the value (see the Java to IDL Language Mapping document, Section 1.5.1.3, “ValueHandler,” on page 1-40). Resolution: Incorporate the revised text and close the issue Revised Text: In section 1.13.8, add a new bullet before the existing second bullet as follows: If this is not successful and an expected type clz was passed on the read_value call, and if clz implements IDLEntity but not ValueBase, then unmarshal the valuetype as a boxed IDL type by calling the read method of Helper. In section 1.13.8, add a new bullet before the existing third bullet as follows: If this is not successful and the RepositoryId is a standard repository id that starts with “IDL:”, then attempt to generate the boxed value helper class name to use by stripping off the “IDL:” header and “:<major>.<minor>” version information trailer, and replacing the “/”s that separate the module names with “.”s and appending “Helper.” Add a sub-bullet under the previous new bullet as follows: If this is not successful and the first two components of the Java class name are "omg.org", then reverse the order of these two components to be "org.omg" and repeat the above step. In section 1.13.8, add a new bullet before the existing fourth bullet as follows: If this is not successful and an expected type clz was passed on the read_value call, and if clz does not implement IDLEntity, then use the ValueHandler interface to read in the value (see the Java to IDL Language Mapping document, Section 1.5.1.3, “ValueHandler,” on page 1-40). Actions taken: October 25, 2000: received issue May 13, 2002: closed issue Discussion: End of Annotations:===== Date: Tue, 24 Oct 2000 20:44:48 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: issues@omg.org CC: java-rtf@omg.org Subject: Valuetype unmarshalling Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: U(6e9X91!!Yp^!!4E:!! The rules for valuetype unmarshalling in section 1.13.8 of the IDL to Java mapping spec need to be expanded. There are two issues with the algorithm currently described: 1. The algorithm described is based purely on the repository ID, which may either be read off the wire or passed as an argument on the read_value() call. However, if the expected type is passed as an argument on the read_value() call, then this should be taken into account in the unmarshalling algorithm. 2. In some cases, the unmarshaller does not have enough information to distinguish between a boxed valuetype (which is unmarshalled using a helper object) and a regular valuetype (which is unmarshalled using a value factory). An additional step in the unmarshalling algorithm is needed to cover these cases. Proposed resolution: In section 1.13.8, add a new bullet before the existing second bullet as follows: If this is not successful and an expected type clz was passed on the read_value call, and if clz implements IDLEntity but not ValueBase, then unmarshal the valuetype as a boxed IDL type by calling the read method of Helper. In section 1.13.8, add a new bullet before the existing third bullet as follows: If this is not successful and the RepositoryId is a standard repository id that starts wit h, then attempt to generate the boxed value helper class name to use by stripping off th e header an d version information trailer, and replacing th es that separate the module names wit hs and appendin g In section 1.13.8, add a new bullet before the existing fourth bullet as follows: If this is not successful and an expected type clz was passed on the read_value call, and if clz does not implement IDLEntity, then use the ValueHandler interface to read in the value (see the Java to IDL Language Mapping document, Section 1.5.1.3 , on page 1-40). Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Wed, 25 Oct 2000 10:45:35 -0400 From: Mary Leland X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash Cc: java-rtf@omg.org Subject: Re: Valuetype unmarshalling References: <39F5E6B0.D93B4956@hursley.ibm.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: c*:e9OZN!!Po]!!;T#"! Simon, Issue 3923, the pragma prefix "org.omg" vs. "omg.org" problem, also requires changes to the algorithm in Section 1.13.8. A possible resolution to 3923 is Add a sub-bullet to the second bullet in Section 13.8: If this is not successful and the first two components of the Java class name are "omg.org", then reverse the order of these components to be "org.omg" and repeat the above step. Would this resolution interfere with your proposal for the new issue? Should your proposed resolution include a similar rule for your 2nd change (the new bullet to be inserted before the existing 3rd bullet)? Thanks, -- Mary Simon Nash wrote: > > The rules for valuetype unmarshalling in section 1.13.8 of the IDL to > Java mapping spec need to be expanded. There are two issues with the > algorithm currently described: > > 1. The algorithm described is based purely on the repository ID, > which may either be read off the wire or passed as an argument on > the read_value() call. However, if the expected type is passed > as an argument on the read_value() call, then this should be taken > into account in the unmarshalling algorithm. > 2. In some cases, the unmarshaller does not have enough information > to distinguish between a boxed valuetype (which is unmarshalled > using a helper object) and a regular valuetype (which is unmarshalled > using a value factory). An additional step in the unmarshalling > algorithm is needed to cover these cases. > > Proposed resolution: > > In section 1.13.8, add a new bullet before the existing second bullet > as follows: > If this is not successful and an expected type clz was passed on the > read_value call, and if clz implements IDLEntity but not ValueBase, then > unmarshal the valuetype as a boxed IDL type by calling the read method > of Helper. > > In section 1.13.8, add a new bullet before the existing third bullet > as follows: > If this is not successful and the RepositoryId is a standard repository id that starts > wit h, then attempt to generate the boxed value helper class name to use by > stripping off th e header an d version information > trailer, and replacing th es that separate the module names wit hs and > appendin g > > In section 1.13.8, add a new bullet before the existing fourth bullet > as follows: > If this is not successful and an expected type clz was passed on the > read_value call, and if clz does not implement IDLEntity, then use the > ValueHandler interface to read in the value (see the Java to IDL Language > Mapping document, Section 1.5.1.3 , on page 1-40). > > Simon > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb