Re: Pre-RTC look at the openejb/geronimo yoko support and request for input [long].
David Jencks wrote:
Now I've reviewed this a bit more and have some minor comments:
1. I think you should include the yoko jars only in j2ee-corba (or
openejb) and client-corba configurations, not also j2ee-server and
client configurations. We might need to split more of openejb into a
corba support module so j2ee-corba can contain all of it and then we
can deploy openejb w/o pulling in any corba stuff.
That's originally what I tried, but that failed because of class loading
issues. The Yoko jars needed to be loaded by the same class loader
that was loading the openejb-core code otherwise the ORB adapter code
(which was in the openejb-core jar) was unable to resolve the yoko
classes.
2. Comment in TSSBean is not quite accurate. A TSSBean can be used
with any number of ejbs. It just supplies the additional security
info beyond the ssl config that the server will require for accessing
the ejbs that reference it. BTW dblevins is rather unhappy with the
reference from ejb container to tssbean on the grounds that transport
info should not be associated with the ejb container itself. One way
to support this would be to have an additional link gbean between
the tssbean and the ejb container. Another way would be to give the
TSSBean a collection of ejbs it services: this was the original
implementation but it was impossible to configure for the tck interop
tests. One of these approaches might be required to separate the
corba stuff out from core openejb.
Ok, I'll correct the comments. Every time I think I've really got a
handle on what this is doing, I discover something new like this :-)
3. This code from SocketFactory just doesn't look right: (around line
298 or the patch)
+// now set our listener creation flags based on the supports
and requires values from the
+// TSS config.
+if ((supports EstablishTrustInClient.value) != 0) {
+clientAuthSupported = true;
+
+if ((requires EstablishTrustInClient.value) != 0) {
+clientAuthRequired = true;
+}
+}
+
+if ((supports EstablishTrustInTarget.value) != 0) {
+clientAuthSupported = true;
+
+if ((requires EstablishTrustInTarget.value) != 0) {
+clientAuthSupported = true;
+}
+}
At least the final clientAuthSupported = true looks redundant to me.
there's similar code around line 565 of the patch:
Good catchthis needs to be clientAuthRequired = true;. Same
problem in the Sun code.
+// figure out the supports and requires information from the
flag values
+boolean authSupported = false;
+boolean authRequired = false;
+
+if ((supports EstablishTrustInClient.value) != 0) {
+authSupported = true;
+
+if ((requires EstablishTrustInClient.value) != 0) {
+authRequired = true;
+}
+}
+
+if ((supports EstablishTrustInTarget.value) != 0) {
+authSupported = true;
+
+if ((requires EstablishTrustInTarget.value) != 0) {
+authSupported = true;
+}
+}
3. Your comment on CSSBean suffers like the one for TSSBean. A
CSSBean just holds the security config info, but you can use one
CSSBean to access many remote ejbs.
Yep, I'll correct.
4. The code I don't understand in (2) appears again around line 3980
in sunorb/OpenEJBSocketFactory
This looks great to me!
thanks
david jencks
On Sep 14, 2006, at 2:56 PM, David Jencks wrote:
Great work!!!
On Sep 14, 2006, at 12:16 PM, Rick McGuire wrote:
I've just attached patches for issue
http://issues.apache.org/jira/browse/GERONIMO-2180, which is to add
Yoko support to Geronimo. This is really patches for this issue
plus 2 other issues that are highly related:
http://issues.apache.org/jira/browse/GERONIMO-2002 OPENEBJ CORBA
SSL should use Keystore GBean
http://issues.apache.org/jira/browse/GERONIMO-2353 Reduce the
number of places where CORBA config parameters are specified.
This should also be the first step toward achieving this goal:
http://issues.apache.org/jira/browse/GERONIMO-433 Tolerate
non-Sun JREs
And should also be a step toward allowing full support of Java 5.
This code works as far as being able to start and stop the
j2ee-corba system module. Fuller testing is going to require
getting the MagicGBall app working and then see how this works with
TCK testing. There are some issues with doing either of those steps
at the moment, but I decided this is a good point to show people
I've done, since it will be easier to ask questions about it.
Let me give the basics of what I've done, and I have a few areas I'd
like community input on how I should proceed from here.
The bulk of the changes are really around GERONIMO-2353. While
trying to fit the Yoko ORB into this structure, I found a number of
pain points:
1. The
Re: Pre-RTC look at the openejb/geronimo yoko support and request for input [long].
Now I've reviewed this a bit more and have some minor comments:
1. I think you should include the yoko jars only in j2ee-corba (or
openejb) and client-corba configurations, not also j2ee-server and
client configurations. We might need to split more of openejb into a
corba support module so j2ee-corba can contain all of it and then we
can deploy openejb w/o pulling in any corba stuff.
2. Comment in TSSBean is not quite accurate. A TSSBean can be used
with any number of ejbs. It just supplies the additional security
info beyond the ssl config that the server will require for accessing
the ejbs that reference it. BTW dblevins is rather unhappy with the
reference from ejb container to tssbean on the grounds that transport
info should not be associated with the ejb container itself. One way
to support this would be to have an additional link gbean between
the tssbean and the ejb container. Another way would be to give the
TSSBean a collection of ejbs it services: this was the original
implementation but it was impossible to configure for the tck interop
tests. One of these approaches might be required to separate the
corba stuff out from core openejb.
3. This code from SocketFactory just doesn't look right: (around line
298 or the patch)
+// now set our listener creation flags based on the supports
and requires values from the
+// TSS config.
+if ((supports EstablishTrustInClient.value) != 0) {
+clientAuthSupported = true;
+
+if ((requires EstablishTrustInClient.value) != 0) {
+clientAuthRequired = true;
+}
+}
+
+if ((supports EstablishTrustInTarget.value) != 0) {
+clientAuthSupported = true;
+
+if ((requires EstablishTrustInTarget.value) != 0) {
+clientAuthSupported = true;
+}
+}
At least the final clientAuthSupported = true looks redundant to me.
there's similar code around line 565 of the patch:
+// figure out the supports and requires information from the
flag values.
+boolean authSupported = false;
+boolean authRequired = false;
+
+if ((supports EstablishTrustInClient.value) != 0) {
+authSupported = true;
+
+if ((requires EstablishTrustInClient.value) != 0) {
+authRequired = true;
+}
+}
+
+if ((supports EstablishTrustInTarget.value) != 0) {
+authSupported = true;
+
+if ((requires EstablishTrustInTarget.value) != 0) {
+authSupported = true;
+}
+}
3. Your comment on CSSBean suffers like the one for TSSBean. A
CSSBean just holds the security config info, but you can use one
CSSBean to access many remote ejbs.
4. The code I don't understand in (2) appears again around line 3980
in sunorb/OpenEJBSocketFactory
This looks great to me!
thanks
david jencks
On Sep 14, 2006, at 2:56 PM, David Jencks wrote:
Great work!!!
On Sep 14, 2006, at 12:16 PM, Rick McGuire wrote:
I've just attached patches for issue http://issues.apache.org/jira/
browse/GERONIMO-2180, which is to add Yoko support to Geronimo.
This is really patches for this issue plus 2 other issues that are
highly related:
http://issues.apache.org/jira/browse/GERONIMO-2002 OPENEBJ CORBA
SSL should use Keystore GBean
http://issues.apache.org/jira/browse/GERONIMO-2353 Reduce the
number of places where CORBA config parameters are specified.
This should also be the first step toward achieving this goal:
http://issues.apache.org/jira/browse/GERONIMO-433 Tolerate non-
Sun JREs
And should also be a step toward allowing full support of Java 5.
This code works as far as being able to start and stop the j2ee-
corba system module. Fuller testing is going to require getting
the MagicGBall app working and then see how this works with TCK
testing. There are some issues with doing either of those steps
at the moment, but I decided this is a good point to show people
I've done, since it will be easier to ask questions about it.
Let me give the basics of what I've done, and I have a few areas
I'd like community input on how I should proceed from here.
The bulk of the changes are really around GERONIMO-2353. While
trying to fit the Yoko ORB into this structure, I found a number
of pain points:
1. The org.openejb.corba.SunNameService GBean only supported the
Sun
ORB, and was not generally configurable like CORBABean or
CSSBean
were.
2. The CORBABean and CSSBean configuration included args and
props items which were passed directly through to an
ORB.init()
call. These attributes were used to configure things like the
initial listener port, the host server name, and the initial
NameServer location. In a few cases, the values set were not
portable between ORB implementations, which made it more
Pre-RTC look at the openejb/geronimo yoko support and request for input [long].
I've just attached patches for issue http://issues.apache.org/jira/browse/GERONIMO-2180, which is to add Yoko support to Geronimo. This is really patches for this issue plus 2 other issues that are highly related: http://issues.apache.org/jira/browse/GERONIMO-2002 OPENEBJ CORBA SSL should use Keystore GBean http://issues.apache.org/jira/browse/GERONIMO-2353 Reduce the number of places where CORBA config parameters are specified. This should also be the first step toward achieving this goal: http://issues.apache.org/jira/browse/GERONIMO-433 Tolerate non-Sun JREs And should also be a step toward allowing full support of Java 5. This code works as far as being able to start and stop the j2ee-corba system module. Fuller testing is going to require getting the MagicGBall app working and then see how this works with TCK testing. There are some issues with doing either of those steps at the moment, but I decided this is a good point to show people I've done, since it will be easier to ask questions about it. Let me give the basics of what I've done, and I have a few areas I'd like community input on how I should proceed from here. The bulk of the changes are really around GERONIMO-2353. While trying to fit the Yoko ORB into this structure, I found a number of pain points: 1. The org.openejb.corba.SunNameService GBean only supported the Sun ORB, and was not generally configurable like CORBABean or CSSBean were. 2. The CORBABean and CSSBean configuration included args and props items which were passed directly through to an ORB.init() call. These attributes were used to configure things like the initial listener port, the host server name, and the initial NameServer location. In a few cases, the values set were not portable between ORB implementations, which made it more difficult to switch between ORBs. 3. The CSSBean and CORBABean declarations needed to be coded with a dependency on SystemProperties. The SystemProperties object was initializing various system properties that were needed by the ORB, and also enabled the RMI support. These properties were generally not portable between ORB implementations, since they included references to Sun specific classes. To clean this up, I reworked the ConfigAdapter interface used in the current code base. This interface now has 3 basic operations 1) create a name service, 2) create a server ORB, and 3) create a client ORB. The existing code is just configured with a ConfigAdapter class name and the CORBABean/CSSBean services instantiated an instance of the class. Now the ConfigAdapters are GBean instances, and the doStart() methods of these GBeans are encapsulate the responsibility for setting the RMI system properties. SunNameService has been replaced by a generic NameService GBean, and NameService, CORBABean, and CSSBean all take a ConfigAdapter instance in their constructors. Now, from a plan standpoint, it's possible to switch between ORBs by changing a single line in the plan. All of this work is really independent of the Yoko-specific changes, but did make it easier to write the Yoko code. Which brings me to ISSUE #1: I added a NameService argument to the CORBABean constructor. The ConfigAdapter would take this NameService instance, and configure the ORB to use the NameService.getURI() result for it's initial NameService reference. Well, when trying to get Geronimo to build, I got a failure on one of the client plans because there was a CORBABean coded, but no NameService. The CORBABean had use the now obsolete arguments attribute to configure the ORB to use a remote NameService. I thought on this a little, and decided to just add a local attribute to the NameService GBean. If local is false, then the bean does not launch a local server instance and the getURI() returns the remote location of the NameService as specified by the host/port combination. This worked very well, but it somehow feels like a convenience hack to me. Does this sound ok, or should I take some other approach with this? For GERONIMO-2002, I create a new SSLConfig GBean. This class has a reference to a KeystoreManager GBean, plus various attributes that are required to generate SSLSocketFactory and SSLServerSocketFactory instances for creating the SSL sockets. The CORBABean and CSSBean objects can be configured with an SSLConfig reference, which is then used whenever an SSL connection is required. This is separate from the TSSConfig/CSSConfig specifications. TSSConfig/CSSConfig help determine WHEN an SSL connection is required. The SSLConfig determines HOW the connection gets created when it is required. ISSUE #2: This works fairly well for the j2ee-corba plan, which imports the j2ee-security plan. The j2ee-security plan defines the default KeystoreManager instances, so things get resolved properly. On the
Re: Pre-RTC look at the openejb/geronimo yoko support and request for input [long].
Great work!!! On Sep 14, 2006, at 12:16 PM, Rick McGuire wrote: I've just attached patches for issue http://issues.apache.org/jira/ browse/GERONIMO-2180, which is to add Yoko support to Geronimo. This is really patches for this issue plus 2 other issues that are highly related: http://issues.apache.org/jira/browse/GERONIMO-2002 OPENEBJ CORBA SSL should use Keystore GBean http://issues.apache.org/jira/browse/GERONIMO-2353 Reduce the number of places where CORBA config parameters are specified. This should also be the first step toward achieving this goal: http://issues.apache.org/jira/browse/GERONIMO-433 Tolerate non- Sun JREs And should also be a step toward allowing full support of Java 5. This code works as far as being able to start and stop the j2ee- corba system module. Fuller testing is going to require getting the MagicGBall app working and then see how this works with TCK testing. There are some issues with doing either of those steps at the moment, but I decided this is a good point to show people I've done, since it will be easier to ask questions about it. Let me give the basics of what I've done, and I have a few areas I'd like community input on how I should proceed from here. The bulk of the changes are really around GERONIMO-2353. While trying to fit the Yoko ORB into this structure, I found a number of pain points: 1. The org.openejb.corba.SunNameService GBean only supported the Sun ORB, and was not generally configurable like CORBABean or CSSBean were. 2. The CORBABean and CSSBean configuration included args and props items which were passed directly through to an ORB.init() call. These attributes were used to configure things like the initial listener port, the host server name, and the initial NameServer location. In a few cases, the values set were not portable between ORB implementations, which made it more difficult to switch between ORBs. 3. The CSSBean and CORBABean declarations needed to be coded with a dependency on SystemProperties. The SystemProperties object was initializing various system properties that were needed by the ORB, and also enabled the RMI support. These properties were generally not portable between ORB implementations, since they included references to Sun specific classes. To clean this up, I reworked the ConfigAdapter interface used in the current code base. This interface now has 3 basic operations 1) create a name service, 2) create a server ORB, and 3) create a client ORB. The existing code is just configured with a ConfigAdapter class name and the CORBABean/CSSBean services instantiated an instance of the class. Now the ConfigAdapters are GBean instances, and the doStart() methods of these GBeans are encapsulate the responsibility for setting the RMI system properties. SunNameService has been replaced by a generic NameService GBean, and NameService, CORBABean, and CSSBean all take a ConfigAdapter instance in their constructors. Now, from a plan standpoint, it's possible to switch between ORBs by changing a single line in the plan. All of this work is really independent of the Yoko-specific changes, but did make it easier to write the Yoko code. This sounds great! Which brings me to ISSUE #1: I added a NameService argument to the CORBABean constructor. The ConfigAdapter would take this NameService instance, and configure the ORB to use the NameService.getURI() result for it's initial NameService reference. Well, when trying to get Geronimo to build, I got a failure on one of the client plans because there was a CORBABean coded, but no NameService. The CORBABean had use the now obsolete arguments attribute to configure the ORB to use a remote NameService. I thought on this a little, and decided to just add a local attribute to the NameService GBean. If local is false, then the bean does not launch a local server instance and the getURI() returns the remote location of the NameService as specified by the host/port combination. This worked very well, but it somehow feels like a convenience hack to me. Does this sound ok, or should I take some other approach with this? This seems reasonable to me. There might be an even better way to deal with this, but we definitely need to support both a name server in the same vm (in which case with luck we can communicate with it in- vm without tcp) or a remote name server. We were starting a name server in vm mostly because it's simpler to administer. Theoretically we could start an app client where all it did was run the name server :-). For GERONIMO-2002, I create a new SSLConfig GBean. This class has a reference to a KeystoreManager GBean, plus various attributes that are required to generate SSLSocketFactory and SSLServerSocketFactory instances for creating the SSL sockets. The
Re: Pre-RTC look at the openejb/geronimo yoko support and request for input [long].
This is great news! Feels like we are getting very close to being able to move to J2SE 5 and Java EE 5! 1) Leave the Sun ORB code in the tree, make the yoko package a separate module that with a dependency on the openejb2 code. The existing build works ok, and the tests can be built for the Sun ORB. The build of the yoko package could then have its own versions of the tests, which would work find. 2) Replace the Sun ORB code with the yoko code and kick the Sun code into a separate module. Same things apply with the test. 3) Place both ORB adapters in outside modules, each with their own builds and tests. I prefer option 3 if I understand you correctly with this we can have an assembly that is intended to run on Sun JDK and one intended to run on Sun or anywhere else. On Issue #3 is it just a build problem? From the sound of it the code won't run if the Sun ORB code is in the bootstrap class path (as it would be on the Sun 1.4 JDK). If we go with option #3 above and completely remove our dependence on the Sun ORB then we could run just fine on the 1.4 JDK correct? If that is the case then I think dropping the Sun ORB ASAP (getting past the TCK etc.) is the way to go. I was also just looking at 2180 and noticed that the yoko dependencies are in maven, is it safe to pull them from there instead of using the attached zip file? I'm applying the patch now to play around with this, thanks again! TTFN, -bd- On Sep 14, 2006, at 12:56 PM, David Jencks wrote: Great work!!! On Sep 14, 2006, at 12:16 PM, Rick McGuire wrote: I've just attached patches for issue http://issues.apache.org/jira/ browse/GERONIMO-2180, which is to add Yoko support to Geronimo. This is really patches for this issue plus 2 other issues that are highly related: http://issues.apache.org/jira/browse/GERONIMO-2002 OPENEBJ CORBA SSL should use Keystore GBean http://issues.apache.org/jira/browse/GERONIMO-2353 Reduce the number of places where CORBA config parameters are specified. This should also be the first step toward achieving this goal: http://issues.apache.org/jira/browse/GERONIMO-433 Tolerate non- Sun JREs And should also be a step toward allowing full support of Java 5. This code works as far as being able to start and stop the j2ee- corba system module. Fuller testing is going to require getting the MagicGBall app working and then see how this works with TCK testing. There are some issues with doing either of those steps at the moment, but I decided this is a good point to show people I've done, since it will be easier to ask questions about it. Let me give the basics of what I've done, and I have a few areas I'd like community input on how I should proceed from here. The bulk of the changes are really around GERONIMO-2353. While trying to fit the Yoko ORB into this structure, I found a number of pain points: 1. The org.openejb.corba.SunNameService GBean only supported the Sun ORB, and was not generally configurable like CORBABean or CSSBean were. 2. The CORBABean and CSSBean configuration included args and props items which were passed directly through to an ORB.init() call. These attributes were used to configure things like the initial listener port, the host server name, and the initial NameServer location. In a few cases, the values set were not portable between ORB implementations, which made it more difficult to switch between ORBs. 3. The CSSBean and CORBABean declarations needed to be coded with a dependency on SystemProperties. The SystemProperties object was initializing various system properties that were needed by the ORB, and also enabled the RMI support. These properties were generally not portable between ORB implementations, since they included references to Sun specific classes. To clean this up, I reworked the ConfigAdapter interface used in the current code base. This interface now has 3 basic operations 1) create a name service, 2) create a server ORB, and 3) create a client ORB. The existing code is just configured with a ConfigAdapter class name and the CORBABean/CSSBean services instantiated an instance of the class. Now the ConfigAdapters are GBean instances, and the doStart() methods of these GBeans are encapsulate the responsibility for setting the RMI system properties. SunNameService has been replaced by a generic NameService GBean, and NameService, CORBABean, and CSSBean all take a ConfigAdapter instance in their constructors. Now, from a plan standpoint, it's possible to switch between ORBs by changing a single line in the plan. All of this work is really independent of the Yoko-specific changes, but did make it easier to write the Yoko code. This sounds great! Which brings me to ISSUE #1: I added a NameService argument to the CORBABean constructor. The ConfigAdapter would
Re: Pre-RTC look at the openejb/geronimo yoko support and request for input [long].
Bill Dudney wrote: This is great news! Feels like we are getting very close to being able to move to J2SE 5 and Java EE 5! 1) Leave the Sun ORB code in the tree, make the yoko package a separate module that with a dependency on the openejb2 code. The existing build works ok, and the tests can be built for the Sun ORB. The build of the yoko package could then have its own versions of the tests, which would work find. 2) Replace the Sun ORB code with the yoko code and kick the Sun code into a separate module. Same things apply with the test. 3) Place both ORB adapters in outside modules, each with their own builds and tests. I prefer option 3 if I understand you correctly with this we can have an assembly that is intended to run on Sun JDK and one intended to run on Sun or anywhere else. You can get that capability with all 3 of these. However, with option 1, the openejb2 code can only be built using the Sun 1.4.2 JDK. Option 1 has the smallest disruption to the existing code though, which is the only reason I included it in the list. We basically can jump in to the pool from the shallow end (option 1) or the deep end (option 3). My personal preference is 3 also. On Issue #3 is it just a build problem? From the sound of it the code won't run if the Sun ORB code is in the bootstrap class path (as it would be on the Sun 1.4 JDK). If we go with option #3 above and completely remove our dependence on the Sun ORB then we could run just fine on the 1.4 JDK correct? If that is the case then I think dropping the Sun ORB ASAP (getting past the TCK etc.) is the way to go. Issue #3 is a runtime issue, not just a built problem. The Sun ORB code is ALWAYS on the bootclass path, since it is part of the JVM. In particularly, the versions of the org.omg.* classes that come with the JVM are back level to (and incompatible with) the version that comes with Yoko. As a result, the Yoko code cannot run unless it is placed in endorsed.dir. However, when things are set up that way, then the Sun code has the same problemit won't run because of the same incompatibility. I was also just looking at 2180 and noticed that the yoko dependencies are in maven, is it safe to pull them from there instead of using the attached zip file? Yes...I hadn't realized that we'd been publishing Yoko snapshots to the repository yet. Assuming the snapshots are reasonably up-to-date, that version should work ok. I'm applying the patch now to play around with this, thanks again! TTFN, -bd- On Sep 14, 2006, at 12:56 PM, David Jencks wrote: Great work!!! On Sep 14, 2006, at 12:16 PM, Rick McGuire wrote: I've just attached patches for issue http://issues.apache.org/jira/browse/GERONIMO-2180, which is to add Yoko support to Geronimo. This is really patches for this issue plus 2 other issues that are highly related: http://issues.apache.org/jira/browse/GERONIMO-2002 OPENEBJ CORBA SSL should use Keystore GBean http://issues.apache.org/jira/browse/GERONIMO-2353 Reduce the number of places where CORBA config parameters are specified. This should also be the first step toward achieving this goal: http://issues.apache.org/jira/browse/GERONIMO-433 Tolerate non-Sun JREs And should also be a step toward allowing full support of Java 5. This code works as far as being able to start and stop the j2ee-corba system module. Fuller testing is going to require getting the MagicGBall app working and then see how this works with TCK testing. There are some issues with doing either of those steps at the moment, but I decided this is a good point to show people I've done, since it will be easier to ask questions about it. Let me give the basics of what I've done, and I have a few areas I'd like community input on how I should proceed from here. The bulk of the changes are really around GERONIMO-2353. While trying to fit the Yoko ORB into this structure, I found a number of pain points: 1. The org.openejb.corba.SunNameService GBean only supported the Sun ORB, and was not generally configurable like CORBABean or CSSBean were. 2. The CORBABean and CSSBean configuration included args and props items which were passed directly through to an ORB.init() call. These attributes were used to configure things like the initial listener port, the host server name, and the initial NameServer location. In a few cases, the values set were not portable between ORB implementations, which made it more difficult to switch between ORBs. 3. The CSSBean and CORBABean declarations needed to be coded with a dependency on SystemProperties. The SystemProperties object was initializing various system properties that were needed by the ORB, and also enabled the RMI support. These properties were generally not portable between ORB implementations, since they included references to Sun specific classes. To clean this
