Kenny MacLeod wrote:
> 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.
Aha.
I modified the code to properly initialize the cause field. I'll check
other places for this kind of cause-less exception nesting, too.
If only those JDK exception classes define a convenient constructor...
>
> 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?
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>
>
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com