On Jul 24, 2009, at 12:33 PM, Morten wrote:
> --- Den fre 24/7/09 skrev Paul Sandoz <Paul.Sandoz_at_Sun.COM>:
>> What HTTP container are you using?
>
> I am using Sun's HTTPSERVER
>
Hmm... the Jersey LW HTTP HttpHandlerContainer is written such that an
IOException will be thrown from the handle method. I suspect that when
the status code and headers are set such exceptions do not result in
premature termination of the connection (plus no logging occurs).
If you don't have any specific configuration with that container it is
easy to switch to using Grizzly to verify if you get the same behaviour.
See the sample here that uses Grizzly:
http://download.java.net/maven/2/com/sun/jersey/samples/helloworld/1.1.1-ea/helloworld-1.1.1-ea-project.zip
and see here:
https://jersey.dev.java.net/nonav/apidocs/1.1.1-ea/jersey/com/sun/jersey/api/container/grizzly/GrizzlyServerFactory.html
https://jersey.dev.java.net/nonav/apidocs/1.1.1-ea/jersey/com/sun/jersey/api/container/grizzly/GrizzlyWebContainerFactory.html
>> If there is an error marshalling the JAXB object then
>> Jersey will throw an IOException to the underlying HTTP
>> container, as the code in the previous email presented
>> (also, any other RuntimeException, expect for
>> WebApplicationException in certain cases, will go directly
>> to the underlying HTTP container).
>>
>> My current guess is that the underlying HTTP container
>> seems to be ignoring the IOException (which wraps a
>> JAXBException) thrown to the underlying HTTP container.
>
> Hmm. Maybe
>
>> Is a JAXBException or a sub-class of thrown?
>
> Not sure about the class. My last email and trace was cut by my
> email client. I will try again with some more details here I hope
> it is not cut again.
>
> IllegalAnnotationExceptions ....(JAXB annotation is placed on a
> method that is not a JAXB property)...
>
> at com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException
> $Builder.check(IllegalAnnotationsException.java:66)
> at
> com
> .sun
> .xml
> .internal
> .bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:
> 422)
> at
> com
> .sun
> .xml
> .internal
> .bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:270)
> at
> com
> .sun
> .xml
> .internal.bind.v2.ContextFactory.createContext(ContextFactory.java:
> 103)
> at
> com
> .sun
> .xml
> .internal.bind.v2.ContextFactory.createContext(ContextFactory.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun
> .reflect
> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun
> .reflect
> .DelegatingMethodAccessorImpl
> .invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)
> at javax.xml.bind.ContextFinder.find(ContextFinder.java:376)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
>
OK. I verified that internal exception extends JAXBException.
Paul.