> I almost always add the "rethrow" version of the ErrorHandler to nearly
every system I work on...
How is this done exactly? I'm poking around and not finding any
implementations of ErrorService. Is this something that must be coded at
custom?
On Thu, Aug 15, 2013 at 7:36 AM, buko <buko_at_chiubarobot.com> wrote:
> Ah, osgi strikes again. Would it make sense to have other methods like
> requireService that would throw an exception?
>
> Another option might be to simply log a warning. Anything would be better
> than just failing silently.
> On Aug 15, 2013 7:27 AM, "John Wells" <john.wells_at_oracle.com> wrote:
>
>> It is (unfortunately IMO) the case that errors are treated by default as
>> pass-throughs on lookups (i.e, lookup will return null rather than re-throw
>> the error). I personally think the default should be the other way
>> around. The reason for this default is that when operating in the OSGi
>> environment we get a lot of reification failures (as the bundles are not
>> hooked up properly) and so it was decided to make the default behavior to
>> ignore that failure. I think it was not a good decision, but changing it
>> now would be dangerous. I almost always add the "rethrow" version of the
>> ErrorHandler to nearly every system I work on...
>>
>> On 8/15/2013 7:01 AM, John Wells wrote:
>>
>> Yes, if you have @Service then the default switches from @PerLookup to
>> @Singleton. This is done for backwards compatibility reasons. I will
>> update the javadoc.
>>
>> On 8/15/2013 6:55 AM, buko wrote:
>>
>> And the problem turns out to be the @Service annotation that was on the
>> class. Removing this annotation made everything work. Not clear why
>> @Service would act as alias for @Singleton. This should probably be made
>> clear in the javadoc.
>>
>>
>> On Thu, Aug 15, 2013 at 6:53 AM, buko <buko_at_chiubarobot.com> wrote:
>>
>>> Encountering a strange issue. Maybe somebody else has encountered it?
>>> Debugging through the code I see that during the lookup the narrowed
>>> results contains this error:
>>>
>>> [ErrorResult(SystemDescriptor(
>>> implementation=sourcery.client.ClientContainer$ClientImpl
>>>
>>> contracts={sourcery.client.ClientContainer$ClientImpl,com.bubblegumproject.sourcery.client.Client}
>>> scope=org.glassfish.hk2.api.PerLookup
>>> qualifiers={}
>>> descriptorType=CLASS
>>> descriptorVisibility=NORMAL
>>> metadata=
>>> rank=0
>>> loader=HK2LoaderImpl(sun.misc.Launcher$AppClassLoader_at_332b9f79)
>>> proxiable=null
>>> proxyForSameScope=null
>>> analysisName=null
>>> id=7
>>> locatorId=0
>>> identityHashCode=933319313
>>> reified=false),null,A MultiException has 2 exceptions. They are:
>>> 1. java.lang.IllegalArgumentException: The scope name given in the
>>> descriptor (org.glassfish.hk2.api.PerLookup) did not match the scope
>>> annotation on the class (javax.inject.Singleton) in class
>>> ClientContainer$ClientImpl
>>> 2. java.lang.IllegalArgumentException: Errors were discovered while
>>> reifying SystemDescriptor(
>>> implementation=sourcery.client.ClientContainer$ClientImpl
>>>
>>> contracts={sourcery.client.ClientContainer$ClientImpl,com.bubblegumproject.sourcery.client.Client}
>>> scope=org.glassfish.hk2.api.PerLookup
>>> qualifiers={}
>>> descriptorType=CLASS
>>> descriptorVisibility=NORMAL
>>> metadata=
>>> rank=0
>>> loader=HK2LoaderImpl(sun.misc.Launcher$AppClassLoader_at_332b9f79)
>>> proxiable=null
>>> proxyForSameScope=null
>>> analysisName=null
>>> id=7
>>> locatorId=0
>>> identityHashCode=933319313
>>> reified=false)
>>> ,465001913)]
>>>
>>> Two problems: (1) the ClientImpl class doesn't have the @Singleton
>>> annotation and (2) for some reason, errorHandlers is empty and so this
>>> error is silently suppressed. No exception is raised. I only found it by
>>> stepping through the code.
>>>
>>> Adding the @Singleton annotation makes everything better.
>>>
>>> Any ideas?
>>>
>>
>>
>>
>>