buildbot failure in ASF Buildbot on tomee-trunk-ubuntu

2013-03-26 Thread buildbot
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

2013-03-26 Thread buildbot
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

2013-03-26 Thread buildbot
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

2013-03-26 Thread Romain Manni-Bucau (JIRA)

 [ 
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)

2013-03-26 Thread Pawel Ruta (JIRA)
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)

2013-03-26 Thread Pawel Ruta (JIRA)

 [ 
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

2013-03-26 Thread rmannibucau
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

2013-03-26 Thread rmannibucau
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)

2013-03-26 Thread Romain Manni-Bucau (JIRA)

[ 
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

2013-03-26 Thread Romain Manni-Bucau (JIRA)

 [ 
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

2013-03-26 Thread Romain Manni-Bucau (JIRA)

 [ 
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

2013-03-26 Thread Romain Manni-Bucau (JIRA)

 [ 
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

2013-03-26 Thread Romain Manni-Bucau (JIRA)

 [ 
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

2013-03-26 Thread Romain Manni-Bucau (JIRA)

 [ 
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

2013-03-26 Thread Romain Manni-Bucau (JIRA)

 [ 
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

2013-03-26 Thread Romain Manni-Bucau (JIRA)

 [ 
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

2013-03-26 Thread Romain Manni-Bucau (JIRA)

 [ 
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

2013-03-26 Thread Romain Manni-Bucau (JIRA)

 [ 
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

2013-03-26 Thread Romain Manni-Bucau (JIRA)

 [ 
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

2013-03-26 Thread Romain Manni-Bucau (JIRA)

 [ 
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

2013-03-26 Thread Romain Manni-Bucau (JIRA)

 [ 
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

2013-03-26 Thread Romain Manni-Bucau (JIRA)

 [ 
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

2013-03-26 Thread Romain Manni-Bucau (JIRA)

 [ 
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

2013-03-26 Thread Romain Manni-Bucau (JIRA)

 [ 
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

2013-03-26 Thread Romain Manni-Bucau (JIRA)

 [ 
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

2013-03-26 Thread Romain Manni-Bucau (JIRA)

 [ 
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