[Bug 63898] JSP EL generation is wrong when using newer version of Java 1.8 & tag class uses method overloading and isELIgnored="false

2019-11-01 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=63898

Michael Osipov  changed:

   What|Removed |Added

 CC||micha...@apache.org

-- 
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 63875] Tomcat 8.5.46, APR/libtcnative crashes

2019-11-01 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=63875

--- Comment #15 from Remy Maucherat  ---
We got and read your latest comment with the additional testing.
However, pinging developers for updates is not acceptable behavior. Please
don't do this again.

-- 
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: RewriteMap parsing

2019-11-01 Thread Felix Schumacher 

Am 28.10.19 um 23:06 schrieb 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).

The function support is already pluggable (by the configuration file :),
but I thought about adding SPI.

It is unclear to me, how to determine the namespace ("int:" in the httpd
example), should it be given by the Service Provider? Would "int" be
reserved for our own functions? How could we achieve such a reservation
mechnism?

Felix

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

Re: RewriteMap parsing

2019-11-01 Thread Romain Manni-Bucau 
Through the spi IMHO and if it can be ambiguous use an ordinal or priority
to let it be overriden maybe?

Le ven. 1 nov. 2019 à 10:46, Felix Schumacher <
felix.schumac...@internetallee.de> a écrit :

>
> Am 28.10.19 um 23:06 schrieb 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).
>
> The function support is already pluggable (by the configuration file :),
> but I thought about adding SPI.
>
> It is unclear to me, how to determine the namespace ("int:" in the httpd
> example), should it be given by the Service Provider? Would "int" be
> reserved for our own functions? How could we achieve such a reservation
> mechnism?
>
> Felix
>
>
> 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
>>
>>

svn commit: r1869240 - in /tomcat/site/trunk: docs/presentations.html xdocs/presentations.xml

2019-11-01 Thread fschumacher 
Author: fschumacher
Date: Fri Nov  1 10:14:59 2019
New Revision: 1869240

URL: http://svn.apache.org/viewvc?rev=1869240&view=rev
Log:
Added presentations from ApacheCon Europe 2019

Modified:
tomcat/site/trunk/docs/presentations.html
tomcat/site/trunk/xdocs/presentations.xml

Modified: tomcat/site/trunk/docs/presentations.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/presentations.html?rev=1869240&r1=1869239&r2=1869240&view=diff
==
--- tomcat/site/trunk/docs/presentations.html (original)
+++ tomcat/site/trunk/docs/presentations.html Fri Nov  1 10:14:59 2019
@@ -1,268 +1,265 @@
 
 
-
-
-
-
-
-Apache Tomcat® - Presentations
-
-
-
-
-
-
-
-
-http://tomcat.apache.org/";>
-
-Apache Tomcat®
-
-
-https://www.apache.org/foundation/contributing.html"; target="_blank" 
class="pull-left">https://www.apache.org/images/SupportApache-small.png"; class="support-asf" 
alt="Support Apache">http://www.apache.org/"; target="_blank" 
class="pull-left">
-
-
-
-
-
-
-
-https://www.google.com/search"; 
method="get">
-
-GO
-
-
-
-https://www.apache.org/events/current-event.html";>https://www.apache.org/events/current-event-234x60.png"; alt="Next ASF 
event">
-
-  Save the date!
+
+
+
+
+
+Apache Tomcat® - Presentations
+
+
+
+
+
+
+
+
+http://tomcat.apache.org/";>
+Apache Tomcat®
+
+
+https://www.apache.org/foundation/contributing.html"; target="_blank" 
class="pull-left">https://www.apache.org/images/SupportApache-small.png"; class="support-asf" 
alt="Support Apache">http://www.apache.org/"; target="_blank" 
class="pull-left">
+
+
+
+
+
+
+
+https://www.google.com/search"; method="get">
+
+GO
+
+
+
+https://www.apache.org/events/current-event.html";>https://www.apache.org/events/current-event-234x60.png"; alt="Next ASF 
event">
+  Save the date!
 
-
-
-
-Apache Tomcat
-
-
-Home
-
-
-Taglibs
-
-
-Maven Plugin
-
-
-
-
-Download
-
-
-Which version?
-
-
-https://tomcat.apache.org/download-90.cgi";>Tomcat 9
-
-
-https://tomcat.apache.org/download-80.cgi";>Tomcat 8
-
-
-https://tomcat.apache.org/download-70.cgi";>Tomcat 7
-
-
-https://tomcat.apache.org/download-connectors.cgi";>Tomcat Connectors
-
-
-https://tomcat.apache.org/download-native.cgi";>Tomcat Native
-
-
-https://tomcat.apache.org/download-taglibs.cgi";>Taglibs
-
-
-https://archive.apache.org/dist/tomcat/";>Archives
-
-
-
-
-Documentation
-

Re: RewriteMap parsing

2019-11-01 Thread Felix Schumacher 

Am 01.11.19 um 11:11 schrieb Romain Manni-Bucau:
> Through the spi IMHO and if it can be ambiguous use an ordinal or
> priority to let it be overriden maybe?

Do we want users to be able to overwrite our functions? Is the "int:"
namespace free for everyone?

Should we break the context startup in case of duplicate functions in
the registry?

Felix

>
> Le ven. 1 nov. 2019 à 10:46, Felix Schumacher
>  > a écrit :
>
>
> Am 28.10.19 um 23:06 schrieb 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).
>
> The function support is already pluggable (by the configuration
> file :), but I thought about adding SPI.
>
> It is unclear to me, how to determine the namespace ("int:" in the
> httpd example), should it be given by the Service Provider? Would
> "int" be reserved for our own functions? How could we achieve such
> a reservation mechnism?
>
> Felix
>
>>
>> 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
>> 
>>

[GitHub] [tomcat-training] dependabot[bot] opened a new pull request #2: Bump extend from 3.0.1 to 3.0.2

2019-11-01 Thread GitBox 
dependabot[bot] opened a new pull request #2: Bump extend from 3.0.1 to 3.0.2
URL: https://github.com/apache/tomcat-training/pull/2
 
 
   Bumps [extend](https://github.com/justmoon/node-extend) from 3.0.1 to 3.0.2.
   
   Changelog
   
   *Sourced from [extend's 
changelog](https://github.com/justmoon/node-extend/blob/master/CHANGELOG.md).*
   
   > 3.0.2 / 2018-07-19
   > ==
   >   * [Fix] Prevent merging `__proto__` property 
([#48](https://github-redirect.dependabot.com/justmoon/node-extend/issues/48))
   >   * [Dev Deps] update `eslint`, `@ljharb/eslint-config`, `tape`
   >   * [Tests] up to `node` `v10.7`, `v9.11`, `v8.11`, `v7.10`, `v6.14`, 
`v4.9`; use `nvm install-latest-npm`
   
   
   Commits
   
   - 
[`8d106d2`](https://github.com/justmoon/node-extend/commit/8d106d23931c0802e8b88188b0aac433e13358d9)
 v3.0.2
   - 
[`e97091f`](https://github.com/justmoon/node-extend/commit/e97091fa7557e106042e475ef59e654fa9d2c7ab)
 [Dev Deps] update `tape`
   - 
[`e841aac`](https://github.com/justmoon/node-extend/commit/e841aac7ce7119606345b440b0a9e7668e848985)
 [Tests] up to `node` `v10.7`
   - 
[`0e68e71`](https://github.com/justmoon/node-extend/commit/0e68e71d93507fcc391e398bc84abd0666b28190)
 [Fix] Prevent merging __proto__ property
   - 
[`a689700`](https://github.com/justmoon/node-extend/commit/a689700740b44846e76f8f1dc4bdf230a2cb5c0d)
 Only apps should have lockfiles
   - 
[`f13c1c4`](https://github.com/justmoon/node-extend/commit/f13c1c4e51c47b90604eb2dc56cc60561e497d36)
 [Dev Deps] update `eslint`, `@ljharb/eslint-config`, `tape`
   - 
[`f3570fe`](https://github.com/justmoon/node-extend/commit/f3570fe5582dbfba47e60c0cd75b4fb6f01cd3fe)
 [Tests] up to `node` `v10.0`, `v9.11`, `v8.11`, `v7.10`, `v6.14`, `v4.9`; 
use...
   - See full diff in [compare 
view](https://github.com/justmoon/node-extend/compare/v3.0.1...v3.0.2)
   
   
   
   [![Dependabot compatibility 
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=extend&package-manager=npm_and_yarn&previous-version=3.0.1&new-version=3.0.2)](https://help.github.com/articles/configuring-automated-security-fixes)
   
   Dependabot will resolve any conflicts with this PR as long as you don't 
alter it yourself. You can also trigger a rebase manually by commenting 
`@dependabot rebase`.
   
   [//]: # (dependabot-automerge-start)
   [//]: # (dependabot-automerge-end)
   
   ---
   
   
   Dependabot commands and options
   
   
   You can trigger Dependabot actions by commenting on this PR:
   - `@dependabot rebase` will rebase this PR
   - `@dependabot recreate` will recreate this PR, overwriting any edits that 
have been made to it
   - `@dependabot merge` will merge this PR after your CI passes on it
   - `@dependabot squash and merge` will squash and merge this PR after your CI 
passes on it
   - `@dependabot cancel merge` will cancel a previously requested merge and 
block automerging
   - `@dependabot reopen` will reopen this PR if it is closed
   - `@dependabot ignore this [patch|minor|major] version` will close this PR 
and stop Dependabot creating any more for this minor/major version (unless you 
reopen the PR or upgrade to it yourself)
   - `@dependabot ignore this dependency` will close this PR and stop 
Dependabot creating any more for this dependency (unless you reopen the PR or 
upgrade to it yourself)
   - `@dependabot use these labels` will set the current labels as the default 
for future PRs for this repo and language
   - `@dependabot use these reviewers` will set the current reviewers as the 
default for future PRs for this repo and language
   - `@dependabot use these assignees` will set the current assignees as the 
default for future PRs for this repo and language
   - `@dependabot use this milestone` will set the current milestone as the 
default for future PRs for this repo and language
   
   You can disable automated security fix PRs for this repo from the [Security 
Alerts page](https://github.com/apache/tomcat-training/network/alerts).
   
   


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-training] branch dependabot/npm_and_yarn/extend-3.0.2 created (now 32fb224)

2019-11-01 Thread github-bot 
This is an automated email from the ASF dual-hosted git repository.

github-bot pushed a change to branch dependabot/npm_and_yarn/extend-3.0.2
in repository https://gitbox.apache.org/repos/asf/tomcat-training.git.


  at 32fb224  Bump extend from 3.0.1 to 3.0.2

No new revisions were added by this update.


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

[Bug 63897] Jasper doesn't reload a JSP if it was modified while being compiled

2019-11-01 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=63897

Christopher Schultz  changed:

   What|Removed |Added

   Keywords||PatchAvailable

--- Comment #1 from Christopher Schultz  ---
Many thanks for your analysis and your patch.

Based solely upon the description and not having read the code, I tend to agree
that the timestamp used for comparison against the source JSP needs to be the
timestamp of the source JSP as it was being initially read for compilation.

I think the only place that is stored is in the timestamp of the generated
.java/.class files themselves, and there is not any other repository of that
metadata. Some filesystems (any modern ones?) don't have great time-resolution
and that may also be a contributing factor.

As this is a bit of an edge case -- nobody should be modifying JSP files at
high-frequency in production -- I don't think it makes sense to consider any
separate repository of such metadata.

(I can say for sure that I've had timing issues with Tomcat for years that are
similar to this -- usually with regard to reloading the whole container -- and
I wonder if this bug is representative of a class of problems like this.)

This patch LGTM, but I want to let others weigh-in just in case there is some
specific reasoning behind the timing of the file-timestamp-capture.

-- 
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: RewriteMap parsing

2019-11-01 Thread Romain Manni-Bucau 
Le ven. 1 nov. 2019 à 11:26, Felix Schumacher <
felix.schumac...@internetallee.de> a écrit :

>
> Am 01.11.19 um 11:11 schrieb Romain Manni-Bucau:
>
> Through the spi IMHO and if it can be ambiguous use an ordinal or priority
> to let it be overriden maybe?
>
> Do we want users to be able to overwrite our functions? Is the "int:"
> namespace free for everyone?
>
I think so, like enabling to enrich it (often implemented as a delegation)



Should we break the context startup in case of duplicate functions in the
> registry?
>

If they have the same priority I think so.


Felix
>
>
> Le ven. 1 nov. 2019 à 10:46, Felix Schumacher <
> felix.schumac...@internetallee.de> a écrit :
>
>>
>> Am 28.10.19 um 23:06 schrieb 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).
>>
>> The function support is already pluggable (by the configuration file :),
>> but I thought about adding SPI.
>>
>> It is unclear to me, how to determine the namespace ("int:" in the httpd
>> example), should it be given by the Service Provider? Would "int" be
>> reserved for our own functions? How could we achieve such a reservation
>> mechnism?
>>
>> Felix
>>
>>
>> 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
>>>
>>>

[GitHub] [tomcat] FSchumacher opened a new pull request #221: RewriteMap with quoted parameters and ServiceLoader support

2019-11-01 Thread GitBox 
FSchumacher opened a new pull request #221: RewriteMap with quoted parameters 
and ServiceLoader support
URL: https://github.com/apache/tomcat/pull/221
 
 
   This PR combines two things:
   * Allows quoted parameters for `RewriteValve` config and adds a new default 
method to `RewriteMap` to allow for more than one parameter
   * Uses a `ServiceLoader` to make implementations of `RewriteMap` available 
in the httpd rewrite module style a-la `int:toupper`.
   
   It is missing a lot of documentation and a few test cases.


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-11-01 Thread Felix Schumacher 

Am 01.11.19 um 14:24 schrieb Romain Manni-Bucau:
>
>
> Le ven. 1 nov. 2019 à 11:26, Felix Schumacher
>  > a écrit :
>
>
> Am 01.11.19 um 11:11 schrieb Romain Manni-Bucau:
>> Through the spi IMHO and if it can be ambiguous use an ordinal or
>> priority to let it be overriden maybe?
>
> Do we want users to be able to overwrite our functions? Is the
> "int:" namespace free for everyone?
>
> I think so, like enabling to enrich it (often implemented as a delegation)
>
>
>
> Should we break the context startup in case of duplicate functions
> in the registry?
>
>
> If they have the same priority I think so.


I have submitted a PR that tries to implement the discussed features:
https://github.com/apache/tomcat/pull/221

Felix

>
>
> Felix
>
>>
>> Le ven. 1 nov. 2019 à 10:46, Felix Schumacher
>> > > a écrit :
>>
>>
>> Am 28.10.19 um 23:06 schrieb 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).
>>
>> The function support is already pluggable (by the
>> configuration file :), but I thought about adding SPI.
>>
>> It is unclear to me, how to determine the namespace ("int:"
>> in the httpd example), should it be given by the Service
>> Provider? Would "int" be reserved for our own functions? How
>> could we achieve such a reservation mechnism?
>>
>> Felix
>>
>>>
>>> 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
>>> 
>>>

[GitHub] [tomcat] rmaucher commented on issue #221: RewriteMap with quoted parameters and ServiceLoader support

2019-11-01 Thread GitBox 
rmaucher commented on issue #221: RewriteMap with quoted parameters and 
ServiceLoader support
URL: https://github.com/apache/tomcat/pull/221#issuecomment-548880968
 
 
   This looks a bit overengineered, personally I am surprised to see the 
service loader being used for such a small feature [I added that map support 
because the original rewrite had it, and nobody ever cared]. We don't use the 
service loader functionality in Tomcat.


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-11-01 Thread Romain Manni-Bucau 
Hi Felix

Overall it looks good but I'd do two minor changes:

1. Only lookup providers once per context (ServiceLoader result being
cached per parser instance)
2. Likely lazy load the parsing after context startup to ensure ioc can be
used (spring web or cdi lookups)

Hope it makes sense

Le ven. 1 nov. 2019 à 18:31, Felix Schumacher <
felix.schumac...@internetallee.de> a écrit :

>
> Am 01.11.19 um 14:24 schrieb Romain Manni-Bucau:
>
>
>
> Le ven. 1 nov. 2019 à 11:26, Felix Schumacher <
> felix.schumac...@internetallee.de> a écrit :
>
>>
>> Am 01.11.19 um 11:11 schrieb Romain Manni-Bucau:
>>
>> Through the spi IMHO and if it can be ambiguous use an ordinal or
>> priority to let it be overriden maybe?
>>
>> Do we want users to be able to overwrite our functions? Is the "int:"
>> namespace free for everyone?
>>
> I think so, like enabling to enrich it (often implemented as a delegation)
>
>
>
> Should we break the context startup in case of duplicate functions in the
>> registry?
>>
>
> If they have the same priority I think so.
>
>
> I have submitted a PR that tries to implement the discussed features:
> https://github.com/apache/tomcat/pull/221
>
> Felix
>
>
>
> Felix
>>
>>
>> Le ven. 1 nov. 2019 à 10:46, Felix Schumacher <
>> felix.schumac...@internetallee.de> a écrit :
>>
>>>
>>> Am 28.10.19 um 23:06 schrieb 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).
>>>
>>> The function support is already pluggable (by the configuration file :),
>>> but I thought about adding SPI.
>>>
>>> It is unclear to me, how to determine the namespace ("int:" in the httpd
>>> example), should it be given by the Service Provider? Would "int" be
>>> reserved for our own functions? How could we achieve such a reservation
>>> mechnism?
>>>
>>> Felix
>>>
>>>
>>> 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 63897] Jasper doesn't recompile a JSP if it was modified while being compiled

2019-11-01 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=63897

Karl von Randow  changed:

   What|Removed |Added

Summary|Jasper doesn't reload a JSP |Jasper doesn't recompile a
   |if it was modified while|JSP if it was modified
   |being compiled  |while being compiled

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