> > > I'm using the standard jdk orb. I also get a security
> exception when
> > > trying to use the Singleton orb instance - this is a bit
> > > strange as the
> > > documentation implies the access to this should only be
> > > restricted when
> > > using an applet. This is a bit of a drag, as calling
> > > org.omg.CORBA.ORB.init(args, props) will create a new orb
> > > instance each
> > > time which isn't very efficient if done for every call.
> I don't think it matters what the arguments are - init(args, props)
> will always return a new instance. What are ORBNames? I wasn't aware
> you could name orbs. POAs have names but I don't think orbs do.
>
"ORBName" is not mentioned in the CORBA spec. However there's a thing called "ORBid".
The "ORBid" is used for identifying an ORB within a process.
"ORBName" is used in by (at least) one of the leading CORBA vendors for... ehmmm....
naming ORBs (in this case the ORBName is used for selecting configuration settings
where the settings are grouped by compound names, i.e. foo.goo.MyORB). Sorry for the
confusion!
> > This is not only inefficient; it would also yield a faulty
> behavior at least if your doing this on the serverside. A
> better approach would be to create a class that wraps your
> "fully functional ORB" instance as a singleton.
> >
>
> It is obviously unnecessary in the case of a client, as we have here,
> and I haven't ever seen a practical case when you would want to create
> multiple orbs on the server (though I've come across people doing so,
> and complaining that the orb was leaking memory :-). But I don't see
> why it would necessarily cause faulty behavior, apart from due to a
> bad implementation. Why can't multiple orbs happily co-exist in the
> same process?
>
You are right! Multiple ORB instances with different settings (port number, hostname,
IORs for initial services etc..) should be able to co-exist if that's what you want to
accomplish.
Regards,
Per
