Funny thing, the issue has vanished... Seems like some cool guy already fixed it :)
Thanks for your help and patience.
Best Regards.
Martin
On 05.05.2010, at 10:11, Paul Sandoz wrote:
>
> On May 5, 2010, at 9:01 AM, Martin Scholl wrote:
>
>> Hi,
>>
>> Sorry for the late reply. I'd been trying to isolate the problem but without luck. I'm not able to create a test case in reasonable time and I still have no clue what could be happening there. But just out of desperation I tried Jetty as ServletContainer and it does neither complain nor throws it any exceptions at me. So I suppose this issue would rather be of interest on the Grizzly mailing list, no?
>
> Can you try upgrading to Grizzly 1.9.18-i ?
>
> If that fails perhaps you can email to the grizzly list, they may well ask for a test case like i have :-) but perhaps they will recognize the stack trace?
>
> Paul.
>
>> But as long as I'm not able to track down the cause I think it turns out to be rather complicated to find out the reasons.
>>
>> So what can I do?
>>
>> Kind regards,
>>
>> Martin
>>
>> On 04.05.2010, at 10:42, Martin Scholl wrote:
>>
>>> Hi Paul,
>>>
>>> I use this artifacts
>>>
>>> <dependency>
>>> <groupId>com.sun.jersey</groupId>
>>> <artifactId>jersey-server</artifactId>
>>> <version>1.1.5.1</version>
>>> </dependency>
>>> <dependency>
>>> <groupId>com.sun.jersey</groupId>
>>> <artifactId>jersey-client</artifactId>
>>> <version>1.1.5.1</version>
>>> </dependency>
>>> <dependency>
>>> <groupId>com.sun.grizzly</groupId>
>>> <artifactId>grizzly-servlet-webserver</artifactId>
>>> <version>1.9.9</version>
>>> </dependency>
>>>
>>> I'll try to compile a test case asap.
>>>
>>>
>>> On 04.05.2010, at 10:37, Paul Sandoz wrote:
>>>
>>>> Hi Martin,
>>>>
>>>> What version of grizzly are you using?
>>>>
>>>> I have not seen this type of error before and need more information.
>>>>
>>>> Can you send me a reproducible test case, preferably maven based?
>>>>
>>>> Paul.
>>>>
>>>> On May 4, 2010, at 9:42 AM, Martin Scholl wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Recently I started to use Jersey for the purpose of adding a REST interface to our server application. I have implemented some operations of the server interface and a corresponding client part. Additionally I wrote some very short JUnit tests that use the client part to simply "see" whether the methods actually return stuff or cause some kind of exception. The weird thing is that all those tests succeed if they are run solely (putting an @Ignore flag at the other tests) but if the complete test class is run some of the service requests cause errors (or to be exact: If the error occurs once all further service requests will fail, too):
>>>>>
>>>>> May 4, 2010 9:28:51 AM com.sun.grizzly.http.servlet.ServletAdapter service
>>>>> SEVERE: service exception:
>>>>> java.lang.NullPointerException
>>>>> at com.sun.grizzly.tcp.http11.GrizzlyOutputStream.write(GrizzlyOutputStream.java:128)
>>>>> at com.sun.grizzly.http.servlet.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:84)
>>>>> at com.sun.jersey.spi.container.servlet.WebComponent$Writer.write(WebComponent.java:276)
>>>>> at com.sun.jersey.spi.container.ContainerResponse$CommittingOutputStream.write(ContainerResponse.java:130)
>>>>> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202)
>>>>> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:272)
>>>>> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:276)
>>>>> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:122)
>>>>> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:212)
>>>>> at java.io.BufferedWriter.flush(BufferedWriter.java:236)
>>>>> at com.sun.jersey.core.util.ReaderWriter.writeToAsString(ReaderWriter.java:178)
>>>>> at com.sun.jersey.core.provider.AbstractMessageReaderWriterProvider.writeToAsString(AbstractMessageReaderWriterProvider.java:125)
>>>>> at com.sun.jersey.core.impl.provider.entity.StringProvider.writeTo(StringProvider.java:85)
>>>>> at com.sun.jersey.core.impl.provider.entity.StringProvider.writeTo(StringProvider.java:57)
>>>>> at com.sun.jersey.spi.container.ContainerResponse.write(ContainerResponse.java:289)
>>>>> at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1029)
>>>>> at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:941)
>>>>> at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:932)
>>>>> at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:384)
>>>>> at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:451)
>>>>> at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:632)
>>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>>>>> at com.sun.grizzly.http.servlet.FilterChainImpl.doFilter(FilterChainImpl.java:188)
>>>>> at com.sun.grizzly.http.servlet.FilterChainImpl.invokeFilterChain(FilterChainImpl.java:137)
>>>>> at com.sun.grizzly.http.servlet.ServletAdapter.service(ServletAdapter.java:278)
>>>>> at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:165)
>>>>> at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:726)
>>>>> at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:615)
>>>>> at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:895)
>>>>> at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:162)
>>>>> at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:136)
>>>>> at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)
>>>>> at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)
>>>>> at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
>>>>> at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)
>>>>> at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
>>>>> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>>>>> at java.lang.Thread.run(Thread.java:637)
>>>>>
>>>>> So the request is received correctly but when it comes to returning a response Grizzly somehow runs into this NPE.
>>>>>
>>>>> I started up the Grizzly server as described in the Jersey Tutorial. Will I have to fine-tune this initialization? Or is this error a result of an erroneous implementation of the server interface methods? Does anybody have a clue why this happens? Help is highly appreciated.
>>>>>
>>>>> Thanks in advance.
>>>>>
>>>>> Best regards.
>>>>>
>>>>> Martin
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>