buildbot failure in ASF Buildbot on tomee-trunk-ubuntu
The Buildbot has detected a new failure on builder tomee-trunk-ubuntu while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomee-trunk-ubuntu/builds/233 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: hemera_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomee/tomee/trunk] 1461000 Blamelist: rmannibucau BUILD FAILED: failed test sincerely, -The Buildbot
buildbot success in ASF Buildbot on tomee-trunk-empty-repo
The Buildbot has detected a restored build on builder tomee-trunk-empty-repo while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomee-trunk-empty-repo/builds/12 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: hemera_ubuntu Build Reason: The Nightly scheduler named 'tomee-trunk-empty-repo' triggered this build Build Source Stamp: [branch tomee/tomee/trunk] HEAD Blamelist: Build succeeded! sincerely, -The Buildbot
buildbot success in ASF Buildbot on tomee-1.6.0.beta1-ubuntu
The Buildbot has detected a restored build on builder tomee-1.6.0.beta1-ubuntu while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomee-1.6.0.beta1-ubuntu/builds/1 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: hemera_ubuntu Build Reason: forced: by IRC user on channel #openejb: None Build Source Stamp: HEAD Blamelist: Build succeeded! sincerely, -The Buildbot
[jira] [Closed] (TOMEE-845) CLONE - Ensure Build is passing
[ https://issues.apache.org/jira/browse/TOMEE-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau closed TOMEE-845. Resolution: Fixed Fix Version/s: 1.6.0.beta1 Assignee: Romain Manni-Bucau > CLONE - Ensure Build is passing > --- > > Key: TOMEE-845 > URL: https://issues.apache.org/jira/browse/TOMEE-845 > Project: TomEE > Issue Type: Sub-task >Reporter: David Blevins >Assignee: Romain Manni-Bucau > Fix For: 1.6.0.beta1 > > > http://ci.apache.org/builders/openejb-trunk-ubuntu > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OPENEJB-2010) OpenEJB Http - Connection reset (4.5.0, 4.5.1)
Pawel Ruta created OPENEJB-2010: --- Summary: OpenEJB Http - Connection reset (4.5.0, 4.5.1) Key: OPENEJB-2010 URL: https://issues.apache.org/jira/browse/OPENEJB-2010 Project: OpenEJB Issue Type: Bug Components: server Affects Versions: 4.5.1, 4.5.0 Environment: Windows 7 / Linux Reporter: Pawel Ruta Priority: Critical Randomly I'm getting "java.net.SocketException: Connection reset" exception when using OpenEJB embedable as a server for Statless Web Services (CXF implementation) and CXF WS client. On some computers it never happens, on some almost always, on some randomly. It happens (randomly) when SOAP Message generated by a server is more than 8192 bytes in size (related to buffer size in SocketInputStream.java). I've noticed that in OpenEJBHttpServer.java (org.apache.openejb.server.httpd.OpenEJBHttpServer), method service(Socket socket) you are closing OutputStream immediatelly after flushing data. Closing OutputStream means also closing socket. Closing socket means "Connection reset" if client isn't fast enough to recieving data from socket. Client-server communication using ServerSocket and Socket is a bit tricky. In ideal situation client should report that it is ending the comunication and then server shoudl close socket. That's not a case for HttpServer. I propose the solution to wait for client to close socket (all good implementation of client will close socket :) ). We can wait (non-blocking) for client closing socket by reading InputStream. When client close connection then InputStream returns -1. If client doesn't responde connection timeout occur (default is 60 seconds I suppose). I've attached changed sources. The solution is quick (dirty). Probably the more sophisticated approach for managing resource (threads, sockets) should be used. Reported exception, full stack: javax.xml.ws.soap.SOAPFaultException: Unmarshalling Error: Connection reset at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:156) Caused by: javax.xml.bind.UnmarshalException with linked exception: [com.ctc.wstx.exc.WstxIOException: Connection reset] at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleStreamException(UnmarshallerImpl.java:426) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:362) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:339) at org.apache.cxf.jaxb.JAXBEncoderDecoder.doUnmarshal(JAXBEncoderDecoder.java:784) at org.apache.cxf.jaxb.JAXBEncoderDecoder.access$100(JAXBEncoderDecoder.java:97) at org.apache.cxf.jaxb.JAXBEncoderDecoder$1.run(JAXBEncoderDecoder.java:812) at java.security.AccessController.doPrivileged(Native Method) at org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:810) at org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:644) at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:157) at org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:109) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262) at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:801) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1694) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1530) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1438) at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:660) at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262) at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:531) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:464) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:367) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:320) at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:89) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:134) ... 36 more Caused by: com.ctc.wstx.exc.WstxIOException: Connection reset at com.ctc.wstx.sr.StreamScanner.constructFromIOE(StreamScanner.java:631) at com.ctc.wstx.sr.StreamScanner.loadMore(StreamScanner.java:999) at com.ctc.wstx.sr.StreamScanner.getNext(StreamScanner.java:759) at com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:2662) at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1048) at com.sun.xml.bind.v2.runtime.unmarshaller
[jira] [Updated] (OPENEJB-2010) OpenEJB Http - Connection reset (4.5.0, 4.5.1)
[ https://issues.apache.org/jira/browse/OPENEJB-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pawel Ruta updated OPENEJB-2010: Attachment: OpenEJBHttpServer.java > OpenEJB Http - Connection reset (4.5.0, 4.5.1) > -- > > Key: OPENEJB-2010 > URL: https://issues.apache.org/jira/browse/OPENEJB-2010 > Project: OpenEJB > Issue Type: Bug > Components: server >Affects Versions: 4.5.0, 4.5.1 > Environment: Windows 7 / Linux >Reporter: Pawel Ruta >Priority: Critical > Attachments: OpenEJBHttpServer.java > > > Randomly I'm getting "java.net.SocketException: Connection reset" exception > when using OpenEJB embedable as a server for Statless Web Services (CXF > implementation) and CXF WS client. On some computers it never happens, on > some almost always, on some randomly. It happens (randomly) when SOAP Message > generated by a server is more than 8192 bytes in size (related to buffer size > in SocketInputStream.java). > I've noticed that in OpenEJBHttpServer.java > (org.apache.openejb.server.httpd.OpenEJBHttpServer), method service(Socket > socket) you are closing OutputStream immediatelly after flushing data. > Closing OutputStream means also closing socket. Closing socket means > "Connection reset" if client isn't fast enough to recieving data from socket. > Client-server communication using ServerSocket and Socket is a bit tricky. In > ideal situation client should report that it is ending the comunication and > then server shoudl close socket. That's not a case for HttpServer. I propose > the solution to wait for client to close socket (all good implementation of > client will close socket :) ). We can wait (non-blocking) for client closing > socket by reading InputStream. When client close connection then InputStream > returns -1. If client doesn't responde connection timeout occur (default is > 60 seconds I suppose). > I've attached changed sources. The solution is quick (dirty). Probably the > more sophisticated approach for managing resource (threads, sockets) should > be used. > Reported exception, full stack: > javax.xml.ws.soap.SOAPFaultException: Unmarshalling Error: Connection reset > at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:156) > Caused by: javax.xml.bind.UnmarshalException > with linked exception: > [com.ctc.wstx.exc.WstxIOException: Connection reset] > at > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleStreamException(UnmarshallerImpl.java:426) > > at > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:362) > > at > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:339) > > at > org.apache.cxf.jaxb.JAXBEncoderDecoder.doUnmarshal(JAXBEncoderDecoder.java:784) > > at > org.apache.cxf.jaxb.JAXBEncoderDecoder.access$100(JAXBEncoderDecoder.java:97) > at org.apache.cxf.jaxb.JAXBEncoderDecoder$1.run(JAXBEncoderDecoder.java:812) > at java.security.AccessController.doPrivileged(Native Method) > at > org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:810) > > at > org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:644) > > at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:157) > at > org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:109) > > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262) > > at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:801) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1694) > > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1530) > > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1438) > > at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) > at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:660) > at > org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62) > > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262) > > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:531) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:464) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:367) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:320) > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:89) > at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:134) > ... 36 more > Caused by: com.ctc.wstx.exc.WstxIOExceptio
svn commit: r1461097 - in /tomee/tomee/trunk/server: openejb-http/src/main/java/org/apache/openejb/server/httpd/OpenEJBHttpServer.java openejb-server/src/main/java/org/apache/openejb/server/ServicePoo
Author: rmannibucau Date: Tue Mar 26 12:53:30 2013 New Revision: 1461097 URL: http://svn.apache.org/r1461097 Log: OPENEJB-2010 forcing openejb http to close the socket after the client read it Modified: tomee/tomee/trunk/server/openejb-http/src/main/java/org/apache/openejb/server/httpd/OpenEJBHttpServer.java tomee/tomee/trunk/server/openejb-server/src/main/java/org/apache/openejb/server/ServicePool.java Modified: tomee/tomee/trunk/server/openejb-http/src/main/java/org/apache/openejb/server/httpd/OpenEJBHttpServer.java URL: http://svn.apache.org/viewvc/tomee/tomee/trunk/server/openejb-http/src/main/java/org/apache/openejb/server/httpd/OpenEJBHttpServer.java?rev=1461097&r1=1461096&r2=1461097&view=diff == --- tomee/tomee/trunk/server/openejb-http/src/main/java/org/apache/openejb/server/httpd/OpenEJBHttpServer.java (original) +++ tomee/tomee/trunk/server/openejb-http/src/main/java/org/apache/openejb/server/httpd/OpenEJBHttpServer.java Tue Mar 26 12:53:30 2013 @@ -88,21 +88,11 @@ public class OpenEJBHttpServer implement @Override public void service(final Socket socket) throws ServiceException, IOException { -/** - * The InputStream used to receive incoming messages from the client. - */ -InputStream in = null; -/** - * The OutputStream used to send outgoing response messages to the client. - */ -OutputStream out = null; +RequestInfos.initRequestInfo(socket); +final InputStream in = new CountingInputStream(socket.getInputStream()); +final OutputStream out = new CountingOutputStream(socket.getOutputStream()); try { -RequestInfos.initRequestInfo(socket); - -in = new CountingInputStream(socket.getInputStream()); -out = new CountingOutputStream(socket.getOutputStream()); - //TODO: if ssl change to https final URI socketURI = new URI("http://"; + socket.getLocalAddress().getHostAddress() + ":" + socket.getLocalPort()); processRequest(socketURI, in, out); @@ -110,31 +100,10 @@ public class OpenEJBHttpServer implement } catch (Throwable e) { log.error("Unexpected error", e); } finally { -if (out != null) { -try { -out.flush(); -} catch (Throwable e) { -//Ignore -} -try { -out.close(); -} catch (Throwable e) { -//Ignore -} -} - -if (in != null) { -try { -in.close(); -} catch (Throwable e) { -//Ignore -} -} - try { -socket.close(); +out.flush(); } catch (Throwable e) { -log.error("Encountered problem while closing connection with client: " + e.getMessage()); +//Ignore } } } @@ -160,10 +129,12 @@ public class OpenEJBHttpServer implement @Override public void start() throws ServiceException { +// no-op } @Override public void stop() throws ServiceException { +// no-op } @Override Modified: tomee/tomee/trunk/server/openejb-server/src/main/java/org/apache/openejb/server/ServicePool.java URL: http://svn.apache.org/viewvc/tomee/tomee/trunk/server/openejb-server/src/main/java/org/apache/openejb/server/ServicePool.java?rev=1461097&r1=1461096&r2=1461097&view=diff == --- tomee/tomee/trunk/server/openejb-server/src/main/java/org/apache/openejb/server/ServicePool.java (original) +++ tomee/tomee/trunk/server/openejb-server/src/main/java/org/apache/openejb/server/ServicePool.java Tue Mar 26 12:53:30 2013 @@ -21,12 +21,14 @@ import org.apache.openejb.loader.SystemI import org.apache.openejb.monitoring.Managed; import org.apache.openejb.util.LogCategory; import org.apache.openejb.util.Logger; +import org.apache.openejb.util.OptionsLog; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; import java.net.Socket; import java.util.Properties; +import java.util.concurrent.BlockingQueue; import java.util.concurrent.LinkedBlockingQueue; import java.util.concurrent.RejectedExecutionHandler; import java.util.concurrent.ThreadFactory; @@ -43,6 +45,9 @@ public class ServicePool extends ServerS private final ThreadPoolExecutor threadPool; private final AtomicBoolean stop = new AtomicBoolean(); +private final CleanUpThread cleanupThread = new CleanUpThread(); +private long maxResponseSize = Long.MAX_VALUE; +private int cleanupTimeout = 500; public ServicePool(final ServerService next, final Properties p
svn commit: r1461098 - in /tomee/tomee/branches/tomee-1.6.0.beta1/server: openejb-http/src/main/java/org/apache/openejb/server/httpd/OpenEJBHttpServer.java openejb-server/src/main/java/org/apache/open
Author: rmannibucau Date: Tue Mar 26 12:53:31 2013 New Revision: 1461098 URL: http://svn.apache.org/r1461098 Log: OPENEJB-2010 forcing openejb http to close the socket after the client read it - 1.6.0.beta1 Modified: tomee/tomee/branches/tomee-1.6.0.beta1/server/openejb-http/src/main/java/org/apache/openejb/server/httpd/OpenEJBHttpServer.java tomee/tomee/branches/tomee-1.6.0.beta1/server/openejb-server/src/main/java/org/apache/openejb/server/ServicePool.java Modified: tomee/tomee/branches/tomee-1.6.0.beta1/server/openejb-http/src/main/java/org/apache/openejb/server/httpd/OpenEJBHttpServer.java URL: http://svn.apache.org/viewvc/tomee/tomee/branches/tomee-1.6.0.beta1/server/openejb-http/src/main/java/org/apache/openejb/server/httpd/OpenEJBHttpServer.java?rev=1461098&r1=1461097&r2=1461098&view=diff == --- tomee/tomee/branches/tomee-1.6.0.beta1/server/openejb-http/src/main/java/org/apache/openejb/server/httpd/OpenEJBHttpServer.java (original) +++ tomee/tomee/branches/tomee-1.6.0.beta1/server/openejb-http/src/main/java/org/apache/openejb/server/httpd/OpenEJBHttpServer.java Tue Mar 26 12:53:31 2013 @@ -88,21 +88,11 @@ public class OpenEJBHttpServer implement @Override public void service(final Socket socket) throws ServiceException, IOException { -/** - * The InputStream used to receive incoming messages from the client. - */ -InputStream in = null; -/** - * The OutputStream used to send outgoing response messages to the client. - */ -OutputStream out = null; +RequestInfos.initRequestInfo(socket); +final InputStream in = new CountingInputStream(socket.getInputStream()); +final OutputStream out = new CountingOutputStream(socket.getOutputStream()); try { -RequestInfos.initRequestInfo(socket); - -in = new CountingInputStream(socket.getInputStream()); -out = new CountingOutputStream(socket.getOutputStream()); - //TODO: if ssl change to https final URI socketURI = new URI("http://"; + socket.getLocalAddress().getHostAddress() + ":" + socket.getLocalPort()); processRequest(socketURI, in, out); @@ -110,31 +100,10 @@ public class OpenEJBHttpServer implement } catch (Throwable e) { log.error("Unexpected error", e); } finally { -if (out != null) { -try { -out.flush(); -} catch (Throwable e) { -//Ignore -} -try { -out.close(); -} catch (Throwable e) { -//Ignore -} -} - -if (in != null) { -try { -in.close(); -} catch (Throwable e) { -//Ignore -} -} - try { -socket.close(); +out.flush(); } catch (Throwable e) { -log.error("Encountered problem while closing connection with client: " + e.getMessage()); +//Ignore } } } @@ -160,10 +129,12 @@ public class OpenEJBHttpServer implement @Override public void start() throws ServiceException { +// no-op } @Override public void stop() throws ServiceException { +// no-op } @Override Modified: tomee/tomee/branches/tomee-1.6.0.beta1/server/openejb-server/src/main/java/org/apache/openejb/server/ServicePool.java URL: http://svn.apache.org/viewvc/tomee/tomee/branches/tomee-1.6.0.beta1/server/openejb-server/src/main/java/org/apache/openejb/server/ServicePool.java?rev=1461098&r1=1461097&r2=1461098&view=diff == --- tomee/tomee/branches/tomee-1.6.0.beta1/server/openejb-server/src/main/java/org/apache/openejb/server/ServicePool.java (original) +++ tomee/tomee/branches/tomee-1.6.0.beta1/server/openejb-server/src/main/java/org/apache/openejb/server/ServicePool.java Tue Mar 26 12:53:31 2013 @@ -21,12 +21,14 @@ import org.apache.openejb.loader.SystemI import org.apache.openejb.monitoring.Managed; import org.apache.openejb.util.LogCategory; import org.apache.openejb.util.Logger; +import org.apache.openejb.util.OptionsLog; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; import java.net.Socket; import java.util.Properties; +import java.util.concurrent.BlockingQueue; import java.util.concurrent.LinkedBlockingQueue; import java.util.concurrent.RejectedExecutionHandler; import java.util.concurrent.ThreadFactory; @@ -43,6 +45,9 @@ public class ServicePool extends ServerS private final ThreadPoolExecutor threadPool; private final AtomicBoolean stop = new AtomicBoolean(); +p
[jira] [Commented] (OPENEJB-2010) OpenEJB Http - Connection reset (4.5.0, 4.5.1)
[ https://issues.apache.org/jira/browse/OPENEJB-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613740#comment-13613740 ] Romain Manni-Bucau commented on OPENEJB-2010: - commited something close to your fix on trunk (if you can give a try) > OpenEJB Http - Connection reset (4.5.0, 4.5.1) > -- > > Key: OPENEJB-2010 > URL: https://issues.apache.org/jira/browse/OPENEJB-2010 > Project: OpenEJB > Issue Type: Bug > Components: server >Affects Versions: 4.5.0, 4.5.1 > Environment: Windows 7 / Linux >Reporter: Pawel Ruta >Priority: Critical > Attachments: OpenEJBHttpServer.java > > > Randomly I'm getting "java.net.SocketException: Connection reset" exception > when using OpenEJB embedable as a server for Statless Web Services (CXF > implementation) and CXF WS client. On some computers it never happens, on > some almost always, on some randomly. It happens (randomly) when SOAP Message > generated by a server is more than 8192 bytes in size (related to buffer size > in SocketInputStream.java). > I've noticed that in OpenEJBHttpServer.java > (org.apache.openejb.server.httpd.OpenEJBHttpServer), method service(Socket > socket) you are closing OutputStream immediatelly after flushing data. > Closing OutputStream means also closing socket. Closing socket means > "Connection reset" if client isn't fast enough to recieving data from socket. > Client-server communication using ServerSocket and Socket is a bit tricky. In > ideal situation client should report that it is ending the comunication and > then server shoudl close socket. That's not a case for HttpServer. I propose > the solution to wait for client to close socket (all good implementation of > client will close socket :) ). We can wait (non-blocking) for client closing > socket by reading InputStream. When client close connection then InputStream > returns -1. If client doesn't responde connection timeout occur (default is > 60 seconds I suppose). > I've attached changed sources. The solution is quick (dirty). Probably the > more sophisticated approach for managing resource (threads, sockets) should > be used. > Reported exception, full stack: > javax.xml.ws.soap.SOAPFaultException: Unmarshalling Error: Connection reset > at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:156) > Caused by: javax.xml.bind.UnmarshalException > with linked exception: > [com.ctc.wstx.exc.WstxIOException: Connection reset] > at > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleStreamException(UnmarshallerImpl.java:426) > > at > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:362) > > at > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:339) > > at > org.apache.cxf.jaxb.JAXBEncoderDecoder.doUnmarshal(JAXBEncoderDecoder.java:784) > > at > org.apache.cxf.jaxb.JAXBEncoderDecoder.access$100(JAXBEncoderDecoder.java:97) > at org.apache.cxf.jaxb.JAXBEncoderDecoder$1.run(JAXBEncoderDecoder.java:812) > at java.security.AccessController.doPrivileged(Native Method) > at > org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:810) > > at > org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:644) > > at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:157) > at > org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:109) > > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262) > > at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:801) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1694) > > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1530) > > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1438) > > at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) > at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:660) > at > org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62) > > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262) > > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:531) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:464) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:367) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:320) > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:89) > at org.apache.cxf.j
[jira] [Updated] (OPENEJB-1978) Unable to deploy anything to a fresh install of 4.5.1
[ https://issues.apache.org/jira/browse/OPENEJB-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated OPENEJB-1978: Fix Version/s: (was: 4.6.0) 4.6.0.beta1 > Unable to deploy anything to a fresh install of 4.5.1 > - > > Key: OPENEJB-1978 > URL: https://issues.apache.org/jira/browse/OPENEJB-1978 > Project: OpenEJB > Issue Type: Bug > Components: deployment >Affects Versions: 4.5.1 >Reporter: Daniel Vashchilenko >Assignee: Romain Manni-Bucau >Priority: Blocker > Fix For: 4.6.0.beta1 > > > A clean installation of 4.5.1 fails to deploy correctly: > http://pastebin.com/TugqQGt2 > No configuration was changed. 4.5.0 worked fine. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OPENEJB-1991) resources.xml ignored in openejb embedded arquillian adapter
[ https://issues.apache.org/jira/browse/OPENEJB-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated OPENEJB-1991: Fix Version/s: (was: 4.6.0) 4.6.0.beta1 > resources.xml ignored in openejb embedded arquillian adapter > > > Key: OPENEJB-1991 > URL: https://issues.apache.org/jira/browse/OPENEJB-1991 > Project: OpenEJB > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: 4.6.0.beta1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OPENEJB-1982) no webcontext created when using openejb arquillian adapter + no webmodule created
[ https://issues.apache.org/jira/browse/OPENEJB-1982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated OPENEJB-1982: Fix Version/s: (was: 4.6.0) 4.6.0.beta1 > no webcontext created when using openejb arquillian adapter + no webmodule > created > -- > > Key: OPENEJB-1982 > URL: https://issues.apache.org/jira/browse/OPENEJB-1982 > Project: OpenEJB > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: 4.6.0.beta1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OPENEJB-1990) ability to force the jul config reload
[ https://issues.apache.org/jira/browse/OPENEJB-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated OPENEJB-1990: Fix Version/s: (was: 4.6.0) 4.6.0.beta1 > ability to force the jul config reload > -- > > Key: OPENEJB-1990 > URL: https://issues.apache.org/jira/browse/OPENEJB-1990 > Project: OpenEJB > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: 4.6.0.beta1 > > > arquillian uses JUL and it starts (often) before openejb so logging doesn't > use OpenEJB LogManager. Adding a property openejb.jul.forceReload to force > the reload of the logging config (using SystemInstance properties simply make > it smooth and consistent to configure if mandatory -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OPENEJB-1983) embedded http layer doesn't handle HEAD
[ https://issues.apache.org/jira/browse/OPENEJB-1983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated OPENEJB-1983: Fix Version/s: (was: 4.6.0) 4.6.0.beta1 > embedded http layer doesn't handle HEAD > --- > > Key: OPENEJB-1983 > URL: https://issues.apache.org/jira/browse/OPENEJB-1983 > Project: OpenEJB > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: 4.6.0.beta1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OPENEJB-1987) ability to deploy at arquillian container startup a ShrinkWrap Archive
[ https://issues.apache.org/jira/browse/OPENEJB-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated OPENEJB-1987: Fix Version/s: (was: 4.6.0) 4.6.0.beta1 > ability to deploy at arquillian container startup a ShrinkWrap Archive > -- > > Key: OPENEJB-1987 > URL: https://issues.apache.org/jira/browse/OPENEJB-1987 > Project: OpenEJB > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: 4.6.0.beta1 > > > openejb.arquillian.predeploy-archives = foo.MyArchives > in properties attribute of arquillian.xml. It is a comma separated property. > The class can get several static public methods annotated @Deployment > Note: no context is managed for these archives (injections doesn't work) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OPENEJB-1985) basic managedconnection validation for JCA implementation
[ https://issues.apache.org/jira/browse/OPENEJB-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated OPENEJB-1985: Fix Version/s: (was: 4.6.0) 4.6.0.beta1 > basic managedconnection validation for JCA implementation > - > > Key: OPENEJB-1985 > URL: https://issues.apache.org/jira/browse/OPENEJB-1985 > Project: OpenEJB > Issue Type: New Feature >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: 4.6.0.beta1 > > > attribute validationInterval on the managedconnectionfactory initialize the > validation if the managedconnectionfactory implements > ValidatingManagedConnectionFactory and the interval if > 0 > Note: this basic implementation only supports > AbstractSinglePoolConnectionInterceptor pools (and not partitioned ones) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OPENEJB-1984) no session management in embedded http layer
[ https://issues.apache.org/jira/browse/OPENEJB-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated OPENEJB-1984: Fix Version/s: (was: 4.6.0) 4.6.0.beta1 > no session management in embedded http layer > > > Key: OPENEJB-1984 > URL: https://issues.apache.org/jira/browse/OPENEJB-1984 > Project: OpenEJB > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: 4.6.0.beta1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OPENEJB-1988) session and request scopes not managed at all in http light layer
[ https://issues.apache.org/jira/browse/OPENEJB-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated OPENEJB-1988: Fix Version/s: (was: 4.6.0) 4.6.0.beta1 > session and request scopes not managed at all in http light layer > - > > Key: OPENEJB-1988 > URL: https://issues.apache.org/jira/browse/OPENEJB-1988 > Project: OpenEJB > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: 4.6.0.beta1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OPENEJB-2002) with openejb arquillian adaptor findResource can be in WEB-INF or / for WebArchives
[ https://issues.apache.org/jira/browse/OPENEJB-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated OPENEJB-2002: Fix Version/s: (was: 4.6.0) 4.6.0.beta1 > with openejb arquillian adaptor findResource can be in WEB-INF or / for > WebArchives > --- > > Key: OPENEJB-2002 > URL: https://issues.apache.org/jira/browse/OPENEJB-2002 > Project: OpenEJB > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: 4.6.0.beta1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OPENEJB-2003) better heuristic to find a validator/validatorfactory in embedded mode when not in a ThreadContext
[ https://issues.apache.org/jira/browse/OPENEJB-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated OPENEJB-2003: Fix Version/s: (was: 4.6.0) 4.6.0.beta1 > better heuristic to find a validator/validatorfactory in embedded mode when > not in a ThreadContext > -- > > Key: OPENEJB-2003 > URL: https://issues.apache.org/jira/browse/OPENEJB-2003 > Project: OpenEJB > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: 4.6.0.beta1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OPENEJB-2001) openejb embedded arquillian adapter not compatible with cucumber because of archive:// urls
[ https://issues.apache.org/jira/browse/OPENEJB-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated OPENEJB-2001: Fix Version/s: (was: 4.6.0) 4.6.0.beta1 > openejb embedded arquillian adapter not compatible with cucumber because of > archive:// urls > --- > > Key: OPENEJB-2001 > URL: https://issues.apache.org/jira/browse/OPENEJB-2001 > Project: OpenEJB > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: 4.6.0.beta1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OPENEJB-1986) Deployment of web application with white spaces in its name fails due to unencoded characters
[ https://issues.apache.org/jira/browse/OPENEJB-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated OPENEJB-1986: Fix Version/s: (was: 4.6.0) 4.6.0.beta1 > Deployment of web application with white spaces in its name fails due to > unencoded characters > - > > Key: OPENEJB-1986 > URL: https://issues.apache.org/jira/browse/OPENEJB-1986 > Project: OpenEJB > Issue Type: Bug > Components: configuration, deployment >Reporter: Polina Genova >Assignee: Romain Manni-Bucau > Fix For: 4.6.0.beta1 > > Attachments: Space AppTest.war > > > Hi, > The deployment of web applications with special characters (such as white > spaces) in the name fails with the following exception (tested on Tomee > Webprofile 1.5.1). > To reproduce simply deploy the attached test application: > SEVERE: Unable to deploy collapsed ear in war > StandardEngine[Catalina].StandardHost[localhost].StandardContext[/Space > AppTest] > java.lang.IllegalArgumentException > at java.net.URI.create(URI.java:842) > at > org.apache.openejb.config.AutoConfig.resolveDestinationLinks(AutoConfig.java:582) > at org.apache.openejb.config.AutoConfig.deploy(AutoConfig.java:183) > at > org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:338) > at > org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:827) > at > org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:974) > at > org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:901) > at > org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:118) > at > org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) > at > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) > at > org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5173) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) > at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633) > at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:977) > at > org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1655) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) > 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:662) > Caused by: java.net.URISyntaxException: Illegal character in path at index 5: > Space AppTest > at java.net.URI$Parser.fail(URI.java:2809) > at java.net.URI$Parser.checkChars(URI.java:2982) > at java.net.URI$Parser.parseHierarchical(URI.java:3066) > at java.net.URI$Parser.parse(URI.java:3024) > at java.net.URI.(URI.java:578) > at java.net.URI.create(URI.java:840) > ... 22 more > The exception is due to incorrect construction of URL in > org.apache.openejb.config.AutoConfig class. > To make special characters legal in this case, they need to be first encoded > before passing them to the URI factory method create. > For example: > URI.create(URLEncoder.encode(webModule.getModuleId())); > I’ve successfully tested this fix using the standard java.net.Encoder (as I > could not find any other internal encoding utility). > Thanks and regards, > Polina -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OPENEJB-2006) EjbRequestHandler fails to disassociate security on all errors
[ https://issues.apache.org/jira/browse/OPENEJB-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated OPENEJB-2006: Fix Version/s: (was: 4.6.0) (was: (trunk/tomee)) 4.6.0.beta1 > EjbRequestHandler fails to disassociate security on all errors > -- > > Key: OPENEJB-2006 > URL: https://issues.apache.org/jira/browse/OPENEJB-2006 > Project: OpenEJB > Issue Type: Bug >Affects Versions: (trunk/tomee) > Environment: NA >Reporter: Andy Gumbrecht >Assignee: Andy Gumbrecht >Priority: Minor > Fix For: 4.6.0.beta1 > > Original Estimate: 1h > Remaining Estimate: 1h > > EjbRequestHandler fails to disassociate the security on all potential errors. > Once the security context has been initialized and associated then > disassociate must be called if a subsequent error occurs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OPENEJB-1980) request with application/x-www-form-urlencoded content type have no servletinputstream in openejb-http
[ https://issues.apache.org/jira/browse/OPENEJB-1980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated OPENEJB-1980: Fix Version/s: (was: 4.6.0) 4.6.0.beta1 > request with application/x-www-form-urlencoded content type have no > servletinputstream in openejb-http > -- > > Key: OPENEJB-1980 > URL: https://issues.apache.org/jira/browse/OPENEJB-1980 > Project: OpenEJB > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: 4.6.0.beta1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OPENEJB-2005) allow to merge all application exceptions
[ https://issues.apache.org/jira/browse/OPENEJB-2005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated OPENEJB-2005: Fix Version/s: (was: 4.6.0) 4.6.0.beta1 > allow to merge all application exceptions > - > > Key: OPENEJB-2005 > URL: https://issues.apache.org/jira/browse/OPENEJB-2005 > Project: OpenEJB > Issue Type: New Feature >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: 4.6.0.beta1 > > > done through the property openejb.propagate.application-exceptions -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OPENEJB-1981) Add ApplicationComposer inspired class to run TestNG tests
[ https://issues.apache.org/jira/browse/OPENEJB-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated OPENEJB-1981: Fix Version/s: (was: 4.6.0) 4.6.0.beta1 > Add ApplicationComposer inspired class to run TestNG tests > -- > > Key: OPENEJB-1981 > URL: https://issues.apache.org/jira/browse/OPENEJB-1981 > Project: OpenEJB > Issue Type: New Feature >Affects Versions: 4.5.1 >Reporter: Jakub Marchwicki >Assignee: Romain Manni-Bucau >Priority: Trivial > Fix For: 4.6.0.beta1 > > Attachments: application-composer-testng.patch > > > Story > *In order* to write and run my intergration tests in my TestNG environment > *As a* developer > *I want* support for TestNG inspired by the ApplicationComposer jUnit runner. > Rationale: > ApplicationComposer is purely jUnit based solution. The test validation and > container bootstrapping code can be abstracted (made independent of the test > framework) so that two adapters can be introduced: jUnit and TestNG. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira