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
> 

Reply via email to