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?
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
