[tomcat] branch master updated: Move ADD_CHILD_EVENT to before the optional container start

2019-05-29 Thread remm
This is an automated email from the ASF dual-hosted git repository.

remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new b510524  Move ADD_CHILD_EVENT to before the optional container start
b510524 is described below

commit b51052483ec3687c6b4db05288d7546d8431eaf0
Author: remm 
AuthorDate: Wed May 29 09:45:54 2019 +0200

Move ADD_CHILD_EVENT to before the optional container start

Since child start is optional and may be delayed, container listeners
already had to handle this situation (and the mapper indeed does). As
the (correct) sequence is now add to collection -> add_child_event ->
start, on stop it is updated to stop -> remove_child_event -> remove
from collection (for consistency, in practice it is unlikely to make any
difference.
Revert the addition of two container events.
Thanks Mark for the review and the comment.
---
 java/org/apache/catalina/Container.java  | 14 --
 java/org/apache/catalina/core/ContainerBase.java | 13 ++---
 java/org/apache/catalina/core/FrameworkListener.java |  4 ++--
 webapps/docs/changelog.xml   |  7 ---
 4 files changed, 12 insertions(+), 26 deletions(-)

diff --git a/java/org/apache/catalina/Container.java 
b/java/org/apache/catalina/Container.java
index 0b30247..177b2d2 100644
--- a/java/org/apache/catalina/Container.java
+++ b/java/org/apache/catalina/Container.java
@@ -84,13 +84,6 @@ public interface Container extends Lifecycle {
 
 /**
  * The ContainerEvent event type sent when a child container is added
- * by addChild(), but before it is started.
- */
-public static final String ADD_CHILD_BEFORE_START_EVENT = 
"addChildBeforeStart";
-
-
-/**
- * The ContainerEvent event type sent when a child container is added
  * by addChild().
  */
 public static final String ADD_CHILD_EVENT = "addChild";
@@ -105,13 +98,6 @@ public interface Container extends Lifecycle {
 
 /**
  * The ContainerEvent event type sent when a child container is removed
- * by removeChild(), but before it is stopped.
- */
-public static final String REMOVE_CHILD_BEFORE_STOP_EVENT = 
"removeChildBeforeStop";
-
-
-/**
- * The ContainerEvent event type sent when a child container is removed
  * by removeChild().
  */
 public static final String REMOVE_CHILD_EVENT = "removeChild";
diff --git a/java/org/apache/catalina/core/ContainerBase.java 
b/java/org/apache/catalina/core/ContainerBase.java
index f3a3011..8bbfaf8 100644
--- a/java/org/apache/catalina/core/ContainerBase.java
+++ b/java/org/apache/catalina/core/ContainerBase.java
@@ -693,8 +693,10 @@ public abstract class ContainerBase extends 
LifecycleMBeanBase
 
 private void addChildInternal(Container child) {
 
-if( log.isDebugEnabled() )
+if (log.isDebugEnabled()) {
 log.debug("Add child " + child + " " + this);
+}
+
 synchronized(children) {
 if (children.get(child.getName()) != null)
 throw new IllegalArgumentException(
@@ -703,7 +705,7 @@ public abstract class ContainerBase extends 
LifecycleMBeanBase
 children.put(child.getName(), child);
 }
 
-fireContainerEvent(ADD_CHILD_BEFORE_START_EVENT, child);
+fireContainerEvent(ADD_CHILD_EVENT, child);
 
 // Start child
 // Don't do this inside sync block - start can be a slow process and
@@ -716,8 +718,6 @@ public abstract class ContainerBase extends 
LifecycleMBeanBase
 }
 } catch (LifecycleException e) {
 throw new 
IllegalStateException(sm.getString("containerBase.child.start"), e);
-} finally {
-fireContainerEvent(ADD_CHILD_EVENT, child);
 }
 }
 
@@ -800,8 +800,6 @@ public abstract class ContainerBase extends 
LifecycleMBeanBase
 return;
 }
 
-fireContainerEvent(REMOVE_CHILD_BEFORE_STOP_EVENT, child);
-
 try {
 if (child.getState().isAvailable()) {
 child.stop();
@@ -821,13 +819,14 @@ public abstract class ContainerBase extends 
LifecycleMBeanBase
 log.error(sm.getString("containerBase.child.destroy"), e);
 }
 
+fireContainerEvent(REMOVE_CHILD_EVENT, child);
+
 synchronized(children) {
 if (children.get(child.getName()) == null)
 return;
 children.remove(child.getName());
 }
 
-fireContainerEvent(REMOVE_CHILD_EVENT, child);
 }
 
 
diff --git a/java/org/apache/catalina/core/FrameworkListener.java 
b/java/org/apache/catalina/core/FrameworkListener.java
index 4b8234b..6e1944d 100644
--- a/java/org/apache/catalina/core/FrameworkListener.java
+++ b/java/org/apache/catalina/core/FrameworkListener.java
@@ -56,9 +56,9 @@ public abstract class Framewo

[Bug 61542] Apache Tomcat Remote Code Execution via JSP Upload bypass

2019-05-29 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=61542

xing  changed:

   What|Removed |Added

  Component|Catalina|Catalina
Version|9.0.0.M22   |8.5.15
   Target Milestone|-   |
Product|Tomcat 9|Tomcat 8

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: [tomcat] branch master updated: Move ADD_CHILD_EVENT to before the optional container start

2019-05-29 Thread Mark Thomas
On 29/05/2019 08:46, r...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> remm pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
> 
> 
> The following commit(s) were added to refs/heads/master by this push:
>  new b510524  Move ADD_CHILD_EVENT to before the optional container start
> b510524 is described below
> 
> commit b51052483ec3687c6b4db05288d7546d8431eaf0
> Author: remm 
> AuthorDate: Wed May 29 09:45:54 2019 +0200
> 
> Move ADD_CHILD_EVENT to before the optional container start
> 
> Since child start is optional and may be delayed, container listeners
> already had to handle this situation (and the mapper indeed does). As
> the (correct) sequence is now add to collection -> add_child_event ->
> start, on stop it is updated to stop -> remove_child_event -> remove
> from collection (for consistency, in practice it is unlikely to make any
> difference.
> Revert the addition of two container events.
> Thanks Mark for the review and the comment.

Thanks for making those changes.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: [tomcat] branch master updated: Move ADD_CHILD_EVENT to before the optional container start

2019-05-29 Thread Rémy Maucherat
On Wed, May 29, 2019 at 12:26 PM Mark Thomas  wrote:

> On 29/05/2019 08:46, r...@apache.org wrote:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > remm pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/tomcat.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> >  new b510524  Move ADD_CHILD_EVENT to before the optional container
> start
> > b510524 is described below
> >
> > commit b51052483ec3687c6b4db05288d7546d8431eaf0
> > Author: remm 
> > AuthorDate: Wed May 29 09:45:54 2019 +0200
> >
> > Move ADD_CHILD_EVENT to before the optional container start
> >
> > Since child start is optional and may be delayed, container listeners
> > already had to handle this situation (and the mapper indeed does). As
> > the (correct) sequence is now add to collection -> add_child_event ->
> > start, on stop it is updated to stop -> remove_child_event -> remove
> > from collection (for consistency, in practice it is unlikely to make
> any
> > difference.
> > Revert the addition of two container events.
> > Thanks Mark for the review and the comment.
>
> Thanks for making those changes.
>

No problem, I first had to convince myself this couldn't break anything. So
we're still fixing Tomcat 4.0 issues :)

Rémy


[tomcat] branch master updated: Follow-up to c2d6278. NPE->ClosedChannelException for closed socket

2019-05-29 Thread markt
This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new 7046644  Follow-up to c2d6278. NPE->ClosedChannelException for closed 
socket
7046644 is described below

commit 7046644bf361b89afc246b6643e24ce2ae60cacc
Author: Mark Thomas 
AuthorDate: Wed May 29 14:10:29 2019 +0100

Follow-up to c2d6278. NPE->ClosedChannelException for closed socket

If an attempt is made to use a closed socket, throw a
ClosedChannelException rather than a NullPointerException
---
 java/org/apache/tomcat/util/net/NioEndpoint.java | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/java/org/apache/tomcat/util/net/NioEndpoint.java 
b/java/org/apache/tomcat/util/net/NioEndpoint.java
index 62dbab2..765935e 100644
--- a/java/org/apache/tomcat/util/net/NioEndpoint.java
+++ b/java/org/apache/tomcat/util/net/NioEndpoint.java
@@ -27,6 +27,7 @@ import java.net.SocketTimeoutException;
 import java.nio.ByteBuffer;
 import java.nio.channels.CancelledKeyException;
 import java.nio.channels.Channel;
+import java.nio.channels.ClosedChannelException;
 import java.nio.channels.CompletionHandler;
 import java.nio.channels.FileChannel;
 import java.nio.channels.NetworkChannel;
@@ -52,6 +53,7 @@ import org.apache.tomcat.util.IntrospectionUtils;
 import org.apache.tomcat.util.collections.SynchronizedQueue;
 import org.apache.tomcat.util.collections.SynchronizedStack;
 import org.apache.tomcat.util.net.AbstractEndpoint.Handler.SocketState;
+import org.apache.tomcat.util.net.NioChannel.ClosedNioChannel;
 import org.apache.tomcat.util.net.jsse.JSSESupport;
 
 /**
@@ -1240,6 +1242,10 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
 
 @Override
 protected void doWrite(boolean block, ByteBuffer from) throws 
IOException {
+NioChannel socket = getSocket();
+if (socket instanceof ClosedNioChannel) {
+throw new ClosedChannelException();
+}
 if (block) {
 long writeTimeout = getWriteTimeout();
 Selector selector = null;
@@ -1249,11 +1255,11 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
 // Ignore
 }
 try {
-pool.write(from, getSocket(), selector, writeTimeout);
+pool.write(from, socket, selector, writeTimeout);
 if (block) {
 // Make sure we are flushed
 do {
-if (getSocket().flush(true, selector, 
writeTimeout)) {
+if (socket.flush(true, selector, writeTimeout)) {
 break;
 }
 } while (true);
@@ -1268,7 +1274,7 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
 // registered for write once as both container and user code 
can trigger
 // write registration.
 } else {
-if (getSocket().write(from) == -1) {
+if (socket.write(from) == -1) {
 throw new EOFException();
 }
 }


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: [tomcat] branch master updated: Follow-up to c2d6278. NPE->ClosedChannelException for closed socket

2019-05-29 Thread Rémy Maucherat
On Wed, May 29, 2019 at 3:11 PM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> markt pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new 7046644  Follow-up to c2d6278. NPE->ClosedChannelException for
> closed socket
> 7046644 is described below
>
> commit 7046644bf361b89afc246b6643e24ce2ae60cacc
> Author: Mark Thomas 
> AuthorDate: Wed May 29 14:10:29 2019 +0100
>
> Follow-up to c2d6278. NPE->ClosedChannelException for closed socket
>
> If an attempt is made to use a closed socket, throw a
> ClosedChannelException rather than a NullPointerException
>

Good point, this was actually incomplete :( No NPEs occurred with the
testsuite, so I moved on. I had been hunting them down. I'll try to tighten
things up further with additional CLOSED immutable object (and the
ClosedSocketChannel object isn't immutable enough right now ...).

Rémy


> ---
>  java/org/apache/tomcat/util/net/NioEndpoint.java | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/java/org/apache/tomcat/util/net/NioEndpoint.java
> b/java/org/apache/tomcat/util/net/NioEndpoint.java
> index 62dbab2..765935e 100644
> --- a/java/org/apache/tomcat/util/net/NioEndpoint.java
> +++ b/java/org/apache/tomcat/util/net/NioEndpoint.java
> @@ -27,6 +27,7 @@ import java.net.SocketTimeoutException;
>  import java.nio.ByteBuffer;
>  import java.nio.channels.CancelledKeyException;
>  import java.nio.channels.Channel;
> +import java.nio.channels.ClosedChannelException;
>  import java.nio.channels.CompletionHandler;
>  import java.nio.channels.FileChannel;
>  import java.nio.channels.NetworkChannel;
> @@ -52,6 +53,7 @@ import org.apache.tomcat.util.IntrospectionUtils;
>  import org.apache.tomcat.util.collections.SynchronizedQueue;
>  import org.apache.tomcat.util.collections.SynchronizedStack;
>  import org.apache.tomcat.util.net.AbstractEndpoint.Handler.SocketState;
> +import org.apache.tomcat.util.net.NioChannel.ClosedNioChannel;
>  import org.apache.tomcat.util.net.jsse.JSSESupport;
>
>  /**
> @@ -1240,6 +1242,10 @@ public class NioEndpoint extends
> AbstractJsseEndpoint
>
>  @Override
>  protected void doWrite(boolean block, ByteBuffer from) throws
> IOException {
> +NioChannel socket = getSocket();
> +if (socket instanceof ClosedNioChannel) {
> +throw new ClosedChannelException();
> +}
>  if (block) {
>  long writeTimeout = getWriteTimeout();
>  Selector selector = null;
> @@ -1249,11 +1255,11 @@ public class NioEndpoint extends
> AbstractJsseEndpoint
>  // Ignore
>  }
>  try {
> -pool.write(from, getSocket(), selector, writeTimeout);
> +pool.write(from, socket, selector, writeTimeout);
>  if (block) {
>  // Make sure we are flushed
>  do {
> -if (getSocket().flush(true, selector,
> writeTimeout)) {
> +if (socket.flush(true, selector,
> writeTimeout)) {
>  break;
>  }
>  } while (true);
> @@ -1268,7 +1274,7 @@ public class NioEndpoint extends
> AbstractJsseEndpoint
>  // registered for write once as both container and user
> code can trigger
>  // write registration.
>  } else {
> -if (getSocket().write(from) == -1) {
> +if (socket.write(from) == -1) {
>  throw new EOFException();
>  }
>  }
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


[tomcat] branch master updated: The closed channels need to be immutable so override a few more methods

2019-05-29 Thread remm
This is an automated email from the ASF dual-hosted git repository.

remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new 339b40b  The closed channels need to be immutable so override a few 
more methods
339b40b is described below

commit 339b40bc07bdba9ded565929b9a3448c5a78f015
Author: remm 
AuthorDate: Wed May 29 16:23:03 2019 +0200

The closed channels need to be immutable so override a few more methods

Avoiding a NPE in NioBlockignSelector is not possible however and
getting there is wasteful, so filter out read as well. In theory ==
CLOSED_NIO_CHANNEL would be enough but use instanceof for now.
---
 java/org/apache/tomcat/util/net/Nio2Channel.java |  5 -
 java/org/apache/tomcat/util/net/NioChannel.java  | 13 +++--
 java/org/apache/tomcat/util/net/NioEndpoint.java |  9 ++---
 3 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/java/org/apache/tomcat/util/net/Nio2Channel.java 
b/java/org/apache/tomcat/util/net/Nio2Channel.java
index 36c5b99..f6b9f0c 100644
--- a/java/org/apache/tomcat/util/net/Nio2Channel.java
+++ b/java/org/apache/tomcat/util/net/Nio2Channel.java
@@ -251,7 +251,7 @@ public class Nio2Channel implements AsynchronousByteChannel 
{
 static final Nio2Channel CLOSED_NIO2_CHANNEL = new ClosedNio2Channel();
 public static class ClosedNio2Channel extends Nio2Channel {
 public ClosedNio2Channel() {
-super(null);
+super(SocketBufferHandler.EMPTY);
 }
 @Override
 public void close() throws IOException {
@@ -267,6 +267,9 @@ public class Nio2Channel implements AsynchronousByteChannel 
{
 public void free() {
 }
 @Override
+public void setAppReadBufHandler(ApplicationBufferHandler handler) {
+}
+@Override
 public Future read(ByteBuffer dst) {
 return DONE_INT;
 }
diff --git a/java/org/apache/tomcat/util/net/NioChannel.java 
b/java/org/apache/tomcat/util/net/NioChannel.java
index d3f2766..1de1e80 100644
--- a/java/org/apache/tomcat/util/net/NioChannel.java
+++ b/java/org/apache/tomcat/util/net/NioChannel.java
@@ -246,7 +246,6 @@ public class NioChannel implements ByteChannel, 
ScatteringByteChannel, Gathering
 }
 }
 
-
 private ApplicationBufferHandler appReadBufHandler;
 public void setAppReadBufHandler(ApplicationBufferHandler handler) {
 this.appReadBufHandler = handler;
@@ -258,7 +257,7 @@ public class NioChannel implements ByteChannel, 
ScatteringByteChannel, Gathering
 static final NioChannel CLOSED_NIO_CHANNEL = new ClosedNioChannel();
 public static class ClosedNioChannel extends NioChannel {
 public ClosedNioChannel() {
-super(null, null);
+super(null, SocketBufferHandler.EMPTY);
 }
 @Override
 public void close() throws IOException {
@@ -274,6 +273,15 @@ public class NioChannel implements ByteChannel, 
ScatteringByteChannel, Gathering
 public void free() {
 }
 @Override
+void setSocketWrapper(NioSocketWrapper socketWrapper) {
+}
+@Override
+public void setIOChannel(SocketChannel sc) {
+}
+@Override
+public void setAppReadBufHandler(ApplicationBufferHandler handler) {
+}
+@Override
 public int read(ByteBuffer dst) throws IOException {
 return -1;
 }
@@ -297,4 +305,5 @@ public class NioChannel implements ByteChannel, 
ScatteringByteChannel, Gathering
 return "Closed NioChannel";
 }
 }
+
 }
diff --git a/java/org/apache/tomcat/util/net/NioEndpoint.java 
b/java/org/apache/tomcat/util/net/NioEndpoint.java
index 765935e..68f401a 100644
--- a/java/org/apache/tomcat/util/net/NioEndpoint.java
+++ b/java/org/apache/tomcat/util/net/NioEndpoint.java
@@ -1215,7 +1215,10 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
 
 private int fillReadBuffer(boolean block, ByteBuffer to) throws 
IOException {
 int nRead;
-NioChannel channel = getSocket();
+NioChannel socket = getSocket();
+if (socket instanceof ClosedNioChannel) {
+throw new ClosedChannelException();
+}
 if (block) {
 Selector selector = null;
 try {
@@ -1224,14 +1227,14 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
 // Ignore
 }
 try {
-nRead = pool.read(to, channel, selector, getReadTimeout());
+nRead = pool.read(to, socket, selector, getReadTimeout());
 } finally {
 if (selector != null) {
 pool.put(selector);
 }
 }
 } else {
-nRead = channel.

buildbot failure in on tomcat-trunk

2019-05-29 Thread buildbot
The Buildbot has detected a new failure on builder tomcat-trunk while building 
tomcat. Full details are available at:
https://ci.apache.org/builders/tomcat-trunk/builds/4401

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' 
triggered this build
Build Source Stamp: [branch master] 339b40bc07bdba9ded565929b9a3448c5a78f015
Blamelist: remm 

BUILD FAILED: failed compile_1

Sincerely,
 -The Buildbot




-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: buildbot failure in on tomcat-trunk

2019-05-29 Thread Rémy Maucherat
On Wed, May 29, 2019 at 4:54 PM  wrote:

> The Buildbot has detected a new failure on builder tomcat-trunk while
> building tomcat. Full details are available at:
> https://ci.apache.org/builders/tomcat-trunk/builds/4401
>
> Buildbot URL: https://ci.apache.org/
>
> Buildslave for this Build: silvanus_ubuntu
>
> Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit'
> triggered this build
> Build Source Stamp: [branch master]
> 339b40bc07bdba9ded565929b9a3448c5a78f015
> Blamelist: remm 
>
> BUILD FAILED: failed compile_1
>

This is apparently the return of the fake window update timeout (in a
different way, since it wasn't happening here before).

From
https://ci.apache.org/projects/tomcat/tomcat9/logs/4401/TEST-org.apache.coyote.http2.TestHttp2Section_5_3.NIO.txt

29-May-2019 14:36:14.863 FINE [http-nio-127.0.0.1-auto-2-exec-2]
org.apache.coyote.http2.Http2UpgradeHandler.incrementWindowSize Connection
[1], Stream [21] released from backlog
29-May-2019 14:36:14.863 FINE [http-nio-127.0.0.1-auto-2-exec-4]
org.apache.coyote.http2.Http2AsyncUpgradeHandler.writeBody Connection [1],
Stream [19], Data length [1]
29-May-2019 14:36:14.863 FINE [http-nio-127.0.0.1-auto-2-exec-2]
org.apache.coyote.http2.Http2UpgradeHandler.incrementWindowSize Connection
[1], Stream [21], notify() called to release StreamOutputBuffer
29-May-2019 14:36:14.863 FINE [http-nio-127.0.0.1-auto-2-exec-3]
org.apache.coyote.http2.Http2UpgradeHandler.reserveWindowSize Connection
[1], Stream [21], Timeout waiting for allocation

Rémy


CDI support improvements

2019-05-29 Thread Rémy Maucherat
Hi,

This was on my hackaton todo list, I guess I'm a bit late, but getting to
it now ...

CDI is the building brick for many other popular libraries and frameworks,
including JAX-RS (Apache CXF), Eclipse Microprofile, etc. Looking at the
CDI implementation from the ASF, I am not fully satisfied with the
integration or packaging of OWB in the context of Tomcat. Since it's such
an important building block, I wanted to do something about it and be able
to have something that played better with Tomcat standalone, in addition to
embedded (that is well covered !). As a result, I took on the task to take
over the Tomcat(7 ;) ) integration that was in OWB.

I'm working on it here: https://github.com/rmaucher/tomcat-owb

The packaging is a big jar that is not done yet (the APIs would of course
be separate JARs, but the goal is to have a big-OWB JAR tuned for Tomcat
with the rest). Eventually if it works well enough, I would move it to
https://github.com/apache/tomcat/tree/master/modules

Note: I'm not a fan of the OWB configuration, it looks rather cryptic to me
(properties files spread across all the JARs, I guess that's pluggable -
even though it's not really needed here). I will look at that area for
Tomcat specific improvements (the main listener could be used for
configuration).

Note 2: Apache CXF is quite the same first impression, when I download it I
find a "lib/WHICH_JARS" file, which kind of says it all. So after OWB, it's
possible there would be another tomcat-cxf module, which would be packaging
only (I hope/expect the integration, which uses CDI and Servlets, will not
need any real improvements).

Comments ?

Rémy


Re: buildbot failure in on tomcat-trunk

2019-05-29 Thread Mark Thomas
On 29/05/2019 16:20, Rémy Maucherat wrote:
> On Wed, May 29, 2019 at 4:54 PM  > wrote:
> 
> The Buildbot has detected a new failure on builder tomcat-trunk
> while building tomcat. Full details are available at:
>     https://ci.apache.org/builders/tomcat-trunk/builds/4401
> 
> Buildbot URL: https://ci.apache.org/
> 
> Buildslave for this Build: silvanus_ubuntu
> 
> Build Reason: The AnyBranchScheduler scheduler named
> 'on-tomcat-commit' triggered this build
> Build Source Stamp: [branch master]
> 339b40bc07bdba9ded565929b9a3448c5a78f015
> Blamelist: remm mailto:r...@apache.org>>
> 
> BUILD FAILED: failed compile_1
> 
> 
> This is apparently the return of the fake window update timeout (in a
> different way, since it wasn't happening here before).

I've figured out what is going on here. Looking at thread 21 the
following sequence of events occurs:

- allocated 1 byte from the connection window (total allocation = 1)
- notified
- allocated 1 byte from the connection window (total allocation = 2)
- write 2 bytes (total allocation = 0)
- notified
- timeout since allocation is currently zero.

What should happen is:
- allocated 1 byte from the connection window (total allocation = 1)
- notified
- write 1 byte (total allocation = 0)
- allocated 1 byte from the connection window (total allocation = 1)
- notified
- write 1 bytes (total allocation = 0)

I haven't figured out how to fix this yet.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: CDI support improvements

2019-05-29 Thread Romain Manni-Bucau
Hi Rémy,

Openwebbeans has a tomcat integration module - mainly standalone case, and
meecrowave subproject - embedded or ready to run fatjar. It looks like it
covers what you target. Where I am loosing track is why not improving
openwebbeans and forking the code in tomcat? At least i would expect to
discuss to move over tomcat the code on dev@owb - and I would support it ;).

More technically: openwebbeans does not need properties files you can pass
Properties when you create the WebBeansContext, this is what tomee does.
Same for cxf and its bus ;).

Biggest short term challenge is to align scanners but it is very doable,
long term it is to drop big core jars in all 3 libs for smaller bundles ;).

Feel free to shout if you need help or more precise pointers.


Le mer. 29 mai 2019 à 18:26, Rémy Maucherat  a écrit :

> Hi,
>
> This was on my hackaton todo list, I guess I'm a bit late, but getting to
> it now ...
>
> CDI is the building brick for many other popular libraries and frameworks,
> including JAX-RS (Apache CXF), Eclipse Microprofile, etc. Looking at the
> CDI implementation from the ASF, I am not fully satisfied with the
> integration or packaging of OWB in the context of Tomcat. Since it's such
> an important building block, I wanted to do something about it and be able
> to have something that played better with Tomcat standalone, in addition to
> embedded (that is well covered !). As a result, I took on the task to take
> over the Tomcat(7 ;) ) integration that was in OWB.
>
> I'm working on it here: https://github.com/rmaucher/tomcat-owb
>
> The packaging is a big jar that is not done yet (the APIs would of course
> be separate JARs, but the goal is to have a big-OWB JAR tuned for Tomcat
> with the rest). Eventually if it works well enough, I would move it to
> https://github.com/apache/tomcat/tree/master/modules
>
> Note: I'm not a fan of the OWB configuration, it looks rather cryptic to
> me (properties files spread across all the JARs, I guess that's pluggable -
> even though it's not really needed here). I will look at that area for
> Tomcat specific improvements (the main listener could be used for
> configuration).
>
> Note 2: Apache CXF is quite the same first impression, when I download it
> I find a "lib/WHICH_JARS" file, which kind of says it all. So after OWB,
> it's possible there would be another tomcat-cxf module, which would be
> packaging only (I hope/expect the integration, which uses CDI and Servlets,
> will not need any real improvements).
>
> Comments ?
>
> Rémy
>
>


Re: CDI support improvements

2019-05-29 Thread Rémy Maucherat
Hi,

On Wed, May 29, 2019 at 11:35 PM Romain Manni-Bucau 
wrote:

> Hi Rémy,
>
> Openwebbeans has a tomcat integration module - mainly standalone case, and
> meecrowave subproject - embedded or ready to run fatjar. It looks like it
> covers what you target. Where I am loosing track is why not improving
> openwebbeans and forking the code in tomcat? At least i would expect to
> discuss to move over tomcat the code on dev@owb - and I would support it
> ;).
>

There's not a lot of code, so I don't call that a fork. The problem is that
I need to make changes and adjustments in Tomcat, so in the end it can't be
in owb. I used the code from webbeans-tomcat7, and didn't see any other
modules (maybe you're referring to the ones in samples I just found).

>
> More technically: openwebbeans does not need properties files you can pass
> Properties when you create the WebBeansContext, this is what tomee does.
> Same for cxf and its bus ;).
>

Ok, I'll have a look at that, it's better than properties files (but
similar).

>
> Biggest short term challenge is to align scanners but it is very doable,
> long term it is to drop big core jars in all 3 libs for smaller bundles ;).
>

Ok.

>
> Feel free to shout if you need help or more precise pointers.
>

Rémy

>
>
> Le mer. 29 mai 2019 à 18:26, Rémy Maucherat  a écrit :
>
>> Hi,
>>
>> This was on my hackaton todo list, I guess I'm a bit late, but getting to
>> it now ...
>>
>> CDI is the building brick for many other popular libraries and
>> frameworks, including JAX-RS (Apache CXF), Eclipse Microprofile, etc.
>> Looking at the CDI implementation from the ASF, I am not fully satisfied
>> with the integration or packaging of OWB in the context of Tomcat. Since
>> it's such an important building block, I wanted to do something about it
>> and be able to have something that played better with Tomcat standalone, in
>> addition to embedded (that is well covered !). As a result, I took on the
>> task to take over the Tomcat(7 ;) ) integration that was in OWB.
>>
>> I'm working on it here: https://github.com/rmaucher/tomcat-owb
>>
>> The packaging is a big jar that is not done yet (the APIs would of course
>> be separate JARs, but the goal is to have a big-OWB JAR tuned for Tomcat
>> with the rest). Eventually if it works well enough, I would move it to
>> https://github.com/apache/tomcat/tree/master/modules
>>
>> Note: I'm not a fan of the OWB configuration, it looks rather cryptic to
>> me (properties files spread across all the JARs, I guess that's pluggable -
>> even though it's not really needed here). I will look at that area for
>> Tomcat specific improvements (the main listener could be used for
>> configuration).
>>
>> Note 2: Apache CXF is quite the same first impression, when I download it
>> I find a "lib/WHICH_JARS" file, which kind of says it all. So after OWB,
>> it's possible there would be another tomcat-cxf module, which would be
>> packaging only (I hope/expect the integration, which uses CDI and Servlets,
>> will not need any real improvements).
>>
>> Comments ?
>>
>> Rémy
>>
>>