[ 
http://issues.apache.org/jira/browse/GERONIMO-1145?page=comments#action_12357090
 ] 

Rick McGuire commented on GERONIMO-1145:
----------------------------------------

An in-VM call assumes the remote object is hosted locally, which is not always 
going to be the case.  If a real network connection is required, then this 
problem still exists 

> Too many ORBs (or possibly not enough)
> --------------------------------------
>
>          Key: GERONIMO-1145
>          URL: http://issues.apache.org/jira/browse/GERONIMO-1145
>      Project: Geronimo
>         Type: Bug
>   Components: OpenEJB
>     Versions: 1.0-M5
>  Environment: All
>     Reporter: Rick McGuire

>
> This is sort of complicated problem to describe, but there is a problem with 
> the wrong ORB getting used with remote references passed in with a request.  
> In the current architecture, when a CORBA bean is started, it calls 
> Util.setORB() to register itself as the server ORB.  Util.setORB() ignores 
> all registration calls after the first. so the first CORBABean started in the 
> server will determine the ORB instance returned by all 
> context.lookup("java:comp/ORB") calls in the server.  This value is set in 
> StandardServant using:
>         // create ReadOnlyContext
>         Map componentContext = new HashMap(2);
>         componentContext.put("ORB", Util.getORB());
>         componentContext.put("HandleDelegate", new CORBAHandleDelegate());
>         try {
>             enc = new SimpleReadOnlyContext(componentContext);
>         } catch (NamingException e) {
>             throw new RuntimeException(e);
>         }
> which uses the ORB object returned from Util.getORB().  This ORB value is 
> used for a lot during request processing, particularly when accessing 
> information from remote references passed to this EBJ.  If there are multiple 
> CORBA beans configured for the server, this can create connection problems 
> when the beans are configured with different TSSConfigs.  In the case we ran 
> into, an ORB instance configured for non-secure transports was trying to 
> (correctly) use an SSL connection to perform an operation.  The connection 
> failed in this case because the ORB did not have the correct transport-level 
> security configuration needed to make the connection. 
> The appropriate solution would be for the StandardServant to set up the 
> comp/ORB value to be the ORB associated with the owning POA instance (created 
> in the TSSBean). 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Reply via email to