Dain Sundstrom wrote:
On Sep 14, 2006, at 3:15 PM, Rick McGuire wrote:
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?
So does this mean we are not using the Sun name service at all even
for the existing code that uses the Sun orb?
Not exactly. I restructured the code a bit so that the code that was
formerly in the SunNameService class is now in the SunORBConfigAdapter
class. The NameService GBean now calls the appropriate ConfigAdapter
for launching the ORB. The NameService suffers from the same problem as
the rest of the ORB code...you can't mix and match ORB usages in the
same JVM instance.
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.
We should be able to have both corba jars in the endorsed dir, but
only add one of the two to the class path. This works because as
Jason found out, the jars in the endorsed dir are not automatically
added to the class path.
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?
I see the Sun code as a temporary bridge that we use until the Yoko
code passes the TCK. Once that happens we turn around and burn that
bridge (a.k.a., remove the code).
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?
I think David Jencks is working on this exact problem now.
-dain
