The implementation of an always rethrow ErrorService is trivial (and is
normally done by the user of hk2). However, we do supply common
implementations of other services, so I think I will supply a
RethrowErrorService (and may also add a method to
ServiceLocatorUtilities to add it).
On 8/16/2013 4:30 AM, buko wrote:
> > 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
> <mailto: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
> <mailto: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
>>> <mailto: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?
>>>
>>>
>>
>
>