On 01/ 4/11 12:56 PM, Jerome Dochez wrote:
> On Jan 4, 2011, at 12:41 PM, Ken wrote:
>
>
>> 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?
>>
> because again, it's probably not on the class-path of the maven tests.
>
> remember you are doing unit tests, you are not running the appserver so you are responsible for setting the classpath correctly by having all the right modules in the classpath (which is what we do for you during the distribution building process).
>
> maven surefire plugin is just taking the list of dependencies of your module and run tests against it. It has no clue whatsoever where the @Contract implementations are located and since you don't depend on the @Service annotated classes to compile, it won't find them unless you specifically add the modules containing them with the<test> scope.
>
>
>> I removed this dependency, but I would really like to know what changed to cause this problem.
>>
> you should not remove that dependency unless it's useless.
>
I KNOW it's useless: it was there to satisfy one method that is not used
anywhere.
By removing the dependency, I mean removing the @Inject field in the class.
>
>> Debugging this is amazingly painful, and we really need to do better than this.
>>
>>
> that's why most people don't do unit tests but have devtests they run against a glassfish installation.
>
Makes sense to me, but again, I'm just trying to figure out why what's
already there
suddenly stopped working.
Ken.