Issue 5454: Java Codebase tagged component and POA (java2idl-rtf) Source: Sun Microsystems (Mr. Everett Anderson, ) Nature: Uncategorized Issue Severity: Summary: The Java to IDL specification uses the IOR TaggedComponent TAG_JAVA_CODEBASE to transmit a codebase string used to download stubs and ties. Yet, at IOR creation time when using the POA, the ORB may not know the implementing servant, so may not be able to determine the correct codebase. I propose solving this by the creationg of a standard POA Policy for the Java codebase component. A POA using this policy will add the given codebase string as the TAG_JAVA_CODEBASE component in the IORs which it creates. (Someone using a single given POA for supporting multiple servant types would of course have to include the codebases for all of them.) Proposed resolution: 1. Add a section in CORBA 11.3.7: 11.3.7.x Java Codebase Policy Objects with the JavaCodebasePolicy interface are obtained using the ORB::create_policy operation and passed to the POA::create_POA operation to specify the TAG_JAVA_CODEBASE TaggedComponent's value that should be used in this POA's IORs. The any passed to ORB::create_policy should contain a string which is a space-separated list of one or more URLs, as described in the Java to IDL mapping (formal/01-06-07), Codebase Transmission. 2. Add the following to the IDL in CORBA 11.4: const CORBA::PolicyType JAVA_CODEBASE_POLICY_ID = nn; [note to editor: number to be assigned by OMG] local interface JavaCodebasePolicy : CORBA::Policy { readonly attribute string codebase; }; Resolution: see above Revised Text: 1. Add a section in CORBA 11.3.7: 11.3.7.x Java Codebase Policy Objects with the JavaCodebasePolicy interface are obtained using the ORB::create_policy operation and passed to the POA::create_POA operation to specify the TAG_JAVA_CODEBASE TaggedComponent's value that must be used in this POA's IORs. The any passed to ORB::create_policy must contain a string which is a space-separated list of one or more URLs, as described in the Java to IDL mapping (formal/01-06-07), Codebase Transmission. 2. Add the following to the IDL in CORBA 11.4: const CORBA::PolicyType JAVA_CODEBASE_POLICY_ID = nn; [note to editor: number to be assigned by OMG] local interface JavaCodebasePolicy : CORBA::Policy { readonly attribute string codebase; }; Actions taken: July 9, 2002: received issue July 1, 2003: closed issue Discussion: Proposed resolution: 1. Add a section in CORBA 11.3.7: 11.3.7.x Java Codebase Policy Objects with the JavaCodebasePolicy interface are obtained using the ORB::create_policy operation and passed to the POA::create_POA operation to specify the TAG_JAVA_CODEBASE TaggedComponent's value that should be used in this POA's IORs. The any passed to ORB::create_policy should contain a string which is a space-separated list of one or more URLs, as described in the Java to IDL mapping (formal/01-06-07), Codebase Transmission. 2. Add the following to the IDL in CORBA 11.4: const CORBA::PolicyType JAVA_CODEBASE_POLICY_ID = nn; [note to editor: number to be assigned by OMG] local interface JavaCodebasePolicy : CORBA::Policy { readonly attribute string codebase; }; End of Annotations:===== Date: Tue, 09 Jul 2002 12:06:30 -0700 From: Everett Anderson X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf,ja To: issues@omg.org CC: core-rtf@omg.org, java2idl-rtf@omg.org Subject: New issue: Java Codebase tagged component and POA Hi, I'd like to raise the following as an issue for the Java to IDL or core RTF (the changes are in the main CORBA spec). The Java to IDL specification uses the IOR TaggedComponent TAG_JAVA_CODEBASE to transmit a codebase string used to download stubs and ties. Yet, at IOR creation time when using the POA, the ORB may not know the implementing servant, so may not be able to determine the correct codebase. I propose solving this by the creationg of a standard POA Policy for the Java codebase component. A POA using this policy will add the given codebase string as the TAG_JAVA_CODEBASE component in the IORs which it creates. (Someone using a single given POA for supporting multiple servant types would of course have to include the codebases for all of them.) Proposed resolution: 1. Add a section in CORBA 11.3.7: 11.3.7.x Java Codebase Policy Objects with the JavaCodebasePolicy interface are obtained using the ORB::create_policy operation and passed to the POA::create_POA operation to specify the TAG_JAVA_CODEBASE TaggedComponent's value that should be used in this POA's IORs. The any passed to ORB::create_policy should contain a string which is a space-separated list of one or more URLs, as described in the Java to IDL mapping (formal/01-06-07), Codebase Transmission. 2. Add the following to the IDL in CORBA 11.4: const CORBA::PolicyType JAVA_CODEBASE_POLICY_ID = nn; [note to editor: number to be assigned by OMG] local interface JavaCodebasePolicy : CORBA::Policy { readonly attribute string codebase; }; - Everett X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 09 Jul 2002 12:32:02 -0700 To: Everett Anderson , issues@omg.org From: Andy Piper Subject: Re: New issue: Java Codebase tagged component and POA Cc: core-rtf@omg.org, java2idl-rtf@omg.org Actually I was going to raise a related issue, which I think needs to be solved also. When doing class evolution the methods provided by the org.omg.SendingContext.CodeBase object in the SendingContextRuntime are not sufficient for determining classes with the same name in different classloaders. For instance meta() just takes a string that is the repositoryid. One way to solve this would be to add a codebase argument to some of the functions. andy At 12:06 PM 7/9/02 -0700, Everett Anderson wrote: Hi, I'd like to raise the following as an issue for the Java to IDL or core RTF (the changes are in the main CORBA spec). The Java to IDL specification uses the IOR TaggedComponent TAG_JAVA_CODEBASE to transmit a codebase string used to download stubs and ties. Yet, at IOR creation time when using the POA, the ORB may not know the implementing servant, so may not be able to determine the correct codebase. I propose solving this by the creationg of a standard POA Policy for the Java codebase component. A POA using this policy will add the given codebase string as the TAG_JAVA_CODEBASE component in the IORs which it creates. (Someone using a single given POA for supporting multiple servant types would of course have to include the codebases for all of them.) Proposed resolution: 1. Add a section in CORBA 11.3.7: 11.3.7.x Java Codebase Policy Objects with the JavaCodebasePolicy interface are obtained using the ORB::create_policy operation and passed to the POA::create_POA operation to specify the TAG_JAVA_CODEBASE TaggedComponent's value that should be used in this POA's IORs. The any passed to ORB::create_policy should contain a string which is a space-separated list of one or more URLs, as described in the Java to IDL mapping (formal/01-06-07), Codebase Transmission. 2. Add the following to the IDL in CORBA 11.4: const CORBA::PolicyType JAVA_CODEBASE_POLICY_ID = nn; [note to editor: number to be assigned by OMG] local interface JavaCodebasePolicy : CORBA::Policy { readonly attribute string codebase; }; - Everett Date: Tue, 09 Jul 2002 13:40:01 -0700 From: Everett Anderson X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf,ja To: Andy Piper CC: core-rtf@omg.org, java2idl-rtf@omg.org Subject: Re: New issue: Java Codebase tagged component and POA Hi Andy, > Actually I was going to raise a related issue, which I think needs to be > solved also. When doing class evolution the methods provided by the > org.omg.SendingContext.CodeBase object in the SendingContextRuntime are not > sufficient for determining classes with the same name in different > classloaders. For instance meta() just takes a string that is the > repositoryid. One way to solve this would be to add a codebase argument to > some of the functions. Would you try to give an example of this? It seems like if a receiver needs information to unmarshal an evolved class, the best thing to ask is the CodeBase of the sender -- what we do today. When would a sender send multiple versions of the same class to the same receiver in one session? Also, given a java.lang.Class instance, is there a way to determine from where it was loaded? - Everett Date: Tue, 9 Jul 2002 17:33:49 -0400 (EDT) From: Bob Scheifler - SMI Software Development Reply-To: Bob Scheifler - SMI Software Development Subject: Re: New issue: Java Codebase tagged component and POA To: andyp@bea.com Cc: java2idl-rtf@omg.org X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc > When doing class evolution the methods provided by the > org.omg.SendingContext.CodeBase object in the SendingContextRuntime > are not > sufficient for determining classes with the same name in different > classloaders. FYI, I raised this back in August 1997 and again in July 1998, but I don't have a record of what the response was (other than that no change was made). - Bob Date: Tue, 9 Jul 2002 17:40:46 -0400 (EDT) From: Bob Scheifler - SMI Software Development Reply-To: Bob Scheifler - SMI Software Development Subject: Re: New issue: Java Codebase tagged component and POA To: everett.anderson@sun.com Cc: core-rtf@omg.org, java2idl-rtf@omg.org X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc > When would a sender send multiple versions of the same class to the same > receiver in one session? A given VM loads a class of the same name from two different codebases, loading them into different class loaders. The resulting classes can have the same repository ID but different FullValueDescriptions. Send instances of those two classes together, as fields of some larger object, in a single call. - Bob Date: Wed, 10 Jul 2002 09:30:44 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Bob Scheifler - SMI Software Development CC: everett.anderson@sun.com, core-rtf@omg.org, java2idl-rtf@omg.org Subject: Re: New issue: Java Codebase tagged component and POA Bob, If the classes are different, then they would not have the same repository ID. The RMI Hashed Format for repository IDs includes a structural hash of the datatype. So any two RMI types that would return different FVD information from the meta() method will have different repository IDs. Simon Bob Scheifler - SMI Software Development wrote: > > > When would a sender send multiple versions of the same class to the same > > receiver in one session? > > A given VM loads a class of the same name from two different codebases, > loading them into different class loaders. The resulting classes can have > the same repository ID but different FullValueDescriptions. Send instances > of those two classes together, as fields of some larger object, in a single > call. > > - Bob -- Simon C Nash, Chief Technical Officer, IBM Java Technology Hursley Park, Winchester, UK nash@hursley.ibm.com Tel. +44-1962-815156 Fax +44-1962-818999 Date: Wed, 10 Jul 2002 09:38:22 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Everett Anderson CC: core-rtf@omg.org, java2idl-rtf@omg.org Subject: Re: New issue: Java Codebase tagged component and POA Everett, I'm concerned about the global nature of this setting. I'd prefer a more flexible approach that allows IORs of different types to be created using different codebase strings. This could be done by the IOR interceptor if it had access to a table mapping IOR types to codebase strings. Simon Everett Anderson wrote: > > Hi, > > I'd like to raise the following as an issue for the Java to IDL or > core RTF (the changes are in the main CORBA spec). > > The Java to IDL specification uses the IOR TaggedComponent > TAG_JAVA_CODEBASE to transmit a codebase string used to download stubs > and ties. Yet, at IOR creation time when using the POA, the ORB may > not know the implementing servant, so may not be able to determine the > correct codebase. > > I propose solving this by the creationg of a standard POA Policy for > the Java codebase component. A POA using this policy will add the > given codebase string as the TAG_JAVA_CODEBASE component in the IORs > which it creates. (Someone using a single given POA for supporting > multiple servant types would of course have to include the codebases > for all of them.) > > Proposed resolution: > > 1. Add a section in CORBA 11.3.7: > > 11.3.7.x Java Codebase Policy > > Objects with the JavaCodebasePolicy interface are obtained using the > ORB::create_policy operation and passed to the POA::create_POA > operation to specify the TAG_JAVA_CODEBASE TaggedComponent's value > that should be used in this POA's IORs. The any passed to > ORB::create_policy should contain a string which is a space-separated > list of one or more URLs, as described in the Java to IDL mapping > (formal/01-06-07), Codebase Transmission. > > 2. Add the following to the IDL in CORBA 11.4: > > const CORBA::PolicyType JAVA_CODEBASE_POLICY_ID = nn; > [note to editor: number to be assigned by OMG] > > local interface JavaCodebasePolicy : CORBA::Policy { > readonly attribute string codebase; > }; > > - Everett -- Simon C Nash, Chief Technical Officer, IBM Java Technology Hursley Park, Winchester, UK nash@hursley.ibm.com Tel. +44-1962-815156 Fax +44-1962-818999 Date: Wed, 10 Jul 2002 09:46:52 -0400 (EDT) From: Bob Scheifler - SMI Software Development Reply-To: Bob Scheifler - SMI Software Development Subject: Re: New issue: Java Codebase tagged component and POA To: nash@hursley.ibm.com Cc: core-rtf@omg.org, java2idl-rtf@omg.org X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc > If the classes are different, then they would not have the same repository ID. > The RMI Hashed Format for repository IDs includes a structural hash of the > datatype. So any two RMI types that would return different FVD information > from the meta() method will have different repository IDs. That's not correct. The RMI: repository ID hash only covers the fields, it doesn't cover the complete contents of the FVD. So it is possible to have two classes with the same fields, but varying in other aspects of the FVD, and thus have the same repository ID. - Bob Date: Wed, 10 Jul 2002 09:57:10 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: New issue: Java Codebase tagged component and POA To: everett.anderson@sun.com, nash@hursley.ibm.com Cc: core-rtf@omg.org, java2idl-rtf@omg.org X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc >From: Simon Nash >X-Accept-Language: en >MIME-Version: 1.0 >To: Everett Anderson >CC: core-rtf@omg.org, java2idl-rtf@omg.org >Subject: Re: New issue: Java Codebase tagged component and POA >Content-Transfer-Encoding: 7bit > >Everett, >I'm concerned about the global nature of this setting. I'd prefer a >more >flexible approach that allows IORs of different types to be created >using >different codebase strings. This could be done by the IOR >interceptor if >it had access to a table mapping IOR types to codebase strings. > > Simon > Simon, A lot of the work in Portable Interceptors which the Object Reference Template proposal built upon has been designed so that everything in the IOR except the object ID is known completely when the object adapter is constructed. This allows an ORB to take advantage of this fact to optimize the representation and marshalling of IORs internally. Obviously this works a bit differently than the pure (non-POA) RMI-IIOP case, where the servant is always available when the object reference (and hence the IOR) is constructed. Also, note that the IOR interceptor only runs when the object adapter is created. It does not run when the IOR/objref is created (and never has, going back to the first merged PI submission over 2 years ago). So I don't see any way that an IOR interceptor could be used here. Do you have a real use case in mind that requires more flexibility? I would much rather have specific examples rather than a general wish for more flexibility. Ken. X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 10 Jul 2002 17:33:23 -0700 To: Simon Nash , Bob Scheifler - SMI Software Development From: Andy Piper Subject: Re: New issue: Java Codebase tagged component and POA Cc: everett.anderson@sun.com, core-rtf@omg.org, java2idl-rtf@omg.org At 09:30 AM 7/10/02 +0100, Simon Nash wrote: If the classes are different, then they would not have the same repository ID. The RMI Hashed Format for repository IDs includes a structural hash of the datatype. So any two RMI types that would return different FVD information from the meta() method will have different repository IDs. Which is probably good enough for serialization. andy Date: Thu, 11 Jul 2002 09:54:43 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Bob Scheifler - SMI Software Development CC: core-rtf@omg.org, java2idl-rtf@omg.org Subject: Re: New issue: Java Codebase tagged component and POA Bob, You are correct that the FVD contains other information (e.g., methods) but this information would not be used by RMI-IIOP serialization versioning code that calls the meta() method. So while there is a theoretical issue, I don't think it will cause any problems in practice. Simon Bob Scheifler - SMI Software Development wrote: > > > If the classes are different, then they would not have the same repository ID. > > The RMI Hashed Format for repository IDs includes a structural hash of the > > datatype. So any two RMI types that would return different FVD information > > from the meta() method will have different repository IDs. > > That's not correct. The RMI: repository ID hash only covers the fields, > it doesn't cover the complete contents of the FVD. So it is possible > to have two classes with the same fields, but varying in other aspects > of the FVD, and thus have the same repository ID. > > - Bob -- Simon C Nash, Chief Technical Officer, IBM Java Technology Hursley Park, Winchester, UK nash@hursley.ibm.com Tel. +44-1962-815156 Fax +44-1962-818999 Date: Mon, 15 Jul 2002 19:53:14 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Ken Cavanaugh CC: everett.anderson@sun.com, core-rtf@omg.org, java2idl-rtf@omg.org Subject: Re: New issue: Java Codebase tagged component and POA Ken, The spec allows the IOR interceptor to run when the IOR is created, but does not require it. So you are correct that implementations cannot rely on this. The use case I have in mind is different servant implementations loaded by different classloaders that have different codebase paths, where the programmer wants to create IORs that have a TAG_JAVA_CODEBASE component containing a precise codebase path for the stub type of the object reference being created. However, with Everett's proposal it would be possible to achieve this using different POAs, each with a different Java codebase policy. It would then be up to the application to select the appropriate POA with which to create each object reference, using some kind of mapping table. This puts more work on the application, but it is a simple mechanism that is easy to explain and understand, so on balance I think it is a reasonable solution. Simon Ken Cavanaugh wrote: > > >From: Simon Nash > >X-Accept-Language: en > >MIME-Version: 1.0 > >To: Everett Anderson > >CC: core-rtf@omg.org, java2idl-rtf@omg.org > >Subject: Re: New issue: Java Codebase tagged component and POA > >Content-Transfer-Encoding: 7bit > > > >Everett, > >I'm concerned about the global nature of this setting. I'd prefer a more > >flexible approach that allows IORs of different types to be created using > >different codebase strings. This could be done by the IOR interceptor if > >it had access to a table mapping IOR types to codebase strings. > > > > Simon > > > > Simon, > > A lot of the work in Portable Interceptors which the Object Reference > Template proposal built upon has been designed so that everything in > the IOR except the object ID is known completely when the object adapter > is constructed. This allows an ORB to take advantage of this fact to > optimize the representation and marshalling of IORs internally. > Obviously this works a bit differently than the > pure (non-POA) RMI-IIOP case, where the servant is always available when the > object reference (and hence the IOR) is constructed. Also, note that > the IOR interceptor only runs when the object adapter is created. > It does not run when the IOR/objref is created (and never has, going > back to the first merged PI submission over 2 years ago). So I don't see > any way that an IOR interceptor could be used here. > > Do you have a real use case in mind that requires more flexibility? I would > much rather have specific examples rather than a general wish for more > flexibility. > > Ken. -- Simon C Nash, Chief Technical Officer, IBM Java Technology Hursley Park, Winchester, UK nash@hursley.ibm.com Tel. +44-1962-815156 Fax +44-1962-818999 Date: Mon, 15 Jul 2002 15:28:11 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: New issue: Java Codebase tagged component and POA To: nash@hursley.ibm.com Cc: everett.anderson@sun.com, core-rtf@omg.org, java2idl-rtf@omg.org X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc >From: Simon Nash >X-Accept-Language: en >MIME-Version: 1.0 >To: Ken Cavanaugh >CC: everett.anderson@sun.com, core-rtf@omg.org, java2idl-rtf@omg.org >Subject: Re: New issue: Java Codebase tagged component and POA >Content-Transfer-Encoding: 7bit > >Ken, >The spec allows the IOR interceptor to run when the IOR is created, >but does >not require it. So you are correct that implementations cannot rely >on this. > The spec (as of the 3.0 draft, ptc/02-02-01 section 21.5.4.1) now says the following: A server side ORB calls the establish_components operation on all registered IORInterceptor instances when it is assempling the list of components that will be included in the profile or profiles of an object reference. The operation is not necessarily called for each individual object reference. In the case of the POA, these calls are made each time POA::create_POA is called. This was modified in the ORT submission from the PI submission adopted version. Certainly my intent in this passage was that IORInterceptors are called ONLY during create_POA, but an implementation that called establish_components both during create_POA and create_reference_xxx does not contradict this passage (I probably should have said "these calls are made only when POA::create_POA is called", but I didn't). >The use case I have in mind is different servant implementations loaded by >different classloaders that have different codebase paths, where the programmer >wants to create IORs that have a TAG_JAVA_CODEBASE component containing a >precise codebase path for the stub type of the object reference being created. > Ok, this is clearly the common EJB case. >However, with Everett's proposal it would be possible to achieve this using >different POAs, each with a different Java codebase policy. It would then be >up to the application to select the appropriate POA with which to create each >object reference, using some kind of mapping table. > In general, app servers should use a POA per unique set of policies, but many may not. Ken. Date: Wed, 24 Jul 2002 12:07:19 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en To: everett.anderson@sun.com CC: java2idl-rtf@omg.org, core-rtf@omg.org Subject: Re: issue 5454 -- Java to IDL RTF issue Everett, As a friendly amendment, can I suggest changing "should" to "must" in two places in your proposed text, to give the following: Objects with the JavaCodebasePolicy interface are obtained using the ORB::create_policy operation and passed to the POA::create_POA operation to specify the TAG_JAVA_CODEBASE TaggedComponent's value that must be used in this POA's IORs. The any passed to ORB::create_policy must contain a string which is a space-separated list of one or more URLs, as described in the Java to IDL mapping (formal/01-06-07), Codebase Transmission. Simon Juergen Boldt wrote: > > This is issue # 5454 Everett Anderson > Java Codebase tagged component and POA > > The Java to IDL specification uses the IOR TaggedComponent > TAG_JAVA_CODEBASE to transmit a codebase string used to download stubs > and ties. Yet, at IOR creation time when using the POA, the ORB may > not know the implementing servant, so may not be able to determine the > correct codebase. > > I propose solving this by the creationg of a standard POA Policy for > the Java codebase component. A POA using this policy will add the > given codebase string as the TAG_JAVA_CODEBASE component in the IORs > which it creates. (Someone using a single given POA for supporting > multiple servant types would of course have to include the codebases > for all of them.) > > Proposed resolution: > > 1. Add a section in CORBA 11.3.7: > > 11.3.7.x Java Codebase Policy > > Objects with the JavaCodebasePolicy interface are obtained using the > ORB::create_policy operation and passed to the POA::create_POA > operation to specify the TAG_JAVA_CODEBASE TaggedComponent's value > that should be used in this POA's IORs. The any passed to > ORB::create_policy should contain a string which is a space-separated > list of one or more URLs, as described in the Java to IDL mapping > (formal/01-06-07), Codebase Transmission. > > 2. Add the following to the IDL in CORBA 11.4: > > const CORBA::PolicyType JAVA_CODEBASE_POLICY_ID = nn; > [note to editor: number to be assigned by OMG] > > local interface JavaCodebasePolicy : CORBA::Policy { > readonly attribute string codebase; > }; > > ================================= > Juergen Boldt > Director, Member Services > > Object Management Group > 250 First Avenue, Suite 201 > Needham, MA 02494 > > Tel. +1 781 444 0404 ext. 132 > Fax: +1 781 444 0320 > email: juergen@omg.org > www www.omg.org > > ================================ -- Simon C Nash, Chief Technical Officer, IBM Java Technology Hursley Park, Winchester, UK nash@hursley.ibm.com Tel. +44-1962-815156 Fax +44-1962-818999 Date: Wed, 24 Jul 2002 10:57:50 -0700 From: Everett Anderson X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf,ja To: Simon Nash CC: java2idl-rtf@omg.org, core-rtf@omg.org Subject: Re: issue 5454 -- Java to IDL RTF issue > As a friendly amendment, can I suggest changing "should" to "must" in > two places in your proposed text, to give the following: Yes, thank you! > > Objects with the JavaCodebasePolicy interface are obtained using > the > ORB::create_policy operation and passed to the POA::create_POA > operation to specify the TAG_JAVA_CODEBASE TaggedComponent's value > that must be used in this POA's IORs. The any passed to > ORB::create_policy must contain a string which is a > space-separated > list of one or more URLs, as described in the Java to IDL mapping > (formal/01-06-07), Codebase Transmission. > > Simon