[Bug 63879] Unessesary log noise under DEBUG

2019-10-28 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=63879

--- Comment #5 from Christopher Schultz  ---
I think switching the log message to TRACE is the best solution.

-- 
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: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2019-10-28 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

Note: this was not a vote.

The consensus seems to be that SSIs should be moved into a separate
JAR file.

I've done a *very* short investigation, and I have discovered the
following:

1. Tomcat builds fine after removing the entire
org.apache.catalina.ssi source package, so it's completely isolated
from the rest of Tomcat (which was entirely expected). This suggests
that releasing Tomcat without any of the SSI components is practical
and relatively easy.

The stock conf/web.xml contains a sample configuration for the SSI
servlet. We will have to decide what to do with that. I can think of
at least two options:

  a. Remove it from the stock conf/web.xml entirely
  b. Add comments to conf/web.xml indicating that the SSI component is
a separate download

I think I like #2 better.

2. Separating the packaging should be easy. Note that I haven't
actually done this:

i.  Modify files.catalina in build.xml to  the
org.apache.catalina.ssi package
ii. Modify the "package" target in build.xml to  with the appropriate classes

I think this is super simple to do and we should go ahead and do this,
/now/. For embedded clients who don't care about SSI, this gives them
a JAR today that they can simply remove from their bundled clients to
save a little space.

3. The SSI component uses a bunch of internal(ish) Tomcat/Catalina
APIs. This may complicate fully-extracting the SSI component and
making it a standalone product (e.g. cross-container):

org.apache.catalina.connector.Connector;
org.apache.catalina.connector.Request;
org.apache.catalina.util.IOTools;
org.apache.catalina.util.Strftime;
org.apache.catalina.util.URLEncoder;
org.apache.coyote.Constants;
org.apache.tomcat.util.buf.B2CConverter;
org.apache.tomcat.util.buf.UDecoder;
org.apache.tomcat.util.http.FastHttpDateFormat;
org.apache.tomcat.util.http.RequestUtil;
org.apache.tomcat.util.res.StringManager;
org.apache.tomcat.util.security.Escape;

Some of them are simply for convenience -- e.g. UDecoder,
FastHttpDateFormat, etc. Those could easily be replaced with
alternatives or re-implementations. I haven't yet looked at how much
the org.apache.catalina.connector.Connector and
org.apache.catalina.connector.Request classes are used. It's possible
that these could be replaced with the generic versions of themselves
(e.g. HttpServletRequest and ... I'm not sure what we get from the
Connector but of course there is no direct replacement for that in the
public API).

So I'd like to move-forward with the separation of the SSI component
into a separate JAR file and then see what can be re-factored within
SSI itself to divorce it from internal Tomcat APIs.

- -chris

On 10/7/19 10:46, Christopher Schultz wrote:
> All,
> 
> I recently gave a presentation on locking-down Apache Tomcat[1] and
> I briefly discussed the "sharp edges" present in Tomcat. Some of
> them are unnecessarily sharp and may be actually unnecessary. I'm
> going to make a few proposals to remove functions from Tomcat.
> 
> Proposal: Remove Server-Side Includes
> 
> Justification:
> 
> The SSI module is a remote-code execution (RCE) vulnerability as a 
> feature. My sense is that SSI is a little-used feature. A few
> years ago, markt[2] asked if anyone was using SSI. The only replies
> were from other Tomcat devs commenting on what to do with SSI if
> it's no longer in the main Tomcat distribution; there were no
> community members who responded saying that SSI was important to
> them.
> 
> If the packaging of Tomcat could be tweaked a bit to move the SSI 
> components into a separate JAR file (e.g. move 
> org/apache/catalina/ssi/* to catalina-ssi.jar) and if the SSI 
> components don't rely on any Tomcat specific capabilities or 
> internals, then the cattalina-ssi.jar file could be used between 
> Tomcat versions. For example, a user of Tomcat 10 who still needs
> SSI could get the SSI module from a distribution of Tomcat 8.5.x or
> 9.x.
> 
> -chris
> 
> 
> [1]
> http://tomcat.apache.org/presentations.html#latest-locking-down-tomc
>
> 
at
> [2] 
> https://lists.apache.org/thread.html/969a9d1b6e883a4017907c44829288062
4c
>
> 
c85eb22c490b241dc9c88@%3Cusers.tomcat.apache.org%3E
> 
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl227lQACgkQHPApP6U8
pFjvbg//W0fD5aokUYxmy7wbTS56RdPRhLo/OmB1DrN5lbjE1rIdpiNtQRkPi9qO
C0X5QJZjYBnbNUr4YMUOVcjKjv8TBUuL6EGbVIsQupYIO0usoLthLfllH6ARXgsB
pr9Wynx7mVCi/KiR+G1mYw4bHbbVuMgZpEKCPSiurK+ZJhW7J/FfQ5U0bfZBqWG9
gT27EapqA35xXt4hHNmCb65dtWRmeXgTXEXrnzeQr3lgtXy6wT/uXjQfxP6/12Lz
vOhmi7HVzkrM6yGETsz45QvzMaY+JwS2bKfg8wxWT8B0A+3DhuevusYCHXxGunRD
LbUomZOW3+l4mVjp85KWr7U0W8LZvA/GSgGaAueqyw5xcQ2de4VdFoefmUGdKRhZ
65gWtyrynDL7wksmx8CXOaXQbAQS0GwOXpEkpPCDqslvM/y9R0qYJdVuNqMnh6vY
7DlCovaS8hcHfOQRnWCBBtBPq2UbGWGIULk1bh8VYnFRpF8PdgGIXc/GiUlVA5cY
pmPLIQ5euJJyY0nvF1IXipVdLHY0asl7tG9fvafH2Gk9TjYMUiek/1zeiD1iTcNU
OqnkT+upJhZEpeG29Oycwtjh8EwQgiB2JwL9Th

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2019-10-28 Thread Rémy Maucherat 
On Mon, Oct 28, 2019 at 2:34 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> Note: this was not a vote.
>
> The consensus seems to be that SSIs should be moved into a separate
> JAR file.
>
> I've done a *very* short investigation, and I have discovered the
> following:
>
> 1. Tomcat builds fine after removing the entire
> org.apache.catalina.ssi source package, so it's completely isolated
> from the rest of Tomcat (which was entirely expected). This suggests
> that releasing Tomcat without any of the SSI components is practical
> and relatively easy.
>
> The stock conf/web.xml contains a sample configuration for the SSI
> servlet. We will have to decide what to do with that. I can think of
> at least two options:
>
>   a. Remove it from the stock conf/web.xml entirely
>   b. Add comments to conf/web.xml indicating that the SSI component is
> a separate download
>
> I think I like #2 better.
>
> 2. Separating the packaging should be easy. Note that I haven't
> actually done this:
>
> i.  Modify files.catalina in build.xml to  the
> org.apache.catalina.ssi package
> ii. Modify the "package" target in build.xml to  jarfile="catalina-ssi.jar" .../> with the appropriate classes
>
> I think this is super simple to do and we should go ahead and do this,
> /now/. For embedded clients who don't care about SSI, this gives them
> a JAR today that they can simply remove from their bundled clients to
> save a little space.
>
> 3. The SSI component uses a bunch of internal(ish) Tomcat/Catalina
> APIs. This may complicate fully-extracting the SSI component and
> making it a standalone product (e.g. cross-container):
>
> org.apache.catalina.connector.Connector;
> org.apache.catalina.connector.Request;
> org.apache.catalina.util.IOTools;
> org.apache.catalina.util.Strftime;
> org.apache.catalina.util.URLEncoder;
> org.apache.coyote.Constants;
> org.apache.tomcat.util.buf.B2CConverter;
> org.apache.tomcat.util.buf.UDecoder;
> org.apache.tomcat.util.http.FastHttpDateFormat;
> org.apache.tomcat.util.http.RequestUtil;
> org.apache.tomcat.util.res.StringManager;
> org.apache.tomcat.util.security.Escape;
>
> Some of them are simply for convenience -- e.g. UDecoder,
> FastHttpDateFormat, etc. Those could easily be replaced with
> alternatives or re-implementations. I haven't yet looked at how much
> the org.apache.catalina.connector.Connector and
> org.apache.catalina.connector.Request classes are used. It's possible
> that these could be replaced with the generic versions of themselves
> (e.g. HttpServletRequest and ... I'm not sure what we get from the
> Connector but of course there is no direct replacement for that in the
> public API).
>
> So I'd like to move-forward with the separation of the SSI component
> into a separate JAR file and then see what can be re-factored within
> SSI itself to divorce it from internal Tomcat APIs.
>

Personally I am in favor of a separate JAR, but maintain everything else
unchanged. The use of utility classes reduces code duplication.
If it becomes cross container then I think SSI should be moved elsewhere.
Maybe something like the taglibs subproject. It's a rather significant
effort to test and maintain compatibility with everything out there IMO.

Rémy


>
> - -chris
>
> On 10/7/19 10:46, Christopher Schultz wrote:
> > All,
> >
> > I recently gave a presentation on locking-down Apache Tomcat[1] and
> > I briefly discussed the "sharp edges" present in Tomcat. Some of
> > them are unnecessarily sharp and may be actually unnecessary. I'm
> > going to make a few proposals to remove functions from Tomcat.
> >
> > Proposal: Remove Server-Side Includes
> >
> > Justification:
> >
> > The SSI module is a remote-code execution (RCE) vulnerability as a
> > feature. My sense is that SSI is a little-used feature. A few
> > years ago, markt[2] asked if anyone was using SSI. The only replies
> > were from other Tomcat devs commenting on what to do with SSI if
> > it's no longer in the main Tomcat distribution; there were no
> > community members who responded saying that SSI was important to
> > them.
> >
> > If the packaging of Tomcat could be tweaked a bit to move the SSI
> > components into a separate JAR file (e.g. move
> > org/apache/catalina/ssi/* to catalina-ssi.jar) and if the SSI
> > components don't rely on any Tomcat specific capabilities or
> > internals, then the cattalina-ssi.jar file could be used between
> > Tomcat versions. For example, a user of Tomcat 10 who still needs
> > SSI could get the SSI module from a distribution of Tomcat 8.5.x or
> > 9.x.
> >
> > -chris
> >
> >
> > [1]
> > http://tomcat.apache.org/presentations.html#latest-locking-down-tomc
> >
> >
> at
> > [2]
> > https://lists.apache.org/thread.html/969a9d1b6e883a4017907c44829288062
> 4c
> 
> >
> >
> c85eb22c490b241dc9c88@%3Cusers.tomcat.apache.org%3E
> >
> -BEGIN PGP

[Bug 63879] Unessesary log noise under DEBUG

2019-10-28 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=63879

--- Comment #6 from Michael Bazos  ---
I agree switching to TRACE is the best option. Also it might be helpful to not
throw new Exception(); as this produces this message "java.lang.Exception:
null" If you are going to have this it might be best to provide a message to
let people know this is intended and testing.

This issue came up as it was forwarded to me by another team at my company and
my response was it's fine it's `DEBUG` but I also feel seeing a stack trace
like this can clue to some potential issue happening or maybe something not
being done in an optimal way. 

Either way I think checking the rest of the code base in NIO and NIO2 for this
pattern and switching the statements to TRACE at a minimum should be fine.

--- Comment #7 from Michael Bazos  ---
I agree switching to TRACE is the best option. Also it might be helpful to not
throw new Exception(); as this produces this message "java.lang.Exception:
null" If you are going to have this it might be best to provide a message to
let people know this is intended and testing.

This issue came up as it was forwarded to me by another team at my company and
my response was it's fine it's `DEBUG` but I also feel seeing a stack trace
like this can clue to some potential issue happening or maybe something not
being done in an optimal way. 

Either way I think checking the rest of the code base in NIO and NIO2 for this
pattern and switching the statements to TRACE at a minimum should be fine.

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

[Bug 63879] Unessesary log noise under DEBUG

2019-10-28 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=63879

--- Comment #6 from Michael Bazos  ---
I agree switching to TRACE is the best option. Also it might be helpful to not
throw new Exception(); as this produces this message "java.lang.Exception:
null" If you are going to have this it might be best to provide a message to
let people know this is intended and testing.

This issue came up as it was forwarded to me by another team at my company and
my response was it's fine it's `DEBUG` but I also feel seeing a stack trace
like this can clue to some potential issue happening or maybe something not
being done in an optimal way. 

Either way I think checking the rest of the code base in NIO and NIO2 for this
pattern and switching the statements to TRACE at a minimum should be fine.

-- 
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: [PROPOSAL] Tomcat 10: Remove CGI Servlet

2019-10-28 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

Note: this was not a vote.

There was very little feedback, and responses were mixed. We got
exactly one response on the users@ list about real-world usage of CGI,
so we cannot draw any conclusions about real-world uses.

Otherwise, the consensus seems to be that CGIs should stay a part of
the main Tomcat distribution, but that perhaps separating it out into
a distinct JAR file and/or separate distribution might be advantageous.

It appears that the CGIServlet is completely self-contained. It makes
use of the following internal(ish) Tomcat APIs:

org.apache.catalina.util.IOTools
org.apache.juli.logging.Log
org.apache.juli.logging.LogFactory
org.apache.tomcat.util.compat.JrePlatform
org.apache.tomcat.util.res.StringManager

All of these could be replaced if necessary to make a standalone,
container-agnostic package.

It looks like it would be fairly easy to separate-out the CGIServlet
into a separate JAR file packaging if there's utility in that. For
example, security-conscious environments may want to remove that JAR
file entirely from the Tomcat deployment to be absolutely sure that
Runtime.exec() isn't available in the deployed Java code (from the
container; yet I realize that SSIServlet/SSIFilter has this, too).

I'd like to go ahead and move the CGIServlet from the general
catalina.jar file into catalina-cgi.jar. That should only require a
small change to the build.xml script.

Any objections?

- -chris

On 10/7/19 10:59, Christopher Schultz wrote:
> All,
> 
> I recently gave a presentation on locking-down Apache Tomcat[1] and
> I briefly discussed the "sharp edges" present in Tomcat. Some of
> them are unnecessarily sharp and may be actually unnecessary. I'm
> going to make a few proposals to remove functions from Tomcat.
> 
> Proposal: Remove CGI Servlet
> 
> Justification:
> 
> The CGIServlet is another component, like server-side-includes,
> which is a remote-code execution (RCE) vulnerability as a feature.
> It is very easy to misconfigure. It is arguably not possible to
> secure it on Windows[2]. There are better solutions if you want to
> run Perl, Python, PHP, or whatever on your server in the form of
> the many fine web-server products out there.
> 
> -chris
> 
> 
> [1]
> http://tomcat.apache.org/presentations.html#latest-locking-down-tomc
>
> 
at
> [2] 
> https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/
23
>
> 
/everyone-quotes-command-line-arguments-the-wrong-way/
> 
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2281sACgkQHPApP6U8
pFjMLw//cR2e2f32IUVK7kbbK2isBhmqd+GB/MhC9/Dt6d7iBPElr1gOid2zegpg
BLVzAdzCjUxR1TlzTfOqq7riZwYPui6+URGePsVyNms3c4tM9hWMArqtYRJFnQXt
bQCRS7dsS7dyonJTdJzAQFwN+zqjP1We4AORSO1uOjPA8wF7NK4d4mQ1yMaF7Bsj
CzGIzvo31iRCix2TUJiok0SrRU9qRQn8IzTU2tUswTEGDR0lTjnSc6XUzvBgYbmx
WF8AVLsjYIJKt1zDDAmAckhnio1Vq9jIwp/fHYd16NPy8n5Mfn1IkWmuZ8RGMDXM
o0W4/HYRYV+9WWiGF3aUrSbmu2hOwXdbPcYm+hzntWzyHoY5JGVSCXS1HrFIGr4S
TZTLzj7sCV+Yl5Na8spie3S5rZ0EsI2BzP7fwmvmBEHAzetFr/tQFYv9t6ibZHUF
e06ef39ws7sO8GlII3TEKfMaByY1BMX/jv8RD6qSCrdLPQgwAzInfL3wJLdqykNC
8SkS1h0Oo4Dm4lrBuAnrwo6cCZOVzI5SJz1q3hJja5BnAg1+7920ts4LGS1EbJVu
2mnlgWJg7veMkjGEyZs3W0WKkOZHnuQjY1gZRBDBnBqqRy7OUmWIftVixUK2m6sP
IKVnaT0f5bS47gqt4wahhuwLo5+JCEiSTpEVlhNV2ZK5ZwAvSWU=
=dNvr
-END PGP SIGNATURE-

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

[Bug 63879] Unessesary log noise under DEBUG

2019-10-28 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=63879

--- Comment #8 from Christopher Schultz  ---
(In reply to Michael Bazos from comment #6)
> I agree switching to TRACE is the best option. Also it might be helpful to
> not throw new Exception()

Note that the exception is not thrown, only constructed. Yes, this requires the
runtime to walk the the stack to produce the stack trace (Which is precisely
why it's being done at all) but we don't incur the penalty of actually throwing
the exception.

> this produces this message
> "java.lang.Exception: null" If you are going to have this it might be best
> to provide a message to let people know this is intended and testing.

+1 to adding a message e.g. new Exception("Intentional stack trace")

-- 
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: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2019-10-28 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rémy,

On 10/28/19 09:51, Rémy Maucherat wrote:
> On Mon, Oct 28, 2019 at 2:34 PM Christopher Schultz 
>  > wrote:
> 
> All,
> 
> Note: this was not a vote.
> 
> The consensus seems to be that SSIs should be moved into a
> separate JAR file.
> 
> I've done a *very* short investigation, and I have discovered the 
> following:
> 
> 1. Tomcat builds fine after removing the entire 
> org.apache.catalina.ssi source package, so it's completely
> isolated from the rest of Tomcat (which was entirely expected).
> This suggests that releasing Tomcat without any of the SSI
> components is practical and relatively easy.
> 
> The stock conf/web.xml contains a sample configuration for the SSI 
> servlet. We will have to decide what to do with that. I can think
> of at least two options:
> 
> a. Remove it from the stock conf/web.xml entirely b. Add comments
> to conf/web.xml indicating that the SSI component is a separate
> download
> 
> I think I like #2 better.
> 
> 2. Separating the packaging should be easy. Note that I haven't 
> actually done this:
> 
> i.  Modify files.catalina in build.xml to  the 
> org.apache.catalina.ssi package ii. Modify the "package" target in
> build.xml to  with the
> appropriate classes
> 
> I think this is super simple to do and we should go ahead and do
> this, /now/. For embedded clients who don't care about SSI, this
> gives them a JAR today that they can simply remove from their
> bundled clients to save a little space.
> 
> 3. The SSI component uses a bunch of internal(ish) Tomcat/Catalina 
> APIs. This may complicate fully-extracting the SSI component and 
> making it a standalone product (e.g. cross-container):
> 
> org.apache.catalina.connector.Connector; 
> org.apache.catalina.connector.Request; 
> org.apache.catalina.util.IOTools; 
> org.apache.catalina.util.Strftime; 
> org.apache.catalina.util.URLEncoder; org.apache.coyote.Constants; 
> org.apache.tomcat.util.buf.B2CConverter; 
> org.apache.tomcat.util.buf.UDecoder; 
> org.apache.tomcat.util.http.FastHttpDateFormat; 
> org.apache.tomcat.util.http.RequestUtil; 
> org.apache.tomcat.util.res.StringManager; 
> org.apache.tomcat.util.security.Escape;
> 
> Some of them are simply for convenience -- e.g. UDecoder, 
> FastHttpDateFormat, etc. Those could easily be replaced with 
> alternatives or re-implementations. I haven't yet looked at how
> much the org.apache.catalina.connector.Connector and 
> org.apache.catalina.connector.Request classes are used. It's
> possible that these could be replaced with the generic versions of
> themselves (e.g. HttpServletRequest and ... I'm not sure what we
> get from the Connector but of course there is no direct replacement
> for that in the public API).
> 
> So I'd like to move-forward with the separation of the SSI
> component into a separate JAR file and then see what can be
> re-factored within SSI itself to divorce it from internal Tomcat
> APIs.
> 
> 
>> Personally I am in favor of a separate JAR, but maintain
>> everything else unchanged. The use of utility classes reduces
>> code duplication. If it becomes cross container then I think SSI
>> should be moved elsewhere. Maybe something like the taglibs
>> subproject. It's a rather significant effort to test and maintain
>> compatibility with everything out there IMO.

Thanks for the feedback. I wouldn't bother replacing the uses of
utility classes unless we were expecting to spin the project off into
a subproject as you say.

If we did that, I would say that anyone wanting to run the
SSIServlet/Filter on another container would be caveat downloader and
that patches were always welcome; the subproject would only promise
compatibility with Tomcat, at least at first.

Who knows? Maybe there is a nascent community out there who wants to
support CGI forever on all servlet containers and they'll get behind
such a project. *shrug*

- -chris

> On 10/7/19 10:46, Christopher Schultz wrote:
>> All,
> 
>> I recently gave a presentation on locking-down Apache Tomcat[1]
>> and I briefly discussed the "sharp edges" present in Tomcat. Some
>> of them are unnecessarily sharp and may be actually unnecessary.
>> I'm going to make a few proposals to remove functions from
>> Tomcat.
> 
>> Proposal: Remove Server-Side Includes
> 
>> Justification:
> 
>> The SSI module is a remote-code execution (RCE) vulnerability as
>> a feature. My sense is that SSI is a little-used feature. A few 
>> years ago, markt[2] asked if anyone was using SSI. The only
>> replies were from other Tomcat devs commenting on what to do with
>> SSI if it's no longer in the main Tomcat distribution; there were
>> no community members who responded saying that SSI was important
>> to them.
> 
>> If the packaging of Tomcat could be tweaked a bit to move the
>> SSI components into a separate JAR file (e.g. move 
>> org/apache/catalina/ssi/* to catalina-ssi.jar) and if the SSI 
>> components don't rely on any

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2019-10-28 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

On 10/28/19 09:34, Christopher Schultz wrote:
> 2. Separating the packaging should be easy. Note that I haven't 
> actually done this:
> 
> i.  Modify files.catalina in build.xml to  the 
> org.apache.catalina.ssi package ii. Modify the "package" target in
> build.xml to  with the
> appropriate classes
> 
> I think this is super simple to do and we should go ahead and do
> this, /now/. For embedded clients who don't care about SSI, this
> gives them a JAR today that they can simply remove from their
> bundled clients to save a little space.

This part was easy, but the MANIFEST.MF file claims it is tomcat-trunk
and not e.g. org.apache.tomcat-ssi. I'm trying to figure out how we do
it for Tribes, but I haven't been able to find the mechanism. There
are Maven-y things in the source tree that contain the string
org.apache.tomcat-tribes but I don't think we are using them to
generate our JAR files at packaging-time.

Can anyone point me to the place(s) where Tribes gets it's
META-INF/MANIFEST.MF values?

Also... will this take care of OSGi, or is there something else I need
to do in addition to addOSGi="true" when building the JAR?

Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl22+fcACgkQHPApP6U8
pFgc4RAAognVhphg2zIznYSnDQqRFu3NXgmd+EhvegyOGKgWWNS29P4Tt1A2WPNk
JGIEToGJ55r7HluwYqk4CZJ1JT8oGD5971CnZVYfwbMsvafO4c+RBirYRitnPdi7
uYpeOE4NTrek+LNK9N4d0rsMEQLCAESe5bBhfErBwV1G2zHe804sy/1RQavM3POr
RMAtzccmM1u2ixJaD6FBkiZutdrBx6nKGAh6yBVI6T7AXkPJas9xLhK8/cQfakRI
esqt2pVKpSJIPeuzQRFPn58gjmsEaztKtxoUj67Z2Z/GKtAMOOenbD6FkKlmlEtW
HMiSTGik7dIBM2lgNy8FPosz6a6Oj2ANDlVX7+3QexSciQwlRjSzYRFGP22aLvzS
k6wQTWcBiP+bdfFY12QxBnGrUMVfr3ln/wBgCTLTHdWO6iM1NElVWHzbVaSDDQ8u
u5sGwi1j5gXvsB4y+vUVw+dnbvtVwZV8peYNpRfkUGzER8VUxL8/Ln9TeUhyiIgJ
bzu6iGg/c7+gCCLLrNvfd+Z1pDeMGUmv+sW3DNlNQzrfqlf5a3qyqw/mFsQT4nnD
Wev9jZW40vGJjUHwnnPpT/VJhX1GLHeVzec9SlN91o62a/aH3XfSUQRBXbx//QN3
piVmxIysDxkfzmnkwlM93MfGkez2xDkNCF6Qmy2ZF/txFDQfS28=
=x1jq
-END PGP SIGNATURE-

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

[tomcat] branch 7.0.x updated: Better fix for bug 63836

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

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


The following commit(s) were added to refs/heads/7.0.x by this push:
 new cdfe4c7  Better fix for bug 63836
cdfe4c7 is described below

commit cdfe4c7458163bdbfc075506e2130ee7d928da0a
Author: Mark Thomas 
AuthorDate: Mon Oct 28 20:29:00 2019 +0100

Better fix for bug 63836

Ensure ContextConfig does not retain a reference to a Host object once
the Host has been destroyed.
---
 java/org/apache/catalina/startup/ContextConfig.java | 15 +++
 java/org/apache/tomcat/util/net/NioEndpoint.java|  1 -
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/java/org/apache/catalina/startup/ContextConfig.java 
b/java/org/apache/catalina/startup/ContextConfig.java
index 34764d6..91fb5f3 100644
--- a/java/org/apache/catalina/startup/ContextConfig.java
+++ b/java/org/apache/catalina/startup/ContextConfig.java
@@ -1511,6 +1511,9 @@ public class ContextConfig implements LifecycleListener {
 entry = new DefaultWebXmlCacheEntry(webXmlDefaultFragment,
 globalTimeStamp, hostTimeStamp);
 hostWebXmlCache.put(host, entry);
+// Add a Lifecycle listener to the Host that will remove it 
from
+// the hostWebXmlCache once the Host is destroyed
+host.addLifecycleListener(new HostWebXmlCacheCleaner());
 }
 
 return webXmlDefaultFragment;
@@ -2792,6 +2795,18 @@ public class ContextConfig implements LifecycleListener {
 }
 }
 
+private static class HostWebXmlCacheCleaner implements LifecycleListener {
+
+@Override
+public void lifecycleEvent(LifecycleEvent event) {
+
+if (event.getType() == Lifecycle.AFTER_DESTROY_EVENT) {
+Host host = (Host) event.getSource();
+hostWebXmlCache.remove(host);
+}
+}
+}
+
 private static class JavaClassCacheEntry {
 public final String superclassName;
 
diff --git a/java/org/apache/tomcat/util/net/NioEndpoint.java 
b/java/org/apache/tomcat/util/net/NioEndpoint.java
index 0eef5f6..eeeb6b8 100644
--- a/java/org/apache/tomcat/util/net/NioEndpoint.java
+++ b/java/org/apache/tomcat/util/net/NioEndpoint.java
@@ -592,7 +592,6 @@ public class NioEndpoint extends 
AbstractEndpoint {
 nioChannels.clear();
 processorCache.clear();
 shutdownExecutor();
-oomParachuteData = null;
 }
 
 


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

[tomcat] branch 7.0.x updated: Update guidance for Eclipse 4.13

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

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


The following commit(s) were added to refs/heads/7.0.x by this push:
 new c2cd611  Update guidance for Eclipse 4.13
c2cd611 is described below

commit c2cd61172858d2b05b20882e9ee96b7c74869c8e
Author: Mark Thomas 
AuthorDate: Mon Oct 28 20:30:13 2019 +0100

Update guidance for Eclipse 4.13
---
 res/ide-support/eclipse/java-compiler-errors-warnings.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/res/ide-support/eclipse/java-compiler-errors-warnings.txt 
b/res/ide-support/eclipse/java-compiler-errors-warnings.txt
index 37b350b..2905d56 100644
--- a/res/ide-support/eclipse/java-compiler-errors-warnings.txt
+++ b/res/ide-support/eclipse/java-compiler-errors-warnings.txt
@@ -18,7 +18,7 @@
 # Java -> Compiler -> Errors/Warnings
 ===
 
-The following settings are for Oxygen (Eclipse 4.7)
+The following settings are for Oxygen (Eclipse 4.13)
 W = Warning
 I = Ignore
 E = Error
@@ -55,9 +55,13 @@ Name shadowing and conflicts
 Deprecated and restricted API
  - Deprecated API   - W
([ ] on all additional check boxes)
+ - Deprecated API marked for removal- W
  - Forbidden references - E
  - Discouraged reference- W
 
+Modules
+ - All  - W
+
 Unnecessary code
  - All  - W
([x] on all additional check boxes)


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

[tomcat] branch 8.5.x updated: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63836

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

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


The following commit(s) were added to refs/heads/8.5.x by this push:
 new 05664f3  Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63836
05664f3 is described below

commit 05664f3a1addb03cf4b3e70803609d13cefb2e91
Author: Mark Thomas 
AuthorDate: Mon Oct 28 20:43:24 2019 +0100

Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63836

While the OOME was not observed in 8.5.x, the memory leak at the roto of
the issue was still present.
---
 java/org/apache/catalina/startup/ContextConfig.java | 15 +++
 webapps/docs/changelog.xml  |  4 
 2 files changed, 19 insertions(+)

diff --git a/java/org/apache/catalina/startup/ContextConfig.java 
b/java/org/apache/catalina/startup/ContextConfig.java
index 4474fcf..0cc1b6a 100644
--- a/java/org/apache/catalina/startup/ContextConfig.java
+++ b/java/org/apache/catalina/startup/ContextConfig.java
@@ -1555,6 +1555,9 @@ public class ContextConfig implements LifecycleListener {
 entry = new DefaultWebXmlCacheEntry(webXmlDefaultFragment,
 globalTimeStamp, hostTimeStamp);
 hostWebXmlCache.put(host, entry);
+// Add a Lifecycle listener to the Host that will remove it 
from
+// the hostWebXmlCache once the Host is destroyed
+host.addLifecycleListener(new HostWebXmlCacheCleaner());
 }
 
 return webXmlDefaultFragment;
@@ -2617,6 +2620,18 @@ public class ContextConfig implements LifecycleListener {
 }
 }
 
+private static class HostWebXmlCacheCleaner implements LifecycleListener {
+
+@Override
+public void lifecycleEvent(LifecycleEvent event) {
+
+if (event.getType() == Lifecycle.AFTER_DESTROY_EVENT) {
+Host host = (Host) event.getSource();
+hostWebXmlCache.remove(host);
+}
+}
+}
+
 static class JavaClassCacheEntry {
 public final String superclassName;
 
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 5db3f80..71c0077 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -51,6 +51,10 @@
 63832: Properly mark container as FAILED when a JVM error
 occurs on stop. (remm)
   
+  
+63836 Ensure that references to the Host object are cleared
+once the Host instance is destroyed. (markt)
+  
 
   
   


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

[tomcat] branch master updated: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63836

2019-10-28 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 7fb643d  Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63836
7fb643d is described below

commit 7fb643d2c0d0c9630fa820d5bdcae5433e30dd9b
Author: Mark Thomas 
AuthorDate: Mon Oct 28 21:03:33 2019 +0100

Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63836

While the OOME was not observed in 8.5.x, the memory leak at the root of
the issue was still present.
---
 .../org/apache/catalina/startup/ContextConfig.java | 24 ++
 webapps/docs/changelog.xml |  4 
 2 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/java/org/apache/catalina/startup/ContextConfig.java 
b/java/org/apache/catalina/startup/ContextConfig.java
index 75a16db..fa11334 100644
--- a/java/org/apache/catalina/startup/ContextConfig.java
+++ b/java/org/apache/catalina/startup/ContextConfig.java
@@ -37,8 +37,6 @@ import java.util.Map;
 import java.util.Map.Entry;
 import java.util.Properties;
 import java.util.Set;
-import java.util.concurrent.ConcurrentHashMap;
-
 import javax.servlet.MultipartConfigElement;
 import javax.servlet.ServletContainerInitializer;
 import javax.servlet.ServletContext;
@@ -80,6 +78,7 @@ import org.apache.tomcat.util.bcel.classfile.ElementValue;
 import org.apache.tomcat.util.bcel.classfile.ElementValuePair;
 import org.apache.tomcat.util.bcel.classfile.JavaClass;
 import org.apache.tomcat.util.buf.UriUtil;
+import org.apache.tomcat.util.collections.ManagedConcurrentWeakHashMap;
 import org.apache.tomcat.util.descriptor.InputSourceUtil;
 import org.apache.tomcat.util.descriptor.XmlErrorHandler;
 import org.apache.tomcat.util.descriptor.web.ContextEjb;
@@ -163,8 +162,8 @@ public class ContextConfig implements LifecycleListener {
 /**
  * Cache of default web.xml fragments per Host
  */
-protected static final Map hostWebXmlCache =
-new ConcurrentHashMap<>();
+protected static final 
ManagedConcurrentWeakHashMap hostWebXmlCache =
+new ManagedConcurrentWeakHashMap<>();
 
 
 /**
@@ -306,6 +305,8 @@ public class ContextConfig implements LifecycleListener {
 if (originalDocBase != null) {
 context.setDocBase(originalDocBase);
 }
+} else if (event.getType().equals(Lifecycle.PERIODIC_EVENT)) {
+hostWebXmlCache.maintain();
 } else if (event.getType().equals(Lifecycle.CONFIGURE_STOP_EVENT)) {
 configureStop();
 } else if (event.getType().equals(Lifecycle.AFTER_INIT_EVENT)) {
@@ -1599,6 +1600,9 @@ public class ContextConfig implements LifecycleListener {
 entry = new DefaultWebXmlCacheEntry(webXmlDefaultFragment,
 globalTimeStamp, hostTimeStamp);
 hostWebXmlCache.put(host, entry);
+// Add a Lifecycle listener to the Host that will remove it 
from
+// the hostWebXmlCache once the Host is destroyed
+host.addLifecycleListener(new HostWebXmlCacheCleaner());
 }
 
 return webXmlDefaultFragment;
@@ -2681,6 +2685,18 @@ public class ContextConfig implements LifecycleListener {
 }
 }
 
+private static class HostWebXmlCacheCleaner implements LifecycleListener {
+
+@Override
+public void lifecycleEvent(LifecycleEvent event) {
+
+if (event.getType() == Lifecycle.AFTER_DESTROY_EVENT) {
+Host host = (Host) event.getSource();
+hostWebXmlCache.remove(host);
+}
+}
+}
+
 static class JavaClassCacheEntry {
 public final String superclassName;
 
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 87e5d44..25c065c 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -59,6 +59,10 @@
 Add more details on the usage of RewriteMap
 functionality in the RewriteValve. (fschumacher)
   
+  
+63836 Ensure that references to the Host object are cleared
+once the Host instance is destroyed. (markt)
+  
 
   
   


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

[tomcat] branch master updated: Update guidance for Eclipse 4.13

2019-10-28 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 8cb570d  Update guidance for Eclipse 4.13
8cb570d is described below

commit 8cb570dec3a668b370a96174076ff9cb33688aa1
Author: Mark Thomas 
AuthorDate: Mon Oct 28 20:30:13 2019 +0100

Update guidance for Eclipse 4.13
---
 res/ide-support/eclipse/java-compiler-errors-warnings.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/res/ide-support/eclipse/java-compiler-errors-warnings.txt 
b/res/ide-support/eclipse/java-compiler-errors-warnings.txt
index 37b350b..2905d56 100644
--- a/res/ide-support/eclipse/java-compiler-errors-warnings.txt
+++ b/res/ide-support/eclipse/java-compiler-errors-warnings.txt
@@ -18,7 +18,7 @@
 # Java -> Compiler -> Errors/Warnings
 ===
 
-The following settings are for Oxygen (Eclipse 4.7)
+The following settings are for Oxygen (Eclipse 4.13)
 W = Warning
 I = Ignore
 E = Error
@@ -55,9 +55,13 @@ Name shadowing and conflicts
 Deprecated and restricted API
  - Deprecated API   - W
([ ] on all additional check boxes)
+ - Deprecated API marked for removal- W
  - Forbidden references - E
  - Discouraged reference- W
 
+Modules
+ - All  - W
+
 Unnecessary code
  - All  - W
([x] on all additional check boxes)


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

[tomcat] branch 8.5.x updated: Update guidance for Eclipse 4.13

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

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


The following commit(s) were added to refs/heads/8.5.x by this push:
 new 6fac0e0  Update guidance for Eclipse 4.13
6fac0e0 is described below

commit 6fac0e019c6b4668ffb6d967953e475f72a3459e
Author: Mark Thomas 
AuthorDate: Mon Oct 28 20:30:13 2019 +0100

Update guidance for Eclipse 4.13
---
 res/ide-support/eclipse/java-compiler-errors-warnings.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/res/ide-support/eclipse/java-compiler-errors-warnings.txt 
b/res/ide-support/eclipse/java-compiler-errors-warnings.txt
index 37b350b..2905d56 100644
--- a/res/ide-support/eclipse/java-compiler-errors-warnings.txt
+++ b/res/ide-support/eclipse/java-compiler-errors-warnings.txt
@@ -18,7 +18,7 @@
 # Java -> Compiler -> Errors/Warnings
 ===
 
-The following settings are for Oxygen (Eclipse 4.7)
+The following settings are for Oxygen (Eclipse 4.13)
 W = Warning
 I = Ignore
 E = Error
@@ -55,9 +55,13 @@ Name shadowing and conflicts
 Deprecated and restricted API
  - Deprecated API   - W
([ ] on all additional check boxes)
+ - Deprecated API marked for removal- W
  - Forbidden references - E
  - Discouraged reference- W
 
+Modules
+ - All  - W
+
 Unnecessary code
  - All  - W
([x] on all additional check boxes)


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

[tomcat] branch master updated: Fix imports

2019-10-28 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 a54fff8  Fix imports
a54fff8 is described below

commit a54fff8601970f9d88d28177d0bc74368535dd0c
Author: Mark Thomas 
AuthorDate: Mon Oct 28 21:20:41 2019 +0100

Fix imports
---
 java/org/apache/catalina/startup/ContextConfig.java | 1 +
 1 file changed, 1 insertion(+)

diff --git a/java/org/apache/catalina/startup/ContextConfig.java 
b/java/org/apache/catalina/startup/ContextConfig.java
index fa11334..f0f2fd2 100644
--- a/java/org/apache/catalina/startup/ContextConfig.java
+++ b/java/org/apache/catalina/startup/ContextConfig.java
@@ -37,6 +37,7 @@ import java.util.Map;
 import java.util.Map.Entry;
 import java.util.Properties;
 import java.util.Set;
+
 import javax.servlet.MultipartConfigElement;
 import javax.servlet.ServletContainerInitializer;
 import javax.servlet.ServletContext;


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

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2019-10-28 Thread Mark Thomas 
On 28/10/2019 15:23, Christopher Schultz wrote:



>> i.  Modify files.catalina in build.xml to  the 
>> org.apache.catalina.ssi package ii. Modify the "package" target in
>> build.xml to  with the
>> appropriate classes
>>
>> I think this is super simple to do and we should go ahead and do
>> this, /now/. For embedded clients who don't care about SSI, this
>> gives them a JAR today that they can simply remove from their
>> bundled clients to save a little space.
> 
> This part was easy, but the MANIFEST.MF file claims it is tomcat-trunk
> and not e.g. org.apache.tomcat-ssi. I'm trying to figure out how we do
> it for Tribes, but I haven't been able to find the mechanism. There
> are Maven-y things in the source tree that contain the string
> org.apache.tomcat-tribes but I don't think we are using them to
> generate our JAR files at packaging-time.
> 
> Can anyone point me to the place(s) where Tribes gets it's
> META-INF/MANIFEST.MF values?
> 
> Also... will this take care of OSGi, or is there something else I need
> to do in addition to addOSGi="true" when building the JAR?

It is res/bnd/catalina-tribes.jar.tmp.bnd

It sets the various bundle properties which are what OSGi looks for when
the add-osgi task runs.

Mark


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

[GitHub] [tomcat] markt-asf commented on a change in pull request #218: WIP: BZ 63835: Add support for Keep-Alive header

2019-10-28 Thread GitBox 
markt-asf commented on a change in pull request #218: WIP: BZ 63835: Add 
support for Keep-Alive header
URL: https://github.com/apache/tomcat/pull/218#discussion_r339780088
 
 

 ##
 File path: java/org/apache/coyote/http11/Http11Processor.java
 ##
 @@ -915,8 +915,26 @@ protected final void prepareResponse() throws IOException 
{
 headers.addValue(Constants.CONNECTION).setString(
 Constants.CLOSE);
 }
-} else if (!http11 && !getErrorState().isError()) {
-
headers.addValue(Constants.CONNECTION).setString(Constants.KEEPALIVE);
+} else if (!getErrorState().isError()) {
+if (!http11) {
+
headers.addValue(Constants.CONNECTION).setString(Constants.KEEPALIVE);
+}
+
+boolean connectionKeepAlivePresent =
+isConnectionToken(request.getMimeHeaders(), 
Constants.KEEPALIVE);
+
+if (connectionKeepAlivePresent) {
+int keepAliveTimeout = protocol.getKeepAliveTimeout();
+
+if (keepAliveTimeout > 0) {
+String value = "timeout=" + keepAliveTimeout / 1000L;
+headers.setValue("Keep-Alive").setString(value);
+}
+
+if (http11) {
+
headers.addValue(Constants.CONNECTION).setString(Constants.KEEPALIVE);
 
 Review comment:
   I care more about what the spec says than what httpd does. While httpd is a 
useful guide, it may not follow the spec in all instances.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

Re: RewriteMap parsing

2019-10-28 Thread Mark Thomas 



On 27/10/2019 11:27, Felix Schumacher wrote:
> Hi all,
> 
> while looking at the RewriteMap configuration, I noticed, that parsing
> of the RewriteMap directive is a bit minimal. Parameters are split at
> whitespace (no quotes will be recognized) and only the first of the
> optional parameters will be used.
> 
> Should this be changed? If so, should we introduce quoting capabilities
> to gather the "one" optional parameter, or allow multiple parameters?
> 
> Version "quote":
> 
> RewriteMap m1 example.MyMap "some params"
> 
> Version "multiple"
> 
> RewriteMap m2 example.OtherMap one two three
> 
> Or should it be a combination?

That is probably the most flexible option. I'd lean towards this option
but would be happy to support the majority view if different.

> "quote" would be sort of compatible with the current interface, as we
> still have only one parameter. "multiple" would be a nicer interface for
> the implementer of the map.
> 
> Another thing I noticed, is that the httpd rewrite map feature has a few
> builtin maps, that could be useful to supply with our implementation.
> Any thoughts on supplying those? (I thought about the maps
> int:[toupper,tolower,escape,unescape], txt:, rnd: and possibly a new one
> called jdbc:{jndi-connection}:{sql statement with placeholder}. For
> these elements a quote detection would be a must)

I don't recall any requests for these on the users list but maybe that
is because the feature isn't that well known.

Mark


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

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2019-10-28 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 10/28/19 16:30, Mark Thomas wrote:
> On 28/10/2019 15:23, Christopher Schultz wrote:
> 
> 
> 
>>> i.  Modify files.catalina in build.xml to  the 
>>> org.apache.catalina.ssi package ii. Modify the "package" target
>>> in build.xml to  with
>>> the appropriate classes
>>> 
>>> I think this is super simple to do and we should go ahead and
>>> do this, /now/. For embedded clients who don't care about SSI,
>>> this gives them a JAR today that they can simply remove from
>>> their bundled clients to save a little space.
>> 
>> This part was easy, but the MANIFEST.MF file claims it is
>> tomcat-trunk and not e.g. org.apache.tomcat-ssi. I'm trying to
>> figure out how we do it for Tribes, but I haven't been able to
>> find the mechanism. There are Maven-y things in the source tree
>> that contain the string org.apache.tomcat-tribes but I don't
>> think we are using them to generate our JAR files at
>> packaging-time.
>> 
>> Can anyone point me to the place(s) where Tribes gets it's 
>> META-INF/MANIFEST.MF values?
>> 
>> Also... will this take care of OSGi, or is there something else I
>> need to do in addition to addOSGi="true" when building the JAR?
> 
> It is res/bnd/catalina-tribes.jar.tmp.bnd
> 
> It sets the various bundle properties which are what OSGi looks for
> when the add-osgi task runs.

Awesome, thanks. I think this is all done, then.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl23Vn8ACgkQHPApP6U8
pFihDg/9Gq20qm3NrW0Nj9EZwmAav0m1jV+bLWtqsCOpwo095DfyUPsppMPLB9ua
cekqNo68CzQ+e+1lNOdYMjJR9GXRtttN44AkP5GaHvsv//mDxblfW8zRvDAaMdI1
znCspMAw4XSOHSezNUlMd7z0sHpWM+P3dNmZuK7U5Ug605CsSj9z56pzkSpPu1n9
NWUlaCT2Jdh+hktqwuxd+L9Ie9t0FZD8DNoBapzOZStJ4+L625yg9KOnGVq/GAQY
p+pL1HcvVQtA5lGDJQxZE3/vbUy1WNGwvXp/E6xZmHLjFSAs/3uJ+ykUH0dVmqUD
1P/p4uW04PWmgEZWmjugTxD/oKPrjsxcmHThP7Ylu7xbwhOhNPQQq+YesRdxYTWX
jUUeM5VEeGm9fZyzIkvfEGZmYXDf2CiasEFx0CAkno/APeDyL8e6PqiepWHKUeuq
EtK71dWSGWUfvnohoU+VpJKm4jldHMizavG5465gWuDxRWD59sAH7iOvzrKNtJY0
9/2Zct9+MZ9wtlrxiWQRdt9G/jHLBTkH8PcM77ctTLJfwwQcFOc21E5+d4PwnnLP
P4drouOTHUGPtOKX+iObs6fj/9FkHSCwqElH2/S7On5YU/Zp7fmFPXDwZuzyZVM6
b824rrUYsIhNzkPEngSTwB1ZK2BtCmQmcutWa18w734smsyzjTk=
=YoLX
-END PGP SIGNATURE-

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

[GitHub] [tomcat] michael-o commented on a change in pull request #218: WIP: BZ 63835: Add support for Keep-Alive header

2019-10-28 Thread GitBox 
michael-o commented on a change in pull request #218: WIP: BZ 63835: Add 
support for Keep-Alive header
URL: https://github.com/apache/tomcat/pull/218#discussion_r339792589
 
 

 ##
 File path: java/org/apache/coyote/http11/Http11Processor.java
 ##
 @@ -915,8 +915,26 @@ protected final void prepareResponse() throws IOException 
{
 headers.addValue(Constants.CONNECTION).setString(
 Constants.CLOSE);
 }
-} else if (!http11 && !getErrorState().isError()) {
-
headers.addValue(Constants.CONNECTION).setString(Constants.KEEPALIVE);
+} else if (!getErrorState().isError()) {
+if (!http11) {
+
headers.addValue(Constants.CONNECTION).setString(Constants.KEEPALIVE);
+}
+
+boolean connectionKeepAlivePresent =
+isConnectionToken(request.getMimeHeaders(), 
Constants.KEEPALIVE);
+
+if (connectionKeepAlivePresent) {
+int keepAliveTimeout = protocol.getKeepAliveTimeout();
+
+if (keepAliveTimeout > 0) {
+String value = "timeout=" + keepAliveTimeout / 1000L;
+headers.setValue("Keep-Alive").setString(value);
+}
+
+if (http11) {
+
headers.addValue(Constants.CONNECTION).setString(Constants.KEEPALIVE);
 
 Review comment:
   Rereading the draft and the RFC 7230, I see not point which obligates us to 
respond with `Connection: Keep-Alive` on `HTTP/1.1` if the connection can be 
kept forever. So I have no counter arguments and will move and nest it.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [tomcat] michael-o commented on a change in pull request #218: WIP: BZ 63835: Add support for Keep-Alive header

2019-10-28 Thread GitBox 
michael-o commented on a change in pull request #218: WIP: BZ 63835: Add 
support for Keep-Alive header
URL: https://github.com/apache/tomcat/pull/218#discussion_r339792589
 
 

 ##
 File path: java/org/apache/coyote/http11/Http11Processor.java
 ##
 @@ -915,8 +915,26 @@ protected final void prepareResponse() throws IOException 
{
 headers.addValue(Constants.CONNECTION).setString(
 Constants.CLOSE);
 }
-} else if (!http11 && !getErrorState().isError()) {
-
headers.addValue(Constants.CONNECTION).setString(Constants.KEEPALIVE);
+} else if (!getErrorState().isError()) {
+if (!http11) {
+
headers.addValue(Constants.CONNECTION).setString(Constants.KEEPALIVE);
+}
+
+boolean connectionKeepAlivePresent =
+isConnectionToken(request.getMimeHeaders(), 
Constants.KEEPALIVE);
+
+if (connectionKeepAlivePresent) {
+int keepAliveTimeout = protocol.getKeepAliveTimeout();
+
+if (keepAliveTimeout > 0) {
+String value = "timeout=" + keepAliveTimeout / 1000L;
+headers.setValue("Keep-Alive").setString(value);
+}
+
+if (http11) {
+
headers.addValue(Constants.CONNECTION).setString(Constants.KEEPALIVE);
 
 Review comment:
   Rereading the draft and the RFC 7230, I see no point which obligates us to 
respond with `Connection: Keep-Alive` on `HTTP/1.1` if the connection can be 
kept forever. So I have no counter arguments and will move and nest it.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[tomcat] branch BZ-63835/9.0.x updated (38fdae1 -> d7f8616)

2019-10-28 Thread michaelo 
This is an automated email from the ASF dual-hosted git repository.

michaelo pushed a change to branch BZ-63835/9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git.


omit 38fdae1  BZ 63835: Add support for Keep-Alive header
 add 8096561  Polish. Align with 8.5.x.
 add ec782a0  Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63865
 add 071d63e  Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63831
 add 70b54a9  Small typo in changelog
 add 63ea6ad  Correct link target for RewriteMap in documentation
 add e70ef85  Add more documentation about usage of RewriteMap
 add 3f9d9de  Add javadoc for RewriteMap
 add 7fb643d  Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63836
 add 8cb570d  Update guidance for Eclipse 4.13
 add a54fff8  Fix imports
 new d7f8616  BZ 63835: Add support for Keep-Alive header

This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version.  This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:

 * -- * -- B -- O -- O -- O   (38fdae1)
\
 N -- N -- N   refs/heads/BZ-63835/9.0.x (d7f8616)

You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.

Any revisions marked "omit" are not gone; other references still
refer to them.  Any revisions marked "discard" are gone forever.

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 .../org/apache/catalina/startup/ContextConfig.java | 23 --
 .../apache/catalina/valves/rewrite/RewriteMap.java | 33 ++
 java/org/apache/coyote/http11/Constants.java   |  1 +
 java/org/apache/coyote/http11/Http11Processor.java | 10 ++---
 .../tomcat/util/http/CookieProcessorBase.java  |  2 +-
 .../tomcat/util/http/LegacyCookieProcessor.java|  2 +-
 .../tomcat/util/http/LocalStrings.properties   |  2 +-
 .../tomcat/util/http/Rfc6265CookieProcessor.java   |  2 +-
 .../apache/tomcat/util/http/SameSiteCookies.java   |  7 ++-
 .../eclipse/java-compiler-errors-warnings.txt  |  6 ++-
 .../coyote/http2/TestHttp2InitialConnection.java   | 10 -
 .../util/http/TestCookieProcessorGeneration.java   | 20 +++--
 .../tomcat/util/http/TestSameSiteCookies.java  | 19 
 webapps/docs/changelog.xml | 15 ++-
 webapps/docs/config/cookie-processor.xml   | 10 -
 webapps/docs/rewrite.xml   | 51 +-
 16 files changed, 188 insertions(+), 25 deletions(-)


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

[tomcat] 01/01: BZ 63835: Add support for Keep-Alive header

2019-10-28 Thread michaelo 
This is an automated email from the ASF dual-hosted git repository.

michaelo pushed a commit to branch BZ-63835/9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git

commit d7f8616144ee0f3eaba94bfee73cfd2ca3de8667
Author: Michael Osipov 
AuthorDate: Wed Oct 23 15:37:42 2019 +0200

BZ 63835: Add support for Keep-Alive header
---
 java/org/apache/coyote/http11/Constants.java   |  1 +
 java/org/apache/coyote/http11/Http11Processor.java | 22 --
 2 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/java/org/apache/coyote/http11/Constants.java 
b/java/org/apache/coyote/http11/Constants.java
index 2ca4dc4..55045d4 100644
--- a/java/org/apache/coyote/http11/Constants.java
+++ b/java/org/apache/coyote/http11/Constants.java
@@ -117,6 +117,7 @@ public final class Constants {
 public static final String CHUNKED = "chunked";
 public static final byte[] ACK_BYTES = ByteChunk.convertToBytes("HTTP/1.1 
100 " + CRLF + CRLF);
 public static final String TRANSFERENCODING = "Transfer-Encoding";
+public static final String KEEP_ALIVE = "Keep-Alive";
 public static final byte[] _200_BYTES = ByteChunk.convertToBytes("200");
 public static final byte[] _400_BYTES = ByteChunk.convertToBytes("400");
 public static final byte[] _404_BYTES = ByteChunk.convertToBytes("404");
diff --git a/java/org/apache/coyote/http11/Http11Processor.java 
b/java/org/apache/coyote/http11/Http11Processor.java
index 0f24e18..56b6b69 100644
--- a/java/org/apache/coyote/http11/Http11Processor.java
+++ b/java/org/apache/coyote/http11/Http11Processor.java
@@ -915,8 +915,26 @@ public class Http11Processor extends AbstractProcessor {
 headers.addValue(Constants.CONNECTION).setString(
 Constants.CLOSE);
 }
-} else if (!http11 && !getErrorState().isError()) {
-
headers.addValue(Constants.CONNECTION).setString(Constants.KEEPALIVE);
+} else if (!getErrorState().isError()) {
+if (!http11) {
+
headers.addValue(Constants.CONNECTION).setString(Constants.KEEPALIVE);
+}
+
+boolean connectionKeepAlivePresent =
+isConnectionToken(request.getMimeHeaders(), 
Constants.KEEPALIVE);
+
+if (connectionKeepAlivePresent) {
+int keepAliveTimeout = protocol.getKeepAliveTimeout();
+
+if (keepAliveTimeout > 0) {
+String value = "timeout=" + keepAliveTimeout / 1000L;
+headers.setValue(Constants.KEEP_ALIVE).setString(value);
+
+if (http11) {
+
headers.addValue(Constants.CONNECTION).setString(Constants.KEEPALIVE);
+}
+}
+}
 }
 
 // Add server header


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

[GitHub] [tomcat] michael-o commented on issue #218: WIP: BZ 63835: Add support for Keep-Alive header

2019-10-28 Thread GitBox 
michael-o commented on issue #218: WIP: BZ 63835: Add support for Keep-Alive 
header
URL: https://github.com/apache/tomcat/pull/218#issuecomment-547156714
 
 
   Critics have been resolved, please re-evaluate.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[tomcat] branch master updated (a54fff8 -> 1638e4f)

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

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


from a54fff8  Fix imports
 add 1638e4f  Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63838

No new revisions were added by this update.

Summary of changes:
 build.xml  | 18 ++
 webapps/docs/changelog.xml |  4 
 2 files changed, 22 insertions(+)


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

[tomcat] branch 8.5.x updated: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63838

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

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


The following commit(s) were added to refs/heads/8.5.x by this push:
 new 08018d3  Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63838
08018d3 is described below

commit 08018d32af89a49a508e744b6eabe26d854b75be
Author: Mark Thomas 
AuthorDate: Mon Oct 28 22:45:28 2019 +0100

Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63838

Add the same options used when Tomcat starts to suppress reflexive
access warnings when running unit tests from the command line.
---
 build.xml  | 18 ++
 webapps/docs/changelog.xml |  4 
 2 files changed, 22 insertions(+)

diff --git a/build.xml b/build.xml
index f8c7d62..ffe78f3 100644
--- a/build.xml
+++ b/build.xml
@@ -202,6 +202,19 @@
  value="-html5"/>
   
 
+  
+  
+  
+  
+  
+  
+
   
   
 
@@ -1517,6 +1530,11 @@
 
 
 
+
+
+
+
+
 
 
 
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 71c0077..9e6abdb 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -105,6 +105,10 @@
 Windows since compiled versions of those components are already
 included within the zip distriubutions. (markt)
   
+  
+63838: Suppress reflexive access warnings when running the
+unit tests on the command line. (markt)
+  
 
   
 


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

[Bug 63838] Illegal reflective access by WebappClassLoaderBase$1 in Java 13

2019-10-28 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=63838

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Mark Thomas  ---
Fixed in:
- master for 9.0.28 onwards
- 8.5.x for 8.5.48 onwards
- 7.0.x for 7.0.98 onwards

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

[tomcat] branch 7.0.x updated: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63838

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

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


The following commit(s) were added to refs/heads/7.0.x by this push:
 new a891580  Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63838
a891580 is described below

commit a891580b3354ba25a8a0326241c49ae32affc603
Author: Mark Thomas 
AuthorDate: Mon Oct 28 22:45:28 2019 +0100

Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63838

Add the same options used when Tomcat starts to suppress reflexive
access warnings when running unit tests from the command line.
---
 build.xml  | 18 ++
 webapps/docs/changelog.xml |  4 
 2 files changed, 22 insertions(+)

diff --git a/build.xml b/build.xml
index e421448..4b49a52 100644
--- a/build.xml
+++ b/build.xml
@@ -205,6 +205,19 @@
  value="-html5"/>
   
 
+  
+  
+  
+  
+  
+  
+
   
   
 
@@ -1521,6 +1534,11 @@
 
 
 
+
+
+
+
+
 
 
 
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index d459c50..b522a83 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -125,6 +125,10 @@
 a DataSource was configured with a database that did not exist. Patch
 provided by Guoxiong Li. (markt)
   
+  
+63838: Suppress reflexive access warnings when running the
+unit tests on the command line. (markt)
+  
 
   
 


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

[Bug 63852] ServerInfo.java discloses server-version ignoring settings from server.xml

2019-10-28 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=63852

--- Comment #14 from Mark Thomas  ---
I'm leaning towards resolving this as WONTFIX.

The server attribute defaults to null whereas ServerInfo (as used in the
ErrorReportValve and other places) defaults to "Apache Tomcat/".

I don't see any easy way to tie these settings together that doesn't
essentially change the default of one of them and that goes against what I
understand to be the current consensus opinion.

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

[GitHub] [tomcat] rmaucher commented on a change in pull request #218: WIP: BZ 63835: Add support for Keep-Alive header

2019-10-28 Thread GitBox 
rmaucher commented on a change in pull request #218: WIP: BZ 63835: Add support 
for Keep-Alive header
URL: https://github.com/apache/tomcat/pull/218#discussion_r339814604
 
 

 ##
 File path: java/org/apache/coyote/http11/Http11Processor.java
 ##
 @@ -915,8 +915,26 @@ protected final void prepareResponse() throws IOException 
{
 headers.addValue(Constants.CONNECTION).setString(
 Constants.CLOSE);
 }
-} else if (!http11 && !getErrorState().isError()) {
-
headers.addValue(Constants.CONNECTION).setString(Constants.KEEPALIVE);
+} else if (!getErrorState().isError()) {
+if (!http11) {
+
headers.addValue(Constants.CONNECTION).setString(Constants.KEEPALIVE);
+}
+
+boolean connectionKeepAlivePresent =
+isConnectionToken(request.getMimeHeaders(), 
Constants.KEEPALIVE);
+
+if (connectionKeepAlivePresent) {
+int keepAliveTimeout = protocol.getKeepAliveTimeout();
+
+if (keepAliveTimeout > 0) {
+String value = "timeout=" + keepAliveTimeout / 1000L;
+headers.setValue("Keep-Alive").setString(value);
+}
+
+if (http11) {
+
headers.addValue(Constants.CONNECTION).setString(Constants.KEEPALIVE);
 
 Review comment:
   As far as I am concerned, it's a weird compatibility thing for HTTP/1.0 
clients pretending to do HTTP/1.1.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

Re: RewriteMap parsing

2019-10-28 Thread Romain Manni-Bucau 
+1 for quotes

Can the "function" support be pluggable either with an explicit registry or
a SPI? Would be awesome to enrich it in "super tomcat" instances (thinking
to meecrowave, tomee and maybe spring boot).

Le lun. 28 oct. 2019 à 21:43, Mark Thomas  a écrit :

>
>
> On 27/10/2019 11:27, Felix Schumacher wrote:
> > Hi all,
> >
> > while looking at the RewriteMap configuration, I noticed, that parsing
> > of the RewriteMap directive is a bit minimal. Parameters are split at
> > whitespace (no quotes will be recognized) and only the first of the
> > optional parameters will be used.
> >
> > Should this be changed? If so, should we introduce quoting capabilities
> > to gather the "one" optional parameter, or allow multiple parameters?
> >
> > Version "quote":
> >
> > RewriteMap m1 example.MyMap "some params"
> >
> > Version "multiple"
> >
> > RewriteMap m2 example.OtherMap one two three
> >
> > Or should it be a combination?
>
> That is probably the most flexible option. I'd lean towards this option
> but would be happy to support the majority view if different.
>
> > "quote" would be sort of compatible with the current interface, as we
> > still have only one parameter. "multiple" would be a nicer interface for
> > the implementer of the map.
> >
> > Another thing I noticed, is that the httpd rewrite map feature has a few
> > builtin maps, that could be useful to supply with our implementation.
> > Any thoughts on supplying those? (I thought about the maps
> > int:[toupper,tolower,escape,unescape], txt:, rnd: and possibly a new one
> > called jdbc:{jndi-connection}:{sql statement with placeholder}. For
> > these elements a quote detection would be a must)
>
> I don't recall any requests for these on the users list but maybe that
> is because the feature isn't that well known.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

[Bug 63859] AJP cping/cpong mode failing on Tomcat 9.x

2019-10-28 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=63859

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #7 from Mark Thomas  ---
I know it is verbose but what we really need is the mod_jk debug log from when
this error occurs. Based on the information provided, that looks like the best
option for further investigation.

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

[Bug 63879] Unessesary log noise under DEBUG

2019-10-28 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=63879

--- Comment #9 from Steve Sanders  ---
(In reply to Christopher Schultz from comment #8)
> (In reply to Michael Bazos from comment #6)
> > I agree switching to TRACE is the best option. Also it might be helpful to
> > not throw new Exception()
> 
> Note that the exception is not thrown, only constructed. Yes, this requires
> the runtime to walk the the stack to produce the stack trace (Which is
> precisely why it's being done at all) but we don't incur the penalty of
> actually throwing the exception.
> 
> > this produces this message
> > "java.lang.Exception: null" If you are going to have this it might be best
> > to provide a message to let people know this is intended and testing.
> 
> +1 to adding a message e.g. new Exception("Intentional stack trace")

Good idea! I've updated my patch to use isTraceEnabled, and added the exception
message.

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

[Bug 63890] New: JDNI & JDBC Connection when using IPV4 going back to IPV6

2019-10-28 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=63890

Bug ID: 63890
   Summary: JDNI & JDBC Connection when using IPV4 going back to
IPV6
   Product: Tomcat 9
   Version: unspecified
  Hardware: PC
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: paul.hard...@polarspark.com
  Target Milestone: -

Apologize in advance my this is my first bug report.


When specifying a Tomcat Resource there is an error with IPV4 and IPV6
conflict. 

I tested this on 3 different Windows server 2016 Standard and got the same
result.

The deployed application needs IPV4 for IOT device connections. The resource
was a SQL Server 2016. I used the 4.2 driver with Java 8 AdoptOpen JDK 8_222
and also tried JDK 8_232. I also tried the 7.4 driver. The Windows servers in
question have IPV6 disabled and I also checked other settings like pinging DNS
names to verify that IPV4 was resolving.

I used the and -Djava.net.preferIPv4Addresses=true to ensure that the tomcat
was starting with an IPV4 forced preference. 

 


The error I get each time is the host cannot be resolved. Generally, I set
sqlserver=localhost but I tried with 127.0.0.1, servername01.company.com,
10.10.2.2 and all give the same error.

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

[Bug 63890] JDNI & JDBC Connection when using IPV4 going back to IPV6

2019-10-28 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=63890

Paul Harding  changed:

   What|Removed |Added

 OS||All

--- Comment #1 from Paul Harding  ---
Also note the error did not occur in v 8.5.40 but when I upgraded to 8.5.47 the
error started. The same error for 9.0.27. Tomorrow I am planning on downloading
each version inbetween to find out where this started failing and comparing
that with the change log. I will document my findings here.

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