dev@glassfish.java.net

Re: Debugging Dependency Injection in GlassFish

From: Jerome Dochez <jerome.dochez_at_oracle.com>
Date: Tue, 4 Jan 2011 13:20:23 -0800

On Jan 4, 2011, at 1:02 PM, Ken wrote:

> On 01/ 4/11 12:35 PM, Jerome Dochez wrote:
>> well, no because it's not necessarily an error for HK2 that you request an object that is not available through APIs.
>> as for the object not being there, if the jar is not on the class-path, I am not sure what hk2 can do.
>>
>>
> I agree with this, but when we start seeing injection failures because A depends on B depends on C depends on D ...,
> and the end of the chain is in a completely unrelated part of the codebase, it's really hard to debug these things.
> Does hk2 have some debug options we could enable in such situations to see the entire chain of injection
> failures, rather than just the end result NPE? I'd also like to see in such cases something saying just
> what jar files hk2 is scanning for dependencies (probably normally not an issue in GF if hk2 is scanning
> all of the modules directory).
I think it would be possible to display the entire chain by walking up the stack trace but it's not trivial.
would u mind filing an RFE against hk2 at hk2.java.net

>
> By the way, I'm still not done with dependency injection problems: the ORB init failure is caused by a
> failure to construct an IIOPSSLSocketFactory (in orb-iiop), which fails because the IIOPSSLSocketFactory
> constructor can't get an instance of IIOPSSLUtil (interface defined in orb-connector, impl in ejb.security).
> Now, once again glassfish-naming has no dependency on ejb.security, so I add to the glassfish-naming pom:
>
> <dependency>
> <groupId>org.glassfish.security</groupId>
> <artifactId>ejb.security</artifactId>
> <version>${project.version}</version>
> <scope>test</scope>
> </dependency>
>
> and FINALLY the glassfish-naming surefire tests pass.
>
> So what's going on? Why did everything work fine for 2+ years, and
> now suddenly I need to add these new dependencies?
some modules must have changed their dependencies/packaging. Transitive dependencies can be a moving target.
>
> Thanks,
>
> Ken.