Issue 5430: Serious backward compatibility issue in the PI (corba-rtf) Source: Sun Microsystems (Mr. Ken Cavanaugh, kcavanaugh@acm.org) Nature: Uncategorized Issue Severity: Summary: I have recently realized that there is a serious backward compatibility issue in the PI changes introduced by the Object Reference Template. The problem is in the IORInterceptor. The original PI specification defined only the establish_components method on IORInterceptor. ORT added 3 new methods to this interface: components_established, adapter_state_changed, and adapter_manager_state_changed. The compatibility problem arises with the Java mapping. Prior to the CORBA 3.0 IDL to Java mapping, local interfaces were simply mapped to interfaces. The mapping for the CORBA 3.0 IORInterceptor is then simply: public interface IORInterceptorOperations extends org.omg.PortableInterceptor.InterceptorOperations { void establish_components (org.omg.PortableInterceptor.IORInfo info); void components_established (org.omg.PortableInterceptor.IORInfo info); void adapter_manager_state_changed (int id, short state); void adapter_state_changed ( org.omg.PortableInterceptor.ObjectReferenceTemplate[] templates, short state); } public interface IORInterceptor extends IORInterceptorOperations, org.omg.PortableInterceptor.Interceptor, org.omg.CORBA.portable.IDLEntity { } Any client of PI that implements IORInterceptor from CORBA 2.6 defines only the establish_components method, so that client will fail on a CORBA 3.0 version of PI. I propose the following changes to the draft CORBA 3.0 spec to fix this problem: In Section 21.5.4, replace the definition of IORInterceptor with: local interface IORInterceptor : Interceptor { void establish_components( in IORInfo info ) ; } ; local interface IORInterceptor_3_0 : IORInterceptor { void components_established( in IORInfo info ) ; void adapter_manager_state_changed( in AdapterManagerId id, in AdapterState state ) ; void adapter_state_changed( in ObjectReferenceTemplateSeq templates, in AdapterState state ) ; } ; Replace the first sentence in 21.5.4.2 with: After all of the establish_components methods have been called, the components_established methods are called on all registered IORInterceptor_3_0 instances. Replace the first sentence in 21.5.4.3 with: Any time the state of an adapter manager changes, the adapter_manager_state_changed method is invoked on all registered IORInterceptor_3_0 instances. Replace the first sentence in 21.5.4.4 with: Adapter state changes unrelated to adapter manager state changes are reported by invoking the adapter_state_changed method on all registered IORInterceptor_3_0 instances. Resolution: Resolve urgently as suggested Revised Text: This issue has been declared urgent. Revised Text: All changes relative to Draft CORBA 3.0 Chapters as in ptc/02-06-10 1. In Section 21.5.4, replace the definition of IORInterceptor with: local interface IORInterceptor : Interceptor { void establish_components( in IORInfo info ) ; } ; local interface IORInterceptor_3_0 : IORInterceptor { void components_established( in IORInfo info ) ; void adapter_manager_state_changed( in AdapterManagerId id, in AdapterState state ) ; void adapter_state_changed( in ObjectReferenceTemplateSeq templates, in AdapterState state ) ; } ; 2. Replace the first sentence in 21.5.4.2 with: "After all of the establish_components methods have been called, the components_established methods are called on all registered IORInterceptor_3_0 instances." 3. Replace the first sentence in 21.5.4.3 with: "Any time the state of an adapter manager changes, the adapter_manager_state_changed method is invoked on all registered IORInterceptor_3_0 instances." 4. Replace the first sentence in 21.5.4.4 with: "Adapter state changes unrelated to adapter manager state changes are reported by invoking the adapter_state_changed method on all registered IORInterceptor_3_0 instances." Actions taken: June 14, 2002: received issue April 28, 2003: closed issue Discussion: End of Annotations:===== Date: Thu, 13 Jun 2002 16:49:16 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: New PI/ORT issue To: issues@omg.org, core-rtf@omg.org Cc: ken.cavanaugh@sun.com X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc This is a core RTF issue. I have recently realized that there is a serious backward compatibility issue in the PI changes introduced by the Object Reference Template. The problem is in the IORInterceptor. The original PI specification defined only the establish_components method on IORInterceptor. ORT added 3 new methods to this interface: components_established, adapter_state_changed, and adapter_manager_state_changed. The compatibility problem arises with the Java mapping. Prior to the CORBA 3.0 IDL to Java mapping, local interfaces were simply mapped to interfaces. The mapping for the CORBA 3.0 IORInterceptor is then simply: public interface IORInterceptorOperations extends org.omg.PortableInterceptor.InterceptorOperations { void establish_components (org.omg.PortableInterceptor.IORInfo info); void components_established (org.omg.PortableInterceptor.IORInfo info); void adapter_manager_state_changed (int id, short state); void adapter_state_changed ( org.omg.PortableInterceptor.ObjectReferenceTemplate[] templates, short state); } public interface IORInterceptor extends IORInterceptorOperations, org.omg.PortableInterceptor.Interceptor, org.omg.CORBA.portable.IDLEntity { } Any client of PI that implements IORInterceptor from CORBA 2.6 defines only the establish_components method, so that client will fail on a CORBA 3.0 version of PI. I propose the following changes to the draft CORBA 3.0 spec to fix this problem: In Section 21.5.4, replace the definition of IORInterceptor with: local interface IORInterceptor : Interceptor { void establish_components( in IORInfo info ) ; } ; local interface IORInterceptor_3_0 : IORInterceptor { void components_established( in IORInfo info ) ; void adapter_manager_state_changed( in AdapterManagerId id, in AdapterState state ) ; void adapter_state_changed( in ObjectReferenceTemplateSeq templates, in AdapterState state ) ; } ; Replace the first sentence in 21.5.4.2 with: After all of the establish_components methods have been called, the components_established methods are called on all registered IORInterceptor_3_0 instances. Replace the first sentence in 21.5.4.3 with: Any time the state of an adapter manager changes, the adapter_manager_state_changed method is invoked on all registered IORInterceptor_3_0 instances. Replace the first sentence in 21.5.4.4 with: Adapter state changes unrelated to adapter manager state changes are reported by invoking the adapter_state_changed method on all registered IORInterceptor_3_0 instances. Ken. X-Sender: andrew@192.67.184.65 Date: Tue, 25 Jun 2002 04:56:02 +0100 To: Jishnu Mukerji , Ken Cavanaugh , corba-rtf@omg.org From: Andrew Watson Subject: Issue 5430 declared Urgent Cc: Juergen Boldt , Fred Waskiewicz Jishnu, Ken and members of the CORBA Core RTF Because of its impact on the forthcoming "Tiger" J2SE release, I'm declaring issue 5430 as urgent in accordance with the procedure laid out in section 4.4.1.5 of the P&P (pp/01-09-01). The summary of this issue can be found here: http://cgi.omg.org/issues/issue5430.txt The issue will be voted on by the Core RTF. The default resolution will be to apply the attached changes, submitted by Ken Cavanaugh when he filed the issue, to the draft CORBA 3.0 spec. This default resolution will be automatically applied if and only if the Core RTF fails to resolve the issue within 14 days (i.e. by Mon 8th July 2002). It is not necessarily the most desirable resolution. Even if the RTF decides to apply the default resolution, I strongly recommed that it makes this decision by a recorded vote. Default resolution ================== 1. In Section 21.5.4, replace the definition of IORInterceptor with: local interface IORInterceptor : Interceptor { void establish_components( in IORInfo info ) ; } ; local interface IORInterceptor_3_0 : IORInterceptor { void components_established( in IORInfo info ) ; void adapter_manager_state_changed( in AdapterManagerId id, in AdapterState state ) ; void adapter_state_changed( in ObjectReferenceTemplateSeq templates, in AdapterState state ) ; } ; 2. Replace the first sentence in 21.5.4.2 with: After all of the establish_components methods have been called, the components_established methods are called on all registered IORInterceptor_3_0 instances. 3. Replace the first sentence in 21.5.4.3 with: Any time the state of an adapter manager changes, the adapter_manager_state_changed method is invoked on all registered IORInterceptor_3_0 instances. 4. Replace the first sentence in 21.5.4.4 with: Adapter state changes unrelated to adapter manager state changes are reported by invoking the adapter_state_changed method on all registered IORInterceptor_3_0 instances. Thanks, Andrew Sender: jon@floorboard.com Date: Wed, 26 Jun 2002 11:08:08 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en To: Andrew Watson CC: Jishnu Mukerji , Ken Cavanaugh , corba-rtf@omg.org, Juergen Boldt , Fred Waskiewicz Subject: Re: Issue 5430 declared Urgent Andrew Watson wrote: > > Jishnu, Ken and members of the CORBA Core RTF > > Because of its impact on the forthcoming "Tiger" J2SE release, I'm > declaring issue 5430 as urgent in accordance with the procedure laid out in > section 4.4.1.5 of the P&P (pp/01-09-01). > > The summary of this issue can be found here: > > http://cgi.omg.org/issues/issue5430.txt > > The issue will be voted on by the Core RTF. > > The default resolution will be to apply the attached changes, submitted by > Ken Cavanaugh when he filed the issue, to the draft CORBA 3.0 spec. This > default resolution will be automatically applied if and only if the Core > RTF fails to resolve the issue within 14 days (i.e. by Mon 8th July 2002). > It is not necessarily the most desirable resolution. Even if the RTF > decides to apply the default resolution, I strongly recommed that it makes > this decision by a recorded vote. > > Default resolution > ================== > > 1. In Section 21.5.4, replace the definition of IORInterceptor with: > > local interface IORInterceptor : Interceptor { > void establish_components( in IORInfo info ) ; > } ; > > local interface IORInterceptor_3_0 : IORInterceptor { > void components_established( in IORInfo info ) ; I think the proposal is reasonable, but I dislike the idea of arbitrarily adding essentially meaningless numbers to the new interface to disambiguate it from the original. Can we please brainstorm a bit and see if we can come up with a descriptive name for the new interface instead? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 26 Jun 2002 17:48:09 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Jonathan Biggar Cc: Andrew Watson , Ken Cavanaugh , corba-rtf@omg.org, Fred Waskiewicz Subject: Re: Issue 5430 declared Urgent Please brainstorm away...... I assume that the basic structure of the proposal is considered sound? Let us take the next couple of days to resolve the "meaningless constants issue" and see if there is a reasonable alternative. Let us try to get closure by Monday July 1. Then I will send out a vote on the (possibly modified) resolution that comes out of the discussion, with votes due on July 8 Monday. Thanks, Jishnu. Jonathan Biggar wrote: > > Andrew Watson wrote: > > > > Jishnu, Ken and members of the CORBA Core RTF > > > > Because of its impact on the forthcoming "Tiger" J2SE release, I'm > > declaring issue 5430 as urgent in accordance with the procedure laid out in > > section 4.4.1.5 of the P&P (pp/01-09-01). > > > > The summary of this issue can be found here: > > > > http://cgi.omg.org/issues/issue5430.txt > > > > The issue will be voted on by the Core RTF. > > > > The default resolution will be to apply the attached changes, submitted by > > Ken Cavanaugh when he filed the issue, to the draft CORBA 3.0 spec. This > > default resolution will be automatically applied if and only if the Core > > RTF fails to resolve the issue within 14 days (i.e. by Mon 8th July 2002). > > It is not necessarily the most desirable resolution. Even if the RTF > > decides to apply the default resolution, I strongly recommed that it makes > > this decision by a recorded vote. > > > > Default resolution > > ================== > > > > 1. In Section 21.5.4, replace the definition of IORInterceptor with: > > > > local interface IORInterceptor : Interceptor { > > void establish_components( in IORInfo info ) ; > > } ; > > > > local interface IORInterceptor_3_0 : IORInterceptor { > > void components_established( in IORInfo info ) ; > > I think the proposal is reasonable, but I dislike the idea of > arbitrarily adding essentially meaningless numbers to the new interface > to disambiguate it from the original. > > Can we please brainstorm a bit and see if we can come up with a > descriptive name for the new interface instead? > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org -- Jishnu Mukerji Senior Systems Architect, SGBU Staff Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA tel:+1 973 443 7528 mailto:jishnu_mukerji@hp.com Date: Mon, 08 Jul 2002 14:36:01 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Jonathan Biggar Cc: corba-rtf@omg.org Subject: Re: Issue 5430 declared Urgent Jonathan Biggar wrote: > > > The default resolution will be to apply the attached changes, submitted by > > Ken Cavanaugh when he filed the issue, to the draft CORBA 3.0 spec. This > > default resolution will be automatically applied if and only if the Core > > RTF fails to resolve the issue within 14 days (i.e. by Mon 8th July 2002). > > It is not necessarily the most desirable resolution. Even if the RTF > > decides to apply the default resolution, I strongly recommed that it makes > > this decision by a recorded vote. > > > > Default resolution > > ================== > > > > 1. In Section 21.5.4, replace the definition of IORInterceptor with: > > > > local interface IORInterceptor : Interceptor { > > void establish_components( in IORInfo info ) ; > > } ; > > > > local interface IORInterceptor_3_0 : IORInterceptor { > > void components_established( in IORInfo info ) ; > > I think the proposal is reasonable, but I dislike the idea of > arbitrarily adding essentially meaningless numbers to the new interface > to disambiguate it from the original. > > Can we please brainstorm a bit and see if we can come up with a > descriptive name for the new interface instead? I was under the impression that the _3_0 suffix was added to denote that this change took effect in CORBA 3.0, and hence it did not appear o be particularly arbitrary to me. Jishnu. Date: Mon, 8 Jul 2002 12:23:56 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Issue 5430 declared Urgent To: jon@floorboard.com, jishnu_mukerji@hp.com Cc: corba-rtf@omg.org X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc >From: Jishnu Mukerji >X-Accept-Language: en >MIME-Version: 1.0 >To: Jonathan Biggar >Cc: corba-rtf@omg.org >Subject: Re: Issue 5430 declared Urgent >Content-Transfer-Encoding: 7bit > > > >Jonathan Biggar wrote: >> > >> > The default resolution will be to apply the attached changes, >submitted by >> > Ken Cavanaugh when he filed the issue, to the draft CORBA 3.0 >spec. This >> > default resolution will be automatically applied if and only if >the Core >> > RTF fails to resolve the issue within 14 days (i.e. by Mon 8th >July 2002). >> > It is not necessarily the most desirable resolution. Even if the >RTF >> > decides to apply the default resolution, I strongly recommed that >it makes >> > this decision by a recorded vote. >> > >> > Default resolution >> > ================== >> > >> > 1. In Section 21.5.4, replace the definition of IORInterceptor >with: >> > >> > local interface IORInterceptor : Interceptor { >> > void establish_components( in IORInfo info ) ; >> > } ; >> > >> > local interface IORInterceptor_3_0 : IORInterceptor { >> > void components_established( in IORInfo info ) ; >> >> I think the proposal is reasonable, but I dislike the idea of >> arbitrarily adding essentially meaningless numbers to the new >interface >> to disambiguate it from the original. >> >> Can we please brainstorm a bit and see if we can come up with a >> descriptive name for the new interface instead? > >I was under the impression that the _3_0 suffix was added to denote >that >this change took effect in CORBA 3.0, and hence it did not appear o >be >particularly arbitrary to me. > That was my intent, but I do not object to changing the name if the RTF wishes to do so. Note that Ann Dalton has another issue about remote-only interceptor registration that may similarly introduce a new module. That issue is not urgent, but perhaps similar considerations should apply. Ken. Subject: Re: Issue 5430 declared Urgent To: Ken Cavanaugh , jishnu_mukerji@hp.com, jon@floorboard.com Cc: corba-rtf@omg.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Ann Dalton1" Date: Mon, 8 Jul 2002 20:44:50 +0100 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a |January 7, 2002) at 08/07/2002 20:44:28 The _n_m suffix seemed preferable to the Ext suffix I had originally suggested for 5296, mainly because it's more extensible. What happens when we need to extend one of these interfaces again? I therefore revised that proposal accordingly. Issue 5439 also includes a proposed _3_x suffixed extended interface. Whatever is resolved here should apply to these two issues also. Ann Ken Cavanaugh cc: corba-rtf@omg.org Subject: Re: Issue 5430 declared Urgent 08/07/2002 20:23 Please respond to Ken Cavanaugh >From: Jishnu Mukerji >X-Accept-Language: en >MIME-Version: 1.0 >To: Jonathan Biggar >Cc: corba-rtf@omg.org >Subject: Re: Issue 5430 declared Urgent >Content-Transfer-Encoding: 7bit > > > >Jonathan Biggar wrote: >> > >> > The default resolution will be to apply the attached changes, submitted by >> > Ken Cavanaugh when he filed the issue, to the draft CORBA 3.0 >spec. Sender: jbiggar@Resonate.com Date: Mon, 08 Jul 2002 13:03:22 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en To: Jishnu Mukerji CC: corba-rtf@omg.org Subject: Re: Issue 5430 declared Urgent Jishnu Mukerji wrote: > > > The default resolution will be to apply the attached changes, submitted by > > > Ken Cavanaugh when he filed the issue, to the draft CORBA 3.0 spec. This > > > default resolution will be automatically applied if and only if the Core > > > RTF fails to resolve the issue within 14 days (i.e. by Mon 8th July 2002). > > > It is not necessarily the most desirable resolution. Even if the RTF > > > decides to apply the default resolution, I strongly recommed that it makes > > > this decision by a recorded vote. > > > > > > Default resolution > > > ================== > > > > > > 1. In Section 21.5.4, replace the definition of IORInterceptor with: > > > > > > local interface IORInterceptor : Interceptor { > > > void establish_components( in IORInfo info ) ; > > > } ; > > > > > > local interface IORInterceptor_3_0 : IORInterceptor { > > > void components_established( in IORInfo info ) ; > > > > I think the proposal is reasonable, but I dislike the idea of > > arbitrarily adding essentially meaningless numbers to the new interface > > to disambiguate it from the original. > > > > Can we please brainstorm a bit and see if we can come up with a > > descriptive name for the new interface instead? > > I was under the impression that the _3_0 suffix was added to denote that > this change took effect in CORBA 3.0, and hence it did not appear o be > particularly arbitrary to me. It's arbitrary in the sense that _3_0 doesn't mean anything useful other than that it was introduced in the 3.0 release. In that sense, it's no better or worse than using an "Ext" suffix, which I don't like either. I'll live with _3_0 if nothing better comes to mind, but I'd prefer something pithy that encapsulates the functionality or reason for the extended interface. Maybe something like "IORTemplateInterceptor" or something similar? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 09 Jul 2002 15:17:43 +0800 From: Kay Kit Chan Subject: Re: Issue 5430 declared Urgent To: Andrew Watson Cc: Jishnu Mukerji , Ken Cavanaugh , corba-rtf@omg.org, Juergen Boldt , Fred Waskiewicz , Ke Jin X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en Hi all, Sorry to bring this up at this point, and i'm not sure if this is a valid concern, but in the specification : Object Reference Template specification, ptc/2001-08-31 OMG Final Adopted Specification with FTF revisions October 2001 the IORInterceptor interface was actually defined as : local interface IORInterceptor : Interceptor { void establish_components (in IORInfo info); void components_established( in IORInfo info ) ; void adapter_manager_state_changed( in AdapterManagerId id, in AdapterState state ); void adapter_state_changed( in ObjectReferenceTemplateSeq templates, in AdapterState state ) ; }; Making the proposed changes will actually break implementations which are based on this final adopted specification. Rgds, Kay Kit Andrew Watson wrote: > Jishnu, Ken and members of the CORBA Core RTF > > Because of its impact on the forthcoming "Tiger" J2SE release, I'm > declaring issue 5430 as urgent in accordance with the procedure laid >out in > section 4.4.1.5 of the P&P (pp/01-09-01). > > The summary of this issue can be found here: > > http://cgi.omg.org/issues/issue5430.txt > > The issue will be voted on by the Core RTF. > > The default resolution will be to apply the attached changes, >submitted by > Ken Cavanaugh when he filed the issue, to the draft CORBA 3.0 >spec. This > default resolution will be automatically applied if and only if the >Core > RTF fails to resolve the issue within 14 days (i.e. by Mon 8th July >2002). > It is not necessarily the most desirable resolution. Even if the RTF > decides to apply the default resolution, I strongly recommed that it >makes > this decision by a recorded vote. > > Default resolution > ================== > > 1. In Section 21.5.4, replace the definition of IORInterceptor with: > > local interface IORInterceptor : Interceptor { > void establish_components( in IORInfo info ) ; > } ; > > local interface IORInterceptor_3_0 : IORInterceptor { > void components_established( in IORInfo info ) ; > > void adapter_manager_state_changed( in AdapterManagerId id, > in AdapterState state ) ; > > void adapter_state_changed( in ObjectReferenceTemplateSeq >templates, > in AdapterState state ) ; > } ; > > 2. Replace the first sentence in 21.5.4.2 with: > > After all of the establish_components methods have been called, the > components_established methods are called on all registered > IORInterceptor_3_0 instances. > > 3. Replace the first sentence in 21.5.4.3 with: > > Any time the state of an adapter manager changes, the > adapter_manager_state_changed method is invoked on all registered > IORInterceptor_3_0 instances. > > 4. Replace the first sentence in 21.5.4.4 with: > > Adapter state changes unrelated to adapter manager state changes are > reported by invoking the adapter_state_changed method on all >registered > IORInterceptor_3_0 instances. > > Thanks, > > Andrew -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. Date: Tue, 09 Jul 2002 12:28:27 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Kay Kit Chan Cc: Andrew Watson , Ken Cavanaugh , corba-rtf@omg.org, Juergen Boldt , Fred Waskiewicz , Ke Jin Subject: Re: Issue 5430 declared Urgent According to my understanding of the situation, unfortunately, the bug was in the finalized version of the ORT specification, which broke compatibility with existing implementations of CORBA Core (PI chapter), and that is what is getting fixed. Jishnu. Kay Kit Chan wrote: > > Hi all, > > Sorry to bring this up at this point, and i'm not sure if this is a valid > concern, but in the specification : > > Object Reference Template specification, ptc/2001-08-31 > OMG Final Adopted Specification with FTF revisions > October 2001 > > the IORInterceptor interface was actually defined as : > > local interface IORInterceptor : Interceptor { > void establish_components (in IORInfo info); > void components_established( in IORInfo info ) ; > void adapter_manager_state_changed( in AdapterManagerId id, > in AdapterState state ); > void adapter_state_changed( in ObjectReferenceTemplateSeq > templates, in AdapterState state ) ; > }; > > Making the proposed changes will actually break implementations which > are based on this final adopted specification. > > Rgds, > Kay Kit > > Andrew Watson wrote: > > > Jishnu, Ken and members of the CORBA Core RTF > > > > Because of its impact on the forthcoming "Tiger" J2SE release, I'm > > declaring issue 5430 as urgent in accordance with the procedure laid out in > > section 4.4.1.5 of the P&P (pp/01-09-01). > > > > The summary of this issue can be found here: > > > > http://cgi.omg.org/issues/issue5430.txt > > > > The issue will be voted on by the Core RTF. > > > > The default resolution will be to apply the attached changes, submitted by > > Ken Cavanaugh when he filed the issue, to the draft CORBA 3.0 spec. This > > default resolution will be automatically applied if and only if the Core > > RTF fails to resolve the issue within 14 days (i.e. by Mon 8th July 2002). > > It is not necessarily the most desirable resolution. Even if the RTF > > decides to apply the default resolution, I strongly recommed that it makes > > this decision by a recorded vote. > > > > Default resolution > > ================== > > > > 1. In Section 21.5.4, replace the definition of IORInterceptor with: > > > > local interface IORInterceptor : Interceptor { > > void establish_components( in IORInfo info ) ; > > } ; > > > > local interface IORInterceptor_3_0 : IORInterceptor { > > void components_established( in IORInfo info ) ; > > > > void adapter_manager_state_changed( in AdapterManagerId id, > > in AdapterState state ) ; > > > > void adapter_state_changed( in ObjectReferenceTemplateSeq templates, > > in AdapterState state ) ; > > } ; > > > > 2. Replace the first sentence in 21.5.4.2 with: > > > > After all of the establish_components methods have been called, the > > components_established methods are called on all registered > > IORInterceptor_3_0 instances. > > > > 3. Replace the first sentence in 21.5.4.3 with: > > > > Any time the state of an adapter manager changes, the > > adapter_manager_state_changed method is invoked on all registered > > IORInterceptor_3_0 instances. > > > > 4. Replace the first sentence in 21.5.4.4 with: > > > > Adapter state changes unrelated to adapter manager state changes are > > reported by invoking the adapter_state_changed method on all registered > > IORInterceptor_3_0 instances. > > > > Thanks, > > > > Andrew