Added classes are indeed generated from idl present in Security Server Specification which is part of Corba 3.3 specification. I can find no information about formal corba compliance process. Can you please point me to people who can help me regarding this?
Regards, Tomek -- Tomasz Adamski Software Engineer JBoss by Red Hat ----- Original Message ----- > From: "Alan Bateman" <alan.bate...@oracle.com> > To: "Andrew Dinn" <ad...@redhat.com>, "Tomasz Adamski" <tadam...@redhat.com> > Cc: core-libs-dev@openjdk.java.net > Sent: Wednesday, May 4, 2016 5:37:56 PM > Subject: Re: RFR: 8152084: Introduction of ssliop protocol to corbaloc > > > On 04/05/2016 15:53, Andrew Dinn wrote: > > : > > Just to dispel any idea that this has been plucked out of thin air by > > the JacORB implementors I'll note that there appears to be both a > > standard for and more than one implementation of ssliop. > > > > Regarding implementations, OpenORB and TAO also implemented it. > > > > As regards standardization I think the relevant info is in the interop > > documentation found at http://www.omg.org/spec/CORBA/3.3/. Look in part > > 2 of the spec dealing with interoperability and search for IIOP/SSL. > > Tomek may be able to clarify whether that provides all the relevant > > information. > > > I have a general concern that this might be overlaying part of CORBA 3.3 > over an API/implementation that is based on CORBA 2.3.1. I don't know > what the compliance issues are here and what certification is required > to claim CORBA 3.3 or even partial compliance. So I expect there is more > work to do than might initially seem. Aside from stating compliance then > this will require tests and I don't see these in the patch. I don't see > any javadoc either (I realize some of strangely named classes might be > generated from IDL). > > -Alan >