users@jaxb.java.net

Re: "impossible" exception thrown from RI

From: Kenny MacLeod <kennym_at_kizoom.com>
Date: Mon, 13 Nov 2006 22:54:50 +0000

line 99 is the InternalError throw.

The original exception is a NoClassDefFoundError. The XJC-generated
code contains a direct reference to the XmlAdapter type, and if that
adapter type is not present at runtime, then NoClassDefFoundError is
thrown, which is wrapped in an InvocationTargetException, and then
eclipsed by the InternalError.

Kohsuke Kawaguchi wrote:
>
> Hmm, line 99 in my workspace is in the following code:
>
>> public Class getClassValue(Annotation a, String name) {
>> try {
>> return (Class)a.annotationType().getMethod(name).invoke(a);
>> } catch (IllegalAccessException e) {
>> // impossible
>> throw new IllegalAccessError(e.getMessage());
>> } catch (InvocationTargetException e) {
>> // impossible
>> throw new InternalError(e.getMessage());
>> } catch (NoSuchMethodException e) {
>> throw new NoSuchMethodError(e.getMessage());
>> }
>> }
>
> So I'm having bit of trouble understanding how the lack of your jar
> could cause this --- this can only happen if JAXB tries to read off
> annotations that it doesn't have access, but JAXB only tries to read
> JAXB annotations.
>
> Perhaps the source code is out of sync? Can you tell me what's your line
> 99?
>
> Kenny MacLeod wrote:
>> I just came across the RI throwing a java.lang.InternalError when
>> setting up the context.
>>
>> The exception is thrown from RuntimeInlineAnnotationReader line 99,
>> which is amusingly commented as "impossible".
>>
>> The root cause was that I had used xjc:javaType in the binding
>> customisation to bind schema types to some custom java types, but when
>> I'd used the generated bindings in my application, I'd forgotten to
>> include the JAR which contained my custom bound types.
>>
>> So the RI failed because it couldn't find the type, which was wrapped
>> in an InvocationTargetException, which in turn was retrown as an
>> InternalError.
>>
>> Tricky one to diagnose, since InternalError doesn't have a getCause(),
>> so I had to use the debugger to trap the original before it was rethrown.
>>
>> Can the RI be changed to handle this more gracefully?
>
>
>