Issue 2889: Should Any.extract_string work for bounded strings? (java-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: It is not clear from the OMG specs or from looking at existing Java ORB products what behavior is intended for the following case: 1. Create an Any with a TypeCode for a bounded string. 2. Call extract_string on the Any object. I have tried this on two Java ORBs and it fails in both cases. It works when the Any"s TypeCode is for an unbounded string. The spec is silent on whether or not this should work. The only relevant statement in the spec is the following from section 1.16: Resolution: close no change Revised Text: Actions taken: September 15, 1999: received issue April 28, 2003: closed issue Discussion: I can't see any reason why this should not work. It works in the current Sun ORB. I also do not see any place in the mapping spec or in the core spec where this question is addressed. It seems that this issue really has more to do with the core CORBA architecture than the Java mapping. As no one has made any comment on this issue in over 3 years, I propose that we close it no change. End of Annotations:===== Date: Wed, 15 Sep 1999 12:34:10 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: issues@omg.org CC: java-rtf@omg.org Subject: Should Any.extract_string work for bounded strings? Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 9a36edfd6a5af3c0d93938d12930d713 It is not clear from the OMG specs or from looking at existing Java ORB products what behavior is intended for the following case: 1. Create an Any with a TypeCode for a bounded string. 2. Call extract_string on the Any object. I have tried this on two Java ORBs and it fails in both cases. It works when the Any's TypeCode is for an unbounded string. The spec is silent on whether or not this should work. The only relevant statement in the spec is the following from section 1.16: Insert and extract methods are defined in order to provide a high speed interface for use by portable stubs and skeletons. An insert and extract method are defined for each primitive IDL type, as well as for a generic streamable to handle the case of non-primitive IDL types. Note that to preserve unsigned type information, unsigned methods are defined where appropriate. This suggests that extract_string is only intended for use by generated code in portable stubs and skeletons. If the Any objects used by these stubs and skeletons are always created with unbounded string TypeCodes, then there is no need for extract_string to work with bounded string TypeCodes. However, I can't see naything in the spec that would lead me to think that this is a reasonable restrictions. For example, I would expect the following code to be valid: // IDL: interface test { void foo1(in string<16> arg); }; // generated Java skeleton code: org.omg.CORBA.NVList _params = _orb().create_list(0); org.omg.CORBA.Any __param_arg = _orb().create_any(); __param_arg.type(_orb().create_string_tc(16)); _params.add_value("arg", __param_arg, org.omg.CORBA.ARG_IN.value); _request.params(_params); java.lang.String arg; arg = __param_arg.extract_string(); _self.foo1(arg); Is this valid? Can a string in an Any whose typecode was created by create_string_tc(16) be extracted from the Any using extract_string? 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: Tue, 10 Dec 2002 13:29:57 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Vote 5 (due 5 pm PST 12/17/02) To: java-rtf@omg.org X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc This is vote 5 of the current Java RTF. It will be the last vote in the current RTF, unless some other issues (or modifications to the proposals in this vote) come up before 12/17/02. I will issue a vote on 12/17 only if it is necessary to clean up after this vote. I will need to submit a final RTF report and supporting documents by 1/6/03. I plan to attend the Burlingame meeting, so I will be able to deliver the RTF report and make the motion to charter another Java RTF. The remaining issues that we have not considered in this RTF are: 3068: Messaging sendc and sendp missing from portability interfaces. Still no work here. Does anyone ever expect to work on this? I guess I'll leave it open, but the lack of interest does seem to argue for closing it. 5108: J2EE ORB Socket Factory API Since Andy and Ann have stated that they want to work on this, we will leave it open for the next Java RTF. This vote is due 5 pm PST December 17, 2002. ------------------------------------------------------------------------------------------- Issue 2889: Should Any.extract_string work for bounded strings? ------------------------------------------------------------------------------------------- Summary: It is not clear from the OMG specs or from looking at existing Java ORB products what behavior is intended for the following case: 1. Create an Any with a TypeCode for a bounded string. 2. Call extract_string on the Any object. I have tried this on two Java ORBs and it fails in both cases. It works when the Any's TypeCode is for an unbounded string. The spec is silent on whether or not this should work. The only relevant statement in the spec is the following from section 1.16: Insert and extract methods are defined in order to provide a high speed interface for use by portable stubs and skeletons. An insert and extract method are defined for each primitive IDL type, as well as for a generic streamable to handle the case of non-primitive IDL types. Note that to preserve unsigned type information, unsigned methods are defined where appropriate. Discussion: I can't see any reason why this should not work. It works in the current Sun ORB. I also do not see any place in the mapping spec or in the core spec where this question is addressed. It seems that this issue really has more to do with the core CORBA architecture than the Java mapping. As no one has made any comment on this issue in over 3 years, I propose that we close it no change. Proposed resolution: close no change.