Issue 3643: Description of ORB.init parameters insufficient (java-rtf) Source: International Business Machines (Mr. Russell Butek, ) Nature: Uncategorized Issue Severity: Summary: I have a number of questions/concerns about the description/usage of ORB.init arguments/properties. 1. There are only two properties described in the Java mapping spec: org.omg.CORBA.ORBClass and org.omg.CORBA.ORBSingletonClass. Setting these via property are described, but not setting these via application string array (ie., args in main). Yet the spec says these values can be obtained via the args array. I believe most folks assume "-ORBClass xxx" is the convention, since that's what the JDK's ORB uses, but it's not documented. 2. Ditto for applet parameters. It's assumed that they are of the form <param name = "org.omg.CORBA.ORBClass" value = "xxx"> but it is not documented. 3. Can this convention be generalized to accommodate the argument naming convention in the core spec? If we follow the convention that says org.omg.CORBA.ORBClass becomes -ORBClass; then can we say that a parameter -ORBXXX may also be specified by the property or applet parameter org.omg.CORBA.ORBXXX? 4. The text around the ORB arguments is tightly coupled to only ORBClass and ORBSingletonClass. It does not seem to expect other args/properties. For example: "...when creating an ORB instance, the class names of the ORB implementation are located using the following search order: ...". I assume the following search order also applies to any args/props. 5. The spec doesn't allow for extensions. "See Table 1-3 for a list of the property names and values that are recognized by ORB.init. Any property names not in this list shall be ignored by ORB.init()." Has the INS spec updated this table with -ORBInitRef and -ORBDefaultInitRef, for example? And the interceptor spec assumes that services are allowed to have their own arguments. And what about proprietary extensions? Given the word "shall", any extensions are non-CORBA-compliant. 6. Repeated arguments fall apart when presented as Properties. For example, the INS spec allows for the following invocation: java myapp -ORBInitRef XX=xx -ORBInitRef YY=yy -ORBInitRef ZZ=zz Since Properties entries are <key, value> pairs, and only one pair for a given key can exist, then if we tried entering the above as Properties we'd only get on of them, not all. I'm not sure how to fix this. Dictate that XX, YY, ZZ be the end of the ORBInitRef string rather than the start of a new string, perhaps? So then, specifying these as system properties for example, we'd have: java myapp -Dorg.omg.CORBA.ORBInitRefXX xx -Dorg.omg.CORBA.ORBInitRefYY yy -Dorg.omg.CORBA.ORBInitRefZZ zz That causes ugly parsing problems. We'd have to search the whole list of properties that contained a key that merely BEGAN with "org.omg.CORBA.ORBInitRef". And this falls apart in applets; we can get a list of all Properties, but we cannot get a list of all applet parameters. Personally I think this is a failing in the applet class, but that's life as we know it. I'm sorry to raise this as one issue instead of six, but most of these points are tightly coupled, so I didn't want to distance them from each other. And I'd like them all to be answered together anyway. Resolution: Revised Text: Actions taken: May 25, 2000: received issue Discussion: End of Annotations:===== From: butek@us.ibm.com Received: from e21.nc.us.ibm.com (e21.raleigh.ibm.com [9.37.2.58]) by admin.ny.us.ibm.com. (8.9.3/8.9.3) with ESMTP id JAA37126; Thu, 25 May 2000 09:51:22 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA99748; Thu, 25 May 2000 09:43:40 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id JAA57958; Thu, 25 May 2000 09:53:03 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568EA.004C43F7 ; Thu, 25 May 2000 09:53:01 -0400 X-Lotus-FromDomain: IBMUS To: java-rft@omg.org, issues@omg.org Message-ID: <852568EA.004C4254.00@d54mta04.raleigh.ibm.com> Date: Thu, 25 May 2000 09:52:55 -0400 Subject: Description of ORB.init parameters insufficient Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: 5;Q!! but it is not documented. 3. Can this convention be generalized to accommodate the argument naming convention in the core spec? If we follow the convention that says org.omg.CORBA.ORBClass becomes -ORBClass; then can we say that a parameter -ORBXXX may also be specified by the property or applet parameter org.omg.CORBA.ORBXXX? 4. The text around the ORB arguments is tightly coupled to only ORBClass and ORBSingletonClass. It does not seem to expect other args/properties. For example: "...when creating an ORB instance, the class names of the ORB implementation are located using the following search order: ...". I assume the following search order also applies to any args/props. 5. The spec doesn't allow for extensions. "See Table 1-3 for a list of the property names and values that are recognized by ORB.init. Any property names not in this list shall be ignored by ORB.init()." Has the INS spec updated this table with -ORBInitRef and -ORBDefaultInitRef, for example? And the interceptor spec assumes that services are allowed to have their own arguments. And what about proprietary extensions? Given the word "shall", any extensions are non-CORBA-compliant. 6. Repeated arguments fall apart when presented as Properties. For example, the INS spec allows for the following invocation: java myapp -ORBInitRef XX=xx -ORBInitRef YY=yy -ORBInitRef ZZ=zz Since Properties entries are pairs, and only one pair for a given key can exist, then if we tried entering the above as Properties we'd only get on of them, not all. I'm not sure how to fix this. Dictate that XX, YY, ZZ be the end of the ORBInitRef string rather than the start of a new string, perhaps? So then, specifying these as system properties for example, we'd have: java myapp -Dorg.omg.CORBA.ORBInitRefXX xx -Dorg.omg.CORBA.ORBInitRefYY yy -Dorg.omg.CORBA.ORBInitRefZZ zz That causes ugly parsing problems. We'd have to search the whole list of properties that contained a key that merely BEGAN with "org.omg.CORBA.ORBInitRef". And this falls apart in applets; we can get a list of all Properties, but we cannot get a list of all applet parameters. Personally I think this is a failing in the applet class, but that's life as we know it. I'm sorry to raise this as one issue instead of six, but most of these points are tightly coupled, so I didn't want to distance them from each other. And I'd like them all to be answered together anyway. Russell Butek butek@us.ibm.com From: Jeffrey Mischkinsky Message-Id: <200005252232.PAA27230@wheel.dcn.davis.ca.us> Subject: Re: Description of ORB.init parameters insufficient To: butek@us.ibm.com Date: Thu, 25 May 2000 15:32:41 -0700 (PDT) Cc: java-rtf@omg.org In-Reply-To: <852568EA.006AD458.00@d54mta04.raleigh.ibm.com> from "butek@us.ibm.com" at May 25, 2000 03:26:49 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: c3o!!BZG!!I8(!!3H-!! 'butek@us.ibm.com' writes: > Russell Butek > 05/25/2000 08:52 AM > > To: java-rft@omg.org, issues@omg.org > cc: > From: Russell Butek/Austin/IBM@IBMUS > Subject: Description of ORB.init parameters insufficient > > > 5. The spec doesn't allow for extensions. > > "See Table 1-3 for a list of the property names and values that are > recognized by > ORB.init. Any property names not in this list shall be ignored by > ORB.init()." > > Has the INS spec updated this table with -ORBInitRef and > -ORBDefaultInitRef, for example? And the interceptor spec assumes that > services are allowed to have their own arguments. And what about > proprietary extensions? Given the word "shall", any extensions are > non-CORBA-compliant. The INS spec should have explicitly identified the java mapping section to update, but we forgot. I think this is really editorial. (sort of like adding a new std exception and forgetting to explicitly specify modifying the table in CORE). jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 Date: Fri, 26 May 2000 12:35:13 +1000 (EST) From: Michi Henning To: Jeffrey Mischkinsky cc: butek@us.ibm.com, java-rtf@omg.org, tmcf@ooc.com.au Subject: Re: Description of ORB.init parameters insufficient In-Reply-To: <200005252232.PAA27230@wheel.dcn.davis.ca.us> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: !O8e9MlUd9lF5e9Z:`d9 On Thu, 25 May 2000, Jeffrey Mischkinsky wrote: > The INS spec should have explicitly identified the java mapping section > to update, but we forgot. > I think this is really editorial. (sort of like adding a new std exception > and forgetting to explicitly specify modifying the table in CORE). Yes, that was an oversight. Ted has the issue and can make the required changes for inclusion in CORBA 2.4 as an editorial fix? Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Jeffrey Mischkinsky Message-Id: <200005260552.WAA26630@wheel.dcn.davis.ca.us> Subject: Re: Description of ORB.init parameters insufficient To: michi@ooc.com.au (Michi Henning) Date: Thu, 25 May 2000 22:52:58 -0700 (PDT) Cc: butek@us.ibm.com, java-rtf@omg.org, tmcf@ooc.com.au In-Reply-To: from "Michi Henning" at May 26, 2000 12:35:13 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: BRj!!>3;e9D\-e906d!! 'Michi Henning' writes: > > On Thu, 25 May 2000, Jeffrey Mischkinsky wrote: > > > The INS spec should have explicitly identified the java mapping section > > to update, but we forgot. > > I think this is really editorial. (sort of like adding a new std exception > > and forgetting to explicitly specify modifying the table in CORE). > > Yes, that was an oversight. Ted has the issue and can make the required > changes for inclusion in CORBA 2.4 as an editorial fix? Actually Mary is the current owner of IDL/Java mapping sources, so she'll have to incorporate the text. I currently have the IDL/Java mapping source for 3.0 and have to remember to make the change in it. Since the java-rtf is cc'd, she'll see this message. cheers, jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA22278 for ; Fri, 26 May 2000 08:55:20 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id JAA52240 for ; Fri, 26 May 2000 09:04:44 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568EB.0047D6E6 ; Fri, 26 May 2000 09:04:40 -0400 X-Lotus-FromDomain: IBMUS To: java-rtf@omg.org Message-ID: <852568EB.0047D40C.00@d54mta04.raleigh.ibm.com> Date: Fri, 26 May 2000 09:04:32 -0400 Subject: Re: Description of ORB.init parameters insufficient Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: $V'!!~@5e9%iA!!"jR!! Jeffrey Mischkinsky on 05/25/2000 05:32:41 PM > > 'butek@us.ibm.com' writes: > > Russell Butek > > 05/25/2000 08:52 AM > > > > To: java-rft@omg.org, issues@omg.org > > cc: > > From: Russell Butek/Austin/IBM@IBMUS > > Subject: Description of ORB.init parameters insufficient > > > > > > 5. The spec doesn't allow for extensions. > > > > "See Table 1-3 for a list of the property names and values that are > > recognized by > > ORB.init. Any property names not in this list shall be ignored by > > ORB.init()." > > > > Has the INS spec updated this table with -ORBInitRef and > > -ORBDefaultInitRef, for example? And the interceptor spec assumes that > > services are allowed to have their own arguments. And what about > > proprietary extensions? Given the word "shall", any extensions are > > non-CORBA-compliant. > > The INS spec should have explicitly identified the java mapping section > to update, but we forgot. > I think this is really editorial. (sort of like adding a new std exception > and forgetting to explicitly specify modifying the table in CORE). > > jeff I just used the INS spec as an example because I was aware of it. But I'm more concerned with the statement "Any property names not in this list shall be ignored by ORB.init()". This means that ORBs that have proprietary properties are non-compliant. But more importantly, this also means, at least to me, that a non-spec'ed service (we don't have specs for logging, or workload management, for instance) CANNOT use properties/arguments to set its state because the ORB SHALL ignore that service's properties/arguments. In other words, when the ORB passes the arguments to the ORBInitializer for that service (see the interceptor spec - ptc/2000-04-05 section 21-7), that service's arguments will not be in the list. Russell Butek butek@us.ibm.com Date: Fri, 26 May 2000 22:18:53 +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: butek@us.ibm.com CC: java-rtf@omg.org Subject: Re: Description of ORB.init parameters insufficient References: <852568EB.0047D40C.00@d54mta04.raleigh.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Z2;e9)DFe9TMQe9ff?!! Russell, butek@us.ibm.com wrote: > > Jeffrey Mischkinsky on 05/25/2000 05:32:41 > PM > > > > 'butek@us.ibm.com' writes: > > > Russell Butek > > > 05/25/2000 08:52 AM > > > > > > To: java-rft@omg.org, issues@omg.org > > > cc: > > > From: Russell Butek/Austin/IBM@IBMUS > > > Subject: Description of ORB.init parameters insufficient > > > > > > > > > 5. The spec doesn't allow for extensions. > > > > > > "See Table 1-3 for a list of the property names and values that are > > > recognized by > > > ORB.init. Any property names not in this list shall be ignored by > > > ORB.init()." > > > > > > Has the INS spec updated this table with -ORBInitRef and > > > -ORBDefaultInitRef, for example? And the interceptor spec assumes that > > > services are allowed to have their own arguments. And what about > > > proprietary extensions? Given the word "shall", any extensions are > > > non-CORBA-compliant. > > > > The INS spec should have explicitly identified the java mapping section > > to update, but we forgot. > > I think this is really editorial. (sort of like adding a new std > exception > > and forgetting to explicitly specify modifying the table in CORE). > > > > jeff > > I just used the INS spec as an example because I was aware of it. But I'm > more concerned with the statement "Any property names not in this list > shall be ignored by ORB.init()". This means that ORBs that have > proprietary properties are non-compliant. But more importantly, this also > means, at least to me, that a non-spec'ed service (we don't have specs for > logging, or workload management, for instance) CANNOT use > properties/arguments to set its state because the ORB SHALL ignore that > service's properties/arguments. In other words, when the ORB passes the > arguments to the ORBInitializer for that service (see the interceptor spec > - ptc/2000-04-05 section 21-7), that service's arguments will not be in the > list. > I believe you have misinterpreted this statement. It says that any additional properties *are* CORBA-compliant and shall be ignored by ORB.init(). They may be processed by any other code in the ORB, including com.mystuff.ORB.set_parameters(), but they are not processed by org.omg.CORBA.ORB.init(). Since org.omg.CORBA.ORB.init() does nothing more than instantiate an ORB and call its set_parameters() method, this seems correct to me. 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 From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA19490 for ; Tue, 30 May 2000 11:00:16 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id LAA25744 for ; Tue, 30 May 2000 11:19:55 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568EF.005437D1 ; Tue, 30 May 2000 11:19:53 -0400 X-Lotus-FromDomain: IBMUS To: java-rtf@omg.org Message-ID: <852568EF.0053EC23.00@d54mta04.raleigh.ibm.com> Date: Tue, 30 May 2000 11:16:37 -0400 Subject: Re: Description of ORB.init parameters insufficient Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: j' on 05/26/2000 04:18:53 PM > > > > I just used the INS spec as an example because I was aware of it. But I'm > > more concerned with the statement "Any property names not in this list > > shall be ignored by ORB.init()". This means that ORBs that have > > proprietary properties are non-compliant. But more importantly, this also > > means, at least to me, that a non-spec'ed service (we don't have specs for > > logging, or workload management, for instance) CANNOT use > > properties/arguments to set its state because the ORB SHALL ignore that > > service's properties/arguments. In other words, when the ORB passes the > > arguments to the ORBInitializer for that service (see the interceptor spec > > - ptc/2000-04-05 section 21-7), that service's arguments will not be in the > > list. > > > I believe you have misinterpreted this statement. It says that any additional > properties *are* CORBA-compliant and shall be ignored by ORB.init(). They may > be processed by any other code in the ORB, including com.mystuff.ORB.set_parameters(), > but they are not processed by org.omg.CORBA.ORB.init(). Since org.omg.CORBA.ORB.init() > does nothing more than instantiate an ORB and call its set_parameters() method, this > seems correct to me. > I hope I have misinterpreted this statement. If that's the case, then I'm glad to have it clarified and we can move on to my other points. I guess my problem is the definition of "ignored". I'd prefer to see the spec explicitly state what you've said above. Something like: "Any property names not in this list shall be ignored by ORB.init(), but the arguments to ORB.init () shall be passed, in their entirety, to set_parameters () which can determine if properties ignored by ORB.init () should be processed by the ORB implementation." You could argue that the given code already says this, but then why is it commented rather than explicitly given? Commenting it implies that it isn't a direct call, but that set_parameters gets called as part of some operation, an operation which could strip off properties that ORB.init is ignoring. I suppose simply uncommenting the call to set_parameters would suffice instead of my proposed textual changes above. Russell Butek butek@us.ibm.com Date: Fri, 17 May 2002 15:45:44 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Issue 3643 To: java-rtf@omg.org X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc This is a long issue, with 6 parts. Let's look at each part separately: 1. Java mapping spec only defines ORBClass and ORBSingletonClass. -ORB convention is not documented. This is now documented by a note in section 4.5.1 of the CORBA 3.0 spec, which states: Note - Whenever an ORB_init argument of the form -ORBxxx is specified, it is understooed that the argument may be represented in different ways in different languages. For example, in Java -ORBxxx is equivalent to a property named org.omg.CORBA.ORBxxx. This documents the equivalence, although we might decide to include this in the Java mapping spec as well. 2. Applet parameters not defined: assumed The mapping spec does not need to say this, as this is what java.applet.Applet.getParameter does, and the spec already states that applet parameters are searched for ORB configuration information. 3. Extend 1 to any arg/property correspondence This is already handled in CORBA 3.0 4.5.1. 4. Text for ORB class/singleton does not allow other args/properties. and 5. Spec does not allow for extensions. I think the previous discussion for this issue has clarified that parameters not specified in the mapping are ignored by ORB.init, but may not be ignored by other parts of the ORB, including ORB.set_parameters. This discussion really only applies to the org.omg.CORBA.ORB class, not to the proprietary subclasses that actually implement the ORB. 6. Repeated arguments don't work as properties. Currently, this is only a problem for ORBInitRef. This does indeed require special handling in parsing arguments, which is unfortunate. But solving this in general is ugly and probably not worthwhile. Given the above, I believe we should close this issue with no change. If there are no objections or desires to change the wording in the spec, I'll put this up for a vote next week. Ken. Subject: Re: Vote 2 To: Ken Cavanaugh Cc: java-rtf@omg.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Ann Dalton1" Date: Thu, 30 May 2002 09:36:48 +0100 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a |January 7, 2002) at 30/05/2002 09:36:10 Ken, IBM votes as follows on the issues in vote 2 4057 NO 3643 ABSTAIN Whilst I agree with most of what you say regarding the points listed in the issue, I do think it would be worthwhile, and not necessarily ugly, to solve point 6 "Repeated arguments don't work as properties". It seems to me we could take the definition of the PortableInterceptor ORBInitializerClass properties as an example giving the equivalent of java myapp -ORBInitRef XX=xx -ORBInitRef YY=yy -ORBInitRef ZZ=zz using system properties would be java myapp -Dorg.omg.CORBA.ORBInitRef.XX xx -Dorg.omg.CORBA.ORBInitRef.YY yy -Dorg.omg.CORBA.ORBInitRef.ZZ zz An