[ http://issues.apache.org/jira/browse/GERONIMO-1145?page=comments#action_12421558 ] Rick McGuire commented on GERONIMO-1145: ----------------------------------------
I didn't think that the dependency workaround had ever been applied to Geronimo, only to WAS/CE because the problem was never occuring with Geronimo running under the Sun JVM (for whatever reasons). The passing of the orb to StandardServant is an indirect passing. The orb instance gets set in StandardServant downstream from this point by doing a JNDI lookup. This fix places the appropriate orb relative to the activated bean into the context for retrieval, rather than using a single global orb, which would be from the first one initialized. I've already checked other uses of Util.getORB(), and they don't have the same sort of impact. Those uses are for occasions where an ORB instance is required for some utility operation (data conversions, etc,). Those occurrances are fine. > Too many ORBs (or possibly not enough) > -------------------------------------- > > Key: GERONIMO-1145 > URL: http://issues.apache.org/jira/browse/GERONIMO-1145 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: OpenEJB > Affects Versions: 1.0-M5 > Environment: All > Reporter: Rick McGuire > Assigned To: David Jencks > Fix For: 1.0 > > Attachments: orb.patch > > > 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
