Issues for IDL/Java Revision Task Force mailing list

List of Open Issues. Other options: All Issues; Closed Issues.

(red=unresolved; yellow=pending Board vote)

Summary: The search for an orb.properties file to set a default ORB class and
 ORB Singleton class looks only in the JDK lib directory.  In many
 installations, this is read-only (e.g., on a shared drive) and not
 updatable by users.  To allow users of these JDK installations to
 set a default ORB, the search order should be:
  1. The user"s home directory (user.home system property)
  2. The <java.home>/lib directory.
 

Summary: The first bullet of the search order for an ORB implementation class
 name in section 25.21.7 is:
  . check in Applet parameter or application string array, if any
 This seems wrong

Delete the words

     "or application string array, if any"

from the first bullet in Section 21.9 (note that section

numbering has changed since this issue was filed).

Summary: The Mapping of OMG IDL to Java, Section 25-20, Mapping for Struct, has a
 String field that is not initialized.  I would like to consider that the
 String value is initialized to a empty String within a Struct eg., String
 foo = new String();
 
 I have an application with a Sequence of Structs.  The Struct has two
 attributes, a boolean and String.  The boolean is initialized to "false"
 but the String is not initialized.  When I try to add the containing
 object, the attribute of Sequence of Structs fails.  I do not want to
 require the use to initialize each Struct within the Sequence  before
 createing the object.
 
 
 

In Section 25-20, Mapping for Struct, have the String value be initialized to


an empty String within a Struct eg., String foo = "";

Summary: When we split the mapping of interfaces into the operations and signature
 interfaces, we had to make a decision what to do with constants that are
 declared within interfaces.
 At the time it seemed that most analogous thing to do was to leave it on
 the signature interface.
 Upon further consideration it would probably be better if it were on the
 operations interface. This would make it available on the server side. This
 is a backwards compatible change because operations is inherited by the
 signature interface so the contstant would still be visible to clients
 without changing their code. It only involves a small change to the
 generated code.
 

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?
 

The Messaging Specification was adopted before Java Portability
layer was really in place. In order to make portability work
with the asynchronous stubs which will in future be generated, 
some things may be added to the portability interface.


Each stub has a sendc_<op> and sendp_<op> operation which
will need to call on the portable stub layer.

A first glance at the requirements to make a portable 
implementation suggest that a sendc_invoke and sendp_invoke
operation will probably need to be added to ObjectImpl and
Delegate.

I dont know if this is viewed as a "compatible" class change
for JDK, or whether we will need to put derived classes 
in CORBA_3_0 package....

Move to Java RTF?  Clearly an IDL Java mapping issue. Send to IDL-Java RTF 

All system exceptions have the following constructors, (BAD_PARAM as eg.)

BAD_PARAM();
BAD_PARAM(int minor_code, CompletionStatus status);
BAD_PARAM(String message);
BAD_PARAM(String message, int minor_code, CompletionStatus status);

UnknownException however has only one. This seems inconsistent.

Proposal:

Add the following constructors to org.omg.CORBA.portable.UnknownException
UnknownException(Throwable orig, int minor_code, CompletionStatus status);
UnknownException(Throwable orig, String message);
UnknownException(Throwable orig, String message, int minor_code,
CompletionStatus status);

I have a number of questions/concerns about the description/usage of
ORB.init arguments/properties.

1.  There are only two properties described in the Java mapping spec:
org.omg.CORBA.ORBClass and org.omg.CORBA.ORBSingletonClass.  Setting these
via property are described, but not setting these via application string
array (ie., args in main).  Yet the spec says these values can be obtained
via the args array.  I believe most folks assume "-ORBClass xxx" is the
convention, since that's what the JDK's ORB uses, but it's not documented.


2.  Ditto for applet parameters.  It's assumed that they are of the form

<param name = "org.omg.CORBA.ORBClass" value = "xxx">

but it is not documented.


3.  Can this convention be generalized to accommodate the argument naming
convention in the core spec?  If we follow the convention that says
org.omg.CORBA.ORBClass becomes -ORBClass; then can we say that a parameter
-ORBXXX may also be specified by the property or applet parameter
org.omg.CORBA.ORBXXX?


4.  The text around the ORB arguments is tightly coupled to only ORBClass
and ORBSingletonClass.  It does not seem to expect other args/properties.
For example:  "...when creating an ORB instance, the class names of the ORB
implementation are located using the following search order: ...".  I
assume the following search order also applies to any args/props.


5.  The spec doesn't allow for extensions.

"See Table 1-3 for a list of the property names and values that are
recognized by
ORB.init. Any property names not in this list shall be ignored by
ORB.init()."

Has the INS spec updated this table with -ORBInitRef and
-ORBDefaultInitRef, for example?  And the interceptor spec assumes that
services are allowed to have their own arguments.  And what about
proprietary extensions?  Given the word "shall", any extensions are
non-CORBA-compliant.


6.  Repeated arguments fall apart when presented as Properties.  For
example, the INS spec allows for the following invocation:

java myapp -ORBInitRef XX=xx -ORBInitRef YY=yy -ORBInitRef ZZ=zz

Since Properties entries are <key, value> pairs, and only one pair for a
given key can exist, then if we tried entering the above as Properties we'd
only get on of them, not all.  I'm not sure how to fix this.  Dictate that
XX, YY, ZZ be the end of the ORBInitRef string rather than the start of a
new string, perhaps?  So then, specifying these as system properties for
example, we'd have:

java myapp -Dorg.omg.CORBA.ORBInitRefXX xx -Dorg.omg.CORBA.ORBInitRefYY yy
-Dorg.omg.CORBA.ORBInitRefZZ zz

That causes ugly parsing problems.  We'd have to search the whole list of
properties that contained a key that merely BEGAN with
"org.omg.CORBA.ORBInitRef".  And this falls apart in applets; we can get a
list of all Properties, but we cannot get a list of all applet parameters.
Personally I think this is a failing in the applet class, but that's life
as we know it.


I'm sorry to raise this as one issue instead of six, but most of these
points are tightly coupled, so I didn't want to distance them from each
other.  And I'd like them all to be answered together anyway.

We notice the following discrepancies with org.omg.PortableServer package
published as part of 00-02-01.tar at the OMG web site.  We need to get
these issues resolved as soon as possible (especially before the next release
of JDK).

(1).  Following specified interfaces have an extra inheritance from 
an org.omg.CORBA.Object interface.
	
	org.omg.PortableServer.Current.java
	org.omg.PortableServer.ServantActivator
	org.omg.PortableServer.ServantLocator

e.g., the actual inheritance hierarchy for Current should be:

	public interface Current extends CurrentOperations, 
		org.omg.CORBA.Current, org.omg.CORBA.portable.IDLEntity

        whereas, in the OMG published interfaces it is:

	public interface Current extends 
org.omg.PortableServer.CurrentOperations,
                             org.omg.CORBA.Current,
                             org.omg.CORBA.portable.IDLEntity,
                             org.omg.CORBA.Object

	PLS. NOTE AN EXTRA INHERITANCE FROM org.omg.CORBA.Object interface,
	which should not be there, since there is already an inheritance from
	org.omg.CORBA.Current. Same for other interfaces.
	

(3).   org.omg.PortableServer.ServantLocatorPackage.CookieHelper.java is 
published for "native" Cookie.  The IDL to Java specification does not specify
mapping for Helper classes for native types, nor does it mention that one
exists for native types.  This should be removed as part of the ZIP file
or the IDL to Java specification needs to be modified to completely specify the
mapping for CookieHelper.java

There are several reasons that Java ORB.init should support
ORBId (without compromising security).  For example:

- Services built on Portable Interceptors work in relation to the ORB
with which they are registered.  There needs to be some means of
identifying this ORB (besides its reference) so other services or
facades (e.g., JNDI) can use the same ORB.

- A Server Activation Framework needs an ORB Id to identify a particular
orb (which hosts a persistent POA) within a server.  The triple:
server id, orb id, poa name is *conceptually* embedded in the adapter
id of a POA making it unique.

  Incorporate change and close issue. However, this is out-of-scope for the interceptors FTF. It is being
transferred to the IDL to java RTF.

The IDL to Java mapping spec (ptc/00-02-07) defines the
mapping for IDL to Enums to Java.  The generated enum
class contains a method

public static <TYPE> from_int( int i )

However, the mapping spec does not call for an exception
to be thrown if the parameter does not correspond to a
valid enum for this enum type.

ptc/00-02-08 defines the standard Java classes for
the PIDL native types and the ORB portability interfaces.
It includes several IDL enums in org.omg.CORBA:

AttributeMode, CompletionStatus, DefinitionKind, OperationMode,
ParameterMode, PrimitiveKind, SetOverrideType, and TCKind.

All have signatures similar to:

public static TCKind from_int( int val ) throws org.omg.CORBA.BAD_PARAM

This is not compliant with the specification.

If we look at the definition of BAD_PARAM, it is a SystemException, which
extends java.lang.RuntimeException, so BAD_PARAM, like all system exceptions,
is an unchecked java exception.  Consequently there is no need to declare
BAD_PARAM in the signature of the from_int methods.  However, the behavior is
useful and should be specified.

I think this issue should be resolved with the following changes:

1. Update ptc/00-02-08.zip to remove the "throws BAD_PARAM" clauses
   on all from_int methods for enums.
   
2. Update ptc/00-02-07 section 1.7 as follows:

replace the paragraph

	"The java class for the enum has an additional method from_int(),
	which returns the enum with the specified value."
	
with

	"The java class for the enum has an additional method from_int(),
	which returns the enum with the specified value if the specified
	value corresponds to an element of the enum.  If the specified
	value is out of range, a BAD_PARAM exception with a minor code
	of XXX is raised."
	
where as usual XXX needs to be filled in with an appropriate minor code.

The first two bullets in Section 1.1.1.1 of ptc/2000-07-03
refer to the fields DEFAULT_ORB and DEFAULT_ORB_SINGLETON in
omg/omg/CORBA/ORB.java.  However, these fields do not exist
in that file (nor are they in org/omg/CORBA_2_3/ORB.java).
The intention of these bullets is to permit vendors to
appropriately modify the implementations of the ORB_init
methods, but since these methods are not implemented using
those fields, the intention is not achieved.

Proposed resolution:
   Add a point #3 to Section 1.1, along the lines of
   "In certain rare cases, the actual body of a method
   must be replaced by a vendor-specific implementation.
   These cases are clearly identified in this specification
   and by comments in the org.omg.* packages."

   Change the first two bullets in Section 1.1.1.1 to
   "Vendor-specific implementations for the ORB_init
   methods of org.omg.CORBA.ORB must be supplied.
   Since these methods are static, they cannot be
   overridden by the vendor-specific ORB subclass,
   but must be provided in the org.omg.CORBA.ORB class
   itself."

   Add a comment 
       /* VENDOR MUST SUPPLY IMPLEMENTATION */
   to the ORB_init methods, and a line in the
   header comments of the org/omg/CORBA/ORB.java
   file saying that implementations of the ORB_init
   methods are required.

Proposed resolution:

   Add a point #3 to Section 1.1, along the lines of

   "In certain rare cases, the actual body of a method

   must be replaced by a vendor-specific implementation.

   These cases are clearly identified in this specification

   and by comments in the org.omg.* packages."



   Change the first two bullets in Section 1.1.1.1 to

   "Vendor-specific implementations for the init

   methods of org.omg.CORBA.ORB must be supplied.

   Since these methods are static, they cannot be

   overridden by the vendor-specific ORB subclass,

   but must be provided in the org.omg.CORBA.ORB class

   itself."



   Add a comment 

       /* VENDOR MUST SUPPLY IMPLEMENTATION */

   to the init methods, and a line in the

   header comments of the org/omg/CORBA/ORB.java

   file saying that implementations of the init

   methods are required.

In order to meet the interoperability compliance requirements,
ORBs must include an IIOP implementation using TCP/IP plain text
sockets. J2EE implementations are required to support CSIv2 and
thus need additional control over the sockets an ORB creates.
It may be necessary
-  to get the ORB to listen on additional sockets, of differing
   types
-  to get the ORB to connect to alternative sockets, of different
   types, for a given IOR
-  for information about these sockets to be included in object
   references exported by the ORB
-  for socket data to be available to request interceptors, e.g
   SSL certificates


Portable IORInterceptors can be used to add this information as
tagged components in the profiles within an IOR.


A mechanism is required to modify the ORB's behaviour to allow
it to handle different socket types, listen on additional sockets,
connect to alternative sockets and make additional data available
to interceptors.


Since this is a J2EE requirement which needs speedy resolution,
it seems appropriate to resolve it by the addition of Java
specific APIs in the IDL to Java specification. For example,


-  a pluggable ORB socket factory could be introduced which would
   be used whenever the ORB needed to create a serverSocket or an
   outbound socket for a given IOR or end point


-  a means of registering such a socket factory would be required.
   Options for this include:-
   . adding an ORB method: this may cause problems in initialisation
   . adding a Java specific extension to the PI ORBInitInfo interface
     so that the registration would need to be called from the
     pre_init/post_init methods in an ORBInitializer: this ties the
     Socket Factory with PIs, but both are likely to be required
     for J2EE.


-  a means of specifying ports on which an ORB/POA should listen
   would be useful but this may be infeasible as part of this issue
   due to the variety of ORB/POA implementations.


-  the PI Client and ServerRequestInfo and IORInfo interfaces may
   need to be extended to support access to Connection related data

The Java source code for org.omg.PortableServer.POAOperations in ptc/02-06-14 defines the method create_reference_with_id as throwing org.omg.PortableServer.POAPackage.WrongPolicy. However, the CORBA/IIOP 2.4 specification (formal/00-10-01) specifies this operation as NOT raising any exceptions (see section 11.3.8.19). Which is correct?

The resolution of issue #3668 should have removed the definition of FixedHolder. There is no need for a Holder for an anonymous Fixed type since none can be defined. Type specific Holders are necessary in order to define the correct read and write operations that use the write_fixed and read_fixed defined by the resolution of 3668.


Proposed resolution:
Remove the definition of FixedHolder from section 1.4.1.4 (page 1-11).

In ptc/02-01-01, the latest (?) compendium of predefined code for the IDL to Java mapping, the enumerations values captured in org.omg.CORBA.SetOverrideType are SET_OVERRIDE and ADD. The correct values are SET_OVERRIDE and ADD_OVERRIDE.

http://www.omg.org/docs/formal/02-08-05.pdf section 1.21.3 IDLEntity inclides the Serializable interface, but if an IDLEntity has a union, it will result in Holder classes (i.e. FloatHolder) which do not implement the Serializable interface. This results in NotSerializable exceptions being created when trying to use such objects with java serialization. The quick fix would be to specify that "public interface Streamable" should extend java.io.Serializable, since the holder classes extend from that as well.