On 01/ 4/11 01:20 PM, Jerome Dochez wrote:
> 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
>
>
OK. I added myself as an Observer for HK2, and filed HK2-12: Request
for improvements
in debugging dependency problems in systems using HK2.
Obviously my suggestions
are not necessarily the best possible choices, given my lack of
knowledge of HK2
internals, but hopefully the description captures the essence if someone
decides to work on this issue.
>> 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.
>
I know. Not only does the consumer not know something has changed, but
the supplier doesn't
know they've affected someone else.
Thanks,
Ken.