I have added in RethrowErrorService and a method on
ServiceLocatorUtilities called enableLookupExceptions.
There are warnings in the javadoc about using this in secure
environments since telling someone that they are not allowed access to a
service is considered a security leak.
Therefore use with care...
On 8/16/2013 7:28 AM, John Wells wrote:
> 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?
>>>>
>>>>
>>>
>>
>>
>