|summary:||Fix for cts jaxrpc failures|
|date:||2009-10-15 23:25:34 UTC (7 years)|
|message:||Fix for cts jaxrpc failures
An earlier set of changes exposed a new problem revealed by the jax-rpc cts tests. This change repairs the newly-exposed problem.
Deployed app client bits in v3 come in two JARs - a generated one with the filled-in descriptor and any generated stubs plus the developer's original app client JAR. Early in its processing the ACC opens the generated JAR to find out some information about the client. To do so it used the AppClientArchivist which performs some post-open work. This work expects to be able to locate classes in the client - classes which are in the developer's original JAR, not the generated one - even though opening the generated JAR does not need to trigger this particular post-open work. But it was happening anyway and failing because the classes are not in the generated JAR.
As part of the earlier check-in I created a ReadableArchive implementation which wraps multiple actual ReadableArchives and the ACC uses this to hide the dual-JAR nature of the client bits from most of the rest of the system. Using that MultiReadableArchive in one additional place has resolved this problem.
Tests: deployment and ejb devtests; QL; cts tests which were failing now pass