Issue 4741: New issue on register_initial_reference (java-rtf) Source: Oracle (Mr. Ken Cavanaugh, nobody) Nature: Uncategorized Issue Severity: Summary: The portable interceptors specification added a new method to the ORB for registering initial references. This method needs to be added to the standard org.omg.CORBA.ORB class. We should simply add the register_initial_reference method to org.omg.CORBA.ORB and not create another version of the ORB class for this purpose. Proposed Resolution: Incorporate edits and close issue Revised Text: In section 1.19.10 in the PIDL section, add before resolve_initial_references: void register_initial_reference( in ObjectId identifier, in Object obj ) raises (InvalidName) ; in the Java section, add before resolve_initial_references: public void register_initial_reference( String id, org.omg.CORBA.Object obj ) throws InvalidName ; Also update the org.omg.CORBA.ORB class in the omg.zip file. Resolution: Incorporate joint resolution changes and close issue Revised Text: In section 1.19.10, add the following to the pseudo interface ORB: After the list_initial_services declaration: void register_initial_reference( in ObjectId id, in Object obj ) raises (InvalidName) ; After the create_abstract_interface_tc declaration: TypeCode create_local_interface_tc( in RepositoryId id, in Identifier name ) ; After the typedef for ObjectIdList: ORBId id() ; In section 1.19.10, delete the paragraph that begins "All types defined in this chapter are either part of the CORBA or ...". All of the IDL level definitions are in the pseudo interface ORB, which has nothing to do with Java packages. In section 1.19.10, add the following to the Java abstract class org.omg.CORBA.ORB: After the list_initial_services method: public void register_initial_reference( String object_name, org.omg.CORBA.Object object ) throws org.omg.CORBA.ORBPackage.InvalidName { throw new org.omg.CORBA.NO_IMPLEMENT() ; } After the create_abstract_interface_tc method: public TypeCode create_local_interface_tc( String id, String name ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } Also, fix the implementation of the create_abstract_interface_tc method to throw new org.omg.CORBA.NO_IMPLEMENT (it was missing the new). At the beginning, add: public String id() { throw new org.omg.CORBA.NO_IMPLEMENT() ; } At the end, add: public org.omg.CORBA.Object get_value_def( String repid ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public org.omg.CORBA.portable.ValueFactory register_value_factory( String id, org.omg.CORBA.portable.ValueFactory factory ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public void unregister_value_factory( String id ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public org.omg.CORBA.portable.ValueFactory lookup_value_factory( String id ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public void set_delegate( java.lang.Object wrapper ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } In section 1.19.10, add the following Java definition to the very end: package org.omg.CORBA_2_5 ; public abstract class ORB extends org.omg.CORBA_2_3.ORB { public String id() { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public void register_initial_reference( String object_name, org.omg.CORBA.Object object ) throws org.omg.CORBA.ORBPackage.InvalidName { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public TypeCode create_local_interface_tc( String id, String name ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } } Actions taken: December 7, 2001: received issue May 13, 2002: closed issue Discussion: End of Annotations:===== Date: Fri, 7 Dec 2001 17:45:03 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: New issue on register_initial_reference To: java-rtf@omg.org Cc: issues@omg.org MIME-Version: 1.0 Content-MD5: +yKjNeeaHF0fX/HPHgAwSw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: ?o1!!Y*S!!=OIe9~ond9 Status: RO The portable interceptors specification added a new method to the ORB for registering initial references. This method needs to be added to the standard org.omg.CORBA.ORB class. We should simply add the register_initial_reference method to org.omg.CORBA.ORB and not create another version of the ORB class for this purpose. Proposed Resolution: Incorporate edits and close issue Revised Text: In section 1.19.10 in the PIDL section, add before resolve_initial_references: void register_initial_reference( in ObjectId identifier, in Object obj ) raises (InvalidName) ; in the Java section, add before resolve_initial_references: public void register_initial_reference( String id, org.omg.CORBA.Object obj ) throws InvalidName ; Also update the org.omg.CORBA.ORB class in the omg.zip file. Ken. Date: Mon, 10 Dec 2001 07:16:39 +1000 (EST) From: Michi Henning To: Ken Cavanaugh cc: java-rtf@omg.org Subject: Re: New issue on register_initial_reference In-Reply-To: <200112080145.fB81j3707417@ha1sca-mail1.SFBay.Sun.COM> Message-ID: Organization: IONA Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: S8)e9MV;!!`!#!!]@0e9 On Fri, 7 Dec 2001, Ken Cavanaugh wrote: > The portable interceptors specification added a new method to the > ORB for registering initial references. This method needs to > be added to the standard org.omg.CORBA.ORB class. Find, that is a sensible place. But, without a way for an interceptor to get at the ORB, it doesn't really fix the problem, does it? Cheers, Michi. Date: Sun, 9 Dec 2001 18:08:31 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: New issue on register_initial_reference To: Ken.Cavanaugh@Sun.COM, michi.henning@iona.com Cc: java-rtf@omg.org MIME-Version: 1.0 Content-MD5: FCv2mG/Wyk5KE3gFxQ71wA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: !ah!!^b,e9B$W!!-KZ!! >From: Michi Henning >To: Ken Cavanaugh >cc: java-rtf@omg.org >Subject: Re: New issue on register_initial_reference >MIME-Version: 1.0 > >On Fri, 7 Dec 2001, Ken Cavanaugh wrote: > >> The portable interceptors specification added a new method to the >> ORB for registering initial references. This method needs to >> be added to the standard org.omg.CORBA.ORB class. > >Find, that is a sensible place. But, without a way for an interceptor >to >get at the ORB, it doesn't really fix the problem, does it? > I agree. But I'm not trying to fix the larger issue of PI access to the ORB. All I want to fix here is a minor discrepancy between CORBA 2.5 and the Java mapping. The ORB access issue needs to be handled in the core RTF first, then we need to see if there is any impact on the java mapping. Ken. From: Jeffrey Mischkinsky Message-Id: <200112080602.WAA12791@wheel.dcn.davis.ca.us> Subject: Re: New issue on register_initial_reference To: Ken.Cavanaugh@sun.com Date: Fri, 7 Dec 2001 22:02:03 -0800 (PST) Cc: java-rtf@omg.org, issues@omg.org In-Reply-To: <200112080145.fB81j3707417@ha1sca-mail1.SFBay.Sun.COM> from "Ken Cavanaugh" at Dec 07, 2001 05:45:03 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: -`Wd9k~ed9>i~e9l4I!! Status: RO Doesn't the new version need to be versioned? i.e. put in a new _2_x package? jeff 'Ken Cavanaugh' writes: > > The portable interceptors specification added a new method to the > ORB for registering initial references. This method needs to > be added to the standard org.omg.CORBA.ORB class. > > We should simply add the register_initial_reference method to > org.omg.CORBA.ORB and not create another version of the ORB > class for this purpose. > > Proposed Resolution: Incorporate edits and close issue > > Revised Text: > > In section 1.19.10 > in the PIDL section, add before resolve_initial_references: > > void register_initial_reference( in ObjectId identifier, > in Object obj ) raises (InvalidName) ; > > in the Java section, add before resolve_initial_references: > > public void register_initial_reference( String id, > org.omg.CORBA.Object obj ) throws InvalidName ; > > Also update the org.omg.CORBA.ORB class in the omg.zip file. > > Ken. > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff.mischkinsky@oracle.com +1 650-506-1975 Date: Mon, 10 Dec 2001 15:17:20 +0000 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: Jeffrey Mischkinsky CC: Ken.Cavanaugh@Sun.COM, java-rtf@omg.org Subject: Re: New issue on register_initial_reference References: <200112080602.WAA12791@wheel.dcn.davis.ca.us> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ,0%!!&/l!!XX\d9 > Doesn't the new version need to be versioned? > i.e. put in a new _2_x package? > > jeff > > 'Ken Cavanaugh' writes: > > > > The portable interceptors specification added a new method to the > > ORB for registering initial references. This method needs to > > be added to the standard org.omg.CORBA.ORB class. > > > > We should simply add the register_initial_reference method to > > org.omg.CORBA.ORB and not create another version of the ORB > > class for this purpose. > > > > Proposed Resolution: Incorporate edits and close issue > > > > Revised Text: > > > > In section 1.19.10 > > in the PIDL section, add before resolve_initial_references: > > > > void register_initial_reference( in ObjectId identifier, > > in Object obj ) raises (InvalidName) ; > > > > in the Java section, add before resolve_initial_references: > > > > public void register_initial_reference( String id, > > org.omg.CORBA.Object obj ) throws InvalidName ; > > > > Also update the org.omg.CORBA.ORB class in the omg.zip file. > > > > Ken. > > > > > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeff.mischkinsky@oracle.com +1 650-506-1975 -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Mon, 10 Dec 2001 12:27:41 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard Company X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ken Cavanaugh Cc: michi.henning@iona.com, java-rtf@omg.org, orb_revision@omg.org Subject: Re: New issue on register_initial_reference References: <200112100208.fBA28V711680@ha1sca-mail1.SFBay.Sun.COM> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 3FO!!Rp>!!?(m!!T7$e9 Ken Cavanaugh wrote: > > >From: Michi Henning > >To: Ken Cavanaugh > >cc: java-rtf@omg.org > >Subject: Re: New issue on register_initial_reference > >MIME-Version: 1.0 > > > >On Fri, 7 Dec 2001, Ken Cavanaugh wrote: > > > >> The portable interceptors specification added a new method to the > >> ORB for registering initial references. This method needs to > >> be added to the standard org.omg.CORBA.ORB class. > > > >Find, that is a sensible place. But, without a way for an interceptor to > >get at the ORB, it doesn't really fix the problem, does it? > > > > I agree. But I'm not trying to fix the larger issue of PI access to > the ORB. All I want to fix here is a minor discrepancy between CORBA 2.5 > and the Java mapping. The ORB access issue needs to be handled in > the core RTF first, then we need to see if there is any impact on the > java mapping. > > Ken. Michi, This really is your chance to propose a complete resolution for issue 3772 of Core RTF, and use the result for providing access to ORB in PI. Please please do so in this RTF cycle so that it can get into CORBA 3.0, 'cause otherwise you may have to hold your peace for a while.:-( Thanks, Jishnu. Date: Mon, 10 Dec 2001 11:03:10 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: New issue on register_initial_reference To: nash@hursley.ibm.com Cc: java-rtf@omg.org MIME-Version: 1.0 Content-MD5: Pm52oL2dKDgWSSoHXZgKDA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: nf>!!7MPe9:W/e9$>5e9 >From: Simon Nash >X-Accept-Language: en >MIME-Version: 1.0 >To: Jeffrey Mischkinsky >CC: Ken.Cavanaugh@sun.com, java-rtf@omg.org >Subject: Re: New issue on register_initial_reference >Content-Transfer-Encoding: 7bit > >Jeff, >I think it needs to be versioned, since on J2SE 1.3 and below the >core API >classes can't be changed by ORB vendors. > Simon, I agree that vendors have a problem for JDK 1.3. However, I do not want to continue to make the CORBA APIs more unusable in Java by creating more CORBA_X_Y packages. Perhaps we can do both: Add a new CORBA_2_5 package, and place register_initial_references in both org.omg.CORBA.ORB and in org.omg.CORBA_2_5.ORB. Then an application written on a JDK 1.3 based system can use the CORBA_2_5 ORB, while in JDK 1.4 and later it can use the CORBA ORB or the CORBA_2_5 ORB for backwards compatibility. I would like to do the same thing for CORBA_2_3 ORB methods: just copy them into CORBA ORB, so that programs written to the JDK 1.4 and later APIs have a simple CORBA API. Ken. Date: Mon, 10 Dec 2001 22:52:22 +0000 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: Ken Cavanaugh CC: java-rtf@omg.org Subject: Re: New issue on register_initial_reference References: <200112101903.fBAJ3A705764@ha1sca-mail1.SFBay.Sun.COM> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ]A%!!^h7e9_-Ee9)"Wd9 Ken, I agree with copying these added methods up to the base class every time the JDK is reved. They could also be removed from the X_Y subclass at the same time, since the X_Y subclass will inherit them from the base class. Fortunately from J2SE 1.4 we will no longer have this problem, since the mechanism for overriding endorsed standards will be available. Simon Ken Cavanaugh wrote: > > >From: Simon Nash > >X-Accept-Language: en > >MIME-Version: 1.0 > >To: Jeffrey Mischkinsky > >CC: Ken.Cavanaugh@sun.com, java-rtf@omg.org > >Subject: Re: New issue on register_initial_reference > >Content-Transfer-Encoding: 7bit > > > >Jeff, > >I think it needs to be versioned, since on J2SE 1.3 and below the core API > >classes can't be changed by ORB vendors. > > > > Simon, > > I agree that vendors have a problem for JDK 1.3. However, I do > not want to continue to make the CORBA APIs more unusable in Java > by creating more CORBA_X_Y packages. > > Perhaps we can do both: Add a new CORBA_2_5 package, and place > register_initial_references in both org.omg.CORBA.ORB and in > org.omg.CORBA_2_5.ORB. Then an application written on a JDK 1.3 > based system can use the CORBA_2_5 ORB, while in JDK 1.4 and > later it can use the CORBA ORB or the CORBA_2_5 ORB for backwards > compatibility. > > I would like to do the same thing for CORBA_2_3 ORB methods: just copy > them into CORBA ORB, so that programs written to the JDK 1.4 and later > APIs have a simple CORBA API. > > Ken. -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Mon, 10 Dec 2001 15:46:22 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: New issue on register_initial_reference To: Ken.Cavanaugh@sun.com, nash@hursley.ibm.com Cc: java-rtf@omg.org MIME-Version: 1.0 Content-MD5: /goTQ7Advk8dPTNCOD5a/A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: QV4!!18T!!Pp8e9Ok`!! >From: Simon Nash >X-Accept-Language: en >MIME-Version: 1.0 >To: Ken Cavanaugh >CC: java-rtf@omg.org >Subject: Re: New issue on register_initial_reference >Content-Transfer-Encoding: 7bit > >Ken, >I agree with copying these added methods up to the base class every >time >the JDK is reved. They could also be removed from the X_Y subclass >at the >same time, since the X_Y subclass will inherit them from the base >class. > Unfortunately, if the CORBA_X_Y classes were shipped in release n, they must still be shipped in release n+1. The JCK looks for exact signature matches, not binary compatibility, so we can't just move the methods, although logically this would make sense. >Fortunately from J2SE 1.4 we will no longer have this problem, since the >mechanism for overriding endorsed standards will be available. > Yes, that makes evolution easier going forward. Ken. Date: Tue, 11 Dec 2001 10:00:27 +0000 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: Ken Cavanaugh CC: java-rtf@omg.org Subject: Re: New issue on register_initial_reference References: <200112102346.fBANkN704831@ha1sca-mail1.SFBay.Sun.COM> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: p>`d9;E$!!LnE!!XR>e9 Ken, I don't understand this. There's nothing to stop signatures changing from one J2SE release to another as long as the change is backward compatible. So if release n has a method in a CORBA_X_Y class, there's no problem with release n+1 moving that method up to a base class instead. It's still necessary to ship an empty (and deprecated) CORBA_X_Y class in release n+1 to support old applications that use it, but since release n+1 doesn't need to pass release n's JCK, there's no problem with release n+1's CORBA_X_Y signature being different from release n's. Simon Ken Cavanaugh wrote: > > >From: Simon Nash > >X-Accept-Language: en > >MIME-Version: 1.0 > >To: Ken Cavanaugh > >CC: java-rtf@omg.org > >Subject: Re: New issue on register_initial_reference > >Content-Transfer-Encoding: 7bit > > > >Ken, > >I agree with copying these added methods up to the base class every time > >the JDK is reved. They could also be removed from the X_Y subclass at the > >same time, since the X_Y subclass will inherit them from the base class. > > > > Unfortunately, if the CORBA_X_Y classes were shipped in release n, > they must still be shipped in release n+1. The JCK looks for exact > signature matches, not binary compatibility, so we can't just move the > methods, although logically this would make sense. > > >Fortunately from J2SE 1.4 we will no longer have this problem, since the > >mechanism for overriding endorsed standards will be available. > > > > Yes, that makes evolution easier going forward. > > Ken. -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Tue, 11 Dec 2001 08:13:55 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: New issue on register_initial_reference To: nash@hursley.ibm.com Cc: java-rtf@omg.org MIME-Version: 1.0 Content-MD5: 5ajEWnSzj4Vz7TooH/VENg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: nRod9p8W!!K-gd921Y!! >From: Simon Nash >X-Accept-Language: en >MIME-Version: 1.0 >To: Ken Cavanaugh >CC: java-rtf@omg.org >Subject: Re: New issue on register_initial_reference >Content-Transfer-Encoding: 7bit > >Ken, >I don't understand this. There's nothing to stop signatures changing >from one >J2SE release to another as long as the change is backward >compatible. So if >release n has a method in a CORBA_X_Y class, there's no problem with >release n+1 >moving that method up to a base class instead. It's still necessary >to ship an >empty (and deprecated) CORBA_X_Y class in release n+1 to support old applications >that use it, but since release n+1 doesn't need to pass release n's >JCK, there's >no problem with release n+1's CORBA_X_Y signature being different >from release n's. You are confusing binary compatibility with JCK requirements. If a method is present in a derived in release n, we can't just move it to the base class in release n+1. This would be binary compatible, but when the JCKs from release n were applied to release n+1, they would fail. And this is not allowed by the JCK rules. Ken. Date: Tue, 11 Dec 2001 16:24:38 +0000 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: Ken Cavanaugh CC: java-rtf@omg.org Subject: Re: New issue on register_initial_reference References: <200112111613.fBBGDt716208@ha1sca-mail1.SFBay.Sun.COM> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: E-J!!6N7!!g^:e908?!! Ken, Thanks for the clarification. Can you point me to the JCK rule that states this? Simon Ken Cavanaugh wrote: > > >From: Simon Nash > >X-Accept-Language: en > >MIME-Version: 1.0 > >To: Ken Cavanaugh > >CC: java-rtf@omg.org > >Subject: Re: New issue on register_initial_reference > >Content-Transfer-Encoding: 7bit > > > >Ken, > >I don't understand this. There's nothing to stop signatures changing from one > >J2SE release to another as long as the change is backward compatible. So if > >release n has a method in a CORBA_X_Y class, there's no problem with release > n+1 > >moving that method up to a base class instead. It's still necessary to ship an > >empty (and deprecated) CORBA_X_Y class in release n+1 to support old > applications > >that use it, but since release n+1 doesn't need to pass release n's JCK, > there's > >no problem with release n+1's CORBA_X_Y signature being different from release > n's. > > You are confusing binary compatibility with JCK requirements. If a method is > present in a derived in release n, we can't just move it to the base class in > release n+1. This would be binary compatible, but when > the JCKs from release n were applied to release n+1, they would fail. > And this is not allowed by the JCK rules. > > Ken. -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Importance: Normal Subject: Re: Proposal for 4741 To: "Franz J. Hauck" Cc: java-rtf@omg.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ann Dalton1" Date: Thu, 13 Dec 2001 12:05:32 +0000 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.8 |June 18, 2001) at 13/12/2001 12:08:31 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: f_H!!Gn8!!W`0e9'Oe!! Franz, I think you're right. Unfortunately we missed this point when reviewing issue 4549 The issue stated:- Note: We do not need to create another version of the org.omg.CORBA package for this, for the following reasons: 1. The new preferred classes mechanism allows vendors to substitute a newer standard version of APIs in packages under org.omg into their JDK implementation. 2. Even without 1, we can evolve classes across major releases of the JDK by adding new methods. Whilst this may be true for JDK 1.4, many customers will continue to run on JDK 1.3 for some considerable time so I think we should, at least this time, continue with the old approach and add an org.omg.CORBA_2_5.ORB as you suggest. Ann ann_dalton@uk.ibm.com "Franz J. Hauck" @informatik.uni-erlangen.de on 13/12/2001 07:13:19 Sent by: Franz.Hauck@informatik.uni-erlangen.de To: issues@omg.org, java-rtf@omg.org cc: Subject: Proposal for 4741 > This is issue # 4741 Ken Cavanaugh > > New issue on register_initial_reference > > The portable interceptors specification added a new method to the > ORB for registering initial references. This method needs to > be added to the standard org.omg.CORBA.ORB class. > > We should simply add the register_initial_reference method to > org.omg.CORBA.ORB and not create another version of the ORB > class for this purpose. > > Proposed Resolution: Incorporate edits and close issue > > Revised Text: > > In section 1.19.10 > in the PIDL section, add before resolve_initial_references: > > void register_initial_reference( in ObjectId identifier, > in Object obj ) raises (InvalidName) ; > > in the Java section, add before resolve_initial_references: > > public void register_initial_reference( String id, > org.omg.CORBA.Object obj ) throws InvalidName ; I think just editing the org.omg.CORBA.ORB class will break compatibility with existing ORBs especially if they should be used together in one JVM (which is a rare case but in principle possible). If editing is the choice then there should be edits of org.omg.CORBA_2_3.ORB, but I don't think this makes any sense. As for the extension of CORBA 2.3 there should be a org.omg.CORBA_2_5 package containing an extension of ORB: package org.omg.CORBA_2_5; public abstract class ORB extends org.omg.CORBA_2_3.ORB { public java.lang.String id() { throw new org.omg.CORBA.NO_IMPLEMENT(); } public void register_initial_reference( java.lang.String id, org.omg.CORBA.Object obj ) throws org.omg.CORBA.ORBPackage.InvalidName { throw new org.omg.CORBA.NO_IMPLEMENT(); } abstract public org.omg.CORBA.TypeCode create_local_interface_tc( java.lang.String id, java.lang.String name); } As you see, there are two other methods that are not part of org.omg.CORBA_2_3.ORB and should be added due to CORBA 2.4 or 2.5 extensions. However, I don't read this list on a regular basis and there may have been other solutions to those methods that I'm not aware of. If those problems haven't been handled yet, we may need another issue or extend this one. Ciao Franz -- | Franz J. Hauck http://www4.informatik.uni-erlangen.de/~fzhauck/ `----------------------------------------------------------------------' "Ich glaub' ich muss mal aufschreiben, was der Papa immer alles sagt." Felicitas (7) Sender: Franz.Hauck@informatik.uni-erlangen.de Message-ID: <3C18550F.9F11AF9B@informatik.uni-erlangen.de> Date: Thu, 13 Dec 2001 08:13:19 +0100 From: "Franz J. Hauck" Organization: Informatik 4, Univ. Erlangen-Nuernberg X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: de-DE MIME-Version: 1.0 To: issues@omg.org, java-rtf@omg.org Subject: Proposal for 4741 References: <4.3.2.7.2.20011210141441.02758920@emerald.omg.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 1_jd9d^/e9%:=!!S%\!! > This is issue # 4741 Ken Cavanaugh > > New issue on register_initial_reference > > The portable interceptors specification added a new method to the > ORB for registering initial references. This method needs to > be added to the standard org.omg.CORBA.ORB class. > > We should simply add the register_initial_reference method to > org.omg.CORBA.ORB and not create another version of the ORB > class for this purpose. > > Proposed Resolution: Incorporate edits and close issue > > Revised Text: > > In section 1.19.10 > in the PIDL section, add before resolve_initial_references: > > void register_initial_reference( in ObjectId identifier, > in Object obj ) raises (InvalidName) ; > > in the Java section, add before resolve_initial_references: > > public void register_initial_reference( String id, > org.omg.CORBA.Object obj ) throws InvalidName ; I think just editing the org.omg.CORBA.ORB class will break compatibility with existing ORBs especially if they should be used together in one JVM (which is a rare case but in principle possible). If editing is the choice then there should be edits of org.omg.CORBA_2_3.ORB, but I don't think this makes any sense. As for the extension of CORBA 2.3 there should be a org.omg.CORBA_2_5 package containing an extension of ORB: package org.omg.CORBA_2_5; public abstract class ORB extends org.omg.CORBA_2_3.ORB { public java.lang.String id() { throw new org.omg.CORBA.NO_IMPLEMENT(); } public void register_initial_reference( java.lang.String id, org.omg.CORBA.Object obj ) throws org.omg.CORBA.ORBPackage.InvalidName { throw new org.omg.CORBA.NO_IMPLEMENT(); } abstract public org.omg.CORBA.TypeCode create_local_interface_tc( java.lang.String id, java.lang.String name); } As you see, there are two other methods that are not part of org.omg.CORBA_2_3.ORB and should be added due to CORBA 2.4 or 2.5 extensions. However, I don't read this list on a regular basis and there may have been other solutions to those methods that I'm not aware of. If those problems haven't been handled yet, we may need another issue or extend this one. Ciao Franz -- | Franz J. Hauck http://www4.informatik.uni-erlangen.de/~fzhauck/ `----------------------------------------------------------------------' "Ich glaub' ich muss mal aufschreiben, was der Papa immer alles sagt." Felicitas (7) Date: Tue, 18 Dec 2001 15:00:20 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Joint resolution for issues 4741, 4549, 4750, 4748 To: java-rtf@omg.org MIME-Version: 1.0 Content-MD5: 8fpTAYJ3/E2Sjji2C7Oplg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: