Kresten Krab Thorup (JIRA) wrote:
[ http://issues.apache.org/jira/browse/GERONIMO-1145?page=comments#action_12357111 ]
Kresten Krab Thorup commented on GERONIMO-1145:
-----------------------------------------------
In the A-B-C scenario, why is it that the relevant CSS info is not included in
the reference? If we use the correct ORB when generating the reference in the
first place, why is this information lost later on?
In the scenario where we ran into this, the information was in the IOR,
and that information was used to decide that a secure transport was
required. At a minimum, the Supports and Requires information was
encoded in the IOR. However, as currently setup, the ORB uses its own
configuration information for sending the request. And because it was
getting dispatched to an ORB instance that was not configured to use
secure transports, the call failed. It really appears the ORB should be
respecting the profile encoded in the IOR when making callbacks,
separate from its profile requirements for publishing its own IORs.
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).
