On 01/ 4/11 11:38 AM, Jerome Dochez wrote:
> is there a dependency on this orb/orb-iiop module with<test> scope in the pom.xml ?
>
> if u do a mvn -X, it will tell you the list of jars used to run tests (yes the output is very prolific)
> it's most likely not in that list.
>
mvn -X does not include orb-iiop anywhere, but I think that's the way
things are
supposed to work: Clients of the ORB use orb-connector, which does not
depend on the ORB impl bundles. orb-iiop uses orb-connector, and
orb-iiop does
depend on the ORB impl bundles. The whole point of the GlassFishORBHelper
is to allow clients of the ORB to force loading of the ORB when
GlassFishORBHelper.getORB()
is called.
This is the way this has been since Mahesh first integrated the ORB into
GF 3 a couple
of years ago. I haven't changed any of the dependencies in this area at
all. From what
you are saying, it seems that perhaps the dependencies in the
glassfish-naming pom.xml
should contain a test-scoped dependency on orb-iiop:
<dependency>
<groupId>org.glassfish.orb</groupId>
<artifactId>orb-iiop</artifactid>
<version>${project.version}</version>
<scope>test</scope>
</dependency>
After adding this, I still get the same test failures, but this time I'm
seeing an exception
propagating up from hk2:
org.jvnet.hk2.component.UnsatisfiedDependencyException: injection failed
on org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.iiopUtils
with class org.glassfish.enterprise.iiop.util.IIOPUtils
This is coming from InjectionManager.inject. The variables are set to:
genericType = org.glassfish.internal.api.ClassLoaderHierarchy
type = org.glassfish.enterprise.iiop.util.IIOPUtils
which is the clHiearchy field in the IIOPUtils class.
This field is only needed for IIOPUtils.getCommonClassLoader, which is
not used in the GF 3.1 appserver.
I see that ClassLoaderHierarchy is still present in common/internal-api,
but is it still meaningful?
And why are no instances of this type available to be injected into
IIOPUtils?
I removed this dependency, but I would really like to know what changed
to cause this problem.
Debugging this is amazingly painful, and we really need to do better
than this.
By the way, at this point I'm debugging an ORB init problem, so the rest
of my problem is in my domain.
But what happened to ClassLoaderHierarchy? Is this obsolete for GF 3.1,
or is there just yet another
error someplace that caused this to be unavailable for injection?
Ken.