The project is a custom channel -- Remoting.Corba. When a call comes into the server, the current code gets the deserializes the stream and, if there's an object reference there, calls Activator.GetObject to get the reference. That reference gets passed on to the server implementation code.
Unfortunately, that means that the server implementation code gets a transparent proxy rather than a reference to the real object. Since it's a proxy, the server can't access any operations or attributes that are used strictly in the implementation, even though they would be available if the reference to the real object were passed in. There's also the remoting layers that any call to the parameter object would have to go through, even though the parameter's local to the server. When implementing remoting using the tcp channel, the reference to the unwrapped object gets passed to the server implementation code, not the transparent proxy that points to it. The Remoting.Corba implementation should do the same. --Michael > -----Original Message----- > From: Mike Woodring (DevelopMentor) [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 15, 2003 6:22 PM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Remoting: Getting object from URI > > > > I had seen that, but wasn't sure that it was applicable to my > > question. It's good to know that it is. Now for the > difficult part of > > convincing myself that I want to use private data :-) > > > > To back up one level, why do you want to take a URL as input > and get your hands on the associated object reference that > incoming remote method calls would be dispatched against? > Maybe there's an alternative design to solve your problem > that wouldn't paint you into a corner that requires the use > of reflection against private members to get out of... > > -Mike > DevelopMentor > http://staff.develop.com/woodring > >
