I see the same behaviour with the same build on a separate, fresh Ubuntu
16.04 system, with JSPWiki in an out of the box state running the
default skin. The full stack trace is:

[WARNING] [] [javax.enterprise.web] [tid: _ThreadID=29
_ThreadName=http-listener-1(2)] [timeMillis: 1488401379691] [levelValue:
900] [[
  StandardWrapperValve[jsp]: Servlet.service() for servlet jsp threw
  exception
java.lang.IllegalStateException: getWriter() has already been called for
this response
        at
        
org.apache.catalina.connector.Response.getOutputStream(Response.java:746)
        at
        
org.apache.catalina.connector.ResponseFacade.getOutputStream(ResponseFacade.java:206)
        at
        org.apache.wiki.ui.WikiJSPFilter.doFilter(WikiJSPFilter.java:128)
        at
        
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
        at
        
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
        at
        
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:316)
        at
        
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
        at
        
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
        at
        
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
        at
        com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
        at
        
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
        at
        
org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:416)
        at
        
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:283)
        at
        
com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
        at
        
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
        at
        
org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
        at
        
org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
        at
        
org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
        at
        
org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
        at
        
org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
        at
        
org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
        at
        
org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
        at
        
org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
        at
        
org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
        at
        
org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
        at
        
org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
        at
        
org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
        at
        
org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
        at
        
org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
        at
        
org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591)
        at
        
org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
        at java.lang.Thread.run(Thread.java:745)

I'll open a bug report for this.

-- 
Dave Koelmeyer
http://blog.davekoelmeyer.co.nz
GPG Key ID: 0x238BFF87

On Wed, Mar 1, 2017, at 07:59 AM, Ross, Ed wrote:
> The errors are not always as intuitive as one might hope.  Check the user
> and permissions.
> 
> You can easily deploy to tomcat to see if there are any configuration
> issues:
> 
> 
> You didn't mention what you were upgrading from?
> 
> FWIW - I just upgraded in December - there were a number of pain points
> but things seem to work ok.  My upgrade was from a Tomcat instance to a
> Tomcat running in Docker
> 
> 
> 
> -----Original Message-----
> From: Dave Koelmeyer [mailto:dave.koelme...@davekoelmeyer.co.nz]
> Sent: Tuesday, February 28, 2017 1:46 PM
> To: user@jspwiki.apache.org
> Subject: IllegalStateException with the latest JSPWiki
> 
> Hi All,
> 
> I've just performed a JSPWiki upgrade using the latest
> JSPWiki-2.10.3-SNAPSHOT checked out from Git. I've replaced my existing
> WAR file with the newly built WAR and restarted my container. JSPWiki
> will then generate the following error when navigating to the base URL:
> 
> The server encountered an internal error that prevented it from
> fulfilling this request.
> java.lang.IllegalStateException: getWriter() has already been called for
> this response
> 
> On other attempts to redeploy the WAR, JSPWiki will apparently start
> fine, but the same error is then generated when trying to save user
> preferences.
> 
> I'm running Payara Server 4.1.1.161 with JDK 1.8.0_73. The container does
> have file-based realm authentication configured, and HTTPS. I'm using the
> Haddock template.
> 
> Any ideas? Thanks!
> 
> --
> Dave Koelmeyer
> http://blog.davekoelmeyer.co.nz
> GPG Key ID: 0x238BFF87
> 
> This email may contain confidential or privileged material. Use or
> disclosure of it by anyone other than the recipient is unauthorized. If
> you are not an intended recipient, please delete this email.

Reply via email to