I originally posted this to the Geronimo dev list, but it was pointed
out that this list is probably the more appropriate place to file the
Jira issues and have the discussion since the bulk of the code changes
are to the openejb2 tree.
I've just attached patches for issue
http://jira.codehaus.org/browse/OPENEJB-266, which is to add Yoko
support to openejb. This is really patches for this issue plus 2 other
issues that are highly related:
http://jira.codehaus.org/browse/OPENEJB-268 OPENEBJ CORBA
SSL should use Keystore GBean
http://jira.codehaus.org/browse/OPENEJB-267 Reduce the
number of places where CORBA config parameters are specified.
This should also be the first step toward achieving this goal of having
the openejb code tolerate Java 5 or non-Sun JREs.
This code works as far as being able to start and stop the j2ee-corba
system module under Geronimo. 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 OPENEJB-267. 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 OPENEJB-268, 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 client side, the client-corba plan does not import j2ee-security,
so I didn't have a configured KeystoreManager to work with. It did not
seem appropriate to import the j2ee-security plan, since there were
items here that did not apply well to a client configuration. As a
shortcut, I just copied the KeystoreManager definitions into the client
plan, but I'm not sure I'm comfortable that this will define/locate the
KeystoreManagers properly. Does anybody with more experience with the
security support have suggestions for how this should be handled?
And, finally, OPENEJB-266. This code was rather straightfoward once I'd
completed the above items. I just created an org.openejb.corba.yoko
package, added a ConfigAdapter implementation, plus whatever
ORB-specific classes were required to bridge between the ORB and
Geronimo. Not really a lot of code in this package. BUT....
ISSUE #3: In order for the Yoko ORB to function properly, the Yoko jar
files need to be part of the endorsed.dir configuration or included on
the bootstrap classpath. This makes it very difficult for the Yoko and
the Sun code to coexist in the same build tree. The code will compile
ok, but unit tests are a problem. There are a couple of tests that
caused problems. The SunNameService class had a test which I replicated
for the Yoko NameService. If the build was enabled for the Sun ORB, the
Yoko test would cause a build failure. If enabled for the Yoko ORB, the
Sun test would fail. When I made the changes to have a generic
NameService GBean, both of these tests became obsolete, so they are
deleted for now. Once we sort out the coexistance strategy, I'll try
introducing new tests. There was a similar problem with one of the
TSSConfigEditorTest, which needed to create an configure a CORBABean
instance.
On the Geronimo side, there are similar problems. Building any of the
corba configurations depended upon whether the yoko classes were in
endorsed.dir. If there were absent, it was not possible to build a
yoko-based configuration. If present, it was not possible to build the
Sun-based configuration. There was some suggestion that we might need
to ship additional full assemblies to accommodate this.
For the openejb2 code tree, I see several possibilities:
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.
Possibility 1) Has one serious disadvantage as it leaves the openejb2
code tree coupled to the Sun 1.4.2 JVM. Either 2 or 3 will remove that
particular Java 1.4.2 dependency. Does anybody have and strong feelings
about this?
ISSUE #4 is then how do we manage the possibility of both the Sun ORB
support and the Yoko support? Will this actually require separate
assemblies to work, or is there some means to easily allow the switching?
Anyway, a lot of words to digest. Issues #3 and #4 are the ones that
are going to cause the most pain to implement, so I'm really interested
in getting community consensus on how to proceed here.
Rick
