[Bug 56890] getRealPath returns null

[bugzilla]

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

Mark Thomas  changed:

   What|Removed |Added

 CC|e.barg0...@icloud.com   |
 Status|NEW |NEEDINFO

-- 
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 64129] mod_webapp errors in Win2k

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=64129
Bug 64129 depends on bug 64127, which changed state.

Bug 64127 Summary: mod_webapp errors in Win2k
https://bz.apache.org/bugzilla/show_bug.cgi?id=64127

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

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

[Bug 64127] mod_webapp errors in Win2k

[bugzilla]

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

Mark Thomas  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 OS||All
 Status|NEW |RESOLVED

--- Comment #1 from Mark Thomas  ---
Spammer

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

[Bug 64129] mod_webapp errors in Win2k

[bugzilla]

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

Mark Thomas  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #1 from Mark Thomas  ---
Spammer

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

Re: [VOTE] Release Apache Tomcat 10.0.0.0-M1

[Mark Thomas]

On 05/02/2020 19:22, Mark Thomas wrote:



> The proposed 10.0.0.0-M1 release is:
> [ ] Broken - do not release
> [X] Alpha  - go ahead and release as 10.0.0.0-M1

Unit tests pass for NIO, NIO2 and APR/native on Windows, Linux and OSX.

Mark

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

Re: [VOTE] Release Apache Tomcat 9.0.31

[Mark Thomas]

On 05/02/2020 21:27, Mark Thomas wrote:



> The proposed 9.0.31 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 9.0.31

Unit tests pass for NIO, NIO2 and APR/native on Windows, Linux and OSX.

Mark


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

Re: [VOTE] Release Apache Tomcat 8.5.51

[Mark Thomas]

On 05/02/2020 22:49, Mark Thomas wrote:



> The proposed 8.5.51 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 8.5.51

Unit tests pass for NIO, NIO2 and APR/native on Windows, Linux and OSX.

Mark

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

Numbering schemes for future releases

[Mark Thomas]

Hi,

I thought it would be useful to re-open the discussion on this. If there
is a better plan that the one we currently have I'd like to try and find it.

I'm happy to hold off on the current 10.0.0.0-M1 release for a few days
to give us time look for a better numbering scheme and so we have the
opportunity to pull the 10.0.0.0-M1 release if necessary.

I have tried to express the various options I have seen proposed in a
similar way so we can compare them. If I have missed one or you think of
a different one then please post it.

Option A: The current plan:
Jakarta EE 9:  10.0.0.x
Jakarta EE 10: 10.0.x   (x>=1)
Jakarta EE 11: 11.0.x
Java EE 8: 9.y.x(where y == major Tomcat version)


Option B: Continue with existing numbering
Jakarta EE 9:  10.0.x
Jakarta EE 10: 11.0.x
Jakarta EE 11: 12.0.x
Java EE 8: 9.y.x(where y == major Tomcat version)


Option C: No stable Jakarta EE 9 release
Jakarta EE 9:  10.0.0-Mx
Jakarta EE 10: 10.0.x
Jakarta EE 11: 11.0.x
Java EE 8: 9.y.x(where y == major Tomcat version)


Option D:
Jakarta EE 9:  10.0.x
Jakarta EE 10: 10.1.x
Jakarta EE 11: 11.0.x
Java EE 8: 9.y.x(where y == major Tomcat version)


My own thoughts:

I don't like option B because the off-by-one issue between Jakarta EE
and Tomcat. It is manageable at the moment but I worry that it will
cause confusion once we have the 9.y.x branch.

I don't like option C because I think we need a stable, supported,
passing the TCK Jakarta EE 9 release. Also, Jakarta EE 10 is meant to
follow shortly after Jakarta EE 9 but what if it doesn't?

For me, the choice is between A and D. If Jakarta EE 10 is very soon
after Jakarta EE 9 then I think option A is better. However, D isn't
that far behind and as soon as Jakarta EE 10 doesn't follow shortly
after Jakarta EE 9 I think D begins to look better. As I think about it,
the EOL decision we make for Jakarta EE 9 support depends a lot on how
quickly Jakarta EE 10 follows and I think D gives us more flexibility.
Finally, D is more consistent with how we have done things in the past
(4.1.x, 5.5.x, 8.5.x etc)

Thoughts?

Mark

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

Re: Numbering schemes for future releases

[Rémy Maucherat]

On Mon, Feb 10, 2020 at 10:47 AM Mark Thomas  wrote:

> Hi,
>
> I thought it would be useful to re-open the discussion on this. If there
> is a better plan that the one we currently have I'd like to try and find
> it.
>
> I'm happy to hold off on the current 10.0.0.0-M1 release for a few days
> to give us time look for a better numbering scheme and so we have the
> opportunity to pull the 10.0.0.0-M1 release if necessary.
>
> I have tried to express the various options I have seen proposed in a
> similar way so we can compare them. If I have missed one or you think of
> a different one then please post it.
>
> Option A: The current plan:
> Jakarta EE 9:  10.0.0.x
> Jakarta EE 10: 10.0.x   (x>=1)
> Jakarta EE 11: 11.0.x
> Java EE 8: 9.y.x(where y == major Tomcat version)
>
>
> Option B: Continue with existing numbering
> Jakarta EE 9:  10.0.x
> Jakarta EE 10: 11.0.x
> Jakarta EE 11: 12.0.x
> Java EE 8: 9.y.x(where y == major Tomcat version)
>
>
> Option C: No stable Jakarta EE 9 release
> Jakarta EE 9:  10.0.0-Mx
> Jakarta EE 10: 10.0.x
> Jakarta EE 11: 11.0.x
> Java EE 8: 9.y.x(where y == major Tomcat version)
>
>
> Option D:
> Jakarta EE 9:  10.0.x
> Jakarta EE 10: 10.1.x
> Jakarta EE 11: 11.0.x
> Java EE 8: 9.y.x(where y == major Tomcat version)
>
>
> My own thoughts:
>
> I don't like option B because the off-by-one issue between Jakarta EE
> and Tomcat. It is manageable at the moment but I worry that it will
> cause confusion once we have the 9.y.x branch.
>

-1 for option B also because the EOL of that "major" Tomcat 10 branch may
be way too quick for a major branch.


>
> I don't like option C because I think we need a stable, supported,
> passing the TCK Jakarta EE 9 release. Also, Jakarta EE 10 is meant to
> follow shortly after Jakarta EE 9 but what if it doesn't?
>
> For me, the choice is between A and D. If Jakarta EE 10 is very soon
> after Jakarta EE 9 then I think option A is better. However, D isn't
> that far behind and as soon as Jakarta EE 10 doesn't follow shortly
> after Jakarta EE 9 I think D begins to look better. As I think about it,
> the EOL decision we make for Jakarta EE 9 support depends a lot on how
> quickly Jakarta EE 10 follows and I think D gives us more flexibility.
> Finally, D is more consistent with how we have done things in the past
> (4.1.x, 5.5.x, 8.5.x etc)
>

D looks good to me for the flexibility. I suppose/hope/would think the
people at Eclipse will want to provide something useful sooner rather than
later, so A seemed acceptable to me, but you never know. You know, three
years later, you could find yourself still releasing 10.0.0.26. Ooops.
10.0.26 would look better, if that unfortunate scenario happens.
The 10.0 branch does imply some amount of support though, so it likely
won't be possible to phase it out as fast as in Option A or C. It's not
nearly as bad as B of course.

C would look the best to me if there was a guarantee on the EE 10 release
schedule being quick. Thinking about it again today, I think that's a huge
unreasonable risk.

Rémy


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

Tag Tomcat 7

[Violeta Georgieva]

Hi,

I'm going to prepare Tomcat 7 for a release/vote tomorrow.
Please reply here if you need more time for additional fixes.

Thanks,
Violeta

Re: Numbering schemes for future releases

[Martin Grigorov]

Hi,

On Mon, Feb 10, 2020 at 11:47 AM Mark Thomas  wrote:

> Hi,
>
> I thought it would be useful to re-open the discussion on this. If there
> is a better plan that the one we currently have I'd like to try and find
> it.
>
> I'm happy to hold off on the current 10.0.0.0-M1 release for a few days
> to give us time look for a better numbering scheme and so we have the
> opportunity to pull the 10.0.0.0-M1 release if necessary.
>
> I have tried to express the various options I have seen proposed in a
> similar way so we can compare them. If I have missed one or you think of
> a different one then please post it.
>
> Option A: The current plan:
> Jakarta EE 9:  10.0.0.x
> Jakarta EE 10: 10.0.x   (x>=1)
> Jakarta EE 11: 11.0.x
> Java EE 8: 9.y.x(where y == major Tomcat version)
>
>
> Option B: Continue with existing numbering
> Jakarta EE 9:  10.0.x
> Jakarta EE 10: 11.0.x
> Jakarta EE 11: 12.0.x
> Java EE 8: 9.y.x(where y == major Tomcat version)
>
>
> Option C: No stable Jakarta EE 9 release
> Jakarta EE 9:  10.0.0-Mx
> Jakarta EE 10: 10.0.x
> Jakarta EE 11: 11.0.x
> Java EE 8: 9.y.x(where y == major Tomcat version)
>
>
> Option D:
> Jakarta EE 9:  10.0.x
> Jakarta EE 10: 10.1.x
> Jakarta EE 11: 11.0.x
> Java EE 8: 9.y.x(where y == major Tomcat version)
>
>
> My own thoughts:
>
> I don't like option B because the off-by-one issue between Jakarta EE
> and Tomcat. It is manageable at the moment but I worry that it will
> cause confusion once we have the 9.y.x branch.
>
> I don't like option C because I think we need a stable, supported,
> passing the TCK Jakarta EE 9 release. Also, Jakarta EE 10 is meant to
> follow shortly after Jakarta EE 9 but what if it doesn't?
>
> For me, the choice is between A and D. If Jakarta EE 10 is very soon
> after Jakarta EE 9 then I think option A is better. However, D isn't
> that far behind and as soon as Jakarta EE 10 doesn't follow shortly
> after Jakarta EE 9 I think D begins to look better. As I think about it,
> the EOL decision we make for Jakarta EE 9 support depends a lot on how
> quickly Jakarta EE 10 follows and I think D gives us more flexibility.
> Finally, D is more consistent with how we have done things in the past
> (4.1.x, 5.5.x, 8.5.x etc)
>
> Thoughts?
>

>From the above I like option C.
It the release of Jakarta EE 10 is delayed for some reason we can switch to
option D.

One more option:
Option E:
Jakarta EE 9:  9.99.x (or 9.999.x)
Jakarta EE 10: 10.0.x
Jakarta EE 11: 11.0.x
Java EE 8: 9.y.x(where y == major Tomcat version)

It is a bit ugly but some projects have used such version scheme to
emphasize that it is a transitional release.

Martin


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

JDK 14 is now in the Release Candidate Phase

[Rory O'Donnell]

 Hi Mark,

*Per the JDK 14 schedule [1]  , we are now in the Release Candidate Phase
*

The stabilization repository, jdk/jdk14, *is open for P1 bug fixes * per 
the JDK Release Process (JEP 3) [2].

All changes require approval via the Fix-Request Process [3].
For more details, see Mark Reinhold's email to jdk-dev mailing list [4]

OpenJDK 14 EA build 36 is now available at http://jdk.java.net/14

 * These early access, open source builds are provided under the GNU
   General Public License, version 2, with the Classpath Exception
   .

OpenJDK 15 EA build 9 is now available at http://jdk.java.net/15 *
*

 * These early access, open source builds are provided under the GNU
   General Public License, version 2, with the Classpath Exception
   .
 * Significant changes since the last availability email:
 o build 8
 + JDK-8235783: DatagramSocket::disconnect should allow an
   implementation to throw UncheckedIOException
 + JDK-8237528: Inefficient compilation of Pattern Matching for
   instanceof
 # Reported by JaCoCo.
 o build 7
 + JDK-8236105: DatagramSocket.send() and
   MulticastSocket.send() methods throw an
   IllegalArgumentException
 + JDK-8231422: Better serial filter handling
 + JDK-8227758: More valid PKIX processing
 + JDK-8230318: Better trust store usage
 + JDK-8234484: Add ability to configure third port for remote JMX

Project Loom Early-Access Builds - Build 15-loom+3-20 (2020/1/27)

 * These early-access builds are provided under the GNU General Public
   License, version 2, with the Classpath Exception
   .
 * These builds are intended for developers looking to "kick the tyres"
   and provide feedback on using the API or by sending bug reports.
   Warning: This build is based on an incomplete version of JDK 14
   .

Links to FOSDEM Videos that might be of interest:

 * https://twitter.com/OpenJDK/status/1225008387009785857
 * https://twitter.com/OpenJDK/status/1225011154159833088
 * https://twitter.com/OpenJDK/status/1225009792596488193

Regards,
Rory

[1] https://openjdk.java.net/projects/jdk/14/#Schedule
[2] https://openjdk.java.net/jeps/3
[3] https://openjdk.java.net/jeps/3#Fix-Request-Process
[4] 
https://mail.openjdk.java.net/pipermail/jdk-dev/2020-February/003885.html


--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland

Re: Numbering schemes for future releases

[Rémy Maucherat]

On Mon, Feb 10, 2020 at 12:05 PM Martin Grigorov 
wrote:

> Hi,
>
> On Mon, Feb 10, 2020 at 11:47 AM Mark Thomas  wrote:
>
>> Hi,
>>
>> I thought it would be useful to re-open the discussion on this. If there
>> is a better plan that the one we currently have I'd like to try and find
>> it.
>>
>> I'm happy to hold off on the current 10.0.0.0-M1 release for a few days
>> to give us time look for a better numbering scheme and so we have the
>> opportunity to pull the 10.0.0.0-M1 release if necessary.
>>
>> I have tried to express the various options I have seen proposed in a
>> similar way so we can compare them. If I have missed one or you think of
>> a different one then please post it.
>>
>> Option A: The current plan:
>> Jakarta EE 9:  10.0.0.x
>> Jakarta EE 10: 10.0.x   (x>=1)
>> Jakarta EE 11: 11.0.x
>> Java EE 8: 9.y.x(where y == major Tomcat version)
>>
>>
>> Option B: Continue with existing numbering
>> Jakarta EE 9:  10.0.x
>> Jakarta EE 10: 11.0.x
>> Jakarta EE 11: 12.0.x
>> Java EE 8: 9.y.x(where y == major Tomcat version)
>>
>>
>> Option C: No stable Jakarta EE 9 release
>> Jakarta EE 9:  10.0.0-Mx
>> Jakarta EE 10: 10.0.x
>> Jakarta EE 11: 11.0.x
>> Java EE 8: 9.y.x(where y == major Tomcat version)
>>
>>
>> Option D:
>> Jakarta EE 9:  10.0.x
>> Jakarta EE 10: 10.1.x
>> Jakarta EE 11: 11.0.x
>> Java EE 8: 9.y.x(where y == major Tomcat version)
>>
>>
>> My own thoughts:
>>
>> I don't like option B because the off-by-one issue between Jakarta EE
>> and Tomcat. It is manageable at the moment but I worry that it will
>> cause confusion once we have the 9.y.x branch.
>>
>> I don't like option C because I think we need a stable, supported,
>> passing the TCK Jakarta EE 9 release. Also, Jakarta EE 10 is meant to
>> follow shortly after Jakarta EE 9 but what if it doesn't?
>>
>> For me, the choice is between A and D. If Jakarta EE 10 is very soon
>> after Jakarta EE 9 then I think option A is better. However, D isn't
>> that far behind and as soon as Jakarta EE 10 doesn't follow shortly
>> after Jakarta EE 9 I think D begins to look better. As I think about it,
>> the EOL decision we make for Jakarta EE 9 support depends a lot on how
>> quickly Jakarta EE 10 follows and I think D gives us more flexibility.
>> Finally, D is more consistent with how we have done things in the past
>> (4.1.x, 5.5.x, 8.5.x etc)
>>
>> Thoughts?
>>
>
> From the above I like option C.
> It the release of Jakarta EE 10 is delayed for some reason we can switch
> to option D.
>
> One more option:
> Option E:
> Jakarta EE 9:  9.99.x (or 9.999.x)
> Jakarta EE 10: 10.0.x
> Jakarta EE 11: 11.0.x
> Java EE 8: 9.y.x(where y == major Tomcat version)
>
> It is a bit ugly but some projects have used such version scheme to
> emphasize that it is a transitional release.
>

Well, this won't work as the plan for the 9 branch [the last branch on
javax] is to track the API changes from the last major branches using minor
branches. So 9.10 [tracking the EE 10 branch], then 9.11, then 9.12, and so
on but still based on Java EE 8. This is an attempt to extend the support
period of the 9 branch even further and keep Tomcat 9 relevant with the new
features from the main most recent branch. So you could propose 9.9,
possibly, but 9.99 or 9.999 or other random number doesn't fit. Then, the
most important problem is that the 9 branch means Java EE 8 support, and
you would be polluting it with a Jakarta EE release.
So unfortunately that option E doesn't work at all, despite its apparent
similarity with option D.

Rémy

Re: Numbering schemes for future releases

[Martin Grigorov]

On Mon, Feb 10, 2020 at 1:56 PM Rémy Maucherat  wrote:

> On Mon, Feb 10, 2020 at 12:05 PM Martin Grigorov 
> wrote:
>
>> Hi,
>>
>> On Mon, Feb 10, 2020 at 11:47 AM Mark Thomas  wrote:
>>
>>> Hi,
>>>
>>> I thought it would be useful to re-open the discussion on this. If there
>>> is a better plan that the one we currently have I'd like to try and find
>>> it.
>>>
>>> I'm happy to hold off on the current 10.0.0.0-M1 release for a few days
>>> to give us time look for a better numbering scheme and so we have the
>>> opportunity to pull the 10.0.0.0-M1 release if necessary.
>>>
>>> I have tried to express the various options I have seen proposed in a
>>> similar way so we can compare them. If I have missed one or you think of
>>> a different one then please post it.
>>>
>>> Option A: The current plan:
>>> Jakarta EE 9:  10.0.0.x
>>> Jakarta EE 10: 10.0.x   (x>=1)
>>> Jakarta EE 11: 11.0.x
>>> Java EE 8: 9.y.x(where y == major Tomcat version)
>>>
>>>
>>> Option B: Continue with existing numbering
>>> Jakarta EE 9:  10.0.x
>>> Jakarta EE 10: 11.0.x
>>> Jakarta EE 11: 12.0.x
>>> Java EE 8: 9.y.x(where y == major Tomcat version)
>>>
>>>
>>> Option C: No stable Jakarta EE 9 release
>>> Jakarta EE 9:  10.0.0-Mx
>>> Jakarta EE 10: 10.0.x
>>> Jakarta EE 11: 11.0.x
>>> Java EE 8: 9.y.x(where y == major Tomcat version)
>>>
>>>
>>> Option D:
>>> Jakarta EE 9:  10.0.x
>>> Jakarta EE 10: 10.1.x
>>> Jakarta EE 11: 11.0.x
>>> Java EE 8: 9.y.x(where y == major Tomcat version)
>>>
>>>
>>> My own thoughts:
>>>
>>> I don't like option B because the off-by-one issue between Jakarta EE
>>> and Tomcat. It is manageable at the moment but I worry that it will
>>> cause confusion once we have the 9.y.x branch.
>>>
>>> I don't like option C because I think we need a stable, supported,
>>> passing the TCK Jakarta EE 9 release. Also, Jakarta EE 10 is meant to
>>> follow shortly after Jakarta EE 9 but what if it doesn't?
>>>
>>> For me, the choice is between A and D. If Jakarta EE 10 is very soon
>>> after Jakarta EE 9 then I think option A is better. However, D isn't
>>> that far behind and as soon as Jakarta EE 10 doesn't follow shortly
>>> after Jakarta EE 9 I think D begins to look better. As I think about it,
>>> the EOL decision we make for Jakarta EE 9 support depends a lot on how
>>> quickly Jakarta EE 10 follows and I think D gives us more flexibility.
>>> Finally, D is more consistent with how we have done things in the past
>>> (4.1.x, 5.5.x, 8.5.x etc)
>>>
>>> Thoughts?
>>>
>>
>> From the above I like option C.
>> It the release of Jakarta EE 10 is delayed for some reason we can switch
>> to option D.
>>
>> One more option:
>> Option E:
>> Jakarta EE 9:  9.99.x (or 9.999.x)
>> Jakarta EE 10: 10.0.x
>> Jakarta EE 11: 11.0.x
>> Java EE 8: 9.y.x(where y == major Tomcat version)
>>
>> It is a bit ugly but some projects have used such version scheme to
>> emphasize that it is a transitional release.
>>
>
>
Indeed it is getting complicated to understand the versions here.


> Well, this won't work as the plan for the 9 branch [the last branch on
> javax] is to track the API changes from the last major branches using minor
> branches. So 9.10 [tracking the EE 10 branch], then 9.11, then 9.12, and so
> on but still based on
>

What do you mean with "So 9.10 [tracking the EE 10 branch]," What is EE 10
here ? Javax or Jakarta ?
Since Oracle won't lead EE anymore then it should be Jakarta EE 10. But
Jakarta EE 10 will (hopefully) be implemented in Tomcat 10.0.x. What
exactly will go in 9.10.x ?


> Java EE 8. This is an attempt to extend the support period of the 9 branch
> even further and keep Tomcat 9 relevant with the new features from the main
> most recent branch. So you could propose 9.9, possibly, but 9.99 or 9.999
> or other random number doesn't fit. Then, the most important problem is
> that the 9 branch means Java EE 8 support, and you would be polluting it
> with a Jakarta EE release.
> So unfortunately that option E doesn't work at all, despite its apparent
> similarity with option D.
>

The idea to use 99 or 999 is to use a number that is far ahead and that it
won't ever be reached by the normal releases, like 9.1.x, 9.2.x, etc.


>
> Rémy
>
>

[tomcat] branch master updated (74cbdf6 -> c4860e6)

[remm]

This is an automated email from the ASF dual-hosted git repository.

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


from 74cbdf6  Fix HTTP_HOST for HTTP/2
 add c4860e6  Improve Kubernetes environment lookups

No new revisions were added by this update.

Summary of changes:
 .../tribes/membership/cloud/CloudMembershipProvider.java |  2 +-
 .../tribes/membership/cloud/DNSMembershipProvider.java   | 15 +--
 .../membership/cloud/KubernetesMembershipProvider.java   | 16 
 webapps/docs/changelog.xml   |  9 +
 4 files changed, 27 insertions(+), 15 deletions(-)


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

[GitHub] [tomcat] rmaucher closed pull request #237: Improved DNSMembershipProvider configuration code option 1

[GitBox]

rmaucher closed pull request #237: Improved DNSMembershipProvider configuration 
code option 1
URL: https://github.com/apache/tomcat/pull/237
 
 
   


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] rmaucher commented on issue #237: Improved DNSMembershipProvider configuration code option 1

[GitBox]

rmaucher commented on issue #237: Improved DNSMembershipProvider configuration 
code option 1
URL: https://github.com/apache/tomcat/pull/237#issuecomment-584099439
 
 
   Thanks, I modified things just a little and did the two PRs at the same 
time. The lookup order was a bad idea obviously, now it will look at the custom 
one first, then the standard one.
   The DNS service now has its own name.


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] rmaucher closed pull request #238: Improved DNSMembershipProvider configuration code option 2

[GitBox]

rmaucher closed pull request #238: Improved DNSMembershipProvider configuration 
code option 2
URL: https://github.com/apache/tomcat/pull/238
 
 
   


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] rmaucher commented on issue #238: Improved DNSMembershipProvider configuration code option 2

[GitBox]

rmaucher commented on issue #238: Improved DNSMembershipProvider configuration 
code option 2
URL: https://github.com/apache/tomcat/pull/238#issuecomment-584099541
 
 
   Merged with #237 


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: Numbering schemes for future releases

[Rémy Maucherat]

On Mon, Feb 10, 2020 at 1:08 PM Martin Grigorov 
wrote:

>
>
> On Mon, Feb 10, 2020 at 1:56 PM Rémy Maucherat  wrote:
>
>> On Mon, Feb 10, 2020 at 12:05 PM Martin Grigorov 
>> wrote:
>>
>>> Hi,
>>>
>>> On Mon, Feb 10, 2020 at 11:47 AM Mark Thomas  wrote:
>>>
 Hi,

 I thought it would be useful to re-open the discussion on this. If there
 is a better plan that the one we currently have I'd like to try and
 find it.

 I'm happy to hold off on the current 10.0.0.0-M1 release for a few days
 to give us time look for a better numbering scheme and so we have the
 opportunity to pull the 10.0.0.0-M1 release if necessary.

 I have tried to express the various options I have seen proposed in a
 similar way so we can compare them. If I have missed one or you think of
 a different one then please post it.

 Option A: The current plan:
 Jakarta EE 9:  10.0.0.x
 Jakarta EE 10: 10.0.x   (x>=1)
 Jakarta EE 11: 11.0.x
 Java EE 8: 9.y.x(where y == major Tomcat version)


 Option B: Continue with existing numbering
 Jakarta EE 9:  10.0.x
 Jakarta EE 10: 11.0.x
 Jakarta EE 11: 12.0.x
 Java EE 8: 9.y.x(where y == major Tomcat version)


 Option C: No stable Jakarta EE 9 release
 Jakarta EE 9:  10.0.0-Mx
 Jakarta EE 10: 10.0.x
 Jakarta EE 11: 11.0.x
 Java EE 8: 9.y.x(where y == major Tomcat version)


 Option D:
 Jakarta EE 9:  10.0.x
 Jakarta EE 10: 10.1.x
 Jakarta EE 11: 11.0.x
 Java EE 8: 9.y.x(where y == major Tomcat version)


 My own thoughts:

 I don't like option B because the off-by-one issue between Jakarta EE
 and Tomcat. It is manageable at the moment but I worry that it will
 cause confusion once we have the 9.y.x branch.

 I don't like option C because I think we need a stable, supported,
 passing the TCK Jakarta EE 9 release. Also, Jakarta EE 10 is meant to
 follow shortly after Jakarta EE 9 but what if it doesn't?

 For me, the choice is between A and D. If Jakarta EE 10 is very soon
 after Jakarta EE 9 then I think option A is better. However, D isn't
 that far behind and as soon as Jakarta EE 10 doesn't follow shortly
 after Jakarta EE 9 I think D begins to look better. As I think about it,
 the EOL decision we make for Jakarta EE 9 support depends a lot on how
 quickly Jakarta EE 10 follows and I think D gives us more flexibility.
 Finally, D is more consistent with how we have done things in the past
 (4.1.x, 5.5.x, 8.5.x etc)

 Thoughts?

>>>
>>> From the above I like option C.
>>> It the release of Jakarta EE 10 is delayed for some reason we can switch
>>> to option D.
>>>
>>> One more option:
>>> Option E:
>>> Jakarta EE 9:  9.99.x (or 9.999.x)
>>> Jakarta EE 10: 10.0.x
>>> Jakarta EE 11: 11.0.x
>>> Java EE 8: 9.y.x(where y == major Tomcat version)
>>>
>>> It is a bit ugly but some projects have used such version scheme to
>>> emphasize that it is a transitional release.
>>>
>>
>>
> Indeed it is getting complicated to understand the versions here.
>
>
>> Well, this won't work as the plan for the 9 branch [the last branch on
>> javax] is to track the API changes from the last major branches using minor
>> branches. So 9.10 [tracking the EE 10 branch], then 9.11, then 9.12, and so
>> on but still based on
>>
>
> What do you mean with "So 9.10 [tracking the EE 10 branch]," What is EE 10
> here ? Javax or Jakarta ?
> Since Oracle won't lead EE anymore then it should be Jakarta EE 10. But
> Jakarta EE 10 will (hopefully) be implemented in Tomcat 10.0.x. What
> exactly will go in 9.10.x ?
>

This is explained in the document:
https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+Release+Numbering
9.10: Continues to support Java EE 8 with Tomcat API identical to latest
Tomcat 10.0.x
9.11: Continues to support Java EE 8 with Tomcat API identical to latest
Tomcat 11.0.x
9.N: Continues to support Java EE 8 with Tomcat API identical to latest
Tomcat N
As I said, this is to be able to maintain an up to date Tomcat release
branch that still uses Java EE 8. If nobody ends up caring, this branch
will of course be dropped eventually, but I don't think that's the most
likely scenario.


>
>
>> Java EE 8. This is an attempt to extend the support period of the 9
>> branch even further and keep Tomcat 9 relevant with the new features from
>> the main most recent branch. So you could propose 9.9, possibly, but 9.99
>> or 9.999 or other random number doesn't fit. Then, the most important
>> problem is that the 9 branch means Java EE 8 support, and you would be
>> polluting it with a Jakarta EE release.
>> So unfortunately that option E doesn't work at all, despite its apparent
>> similarity with option D.
>>
>
> The idea to use 99 or 999 is to use a number that is far ahead and that it
> won't ever be reached by the normal releases

[tomcat] branch 9.0.x updated: Improve Kubernetes environment lookups

[remm]

This is an automated email from the ASF dual-hosted git repository.

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


The following commit(s) were added to refs/heads/9.0.x by this push:
 new 65e6925  Improve Kubernetes environment lookups
65e6925 is described below

commit 65e6925fabc8e707c2b6a91667e35721a8d4501d
Author: remm 
AuthorDate: Mon Feb 10 13:26:26 2020 +0100

Improve Kubernetes environment lookups

Fix lookup order by looking for specific names first, then the standard
Kubernetes ones, otherwise overriding will most likely not work.
Also add a dedicated name for the DNS service, that will default to
getNamespace() if not present.
Submitted by Bernd Bohmann.
---
 .../tribes/membership/cloud/CloudMembershipProvider.java |  2 +-
 .../tribes/membership/cloud/DNSMembershipProvider.java   | 15 +--
 .../membership/cloud/KubernetesMembershipProvider.java   | 16 
 webapps/docs/changelog.xml   |  9 +
 4 files changed, 27 insertions(+), 15 deletions(-)

diff --git 
a/java/org/apache/catalina/tribes/membership/cloud/CloudMembershipProvider.java 
b/java/org/apache/catalina/tribes/membership/cloud/CloudMembershipProvider.java
index f33aed6..22f9a95 100644
--- 
a/java/org/apache/catalina/tribes/membership/cloud/CloudMembershipProvider.java
+++ 
b/java/org/apache/catalina/tribes/membership/cloud/CloudMembershipProvider.java
@@ -88,7 +88,7 @@ public abstract class CloudMembershipProvider extends 
MembershipProviderBase imp
  * @return the namespace
  */
 protected String getNamespace() {
-String namespace = getEnv("KUBERNETES_NAMESPACE", CUSTOM_ENV_PREFIX + 
"NAMESPACE");
+String namespace = getEnv(CUSTOM_ENV_PREFIX + "NAMESPACE", 
"KUBERNETES_NAMESPACE");
 if (namespace == null || namespace.length() == 0) {
 log.warn(sm.getString("kubernetesMembershipProvider.noNamespace"));
 namespace = "tomcat";
diff --git 
a/java/org/apache/catalina/tribes/membership/cloud/DNSMembershipProvider.java 
b/java/org/apache/catalina/tribes/membership/cloud/DNSMembershipProvider.java
index 25fcff1..7b57d97 100644
--- 
a/java/org/apache/catalina/tribes/membership/cloud/DNSMembershipProvider.java
+++ 
b/java/org/apache/catalina/tribes/membership/cloud/DNSMembershipProvider.java
@@ -33,7 +33,7 @@ import org.apache.juli.logging.LogFactory;
 public class DNSMembershipProvider extends CloudMembershipProvider {
 private static final Log log = 
LogFactory.getLog(DNSMembershipProvider.class);
 
-private String namespace;
+private String dnsServiceName;
 
 @Override
 public void start(int level) throws Exception {
@@ -44,12 +44,15 @@ public class DNSMembershipProvider extends 
CloudMembershipProvider {
 super.start(level);
 
 // Set up Kubernetes API parameters
-namespace = getNamespace();
+dnsServiceName = getEnv("DNS_MEMBERSHIP_SERVICE_NAME");
+if (dnsServiceName == null) {
+dnsServiceName = getNamespace();
+}
 
 if (log.isDebugEnabled()) {
-log.debug(String.format("Namespace [%s] set; clustering enabled", 
namespace));
+log.debug(String.format("Namespace [%s] set; clustering enabled", 
dnsServiceName));
 }
-namespace = URLEncoder.encode(namespace, "UTF-8");
+dnsServiceName = URLEncoder.encode(dnsServiceName, "UTF-8");
 
 // Fetch initial members
 heartbeat();
@@ -66,9 +69,9 @@ public class DNSMembershipProvider extends 
CloudMembershipProvider {
 
 InetAddress[] inetAddresses = null;
 try {
-inetAddresses = InetAddress.getAllByName(namespace);
+inetAddresses = InetAddress.getAllByName(dnsServiceName);
 } catch (UnknownHostException exception) {
-log.warn(sm.getString("dnsMembershipProvider.dnsError", 
namespace), exception);
+log.warn(sm.getString("dnsMembershipProvider.dnsError", 
dnsServiceName), exception);
 }
 
 if (inetAddresses != null) {
diff --git 
a/java/org/apache/catalina/tribes/membership/cloud/KubernetesMembershipProvider.java
 
b/java/org/apache/catalina/tribes/membership/cloud/KubernetesMembershipProvider.java
index 2950f5a..ce2b1b1 100644
--- 
a/java/org/apache/catalina/tribes/membership/cloud/KubernetesMembershipProvider.java
+++ 
b/java/org/apache/catalina/tribes/membership/cloud/KubernetesMembershipProvider.java
@@ -57,12 +57,12 @@ public class KubernetesMembershipProvider extends 
CloudMembershipProvider {
 log.debug(String.format("Namespace [%s] set; clustering enabled", 
namespace));
 }
 
-String protocol = getEnv("KUBERNETES_MASTER_PROTOCOL", 
CUSTOM_ENV_PREFIX + "MASTER_PROTOCOL");
-String masterHost = getEnv("KUBERNETES_SERVICE_HOST", 
CUSTOM_ENV_PREFIX + "MASTER_HOST");
-String masterPort = getEnv("KUBERNETES_SERVICE_PORT", 
CUSTO

Re: Numbering schemes for future releases

[Martin Grigorov]

On Mon, Feb 10, 2020 at 2:34 PM Rémy Maucherat  wrote:

> On Mon, Feb 10, 2020 at 1:08 PM Martin Grigorov 
> wrote:
>
>>
>>
>> On Mon, Feb 10, 2020 at 1:56 PM Rémy Maucherat  wrote:
>>
>>> On Mon, Feb 10, 2020 at 12:05 PM Martin Grigorov 
>>> wrote:
>>>
 Hi,

 On Mon, Feb 10, 2020 at 11:47 AM Mark Thomas  wrote:

> Hi,
>
> I thought it would be useful to re-open the discussion on this. If
> there
> is a better plan that the one we currently have I'd like to try and
> find it.
>
> I'm happy to hold off on the current 10.0.0.0-M1 release for a few days
> to give us time look for a better numbering scheme and so we have the
> opportunity to pull the 10.0.0.0-M1 release if necessary.
>
> I have tried to express the various options I have seen proposed in a
> similar way so we can compare them. If I have missed one or you think
> of
> a different one then please post it.
>
> Option A: The current plan:
> Jakarta EE 9:  10.0.0.x
> Jakarta EE 10: 10.0.x   (x>=1)
> Jakarta EE 11: 11.0.x
> Java EE 8: 9.y.x(where y == major Tomcat version)
>
>
> Option B: Continue with existing numbering
> Jakarta EE 9:  10.0.x
> Jakarta EE 10: 11.0.x
> Jakarta EE 11: 12.0.x
> Java EE 8: 9.y.x(where y == major Tomcat version)
>
>
> Option C: No stable Jakarta EE 9 release
> Jakarta EE 9:  10.0.0-Mx
> Jakarta EE 10: 10.0.x
> Jakarta EE 11: 11.0.x
> Java EE 8: 9.y.x(where y == major Tomcat version)
>
>
> Option D:
> Jakarta EE 9:  10.0.x
> Jakarta EE 10: 10.1.x
> Jakarta EE 11: 11.0.x
> Java EE 8: 9.y.x(where y == major Tomcat version)
>
>
> My own thoughts:
>
> I don't like option B because the off-by-one issue between Jakarta EE
> and Tomcat. It is manageable at the moment but I worry that it will
> cause confusion once we have the 9.y.x branch.
>
> I don't like option C because I think we need a stable, supported,
> passing the TCK Jakarta EE 9 release. Also, Jakarta EE 10 is meant to
> follow shortly after Jakarta EE 9 but what if it doesn't?
>
> For me, the choice is between A and D. If Jakarta EE 10 is very soon
> after Jakarta EE 9 then I think option A is better. However, D isn't
> that far behind and as soon as Jakarta EE 10 doesn't follow shortly
> after Jakarta EE 9 I think D begins to look better. As I think about
> it,
> the EOL decision we make for Jakarta EE 9 support depends a lot on how
> quickly Jakarta EE 10 follows and I think D gives us more flexibility.
> Finally, D is more consistent with how we have done things in the past
> (4.1.x, 5.5.x, 8.5.x etc)
>
> Thoughts?
>

 From the above I like option C.
 It the release of Jakarta EE 10 is delayed for some reason we can
 switch to option D.

 One more option:
 Option E:
 Jakarta EE 9:  9.99.x (or 9.999.x)
 Jakarta EE 10: 10.0.x
 Jakarta EE 11: 11.0.x
 Java EE 8: 9.y.x(where y == major Tomcat version)

 It is a bit ugly but some projects have used such version scheme to
 emphasize that it is a transitional release.

>>>
>>>
>> Indeed it is getting complicated to understand the versions here.
>>
>>
>>> Well, this won't work as the plan for the 9 branch [the last branch on
>>> javax] is to track the API changes from the last major branches using minor
>>> branches. So 9.10 [tracking the EE 10 branch], then 9.11, then 9.12, and so
>>> on but still based on
>>>
>>
>> What do you mean with "So 9.10 [tracking the EE 10 branch]," What is EE
>> 10 here ? Javax or Jakarta ?
>> Since Oracle won't lead EE anymore then it should be Jakarta EE 10. But
>> Jakarta EE 10 will (hopefully) be implemented in Tomcat 10.0.x. What
>> exactly will go in 9.10.x ?
>>
>
>


> This is explained in the document:
> https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+Release+Numbering
> 9.10: Continues to support Java EE 8 with Tomcat API identical to latest
> Tomcat 10.0.x
> 9.11: Continues to support Java EE 8 with Tomcat API identical to latest
> Tomcat 11.0.x
> 9.N: Continues to support Java EE 8 with Tomcat API identical to latest
> Tomcat N
> As I said, this is to be able to maintain an up to date Tomcat release
> branch that still uses Java EE 8. If nobody ends up caring, this branch
> will of course be dropped eventually, but I don't think that's the most
> likely scenario.
>

Thanks for the reference!
If Tomcat was a library/framework I'd suggest to use Maven classifiers.
Lately most of my applications use Tomcat as embedded server.
It would be much more natural to add  javax (for
Maven) or to append ":javax" (e.g.
"org.apache.tomcat:tomcat-embed-core:10.0.1:javax" for Gradle)
But I don't see how this could work for the standalone downloads and the OS
packages.



>
>
>>
>>
>>> Java EE 8. This is an attem

Re: Numbering schemes for future releases

[Coty Sutherland]

On Mon, Feb 10, 2020 at 4:48 AM Mark Thomas  wrote:

> Hi,
>
> I thought it would be useful to re-open the discussion on this. If there
> is a better plan that the one we currently have I'd like to try and find
> it.
>
> I'm happy to hold off on the current 10.0.0.0-M1 release for a few days
> to give us time look for a better numbering scheme and so we have the
> opportunity to pull the 10.0.0.0-M1 release if necessary.
>
> I have tried to express the various options I have seen proposed in a
> similar way so we can compare them. If I have missed one or you think of
> a different one then please post it.
>
> Option A: The current plan:
> Jakarta EE 9:  10.0.0.x
> Jakarta EE 10: 10.0.x   (x>=1)
> Jakarta EE 11: 11.0.x
> Java EE 8: 9.y.x(where y == major Tomcat version)
>
>
> Option B: Continue with existing numbering
> Jakarta EE 9:  10.0.x
> Jakarta EE 10: 11.0.x
> Jakarta EE 11: 12.0.x
> Java EE 8: 9.y.x(where y == major Tomcat version)
>
>
> Option C: No stable Jakarta EE 9 release
> Jakarta EE 9:  10.0.0-Mx
> Jakarta EE 10: 10.0.x
> Jakarta EE 11: 11.0.x
> Java EE 8: 9.y.x(where y == major Tomcat version)
>
>
> Option D:
> Jakarta EE 9:  10.0.x
> Jakarta EE 10: 10.1.x
> Jakarta EE 11: 11.0.x
> Java EE 8: 9.y.x(where y == major Tomcat version)
>

I think I prefer option A, with D as a secondary. Initially I liked C the
best, but given the conversation I agree that it's probably not the best
way forward. Either way we do it is going to be somewhat confusing for
folks I think, at least initially, but the options we have all seem pretty
easy to explain.


>
>
> My own thoughts:
>
> I don't like option B because the off-by-one issue between Jakarta EE
> and Tomcat. It is manageable at the moment but I worry that it will
> cause confusion once we have the 9.y.x branch.
>
> I don't like option C because I think we need a stable, supported,
> passing the TCK Jakarta EE 9 release. Also, Jakarta EE 10 is meant to
> follow shortly after Jakarta EE 9 but what if it doesn't?
>
> For me, the choice is between A and D. If Jakarta EE 10 is very soon
> after Jakarta EE 9 then I think option A is better. However, D isn't
> that far behind and as soon as Jakarta EE 10 doesn't follow shortly
> after Jakarta EE 9 I think D begins to look better. As I think about it,
> the EOL decision we make for Jakarta EE 9 support depends a lot on how
> quickly Jakarta EE 10 follows and I think D gives us more flexibility.
> Finally, D is more consistent with how we have done things in the past
> (4.1.x, 5.5.x, 8.5.x etc)
>
> Thoughts?
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

buildbot success in on tomcat-trunk

[buildbot]

The Buildbot has detected a restored build on builder tomcat-trunk while 
building tomcat. Full details are available at:
https://ci.apache.org/builders/tomcat-trunk/builds/4928

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

Buildslave for this Build: asf946_ubuntu

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

Build succeeded!

Sincerely,
 -The Buildbot




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

Re: Numbering schemes for future releases

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Coty,

On 2/10/20 8:37 AM, Coty Sutherland wrote:
> On Mon, Feb 10, 2020 at 4:48 AM Mark Thomas  > wrote:
> 
> Hi,
> 
> I thought it would be useful to re-open the discussion on this. If
> there is a better plan that the one we currently have I'd like to
> try and find it.
> 
> I'm happy to hold off on the current 10.0.0.0-M1 release for a few
> days to give us time look for a better numbering scheme and so we
> have the opportunity to pull the 10.0.0.0-M1 release if necessary.
> 
> I have tried to express the various options I have seen proposed in
> a similar way so we can compare them. If I have missed one or you
> think of a different one then please post it.
> 
> Option A: The current plan: Jakarta EE 9:  10.0.0.x Jakarta EE 10:
> 10.0.x   (x>=1) Jakarta EE 11: 11.0.x Java EE 8: 9.y.x
> (where y == major Tomcat version)
> 
> 
> Option B: Continue with existing numbering Jakarta EE 9:  10.0.x 
> Jakarta EE 10: 11.0.x Jakarta EE 11: 12.0.x Java EE 8: 9.y.x
> (where y == major Tomcat version)
> 
> 
> Option C: No stable Jakarta EE 9 release Jakarta EE 9:  10.0.0-Mx 
> Jakarta EE 10: 10.0.x Jakarta EE 11: 11.0.x Java EE 8: 9.y.x
> (where y == major Tomcat version)
> 
> 
> Option D: Jakarta EE 9:  10.0.x Jakarta EE 10: 10.1.x Jakarta EE
> 11: 11.0.x Java EE 8: 9.y.x(where y == major Tomcat
> version)
> 
> 
> I think I prefer option A, with D as a secondary. Initially I liked
> C the best, but given the conversation I agree that it's probably
> not the best way forward.

I think you have captured the essence of this conversation, here:

> Either way we do it is going to be somewhat confusing for folks I 
> think, at least initially, but the options we have all seem pretty 
> easy to explain.
Given that confusion is inevitable, let's go with the option that has
the best steady-state outcome, which is option A -- where the Tomcat
version lines-up with the Jakarta EE version number.

Back when Tomcat 3/4/5 were released, the Java EE version numbering
was unpredictable and it wasn't obvious that Tomcat versions followed
various combinations of specifications. Now that Tomcat is essentially
following a numbered-bundle of specs (e.g. "Jakarta EE 10") instead of
collections of individual specs (Servlet, JSP, EL, WebSocket, JASPIC),
it makes much more sense for our version numbers to b as
easily-trackable as possible.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5BcbcACgkQHPApP6U8
pFiQ8hAAnpUQ6xBi2x/MrcmlzjzvJvfJCHZ+KICaWvWuKoOXfk45iiuDzJZwWR0/
WKm5vZ2oDEmjQNSkqiaUHklCXm3lNNJ+/Epc1ikZ19cfoWo++KeyeQG995ePvED8
KPh7z5OtNaDaUi7ciJjKiORCJH4BtAlnBXlZBpcnTZ9I/YbRzQjSgYjeMPiUEDnY
J5wQq/jNnutAiU1B4pzcFRGKw82yetA41isvGdyn3dLkWaSFzKAkQAbvGrOPrlER
KuNrhJUgwCo7R9KAzzv58QSITn+kBt+3Y6CMAxRe65uOaozNEZJ7cPbf2fr3otSR
UOB7m8sTYdHBsMEMKRbUw9Lw0SFRGHKWR5WxFam8JlvYcwQeQwnY3dj5MiDNZvoV
ybeho0H61AWluZbmRgP/B9Ev3R2KhpEVwTJaDMJcy/dbXeogTONLVmqUesb6GhxA
HC+pMlZV9Zqe4p7sdR2mBLjVNQYKiRKCOzPkRowzRS2kLrgsQLizn6tgDRjPwzSu
UHWkFku3L1/5bufpESwv8UwVe875uqjkjPOQ6UvLlsErt4tSNWuaLRZxzaMHIGR2
lEs0FfvIfuLHtnmcA9cib4/gf80O9wI3dlyVM16qBLHwT+DGFb0qfDIG8Bt/oHg0
Q04Vs+nFSZ8wBVEbOmYrmg3O78KQeBRU1IB1TQVyikqBJTUybQc=
=sXCR
-END PGP SIGNATURE-

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

[tomcat] branch master updated (c4860e6 -> eac3c26)

[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 c4860e6  Improve Kubernetes environment lookups
 add eac3c26  Fix missing implicit TLD map entries.

No new revisions were added by this update.

Summary of changes:
 java/org/apache/jasper/servlet/TldScanner.java | 10 ++
 webapps/docs/changelog.xml |  7 +++
 2 files changed, 13 insertions(+), 4 deletions(-)


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

[tomcat] branch 9.0.x updated: Fix missing implicit TLD map entries.

[markt]

This is an automated email from the ASF dual-hosted git repository.

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


The following commit(s) were added to refs/heads/9.0.x by this push:
 new 3a24514  Fix missing implicit TLD map entries.
3a24514 is described below

commit 3a24514a375776c2b73a8021d841a58c5ef05cb7
Author: Markus Lottmann 
AuthorDate: Wed Dec 11 15:10:04 2019 +0100

Fix missing implicit TLD map entries.

If TldResourcePath was already registred during parsing of jsp-config
section of web.xml, the implicit TLD map entries (derived from TLD files
URI) were not added to the uriTldResourcePathMap.

This was not in line with JSP2.2 specification section 7.3.4.
---
 java/org/apache/jasper/servlet/TldScanner.java | 10 ++
 webapps/docs/changelog.xml |  7 +++
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/java/org/apache/jasper/servlet/TldScanner.java 
b/java/org/apache/jasper/servlet/TldScanner.java
index 5956ca2..4561739 100644
--- a/java/org/apache/jasper/servlet/TldScanner.java
+++ b/java/org/apache/jasper/servlet/TldScanner.java
@@ -272,10 +272,6 @@ public class TldScanner {
 }
 
 protected void parseTld(TldResourcePath path) throws IOException, 
SAXException {
-if (tldResourcePathTaglibXmlMap.containsKey(path)) {
-// TLD has already been parsed as a result of processing web.xml
-return;
-}
 TaglibXml tld = tldParser.parse(path);
 String uri = tld.getUri();
 if (uri != null) {
@@ -283,6 +279,12 @@ public class TldScanner {
 uriTldResourcePathMap.put(uri, path);
 }
 }
+
+if (tldResourcePathTaglibXmlMap.containsKey(path)) {
+// TLD has already been parsed as a result of processing web.xml
+return;
+}
+
 tldResourcePathTaglibXmlMap.put(path, tld);
 if (tld.getListeners() != null) {
 listeners.addAll(tld.getListeners());
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 82c6ea9..9793ab4 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -64,6 +64,13 @@
 Parameterize JSP version and API class names in localization messages 
to
 allow simpler re-use between major versions. (markt)
   
+  
+Ensure that TLD files listed in the jsp-config section of
+web.xml that are registered in the
+uriTldResourcePathMap with the URI specified in
+web.xml are also registered with the URI in the TLD file 
if
+it is different. Patch provided by Markus Lottmann. (markt)
+  
 
   
   


-
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 missing implicit TLD map entries.

[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 d169c35  Fix missing implicit TLD map entries.
d169c35 is described below

commit d169c35d2ec977a22ad678fc1981285badbf2ad0
Author: Markus Lottmann 
AuthorDate: Wed Dec 11 15:10:04 2019 +0100

Fix missing implicit TLD map entries.

If TldResourcePath was already registred during parsing of jsp-config
section of web.xml, the implicit TLD map entries (derived from TLD files
URI) were not added to the uriTldResourcePathMap.

This was not in line with JSP2.2 specification section 7.3.4.
---
 java/org/apache/jasper/servlet/TldScanner.java | 10 ++
 webapps/docs/changelog.xml |  7 +++
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/java/org/apache/jasper/servlet/TldScanner.java 
b/java/org/apache/jasper/servlet/TldScanner.java
index 5956ca2..4561739 100644
--- a/java/org/apache/jasper/servlet/TldScanner.java
+++ b/java/org/apache/jasper/servlet/TldScanner.java
@@ -272,10 +272,6 @@ public class TldScanner {
 }
 
 protected void parseTld(TldResourcePath path) throws IOException, 
SAXException {
-if (tldResourcePathTaglibXmlMap.containsKey(path)) {
-// TLD has already been parsed as a result of processing web.xml
-return;
-}
 TaglibXml tld = tldParser.parse(path);
 String uri = tld.getUri();
 if (uri != null) {
@@ -283,6 +279,12 @@ public class TldScanner {
 uriTldResourcePathMap.put(uri, path);
 }
 }
+
+if (tldResourcePathTaglibXmlMap.containsKey(path)) {
+// TLD has already been parsed as a result of processing web.xml
+return;
+}
+
 tldResourcePathTaglibXmlMap.put(path, tld);
 if (tld.getListeners() != null) {
 listeners.addAll(tld.getListeners());
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 62ab059..7ffd7af 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -64,6 +64,13 @@
 Parameterize JSP version and API class names in localization messages 
to
 allow simpler re-use between major versions. (markt)
   
+  
+Ensure that TLD files listed in the jsp-config section of
+web.xml that are registered in the
+uriTldResourcePathMap with the URI specified in
+web.xml are also registered with the URI in the TLD file 
if
+it is different. Patch provided by Markus Lottmann. (markt)
+  
 
   
   


-
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: A few more Javadoc fixes for newer versions of Java

[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 c8c87f2  A few more Javadoc fixes for newer versions of Java
c8c87f2 is described below

commit c8c87f2b90c367bee407f24ffc98e7c70d18b7c4
Author: Mark Thomas 
AuthorDate: Thu Feb 6 14:58:53 2020 +

A few more Javadoc fixes for newer versions of Java
---
 java/org/apache/jasper/compiler/ErrorHandler.java  | 4 
 java/org/apache/jasper/compiler/JarResource.java   | 4 ++--
 java/org/apache/jasper/compiler/JarScannerFactory.java | 2 ++
 java/org/apache/jasper/compiler/JspConfig.java | 4 
 java/org/apache/jasper/compiler/JspUtil.java   | 7 +++
 java/org/apache/jasper/runtime/PageContextImpl.java| 2 ++
 6 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/java/org/apache/jasper/compiler/ErrorHandler.java 
b/java/org/apache/jasper/compiler/ErrorHandler.java
index 8b2f028..5d069f0 100644
--- a/java/org/apache/jasper/compiler/ErrorHandler.java
+++ b/java/org/apache/jasper/compiler/ErrorHandler.java
@@ -40,6 +40,7 @@ public interface ErrorHandler {
  * @param column Parse error column number
  * @param msg Parse error message
  * @param exception Parse exception
+ * @throws JasperException An error occurred
  */
 public void jspError(String fname, int line, int column, String msg,
 Exception exception) throws JasperException;
@@ -49,6 +50,7 @@ public interface ErrorHandler {
  *
  * @param msg Parse error message
  * @param exception Parse exception
+ * @throws JasperException An error occurred
  */
 public void jspError(String msg, Exception exception)
 throws JasperException;
@@ -58,6 +60,7 @@ public interface ErrorHandler {
  *
  * @param details Array of JavacErrorDetail instances corresponding to the
  * compilation errors
+ * @throws JasperException An error occurred
  */
 public void javacError(JavacErrorDetail[] details)
 throws JasperException;
@@ -67,6 +70,7 @@ public interface ErrorHandler {
  *
  * @param errorReport Compilation error report
  * @param exception Compilation exception
+ * @throws JasperException An error occurred
  */
 public void javacError(String errorReport, Exception exception)
 throws JasperException;
diff --git a/java/org/apache/jasper/compiler/JarResource.java 
b/java/org/apache/jasper/compiler/JarResource.java
index ea73855..614dfa7 100644
--- a/java/org/apache/jasper/compiler/JarResource.java
+++ b/java/org/apache/jasper/compiler/JarResource.java
@@ -26,7 +26,7 @@ public interface JarResource {
 /**
  * @return The JarFile for this resource. A new instance of JarFile
  * should be returned on each call.
- * @throws IOException
+ * @throws IOException If an I/O error occurs reading the JAR
  */
 JarFile getJarFile() throws IOException;
 
@@ -37,7 +37,7 @@ public interface JarResource {
 String getUrl();
 
 /**
- * @param name
+ * @param name Name of entry to return
  * @return The URL for the entry within this resource.
  */
 URL getEntry(String name);
diff --git a/java/org/apache/jasper/compiler/JarScannerFactory.java 
b/java/org/apache/jasper/compiler/JarScannerFactory.java
index 29a58a2..ea0350b 100644
--- a/java/org/apache/jasper/compiler/JarScannerFactory.java
+++ b/java/org/apache/jasper/compiler/JarScannerFactory.java
@@ -34,6 +34,8 @@ public class JarScannerFactory {
 /**
  * Obtain the {@link JarScanner} associated with the specified {@link
  * ServletContext}. It is obtained via a context parameter.
+ * @param ctxt The Servlet context
+ * @return a scanner instance
  */
 public static JarScanner getJarScanner(ServletContext ctxt) {
 JarScanner jarScanner =
diff --git a/java/org/apache/jasper/compiler/JspConfig.java 
b/java/org/apache/jasper/compiler/JspConfig.java
index 8157138..506e0b1 100644
--- a/java/org/apache/jasper/compiler/JspConfig.java
+++ b/java/org/apache/jasper/compiler/JspConfig.java
@@ -296,6 +296,7 @@ public class JspConfig {
  * Find a property that best matches the supplied resource.
  * @param uri the resource supplied.
  * @return a JspProperty indicating the best match, or some default.
+ * @throws JasperException Not used
  */
 public JspProperty findJspProperty(String uri) throws JasperException {
 
@@ -459,6 +460,9 @@ public class JspConfig {
 /**
  * To find out if a uri matches a url pattern in jsp config.  If so,
  * then the uri is a JSP page.  This is used primarily for jspc.
+ * @param uri The path to check
+ * @return true if the path denotes a JSP page
+ * @throws JasperException Not used
  */
 public boolean isJspPage(String uri) throws JasperEx

[GitHub] [tomcat] markt-asf commented on issue #230: Fix missing implicit TLD map entries.

[GitBox]

markt-asf commented on issue #230: Fix missing implicit TLD map entries.
URL: https://github.com/apache/tomcat/pull/230#issuecomment-584223448
 
 
   I've merged this along with a changelog entry. Many thanks for the PR.


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] markt-asf closed pull request #230: Fix missing implicit TLD map entries.

[GitBox]

markt-asf closed pull request #230: Fix missing implicit TLD map entries.
URL: https://github.com/apache/tomcat/pull/230
 
 
   


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

buildbot failure in on tomcat-trunk

[buildbot]

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

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

Buildslave for this Build: asf946_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' 
triggered this build
Build Source Stamp: [branch master] eac3c266c525b975d1fbc776a81f9dcea2cb5b0e
Blamelist: Markus Lottmann 

BUILD FAILED: failed compile_1

Sincerely,
 -The Buildbot




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

[tomcat-connectors] branch master updated: Fix BZ 64051. Update session cookie on failover

[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-connectors.git


The following commit(s) were added to refs/heads/master by this push:
 new 92b4bc1  Fix BZ 64051. Update session cookie on failover
92b4bc1 is described below

commit 92b4bc13494d6ba07b472a00fce5cd2977624319
Author: Mark Thomas 
AuthorDate: Wed Jan 29 22:55:06 2020 +

Fix BZ 64051. Update session cookie on failover

https://bz.apache.org/bugzilla/show_bug.cgi?id=64051
---
 native/common/jk_lb_worker.c  | 1 +
 xdocs/miscellaneous/changelog.xml | 5 +
 2 files changed, 6 insertions(+)

diff --git a/native/common/jk_lb_worker.c b/native/common/jk_lb_worker.c
index ac91dc4..9d2f9c3 100644
--- a/native/common/jk_lb_worker.c
+++ b/native/common/jk_lb_worker.c
@@ -966,6 +966,7 @@ static int find_bysession_route(jk_ws_service_t *s,
  * balancer. Of course you will need a some kind of
  * session replication between those two remote.
  */
+s->sticky = JK_FALSE;
 if (p->sticky_session_force)
 candidate = -1;
 else if (*wr.redirect) {
diff --git a/xdocs/miscellaneous/changelog.xml 
b/xdocs/miscellaneous/changelog.xml
index f199848..6723754 100644
--- a/xdocs/miscellaneous/changelog.xml
+++ b/xdocs/miscellaneous/changelog.xml
@@ -59,6 +59,11 @@
 Common: Update the documentation to reflect that the source code for 
the
 Apache Tomcat Connectors has moved from Subversion to Git. (markt)
   
+  
+64051: Common. When using set_session_cookie,
+ensure that an updated session cookie is issued if the load-balancer 
has
+to failover to a different worker. (markt)
+  
 
   
 


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

[Bug 64051] mod_jk set_session_cookie not sending new cookie after node failover for sticky session

[bugzilla]

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

Mark Thomas  changed:

   What|Removed |Added

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

--- Comment #17 from Mark Thomas  ---
The patch worked for me in local testing so I am going to mark this as
resolved.

The fix will be in 1.2.24 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

Re: buildbot failure in on tomcat-trunk

[Rémy Maucherat]

On Mon, Feb 10, 2020 at 6:15 PM  wrote:

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

A HTTP/2 failure, it's been a long while ...
https://ci.apache.org/projects/tomcat/tomcat10/logs/4929/TEST-org.apache.coyote.http2.TestHttp2Section_5_3.NIO.txt
vs
https://ci.apache.org/projects/tomcat/tomcat10/logs/4929/TEST-org.apache.coyote.http2.TestHttp2Section_5_3.NIO2.txt

I would say the abuse closed the stream after apparently seeing two 1 byte
body frames. Odd. Just a guess at this point.

Rémy


>
> Sincerely,
>  -The Buildbot
>
>
>
>
> -
> 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: Remove PushBuilder from the Servlet 4.0 API preview package

[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 45f6c01  Remove PushBuilder from the Servlet 4.0 API preview package
45f6c01 is described below

commit 45f6c010d93ab3f0c391c4107871f2b0d27dfb84
Author: Mark Thomas 
AuthorDate: Mon Feb 10 19:48:48 2020 +

Remove PushBuilder from the Servlet 4.0 API preview package
---
 java/org/apache/catalina/connector/Request.java|  16 +-
 .../apache/catalina/connector/RequestFacade.java   |  13 +-
 .../catalina/core/ApplicationHttpRequest.java  |   4 +-
 .../catalina/core/ApplicationPushBuilder.java  |  18 +-
 .../apache/catalina/filters/RemoteIpFilter.java|  15 --
 .../servlet4preview/http/HttpServletRequest.java   |  16 --
 .../http/HttpServletRequestWrapper.java|  14 --
 .../catalina/servlet4preview/http/PushBuilder.java | 196 -
 webapps/docs/changelog.xml |   6 +
 9 files changed, 16 insertions(+), 282 deletions(-)

diff --git a/java/org/apache/catalina/connector/Request.java 
b/java/org/apache/catalina/connector/Request.java
index c4b6554..a38e97a 100644
--- a/java/org/apache/catalina/connector/Request.java
+++ b/java/org/apache/catalina/connector/Request.java
@@ -82,7 +82,6 @@ import 
org.apache.catalina.core.ApplicationSessionCookieConfig;
 import org.apache.catalina.core.AsyncContextImpl;
 import org.apache.catalina.mapper.MappingData;
 import org.apache.catalina.servlet4preview.http.HttpServletMapping;
-import org.apache.catalina.servlet4preview.http.PushBuilder;
 import org.apache.catalina.session.ManagerBase;
 import org.apache.catalina.util.ParameterMap;
 import org.apache.catalina.util.TLSUtil;
@@ -2004,21 +2003,12 @@ public class Request implements 
org.apache.catalina.servlet4preview.http.HttpSer
 }
 
 
-// - HttpServletRequest Methods
-
-/**
- * Pulled forward from Servlet 4.0. The method signature may be modified,
- * removed or replaced at any time until Servlet 4.0 becomes final.
- *
- * @return A builder to use to construct the push request
- */
-@Override
-public PushBuilder newPushBuilder() {
+public ApplicationPushBuilder newPushBuilder() {
 return newPushBuilder(this);
 }
 
 
-public PushBuilder newPushBuilder(HttpServletRequest request) {
+public ApplicationPushBuilder newPushBuilder(HttpServletRequest request) {
 AtomicBoolean result = new AtomicBoolean();
 coyoteRequest.action(ActionCode.IS_PUSH_SUPPORTED, result);
 if (result.get()) {
@@ -2029,6 +2019,8 @@ public class Request implements 
org.apache.catalina.servlet4preview.http.HttpSer
 }
 
 
+// - HttpServletRequest Methods
+
 /**
  * {@inheritDoc}
  *
diff --git a/java/org/apache/catalina/connector/RequestFacade.java 
b/java/org/apache/catalina/connector/RequestFacade.java
index 23146ed..41d0dde 100644
--- a/java/org/apache/catalina/connector/RequestFacade.java
+++ b/java/org/apache/catalina/connector/RequestFacade.java
@@ -40,10 +40,10 @@ import javax.servlet.http.HttpUpgradeHandler;
 import javax.servlet.http.Part;
 
 import org.apache.catalina.Globals;
+import org.apache.catalina.core.ApplicationPushBuilder;
 import org.apache.catalina.security.SecurityUtil;
 import org.apache.catalina.servlet4preview.http.HttpServletMapping;
 import org.apache.catalina.servlet4preview.http.HttpServletRequest;
-import org.apache.catalina.servlet4preview.http.PushBuilder;
 import org.apache.tomcat.util.res.StringManager;
 
 /**
@@ -1128,19 +1128,12 @@ public class RequestFacade implements 
HttpServletRequest {
 }
 
 
-public PushBuilder newPushBuilder(javax.servlet.http.HttpServletRequest 
request) {
+public ApplicationPushBuilder 
newPushBuilder(javax.servlet.http.HttpServletRequest request) {
 return this.request.newPushBuilder(request);
 }
 
 
-/**
- * {@inheritDoc}
- * 
- * Pulled forward from Servlet 4.0. The method signature may be modified,
- * removed or replaced at any time until Servlet 4.0 becomes final.
- */
-@Override
-public PushBuilder newPushBuilder() {
+public ApplicationPushBuilder newPushBuilder() {
 return request.newPushBuilder();
 }
 }
diff --git a/java/org/apache/catalina/core/ApplicationHttpRequest.java 
b/java/org/apache/catalina/core/ApplicationHttpRequest.java
index 3277d9a..2bb795c 100644
--- a/java/org/apache/catalina/core/ApplicationHttpRequest.java
+++ b/java/org/apache/catalina/core/ApplicationHttpRequest.java
@@ -43,7 +43,6 @@ import org.apache.catalina.Manager;
 import org.apache.catalina.Session;
 import org.apache.catalina.connector.RequestFacade;
 import org.apache.catalina.servlet4preview.http.HttpServletMapping;
-import org.apache

Re: buildbot failure in on tomcat-trunk

[Mark Thomas]

On 10/02/2020 19:45, Rémy Maucherat wrote:
> On Mon, Feb 10, 2020 at 6:15 PM  > wrote:
> 
> The Buildbot has detected a new failure on builder tomcat-trunk
> while building tomcat. Full details are available at:
>     https://ci.apache.org/builders/tomcat-trunk/builds/4929
> 
> Buildbot URL: https://ci.apache.org/
> 
> Buildslave for this Build: asf946_ubuntu
> 
> Build Reason: The AnyBranchScheduler scheduler named
> 'on-tomcat-commit' triggered this build
> Build Source Stamp: [branch master]
> eac3c266c525b975d1fbc776a81f9dcea2cb5b0e
> Blamelist: Markus Lottmann  >
> 
> BUILD FAILED: failed compile_1
> 
> 
> A HTTP/2 failure, it's been a long while ...
> https://ci.apache.org/projects/tomcat/tomcat10/logs/4929/TEST-org.apache.coyote.http2.TestHttp2Section_5_3.NIO.txt
> vs
> https://ci.apache.org/projects/tomcat/tomcat10/logs/4929/TEST-org.apache.coyote.http2.TestHttp2Section_5_3.NIO2.txt
> 
> I would say the abuse closed the stream after apparently seeing two 1
> byte body frames. Odd. Just a guess at this point.

Good guess. Looks consistent with the trace and the test configuration.

I did occasionally see repeated 1-byte data frames on the same stream
running this test. It all depends on timing (see the long comment in the
middle of the test).

I'll disabled the small data frame protection for that test as well.

Mark

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

[tomcat] branch master updated: Fix rare test failure.

[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 ccab309  Fix rare test failure.
ccab309 is described below

commit ccab3098504dad8a49c8bdb31dfb660c15e4
Author: Mark Thomas 
AuthorDate: Mon Feb 10 19:55:44 2020 +

Fix rare test failure.
---
 test/org/apache/coyote/http2/TestHttp2Section_5_3.java | 4 
 1 file changed, 4 insertions(+)

diff --git a/test/org/apache/coyote/http2/TestHttp2Section_5_3.java 
b/test/org/apache/coyote/http2/TestHttp2Section_5_3.java
index 20a3b30..18eaf4f 100644
--- a/test/org/apache/coyote/http2/TestHttp2Section_5_3.java
+++ b/test/org/apache/coyote/http2/TestHttp2Section_5_3.java
@@ -55,6 +55,10 @@ public class TestHttp2Section_5_3 extends Http2TestBase {
 // This test uses small window updates that will trigger the excessive
 // overhead protection so disable it.
 http2Protocol.setOverheadWindowUpdateThreshold(0);
+// May also see (rarely, depends on timing) sequential 1 byte data
+// frames on the same Stream
+http2Protocol.setOverheadDataThreshold(0);
+
 
 // Default connection window size is 64k - 1. Initial request will have
 // used 8k (56k -1). Increase it to 57k


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

[tomcat] branch 9.0.x updated: Fix rare test failure.

[markt]

This is an automated email from the ASF dual-hosted git repository.

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


The following commit(s) were added to refs/heads/9.0.x by this push:
 new fe45e13  Fix rare test failure.
fe45e13 is described below

commit fe45e132ba0e572cee360e1f51f46e5e5296a2f4
Author: Mark Thomas 
AuthorDate: Mon Feb 10 19:55:44 2020 +

Fix rare test failure.
---
 test/org/apache/coyote/http2/TestHttp2Section_5_3.java | 4 
 1 file changed, 4 insertions(+)

diff --git a/test/org/apache/coyote/http2/TestHttp2Section_5_3.java 
b/test/org/apache/coyote/http2/TestHttp2Section_5_3.java
index 20a3b30..18eaf4f 100644
--- a/test/org/apache/coyote/http2/TestHttp2Section_5_3.java
+++ b/test/org/apache/coyote/http2/TestHttp2Section_5_3.java
@@ -55,6 +55,10 @@ public class TestHttp2Section_5_3 extends Http2TestBase {
 // This test uses small window updates that will trigger the excessive
 // overhead protection so disable it.
 http2Protocol.setOverheadWindowUpdateThreshold(0);
+// May also see (rarely, depends on timing) sequential 1 byte data
+// frames on the same Stream
+http2Protocol.setOverheadDataThreshold(0);
+
 
 // Default connection window size is 64k - 1. Initial request will have
 // used 8k (56k -1). Increase it to 57k


-
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 rare test failure.

[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 38a2f4e  Fix rare test failure.
38a2f4e is described below

commit 38a2f4ecda7917aec3332e93a79a3622a6709299
Author: Mark Thomas 
AuthorDate: Mon Feb 10 19:55:44 2020 +

Fix rare test failure.
---
 test/org/apache/coyote/http2/TestHttp2Section_5_3.java | 4 
 1 file changed, 4 insertions(+)

diff --git a/test/org/apache/coyote/http2/TestHttp2Section_5_3.java 
b/test/org/apache/coyote/http2/TestHttp2Section_5_3.java
index 0a4c571..a89a762 100644
--- a/test/org/apache/coyote/http2/TestHttp2Section_5_3.java
+++ b/test/org/apache/coyote/http2/TestHttp2Section_5_3.java
@@ -55,6 +55,10 @@ public class TestHttp2Section_5_3 extends Http2TestBase {
 // This test uses small window updates that will trigger the excessive
 // overhead protection so disable it.
 http2Protocol.setOverheadWindowUpdateThreshold(0);
+// May also see (rarely, depends on timing) sequential 1 byte data
+// frames on the same Stream
+http2Protocol.setOverheadDataThreshold(0);
+
 
 // Default connection window size is 64k - 1. Initial request will have
 // used 8k (56k -1). Increase it to 57k


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

buildbot success in on tomcat-trunk

[buildbot]

The Buildbot has detected a restored build on builder tomcat-trunk while 
building tomcat. Full details are available at:
https://ci.apache.org/builders/tomcat-trunk/builds/4930

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

Buildslave for this Build: asf946_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' 
triggered this build
Build Source Stamp: [branch master] ccab3098504dad8a49c8bdb31dfb660c15e4
Blamelist: Mark Thomas 

Build succeeded!

Sincerely,
 -The Buildbot




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

UTF-8 properties files and BOMs

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I've recently begun making a change to my application's resource
bundles, converting them into UTF-8 for readability and converting
them to ISO-8859-1 during my build process to make ResourceBundle happy.

I have everything working, except that Eclipse still thinks that my
files ought to be ISO-8859-1 and ruins them when I load them.
Sometimes, it's very obvious and that's not a problem: a developer
will see that and fix it before continuing. But some files are only
*slightly* broken by this and someone might make a mistake.

NOTE: We don't keep Eclipse settings in revision-control, so I can't
modify everyone's Eclipse configuration. We are using svn and
svn:mime-type is correctly set for these files; Eclipse just ignores tha
t.

Anyway, I found that adding a UTF-8 BOM to the beginning of the file
fixes that issue and Eclipse does the right thing.

As a sanity check. I looked at how Tomcat's files are laid-out and I
don't see any BOMs.

Should we add BOMs? Is there any reason NOT to use a BOM? These are
file types that are officially supposed to be ISO-8859-1 but everyone
wants to handle them differently, so I think adding BOMs might be a
good idea so that editors are always informed of exactly what's happenin
g.

WDYT?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5BxBIACgkQHPApP6U8
pFguIw//aJRuOHxjeNX5/Fh981aG3Vajr0+W3PvBFuF85WpNtGAHGA/V2uCy7uY3
arZBGrE9HvLu0m+1ezs2oB9/craJogOIm/H7n5nDHDAk+Y9S6IIvookTXUIQrMH/
Eqqv4FWfJpHQKj4jE43nWR6SyJsll7TZ3GJ5jwnq4DpcZodSsyzneKchyys14YTp
7+zALlaVZV4+82aAbFPc6Z3WIiHCNXrHrixYOLgq6XZ8hwS7TP//vMTkMn8Rq1CW
HJZ6k09+KLWTeMbPPUdbqFj8znl3UIbUSgx2Jq/MxNqZikBoiV9WYDAgFFNkA3OW
VOSNdLSmHqx+mAz3l2LaVXItb8cdHoK/zhRvzwYpq6oslApOcgn9ZQBxPBsmjx/8
PfyIUK7dnz3YO3fPBXEXtn9KyZ5lj98iarMPby2WIHJq1KJNslMUuAFTX9k6vL/1
WTcmF1VOfdBraWRhTZL5m9e48WIYXD1/jl+Px+R5MKRpBXgyKOIAZiAE/k2NsDsC
bsl1ua0ITpuVqeCXRdqn8YsBh8yBmFW35Z+5QDPoxM6o5A7EKirzAW8ILBGRZoGT
7HGFdW1/47vbSRztzInzKUvUAg0jtNVy9Yt8S+/mQfm2mlbqtKrHrjN+nqi9mh/H
SYe3kJRFgNTXIBLds847vZwOXoq+wtpOps5uTRUPAWjuzL1Rt+8=
=srFY
-END PGP SIGNATURE-

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

Re: UTF-8 properties files and BOMs

[Martin Grigorov]

Hi Chris,

On Mon, Feb 10, 2020 at 10:59 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> I've recently begun making a change to my application's resource
> bundles, converting them into UTF-8 for readability and converting
> them to ISO-8859-1 during my build process to make ResourceBundle happy.
>

I guess you use Java 8.
Newer versions of Java try UTF-8 first and then fallback to ISO-8859-1:
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/PropertyResourceBundle.html

API Note:
PropertyResourceBundle can be constructed either from an InputStream or a
Reader, which represents a property file. Constructing a
PropertyResourceBundle instance from an InputStream requires that the input
stream be encoded in UTF-8. By default, if a MalformedInputException

 or an UnmappableCharacterException

 occurs on reading the input stream, then the PropertyResourceBundle instance
resets to the state before the exception, re-reads the input stream in
ISO-8859-1, and continues reading. If the system property
java.util.PropertyResourceBundle.encoding is set to either "ISO-8859-1" or
"UTF-8", the input stream is solely read in that encoding, and throws the
exception if it encounters an invalid sequence. If "ISO-8859-1" is
specified, characters that cannot be represented in ISO-8859-1 encoding
must be represented by Unicode Escapes as defined in section 3.3 of The
Java™ Language Specification whereas the other constructor which takes a
Reader does not have that limitation. Other encoding values are ignored for
this system property. The system property is read and evaluated when
initializing this class. Changing or removing the property has no effect
after the initialization.


>
> I have everything working, except that Eclipse still thinks that my
> files ought to be ISO-8859-1 and ruins them when I load them.
> Sometimes, it's very obvious and that's not a problem: a developer
> will see that and fix it before continuing. But some files are only
> *slightly* broken by this and someone might make a mistake.
>
> NOTE: We don't keep Eclipse settings in revision-control, so I can't
> modify everyone's Eclipse configuration. We are using svn and
> svn:mime-type is correctly set for these files; Eclipse just ignores tha
> t.
>
> Anyway, I found that adding a UTF-8 BOM to the beginning of the file
> fixes that issue and Eclipse does the right thing.
>
> As a sanity check. I looked at how Tomcat's files are laid-out and I
> don't see any BOMs.
>
> Should we add BOMs? Is there any reason NOT to use a BOM? These are
> file types that are officially supposed to be ISO-8859-1 but everyone
> wants to handle them differently, so I think adding BOMs might be a
> good idea so that editors are always informed of exactly what's happenin
> g.
>
> WDYT?
>

I don't use Eclipse so I cannot help you with that.
My gut feeling says: If it ain't broken then don't fix it. If no one
complained so far then probably such kind of improvement is not worth it.



>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5BxBIACgkQHPApP6U8
> pFguIw//aJRuOHxjeNX5/Fh981aG3Vajr0+W3PvBFuF85WpNtGAHGA/V2uCy7uY3
> arZBGrE9HvLu0m+1ezs2oB9/craJogOIm/H7n5nDHDAk+Y9S6IIvookTXUIQrMH/
> Eqqv4FWfJpHQKj4jE43nWR6SyJsll7TZ3GJ5jwnq4DpcZodSsyzneKchyys14YTp
> 7+zALlaVZV4+82aAbFPc6Z3WIiHCNXrHrixYOLgq6XZ8hwS7TP//vMTkMn8Rq1CW
> HJZ6k09+KLWTeMbPPUdbqFj8znl3UIbUSgx2Jq/MxNqZikBoiV9WYDAgFFNkA3OW
> VOSNdLSmHqx+mAz3l2LaVXItb8cdHoK/zhRvzwYpq6oslApOcgn9ZQBxPBsmjx/8
> PfyIUK7dnz3YO3fPBXEXtn9KyZ5lj98iarMPby2WIHJq1KJNslMUuAFTX9k6vL/1
> WTcmF1VOfdBraWRhTZL5m9e48WIYXD1/jl+Px+R5MKRpBXgyKOIAZiAE/k2NsDsC
> bsl1ua0ITpuVqeCXRdqn8YsBh8yBmFW35Z+5QDPoxM6o5A7EKirzAW8ILBGRZoGT
> 7HGFdW1/47vbSRztzInzKUvUAg0jtNVy9Yt8S+/mQfm2mlbqtKrHrjN+nqi9mh/H
> SYe3kJRFgNTXIBLds847vZwOXoq+wtpOps5uTRUPAWjuzL1Rt+8=
> =srFY
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>