You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Rick McGuire (JIRA)" <de...@geronimo.apache.org> on 2005/11/08 18:00:19 UTC
[jira] Created: (GERONIMO-1145) Too many ORBs (or possibly not enough)
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
[jira] Updated: (GERONIMO-1145) Too many ORBs (or possibly not enough)
Posted by "Rick McGuire (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1145?page=all ]
Rick McGuire updated GERONIMO-1145:
-----------------------------------
Geronimo Info: [Patch Available]
> 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
> 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
[jira] Commented: (GERONIMO-1145) Too many ORBs (or possibly not
enough)
Posted by "Ted Kirby (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1145?page=comments#action_12421596 ]
Ted Kirby commented on GERONIMO-1145:
-------------------------------------
Thanks Rick.
I am still confused about David's fix of [05/Dec/05 10:32 PM].
When you say "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.", are you talking about David's fix of [05/Dec/05 10:32 PM]?
It still seems that a key piece of it is missing, namely:
< componentContext.put("ORB", Util.getORB());
---
> componentContext.put("ORB", orb);
Otherwise, I don't see that that fix accomplishes anything.
> 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
[jira] Commented: (GERONIMO-1145) Too many ORBs (or possibly not
enough)
Posted by "Ted Kirby (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1145?page=comments#action_12421316 ]
Ted Kirby commented on GERONIMO-1145:
-------------------------------------
Could/Should not then the [08/Nov/05 10:47 PM] workaround (dependency of UnprotectedServer on Server in j2ee-corba plan) be removed?
It does not appear to be in the CTS/tck server-ior plan.
> 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
[jira] Commented: (GERONIMO-1145) Too many ORBs (or possibly not
enough)
Posted by "Rick McGuire (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1145?page=comments#action_12421600 ]
Rick McGuire commented on GERONIMO-1145:
----------------------------------------
I'm sorry, I misread your ealier comment. I thought you were saying that the change didn't seem to be doing anything, not that the change was missing. Yes, I believe you are correct. I'm not sure how/when that part of the fix got deleted.
> 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
[jira] Commented: (GERONIMO-1145) Too many ORBs (or possibly not enough)
Posted by "David Jencks (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1145?page=comments#action_12357104 ]
David Jencks commented on GERONIMO-1145:
----------------------------------------
The calls in question are made during the process of serializing a handle or home handle by the ejb whose handle is being serialized, so in-vm access is certainly possible. Access to another ejb via an ejb-ref which includes a css-bean reference providing the information needed to construct the connection. We still have a problem if there are 3 ejbs A, B, and C and B sends a handle for A to C: C has no infomation about the CSS settings it should use to contact A. However, this needs an entire CSS configuration, not just knowledge of which orb to use.
> 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
[jira] Commented: (GERONIMO-1145) Too many ORBs (or possibly not
enough)
Posted by "Rick McGuire (JIRA)" <de...@geronimo.apache.org>.
[ 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
[jira] Updated: (GERONIMO-1145) Too many ORBs (or possibly not enough)
Posted by "Rick McGuire (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1145?page=all ]
Rick McGuire updated GERONIMO-1145:
-----------------------------------
Attachment: orb.patch
There are other probems/issues involved with the ORB uses, but it turns out to be fairly simple to ensure that lookup("java:comp/ORB") returns the ORB associated with the servant's POA instance rather than mapping this value to a single, global server value.
> 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
> 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
[jira] Commented: (GERONIMO-1145) Too many ORBs (or possibly not
enough)
Posted by "Ted Kirby (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1145?page=comments#action_12421328 ]
Ted Kirby commented on GERONIMO-1145:
-------------------------------------
On further inspection, it seems a key piece of the [05/Dec/05 10:32 PM] fix is missing. It seems the intent of the patch is to pass the orb to StandardServant, but it doesn't do anything with it! It seems this change should be added:
- componentContext.put("ORB", Util.getORB());
+ componentContext.put("ORB", orb);
Shouldn't other (all?) references to Util.getORB() be replaced with references to the appropriate servant's POA instance?
> 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
[jira] Commented: (GERONIMO-1145) Too many ORBs (or possibly not enough)
Posted by "David Jencks (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1145?page=comments#action_12357078 ]
David Jencks commented on GERONIMO-1145:
----------------------------------------
I wonder if the proposed solution will work properly if the target TSSBean has a required identity token: the source of the identity token needs to be configured in a CSSBean, which is still not present in our configuration.
I would think that the ideal solution would be to make the call be in-vm, requiring no tcp connection of any sort.
For a workaround in geronimo head we can include a dependency of the unsecured orb on the secured orb so the secured orb will always be the one retrieved from jndi.
> 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
[jira] Commented: (GERONIMO-1145) Too many ORBs (or possibly not enough)
Posted by "Rick McGuire (JIRA)" <de...@geronimo.apache.org>.
[ 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
[jira] Assigned: (GERONIMO-1145) Too many ORBs (or possibly not enough)
Posted by "David Jencks (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1145?page=all ]
David Jencks reassigned GERONIMO-1145:
--------------------------------------
Assign To: David Jencks
> 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
> Assignee: David Jencks
> 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
Re: [jira] Commented: (GERONIMO-1145) Too many ORBs (or possibly not enough)
Posted by Kresten Krab Thorup <kr...@trifork.com>.
On Nov 9, 2005, at 11:18 AM, Rick McGuire wrote:
> 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.
Right. an IOR is exactly that: an recipe for how to contact a server
object, and this includes options and constraints for security. This
information may have to be applied to a "logical and" with client
security constraint before an attempt is made to contact the server.
So in this case, C's TSS should be encoded into the handle, and this
info should stay there across the call to B, so that A can see C's
TSS info in the IOR.
In this sense, there is no difference between a callback and other
kinds of call. A call is a call, and it should respect the
requirements of the target's IOR. An IOR is immutable, and the
profiles contained in it should not be changed because it is passed
through an intermediary.
Kresten
Re: [jira] Commented: (GERONIMO-1145) Too many ORBs (or possibly
not enough)
Posted by Rick McGuire <ri...@gmail.com>.
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).
>>
>>
>
>
>
[jira] Commented: (GERONIMO-1145) Too many ORBs (or possibly not enough)
Posted by "Kresten Krab Thorup (JIRA)" <de...@geronimo.apache.org>.
[ 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?
> 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
[jira] Commented: (GERONIMO-1145) Too many ORBs (or possibly not enough)
Posted by "David Jencks (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1145?page=comments#action_12357112 ]
David Jencks commented on GERONIMO-1145:
----------------------------------------
First of all, I don't think CSS info is ever encoded in an IOR, just TSS info.
Let me see if I can make my example more concrete, while changing the names of the participants
A is an app client with a client cert and a user/pw
B is an ejb on an app server b. B requires a client cert for user authentication, no identity token
C is an ejb on an app server c. C requires either a client cert for server authentication and an identity token, or a no-client-cert SSL connection with AS level user-password client authentication.
A calls a method on B, authenticating the user identity with the client cert.
The B method calls C, using the b cert to identify the server, and including an identity token identifying A as the user. C returns a handle
B returns the C handle to A.
How is A supposed to use the handle? It has appropriate info (the user/pw) but no way to negotiate a security policy with C. Neither the configuration it used to contact B nor the configuration B used to contact C are usable for A to contact C. It might be able to use the CSS info associated with the ejb-ref to B, but there is no way currently to apply it to the attempt to contact C.
> 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
[jira] Commented: (GERONIMO-1145) Too many ORBs (or possibly not enough)
Posted by "David Jencks (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1145?page=comments#action_12357084 ]
David Jencks commented on GERONIMO-1145:
----------------------------------------
Dependency added
Sending modules/assembly/src/plan/j2ee-server-corba-plan.xml
Transmitting file data .
Committed revision 331899.
> 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
[jira] Closed: (GERONIMO-1145) Too many ORBs (or possibly not enough)
Posted by "David Jencks (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1145?page=all ]
David Jencks closed GERONIMO-1145:
----------------------------------
Fix Version: 1.0
Resolution: Fixed
Checking in modules/core/src/java/org/openejb/corba/Adapter.java;
new revision: 1.13; previous revision: 1.12
Checking in modules/core/src/java/org/openejb/corba/AdapterEntity.java;
new revision: 1.13; previous revision: 1.12
Checking in modules/core/src/java/org/openejb/corba/AdapterStateful.java;
new revision: 1.13; previous revision: 1.12
Checking in modules/core/src/java/org/openejb/corba/AdapterStateless.java;
new revision: 1.13; previous revision: 1.12
Checking in modules/core/src/java/org/openejb/corba/StandardServant.java;
new revision: 1.13; previous revision: 1.12
> 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
> Assignee: 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