Issue 2661: Valuetype packages (java-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: For certain IDL types defined in an interface Foo, the Java classes are placed in the package FooPackage. The reason given in the mapping document is that Java classes cannot be defined in Java interfaces, therefore a new package is required. However, since valuetypes are defined as abstract classes, does that imply that IDL types such as struct, exception, etc., that are defined within a valuetype are mapped to nested classes of the valuetype class? Or is a separate package used, a la interfaces? Resolution: Revised Text: In section 1.2.1, change the fifth bullet to: * The nested scope Java package name <type>Package, where <type> is the name of an IDL interface, valuetype, struct, union or exception (Section 1.17, "Mapping for Certain Nested Types," on page 1-61). And in section 1.17, change the text to: IDL allows type declarations nested within interfaces. Java does not allow classes to be nested within interfaces. Hence those IDL types that map to Java classes and that are declared within the scope of an interface must appear in a special "scope" package when mapped to Java. For consistency, the "scope" package is also used for those IDL type declarations nested within valuetypes, structs, unions and exceptions. IDL types that contain these nested type declarations will generate a scope package to contain the mapped Java class declarations. The scope package name is constructed by appending Package to the IDL type name. Actions taken: May 25, 1999: received issue January 9, 2001: closed issue Discussion: End of Annotations:===== X-Sender: mark@192.168.1.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 24 May 1999 16:55:43 -0700 To: java-rtf@omg.org From: Mark Spruiell Subject: Valuetype packages Cc: us@ooc.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: f9cae275e6a470e484fefe433f872720 Hi, For certain IDL types defined in an interface Foo, the Java classes are placed in the package FooPackage. The reason given in the mapping document is that Java classes cannot be defined in Java interfaces, therefore a new package is required. However, since valuetypes are defined as abstract classes, does that imply that IDL types such as struct, exception, etc., that are defined within a valuetype are mapped to nested classes of the valuetype class? Or is a separate package used, a la interfaces? Thanks, Mark -- Mark E. Spruiell Object-Oriented Concepts, Inc. mes@ooc.com * http://www.ooc.com * 1-978-439-9285 x 247 Date: Mon, 29 Nov 1999 23:47:03 +0000 From: Owen Rees To: mchapman@iona.com, firewall-rtf@omg.org Subject: RE: Round 1 - issue 2661 Message-ID: <3321385705.943919223@localhost> In-Reply-To: <001701bf3a6e$650b0da0$4d01020a@leo.dublin.iona.ie> X-Mailer: Mulberry (Win32) [2.0.0b1, s/n P005-300802-002] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: Owen_Rees@hpl.hp.com Content-Type: text/plain; charset=us-ascii X-UIDL: !gld9f_[!!n1Rd9R63e9 --On 29 November 1999 13:34 +0000 Martin Chapman wrote: > Issue 2261: passthrough connection (firewall-rtf) > Section 4.13, Page 4-27, para just after figure 4-10: > > Add: " The client issues a new_target using C as the target object > to > connect to and a mode argument of PASSTHRU or PASSTHRUONLY." The second sentence of the paragraph is very similar, and I think this wording will not fit well. If the idea is to describe the example in Fig 4-10, then it would be better to add "At step (1), the client could have used a mode argument of PASSTHRUONLY.", if matching the example is not important, just put "or PASSTHRUONLY" after "PASSTHRU". While on the subject of PASSTHRU, the last paragraph before the new_callback heading on page 4-15 needs fixing. That paragraph applies only to NORMAL. For a PASSTHRU[ONLY] connection, the returned object must contain the same object key as in the profile whose connection data will be used to contact the target - since the proxy "is not able to examine" (and presumably not modify) the traffic, the client must use the object key expected by the target server. This also means that there must be a separate connection for each target host/port pair. My preference is to just delete this paragraph. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 Reply-To: From: "Martin Chapman" To: "Owen Rees" , Subject: RE: Round 1 - issue 2661 Date: Tue, 30 Nov 1999 16:15:21 -0000 Message-ID: <002301bf3b4e$197d6780$4d01020a@leo.dublin.iona.ie> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <3321385705.943919223@localhost> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: &~Ce98o6!!Z_[d9fCL!! An interesting observation I hadn't made before - in passthru[only] you should use the target's object_key and not the key of the object returned by new_target. The first para of the new target section needs to be changed as well. Well spotted. Martin. > > While on the subject of PASSTHRU, the last paragraph before the > new_callback heading on page 4-15 needs fixing. That paragraph > applies only > to NORMAL. For a PASSTHRU[ONLY] connection, the returned object must > contain the same object key as in the profile whose connection > data will be > used to contact the target - since the proxy "is not able to examine" (and > presumably not modify) the traffic, the client must use the object key > expected by the target server. This also means that there must be a > separate connection for each target host/port pair. My preference is to > just delete this paragraph. > > > Regards, > Owen Rees > Hewlett Packard Laboratories, Bristol, UK > tel: +44 117 312 9439 fax: +44 117 312 9285 > Reply-To: From: "Martin Chapman" To: "Owen Rees" , Subject: RE: Round 1 - issue 2661 Date: Tue, 30 Nov 1999 16:15:21 -0000 Message-ID: <002301bf3b4e$197d6780$4d01020a@leo.dublin.iona.ie> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <3321385705.943919223@localhost> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: &~Ce98o6!!Z_[d9fCL!! An interesting observation I hadn't made before - in passthru[only] you should use the target's object_key and not the key of the object returned by new_target. The first para of the new target section needs to be changed as well. Well spotted. Martin. > > While on the subject of PASSTHRU, the last paragraph before the > new_callback heading on page 4-15 needs fixing. That paragraph > applies only > to NORMAL. For a PASSTHRU[ONLY] connection, the returned object must > contain the same object key as in the profile whose connection > data will be > used to contact the target - since the proxy "is not able to examine" (and > presumably not modify) the traffic, the client must use the object key > expected by the target server. This also means that there must be a > separate connection for each target host/port pair. My preference is to > just delete this paragraph. > > > Regards, > Owen Rees > Hewlett Packard Laboratories, Bristol, UK > tel: +44 117 312 9439 fax: +44 117 312 9285 > X-Sender: mark@192.168.1.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 07 Feb 2000 10:51:06 -0800 To: Mary Leland , Java RTF , Vishy Kasar , Russell Butek From: Mark Spruiell Subject: Re: IDL to Java RTF Administrivia - Proposed resolution for 2661 In-Reply-To: <389EE3A3.BED3BA41@fpk.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: kmh!!<-+e9jJ]!!]I)!! Hi Mary, Best of luck as chair. I'll propose a resolution for issue 2661. The mapping for IDL types nested within valuetypes should follow the same semantics as for interfaces. Here is the rationale: 1) The mapping currently doesn't use nested classes. 2) An abstract valuetype maps to a Java interface, so a "scope" package is necessary. But a concrete valuetype maps to an abstract Java class which could conceivably use nested classes. However, we shouldn't use *two* mappings for types nested within valuetypes, dependent on whether the valuetype is abstract or concrete. 3) Last but not least, it's the simplest and most consistent solution. So, here are the proposed changes: In section 1.2.1, change the fifth bullet to: * The nested scope Java package name Package, where is the name of an IDL interface or valuetype (Section 1.17, "Mapping for Certain Nested Types," on page 1-61). And in section 1.17, change the text to: IDL allows type declarations nested within interfaces. Java does not allow classes to be nested within interfaces. Hence those IDL types that map to Java classes and that are declared within the scope of an interface must appear in a special "scope" package when mapped to Java. For consistency, the "scope" package is also used for those IDL type declarations nested within valuetypes. IDL interfaces and valuetypes that contain these type declarations will generate a scope package to contain the mapped Java class declarations. The scope package name is constructed by appending Package to the IDL type name. Take care, Mark -- Mark E. Spruiell Object Oriented Concepts, Inc. mes@ooc.com * http://www.ooc.com * 1-978-439-9285 x 247 >Issue 2661: Valuetype packages (java-rtf) > > > > >Click here for this issue's archive. >Source: Object Oriented Concepts (Mr. Mark Spruiell, >mes@ooc.com) >Nature: Uncategorized Issue >Severity: >Summary: For certain IDL types defined in an interface Foo, the Java >classes are placed in the package FooPackage. The reason given in the >mapping document is that Java classes cannot be defined in Java >interfaces, therefore a new package is required. However, since valuetypes >are defined as abstract classes, does that imply that IDL types such as >struct, exception, etc., that are defined within a valuetype are mapped to >nested classes of the valuetype class? Or is a separate package used, a la >interfaces? >Resolution: >Revised Text: >Actions taken: >May 25, 1999: received issue >January 19, 2000: deferred > >Discussion: X-Sender: mark@192.168.1.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 28 Feb 2000 15:21:17 -0800 To: java-rtf@omg.org From: Mark Spruiell Subject: Followup on Issue 2661 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: "@Qd9c'\!!Ee8e9Adh!! In issue 2661, I raised the issue of the mapping for nested types specifically within valuetypes. However, the issue also applies to types nested within structs, unions and exceptions. For example: // IDL struct S { union U switch(boolean) { case FALSE: string name; } the_U; }; Therefore, I'll change my proposed resolution to the following. In section 1.2.1, change the fifth bullet to: * The nested scope Java package name Package, where is the name of an IDL interface, valuetype, struct, union or exception (Section 1.17, "Mapping for Certain Nested Types," on page 1-61). And in section 1.17, change the text to: IDL allows type declarations nested within interfaces. Java does not allow classes to be nested within interfaces. Hence those IDL types that map to Java classes and that are declared within the scope of an interface must appear in a special "scope" package when mapped to Java. For consistency, the "scope" package is also used for those IDL type declarations nested within valuetypes, structs, unions and exceptions. IDL types that contain these nested type declarations will generate a scope package to contain the mapped Java class declarations. The scope package name is constructed by appending Package to the IDL type name. -- Mark E. Spruiell Object Oriented Concepts, Inc. mes@ooc.com * http://www.ooc.com * 1-978-439-9285 x 247