I have created this to track this:
https://java.net/jira/browse/HK2-174
Feature requests can also be added to Jira. We get to most of them...
eventually...
I don't understand the request to identify the classloader of components
since there is a "getLoader" method on
https://hk2.java.net/2.2.0-b27/apidocs/org/glassfish/hk2/api/Descriptor.html.
I know this returns an HKLoader as opposed to a classloader but this was
done because we have several products that do byte-weaving into existing
classes and so using a raw class-loader would not have worked properly.
As far as using @Nullable, we can't use that specifically at the base
level of HK2 since it is a Guice annotation. What I think might be a
reasonable feature request here is the ability to use any annotation as
an indicator for @Optional. That does sound like an interesting feature...
On 1/3/2014 1:39 AM, buko wrote:
>
> Thanks, I was just wondering if hk2 has any kind of public backlog.
> There are a many features/bugs I've run into and its not clear whether
> they're being tracked or not. Stuff like the ability to correctly
> identify the classloader of components, ability to use of
> javax.inject.Provider instead of hk2's custom Factory interface,
> ability to use @Nullable instead of @Optional,support for interceptors
> would be really nice.
>
> On Jan 3, 2014 1:12 AM, "cowwoc" <cowwoc_at_bbs.darktech.org
> <mailto:cowwoc_at_bbs.darktech.org>> wrote:
>
> On 03/01/2014 12:58 AM, buko wrote:
>
>
> Discovered another case where hk2 is silently suppressing an
> exception/hiding it behind another exception. Each time this
> happens it's pretty frustrating because a good chunk of time
> must be spent debugging the container trying to figure out
> what, if anything it's doing.
>
> In this case I created a Factory implementation that throws a
> RuntimeException from the Factory#provide() method. (It's not
> clear, BTW, why Factory#provide() doesn't allow an exception
> to be thrown.) The exception boils up to Cache#compute(final K
> key). The catch(ExecutionException ex) block then rethrows the
> exception to SingletonContext#findOrCreate
> catch(RuntimeException re) block. This method rethrows the
> exception in a MultiException and calls
> RuntimeException.getCause(). MultiException(Throwable th) ctor
> requires that Throwable not be null but it does not check that
> condition. It just assumes it and the result is a
> NullPointerException that very effectively hides the
> underlying exception. If MultiException simply did a check it
> might raise a more informative error that preserves the stack
> trace. It's also not clear why SingletonContext#findOrCreate
> doesn't preserve the runtimeException and instead chooses to
> unwrap it by calling RuntimeException.getCause().
>
> One issue to get around this would be better logging. hk2
> seems to do little logging that doesn't provide much insight
> into what's happening or what went wrong.
>
>
> Very good detective work! I suggest filing a bug report and
> sharing it with the mailing list: https://java.net/jira/browse/HK2
>
> Gili
>