[GitHub] [tomcat] rotty3000 opened a new pull request #302: Store common build details in a shared build-defaults.bnd

[GitBox]

rotty3000 opened a new pull request #302:
URL: https://github.com/apache/tomcat/pull/302


   Signed-off-by: Raymond Augé 



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



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

[Bug 64528] Regression in 8.5.56, no statistics in GlobalRequestProcessor MBean anymore

[bugzilla]

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

--- Comment #5 from Mark Thomas  ---
Correct HTTP/2 traffic isn't included in the the GlobalRequestProcessor metrics
either. I'll add a note to Bug 63362.

-- 
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 63362] GlobalRequestProcessor statistics in MBean does not count Websocket communication

[bugzilla]

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

--- Comment #5 from Mark Thomas  ---
Note: HTTP/2 traffic is also excluded from the GlobalRequestProcessor metrics.

-- 
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 64528] Regression in 8.5.56, no statistics in GlobalRequestProcessor MBean anymore

[bugzilla]

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

--- Comment #4 from Markus Schlegel  ---
Given that it is related to the http/2 protocol upgrade, I think it indeed is
related to Bug 63362.
Nevertheless, since Tomcat Performance optimisation literature all over the net
refers to GlobalRequestProcessor as a source of metrics, I would very welcome
if that MBean would also work for upgraded http/2 connections.
Also it is still unclear for me which code change caused this problem to appear
in 8.5.56.

-- 
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 64528] Regression in 8.5.56, no statistics in GlobalRequestProcessor MBean anymore

[bugzilla]

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

--- Comment #3 from Markus Schlegel  ---
If I disable the http/2 upgrade, it works again:

boolean ENABLE_HTTP2 = false;
if (ENABLE_HTTP2) {
Http2Protocol http2Protocol = new Http2Protocol();
sslConnector.addUpgradeProtocol(http2Protocol);
}

We had the ENABLE_HTTP2=true in our code before, such that our customers could
easily enable http/2 by simply adding the native library. However, most of the
time this was not the case. Therefore, http/2 was never really used in our app.
I have disabled it now by default and GlobalRequestProcessor is working again
now.
Please note, that using GlobalRequestProcessor for performance metrics is being
recommended in many documentations about Tomcat. People and tools might rely on
it.

-- 
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: Changing the name of the default branch in our git repos

[Romain Manni-Bucau]

Hi,

Do you know if there would be a redirect of existing PR and "existing"
references to master or does it break the ecosystem for a while - if so I'm
not sure it is worth it ?
If it does not break anything "latest" does not sound that bad and likely
avoids this superior/inferior thought people can have as with master or
main and it sounds more modern than trunk ;).

Indeed, just my 2 cents ;).

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mar. 16 juin 2020 à 17:36, Martin Grigorov  a
écrit :

> Hi,
>
> On Tue, Jun 16, 2020 at 11:02 AM Mark Thomas  wrote:
>
>> All,
>>
>> You may have seen the recent discussions both inside and outside the ASF
>> about the user of "master" as the name of the default git branch. If you
>> haven't, the short version is that the name can be traced back to
>> master/slave and its associations with human slavery.
>>
>> I'd like to propose that the Apache Tomcat project renames the master
>> branch in all of the project repositories.
>>
>> I think there are two front runners for the new name:
>>
>> - main - this looks to be the name GitHub and a number of OSS projects
>>  will be switching to
>>
>> - trunk - reflects the Subversion heritage of both the project and the
>>   ASF
>>
>> Other options I have seen suggested include "default", "dev", "develop".
>> Other suggestions welcome.
>>
>> Personally, I am leaning towards main as that looks to be the choice of
>> the majority and using the majority choice will make it (a little bit)
>> easier for new community members to find their way around the project.
>>
>> In terms of impact, changing the name is going to break stuff. It is
>> really creating a new branch and deleting the old one.
>>
>> Deleting a branch triggers the automatic closure of github PRs against
>> that branch. However if we create "$new_branch" we can edit the PRs to
>> use "$new_branch" before we delete master. Given the small number of
>> open PRs that is easily done.
>>
>> CI systems will need to be updated (buildbot, gump). That should be
>> relatively simple.
>>
>> Docs will need to be updated (relatively simple).
>>
>> Committers and contributors will rebase any local branches to $new_branch
>>
>> Having thought about what is involved, renaming the default branch
>> doesn't look as problematic as I thought it might be. This looks like
>> something that could be done in around an hour for all our repos.
>>
>> Thoughts?
>>
>
> I, personally, do not see any relation between technical nomenclature and
> social problems in real life.
> I have many colored skin friends and colleagues and I've never heard
> anyone making such associations.
> I am Bulgarian. Until not so long ago we were ruled for 5 centuries by
> Ottomans but I do not feel like a slave and I don't find 'master' branch
> name anyhow related to slavery.
> I am -0 on such change and any other change that comes from politics.
>
> But if we are going to change the branch name then I suggest '10.0.x'.
> This way it will be consistent with all other branches.
>
> Martin
>
>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>

[Bug 64528] Regression in 8.5.56, no statistics in GlobalRequestProcessor MBean anymore

[bugzilla]

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

Mark Thomas  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|NEW |RESOLVED

--- Comment #2 from Mark Thomas  ---
And I can't reproduce it from the 8.5.56 tag with either a standard Tomcat
instance nor with the embedded JARs.

This looks like configuration error at this point. Please use the users mailing
list for further assistance.

http://tomcat.apache.org/lists.html#tomcat-users

-- 
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: Changing the name of the default branch in our git repos

[Martin Grigorov]

Hi,

On Tue, Jun 16, 2020 at 11:02 AM Mark Thomas  wrote:

> All,
>
> You may have seen the recent discussions both inside and outside the ASF
> about the user of "master" as the name of the default git branch. If you
> haven't, the short version is that the name can be traced back to
> master/slave and its associations with human slavery.
>
> I'd like to propose that the Apache Tomcat project renames the master
> branch in all of the project repositories.
>
> I think there are two front runners for the new name:
>
> - main - this looks to be the name GitHub and a number of OSS projects
>  will be switching to
>
> - trunk - reflects the Subversion heritage of both the project and the
>   ASF
>
> Other options I have seen suggested include "default", "dev", "develop".
> Other suggestions welcome.
>
> Personally, I am leaning towards main as that looks to be the choice of
> the majority and using the majority choice will make it (a little bit)
> easier for new community members to find their way around the project.
>
> In terms of impact, changing the name is going to break stuff. It is
> really creating a new branch and deleting the old one.
>
> Deleting a branch triggers the automatic closure of github PRs against
> that branch. However if we create "$new_branch" we can edit the PRs to
> use "$new_branch" before we delete master. Given the small number of
> open PRs that is easily done.
>
> CI systems will need to be updated (buildbot, gump). That should be
> relatively simple.
>
> Docs will need to be updated (relatively simple).
>
> Committers and contributors will rebase any local branches to $new_branch
>
> Having thought about what is involved, renaming the default branch
> doesn't look as problematic as I thought it might be. This looks like
> something that could be done in around an hour for all our repos.
>
> Thoughts?
>

I, personally, do not see any relation between technical nomenclature and
social problems in real life.
I have many colored skin friends and colleagues and I've never heard anyone
making such associations.
I am Bulgarian. Until not so long ago we were ruled for 5 centuries by
Ottomans but I do not feel like a slave and I don't find 'master' branch
name anyhow related to slavery.
I am -0 on such change and any other change that comes from politics.

But if we are going to change the branch name then I suggest '10.0.x'. This
way it will be consistent with all other branches.

Martin


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

[Bug 64528] Regression in 8.5.56, no statistics in GlobalRequestProcessor MBean anymore

[bugzilla]

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

Mark Thomas  changed:

   What|Removed |Added

 OS||All

--- Comment #1 from Mark Thomas  ---
OK. I can't reproduce this with current 8.5.x and a standard Tomcat build.

Switching to the 8.5.56 tag...

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

[tomcat] branch 8.5.x updated: Fix BZ 64522 back port

[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 1c318d2  Fix BZ 64522 back port
1c318d2 is described below

commit 1c318d20bd12adb5eb6549d3e1fa55516775049a
Author: Mark Thomas 
AuthorDate: Tue Jun 16 16:28:54 2020 +0100

Fix BZ 64522 back port
---
 build.xml | 10 --
 1 file changed, 10 deletions(-)

diff --git a/build.xml b/build.xml
index f715a12..348487c 100644
--- a/build.xml
+++ b/build.xml
@@ -849,11 +849,6 @@
   filesDir="${tomcat.classes}"
   filesId="files.catalina-ha" />
 
-
-
-
 
 
   filesDir="java"
   filesId="files.catalina-ha" />
 
-
-
-
 
 

[Bug 64527] JarWarResourceSet gc caused class loading slowly

[bugzilla]

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

Mark Thomas  changed:

   What|Removed |Added

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

--- Comment #1 from Mark Thomas  ---
Bugzilla is not a support forum. Please direct your question to the Apache
Tomcat users mailing list.

http://tomcat.apache.org/lists.html

-- 
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 64528] New: Regression in 8.5.56, no statistics in GlobalRequestProcessor MBean anymore

[bugzilla]

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

Bug ID: 64528
   Summary: Regression in 8.5.56, no statistics in
GlobalRequestProcessor MBean anymore
   Product: Tomcat 8
   Version: 8.5.56
  Hardware: PC
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: sch...@gmail.com
  Target Milestone: 

We have used GlobalRequestProcessor MBean recently to access embedded Tomcat's
performance metrics.
This worked very well with 8.5.55 and 8.5.54 (and maybe it worked before too,
but not tested).
With 8.5.56, all values of GlobalRequestProcessor are 0 now.

I made a diff of both versions (8.5.55 against 8.5.56) sourcecode but could not
find an obvious source of the problem. 

I have seen Bug 63362, but this is not related, since it worked before 8.5.56
and we are not using websockets.

-- 
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 64522] package jars in effective dependency order

[bugzilla]

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

Mark Thomas  changed:

   What|Removed |Added

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

--- Comment #3 from Mark Thomas  ---
Fixed in:
- master for 10.0.0-M7 onwards
- 9.0.x for 9.0.37 onwards
- 8.5.x for 8.5.57 onwards

Thanks for the PR.

While not strictly required for 8.5.x I back-ported it anyway to keep the code
in sync to ease any future back-ports.

-- 
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: Java library bug in JCEKS keystore loader

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michael,

On 6/13/20 14:54, Michael Osipov wrote:
> Am 2020-06-12 um 23:54 schrieb Christopher Schultz:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>
>> All,
>>
>> I've been writing a Java-based certification-expiration checking
>> utility that can handle all kinds of file formats like PEM and
>> the various keystore formats supported by the JVM.
>>
>> Since it's not possible to tell what type of keystore is being
>> loaded without writing a bunch of magic-checking code or
>> implementing an ASN.1 parser (no thank you), I simply try all
>> keystore types until I find one that works. I'm using a
>> rewindable InputStream which works well .
>
> there is no need to, use Apache Directory Kerby ASN.1 module. I use
> it too and it works very well for my certiticate tasks at work.

It's pretty simple to look for "-BEGIN" or hand-off things to
KeyStore.load. Right now, this is a single-class utility with no
dependencies. No need to add more dependencies if they aren't
necessary. I'm not looking to build a complete certificate
manipulation framework.

Attempting to load using KeyStore.load will be required, anyway, for
keystore types such as JKS, JCEKS, Windows-MY, Windows-ROOT,
KeychainStore, etc. which aren't ASN.1 files like PKCS12.

Anyway, the point was that there is a bug in one of the keystore
implementations that may cause some troubles.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7o4iMACgkQHPApP6U8
pFiiiQ/+I2UHDRSi2xqP1ehQIBvwMXDxtXq71nCeZrN6VTEyPJS3V1IqJVKG4eks
9rAc7QnVYBMSaWglzVJQKKl8zdf8GncOYhk8JkDEON7LjLDuyLRj2m/bHkivQs6Q
AY/Fo9CRSscxV1YS78erNdMDLwWr7YXmkeJypJ1IL8OaB5kNzIak3t70zb3XRSWb
3JQ4F/64AYv+nnapGbsT2pYTMy6vKOVTearrXKZQJGRD0NIbz7xAh/tceem4eeUh
SGQLPJW6Bg1fN52bmKOuluCCu95K8u2eblqoPVlTvtJutxGDSz2HGCjJLISqgJrZ
PvwIpsbpCQ8x1vOXL4geu0XhXmpEtA49s3sj8c0aFUM2Aq9z4kRfQz0/BQQaeZo4
r1inQ4CSj2dhtE/7lGtMG4aXjoJgtvC81rcJR/rrr2VjZwQOWSHmcPVWKAG0Pk00
NffUll3+BcZnFbeMzV/GkMonY7bXfHvDkvlwjdA8ykAWAYXUy4fsQoHwU+RiODLh
ds7OwjtA6WlJMPvWprZXucmhEAXDBJJsU55ttEtIeDMf3NU6j9ckHwDvzg9M1BcW
2rPgZyOoZiz9vwsjRyEXp7V/luMZI7KnbTpa/l/DkU+ET5284B/zy95V3/CU8HgD
oYY5D/PtEdE6S4Y34whpcb7dUffKoFIMDVaDXGbcaA8D5VwRi1g=
=0dZ2
-END PGP SIGNATURE-

-
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 BZ 64522 - package jars in effective dependency order

[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 efa4cfc  Fix BZ 64522 - package jars in effective dependency order
efa4cfc is described below

commit efa4cfc4411d0bed86490ea7de22f6a7e33fbc22
Author: Raymond Augé 
AuthorDate: Sat Jun 13 19:55:07 2020 -0400

Fix BZ 64522 - package jars in effective dependency order

(only order is changed, no other changes)
---
 build.xml  | 238 +++--
 webapps/docs/changelog.xml |   4 +
 2 files changed, 126 insertions(+), 116 deletions(-)

diff --git a/build.xml b/build.xml
index dccfc78..1900b78 100644
--- a/build.xml
+++ b/build.xml
@@ -746,6 +746,12 @@
   
 
   
+
+
 
 
 
-
-
-
-
+
 
 
-
+
+
+
+
 
 
-
-
+
 
 
@@ -803,81 +808,75 @@
   filesId="files.bootstrap"
   manifest="${tomcat.manifests}/bootstrap.jar.manifest" />
 
-
-
+
 
-
-
+
 
-
-
+
 
-
-
 
-
-
+
 
-
-
-
-
-
+
 
-
-
+
 
-
-
+
 
-
-
+
 
-
-
+
 
-
+
+  filesId="files.catalina-ant" />
 
-
-
+
 
 
@@ -887,6 +886,13 @@
   meta-inf="${tomcat.manifests}/jasper-el.jar"
   addOSGi="true" />
 
+
+
+
 
 
+
 
-
 
-
 
+
 
@@ -2595,7 +2601,13 @@ skip.installer property in build.properties" />
   notice="${tomcat.manifests}/servlet-api.jar.notice"
   license="${tomcat.manifests}/servlet-api.jar.license" />
 
-
+
+
+
+
 
   notice="${tomcat.manifests}/jsp-api.jar.notice"
   license="${tomcat.manifests}/jsp-api.jar.license" />
 
-
-
-
-
+
 
 
-
-
-
-
+
 
   notice="${tomcat.manifests}/jaspic-api.jar.notice"
   license="${tomcat.manifests}/jaspic-api.jar.license" />
 
+
+
+
 
 
 
-
-
+
+  filesId="files.tomcat-util" />
 
-
-
+
+  filesId="files.tomcat-api" />
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
 
-
-
+
+  filesId="files.catalina" />
 
 
 
 
+
+
+
 
 
   filesDir="java"
   filesId="files.catalina-storeconfig" />
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+  filesId="files.jasper-el" />
 
 
 
 
-
-
-
 
 
+  
+64522: Package jars in effective dependency order. Pull
+request provided by Raymond Augé. (markt)
+  
 
   
 


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

[GitHub] [tomcat] markt-asf merged pull request #301: Fix BZ 64522 - package jars in effective dependency order (only order…

[GitBox]

markt-asf merged pull request #301:
URL: https://github.com/apache/tomcat/pull/301


   



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



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

[tomcat] branch master updated: Fix BZ 64522 - package jars in effective dependency order (only order is changed, no other changes)

[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 f94b2f3  Fix BZ 64522 - package jars in effective dependency order 
(only order is changed, no other changes)
f94b2f3 is described below

commit f94b2f3a62e484ba979476bda9d66acf6d517134
Author: Raymond Augé 
AuthorDate: Sat Jun 13 19:55:07 2020 -0400

Fix BZ 64522 - package jars in effective dependency order (only order is 
changed, no other changes)

Signed-off-by: Raymond Augé 
---
 build.xml  | 228 +++--
 webapps/docs/changelog.xml |   4 +
 2 files changed, 121 insertions(+), 111 deletions(-)

diff --git a/build.xml b/build.xml
index b77c03f..05ebace 100644
--- a/build.xml
+++ b/build.xml
@@ -762,6 +762,12 @@
   
 
   
+
+
 
 
 
-
-
-
 
 
 
+
+
+
 
 
 
-
-
+
 
 
@@ -819,81 +824,75 @@
   filesId="files.bootstrap"
   manifest="${tomcat.manifests}/bootstrap.jar.manifest" />
 
-
-
+
 
-
-
+
 
-
-
+
 
-
-
 
-
-
+
 
-
-
-
-
-
+
 
-
-
+
 
-
-
+
 
-
-
+
 
-
-
+
 
-
+
+  filesId="files.catalina-ant" />
 
-
-
+
 
 
@@ -903,6 +902,13 @@
   meta-inf="${tomcat.manifests}/jasper-el.jar"
   addOSGi="true" />
 
+
+
+
 
 
+
 
-
 
-
 
+
 
@@ -2612,6 +2618,12 @@ skip.installer property in build.properties" />
   notice="${tomcat.manifests}/servlet-api.jar.notice"
   license="${tomcat.manifests}/servlet-api.jar.license" />
 
+
+
+
 
 
   notice="${tomcat.manifests}/jsp-api.jar.notice"
   license="${tomcat.manifests}/jsp-api.jar.license" />
 
-
-
-
 
 
 
-
-
-
 
 
   notice="${tomcat.manifests}/jaspic-api.jar.notice"
   license="${tomcat.manifests}/jaspic-api.jar.license" />
 
+
+
+
 
 
 
-
-
+
+  filesId="files.tomcat-util" />
 
-
-
+
+  filesId="files.tomcat-api" />
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
 
-
-
+
+  filesId="files.catalina" />
 
 
 
 
+
+
+
 
 
   filesDir="java"
   filesId="files.catalina-storeconfig" />
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+  filesId="files.jasper-el" />
 
 
 
 
-
-
-
 
 
+  
+64522: Package jars in effective dependency order. Pull
+request provided by Raymond Augé. (markt)
+  
 
   
 


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

Re: JPMS module names

[Mark Thomas]

On 16/06/2020 15:52, Raymond Auge wrote:
> 
> 
> On Tue, Jun 16, 2020 at 10:43 AM Mark Thomas  > wrote:
> 
> On 16/06/2020 15:00, Raymond Auge wrote:
> > Hey folks,
> >
> > I've extrapolated what I found as basis for a rule to create module
> > names and this is what I've come up with:
> >
> > module.name  :
> org.apache.${replace;${Bundle-Name};-;.}
> >
> > that is:
> > - take the `Bundle-Name` value (which appears to have a consistent
> format)
> > - replace dashes with dots
> > - prefix with "org.apache."
> >
> > The result is:
> >
> > org.apache.tomcat.api
> > org.apache.tomcat.catalina
> > org.apache.tomcat.catalina.ant
> > org.apache.tomcat.catalina.ha
> > org.apache.tomcat.coyote
> > org.apache.tomcat.dbcp
> > org.apache.tomcat.jasper
> > org.apache.tomcat.jasper.el
> > org.apache.tomcat.jni
> > org.apache.tomcat.juli
> > org.apache.tomcat.ssi
> > org.apache.tomcat.storeconfig
> > org.apache.tomcat.tribes
> > org.apache.tomcat.util
> > org.apache.tomcat.util.scan
> > org.apache.tomcat.websocket
> 
> 
> Are we at least fine with the tomcat module names? (notice I did miss
> tomcat-jdbc which has a special build that I still need to work on).

They look OK to me.

> > For the spec API I've used the official names pulled from each
> spec project:
> >
> > jakarta.annotation
> > jakarta.el.api
> > jakarta.security.enterprise
> > jakarta.servlet
> > jakarta.servlet.jsp
> > jakarta.websocket.api
> >
> > Does that look correct?
> 
> A couple of the spec ones look inconsistent. The naming guidance for
> Jakarta is:
> https://wiki.eclipse.org/JakartaEE_Maven_Versioning_Rules
> 
> I don't think the Jakarta PMC has made a final decision on JMPS rules or
> even if a JPMS name is required. I have proposed that as a general rule
> each project uses the OSGi Bundle-SymbolicName with any "-" characters
> replaced by "." as the JPMS module name.
> 
> I'd expect at least JSP and servlet to switch to that format by the time
> of the Jakarta EE 9 release.
> 
> 
> I will adjust and follow your proposal for the time being then.

OK. I guess explicitly stating something and being "wrong" is no worse
than one being implied from the file name and being "wrong".

I'll see what I can do to get clearer guidance from the Jakarta EE PMC.

Mark

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

Re: JPMS module names

[Raymond Auge]

On Tue, Jun 16, 2020 at 10:43 AM Mark Thomas  wrote:

> On 16/06/2020 15:00, Raymond Auge wrote:
> > Hey folks,
> >
> > I've extrapolated what I found as basis for a rule to create module
> > names and this is what I've come up with:
> >
> > module.name :
> org.apache.${replace;${Bundle-Name};-;.}
> >
> > that is:
> > - take the `Bundle-Name` value (which appears to have a consistent
> format)
> > - replace dashes with dots
> > - prefix with "org.apache."
> >
> > The result is:
> >
> > org.apache.tomcat.api
> > org.apache.tomcat.catalina
> > org.apache.tomcat.catalina.ant
> > org.apache.tomcat.catalina.ha
> > org.apache.tomcat.coyote
> > org.apache.tomcat.dbcp
> > org.apache.tomcat.jasper
> > org.apache.tomcat.jasper.el
> > org.apache.tomcat.jni
> > org.apache.tomcat.juli
> > org.apache.tomcat.ssi
> > org.apache.tomcat.storeconfig
> > org.apache.tomcat.tribes
> > org.apache.tomcat.util
> > org.apache.tomcat.util.scan
> > org.apache.tomcat.websocket
>

Are we at least fine with the tomcat module names? (notice I did miss
tomcat-jdbc which has a special build that I still need to work on).


> >
> > For the spec API I've used the official names pulled from each spec
> project:
> >
> > jakarta.annotation
> > jakarta.el.api
> > jakarta.security.enterprise
> > jakarta.servlet
> > jakarta.servlet.jsp
> > jakarta.websocket.api
> >
> > Does that look correct?
>
> A couple of the spec ones look inconsistent. The naming guidance for
> Jakarta is:
> https://wiki.eclipse.org/JakartaEE_Maven_Versioning_Rules
>
> I don't think the Jakarta PMC has made a final decision on JMPS rules or
> even if a JPMS name is required. I have proposed that as a general rule
> each project uses the OSGi Bundle-SymbolicName with any "-" characters
> replaced by "." as the JPMS module name.
>
> I'd expect at least JSP and servlet to switch to that format by the time
> of the Jakarta EE 9 release.
>

I will adjust and follow your proposal for the time being then.

- Ray


>
> JPMS name feels like a bit of a moving target at this point.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)

Re: JPMS module names

[Mark Thomas]

On 16/06/2020 15:00, Raymond Auge wrote:
> Hey folks,
> 
> I've extrapolated what I found as basis for a rule to create module
> names and this is what I've come up with:
> 
> module.name : org.apache.${replace;${Bundle-Name};-;.}
> 
> that is:
> - take the `Bundle-Name` value (which appears to have a consistent format)
> - replace dashes with dots
> - prefix with "org.apache."
> 
> The result is:
> 
> org.apache.tomcat.api
> org.apache.tomcat.catalina
> org.apache.tomcat.catalina.ant
> org.apache.tomcat.catalina.ha
> org.apache.tomcat.coyote
> org.apache.tomcat.dbcp
> org.apache.tomcat.jasper
> org.apache.tomcat.jasper.el
> org.apache.tomcat.jni
> org.apache.tomcat.juli
> org.apache.tomcat.ssi
> org.apache.tomcat.storeconfig
> org.apache.tomcat.tribes
> org.apache.tomcat.util
> org.apache.tomcat.util.scan
> org.apache.tomcat.websocket
> 
> For the spec API I've used the official names pulled from each spec project:
> 
> jakarta.annotation
> jakarta.el.api
> jakarta.security.enterprise
> jakarta.servlet
> jakarta.servlet.jsp
> jakarta.websocket.api
> 
> Does that look correct?

A couple of the spec ones look inconsistent. The naming guidance for
Jakarta is:
https://wiki.eclipse.org/JakartaEE_Maven_Versioning_Rules

I don't think the Jakarta PMC has made a final decision on JMPS rules or
even if a JPMS name is required. I have proposed that as a general rule
each project uses the OSGi Bundle-SymbolicName with any "-" characters
replaced by "." as the JPMS module name.

I'd expect at least JSP and servlet to switch to that format by the time
of the Jakarta EE 9 release.

JPMS name feels like a bit of a moving target at this point.

Mark

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

JPMS module names

[Raymond Auge]

Hey folks,

I've extrapolated what I found as basis for a rule to create module names
and this is what I've come up with:

module.name: org.apache.${replace;${Bundle-Name};-;.}

that is:
- take the `Bundle-Name` value (which appears to have a consistent format)
- replace dashes with dots
- prefix with "org.apache."

The result is:

org.apache.tomcat.api
org.apache.tomcat.catalina
org.apache.tomcat.catalina.ant
org.apache.tomcat.catalina.ha
org.apache.tomcat.coyote
org.apache.tomcat.dbcp
org.apache.tomcat.jasper
org.apache.tomcat.jasper.el
org.apache.tomcat.jni
org.apache.tomcat.juli
org.apache.tomcat.ssi
org.apache.tomcat.storeconfig
org.apache.tomcat.tribes
org.apache.tomcat.util
org.apache.tomcat.util.scan
org.apache.tomcat.websocket

For the spec API I've used the official names pulled from each spec project:

jakarta.annotation
jakarta.el.api
jakarta.security.enterprise
jakarta.servlet
jakarta.servlet.jsp
jakarta.websocket.api

Does that look correct?

-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)

[tomcat] branch 8.5.x updated: Return correct response code for HTTP/2 when method is not implemented

[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 cc53fc0  Return correct response code for HTTP/2 when method is not 
implemented
cc53fc0 is described below

commit cc53fc08df882a9294549b35d1f9fd005c96eabe
Author: Mark Thomas 
AuthorDate: Tue Jun 16 14:26:49 2020 +0100

Return correct response code for HTTP/2 when method is not implemented
---
 java/javax/servlet/http/HttpServlet.java   |  36 +++-
 test/javax/servlet/http/TestHttpServlet.java   | 102 +
 .../coyote/http11/TestHttp11InputBufferCRLF.java   |   1 -
 test/org/apache/coyote/http2/TestHttpServlet.java  |  59 
 webapps/docs/changelog.xml |   6 ++
 5 files changed, 181 insertions(+), 23 deletions(-)

diff --git a/java/javax/servlet/http/HttpServlet.java 
b/java/javax/servlet/http/HttpServlet.java
index aedbee6..57617e7 100644
--- a/java/javax/servlet/http/HttpServlet.java
+++ b/java/javax/servlet/http/HttpServlet.java
@@ -168,13 +168,8 @@ public abstract class HttpServlet extends GenericServlet {
 protected void doGet(HttpServletRequest req, HttpServletResponse resp)
 throws ServletException, IOException
 {
-String protocol = req.getProtocol();
 String msg = lStrings.getString("http.method_get_not_supported");
-if (protocol.endsWith("1.1")) {
-resp.sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED, msg);
-} else {
-resp.sendError(HttpServletResponse.SC_BAD_REQUEST, msg);
-}
+sendMethodNotAllowed(req, resp, msg);
 }
 
 
@@ -308,13 +303,8 @@ public abstract class HttpServlet extends GenericServlet {
 protected void doPost(HttpServletRequest req, HttpServletResponse resp)
 throws ServletException, IOException {
 
-String protocol = req.getProtocol();
 String msg = lStrings.getString("http.method_post_not_supported");
-if (protocol.endsWith("1.1")) {
-resp.sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED, msg);
-} else {
-resp.sendError(HttpServletResponse.SC_BAD_REQUEST, msg);
-}
+sendMethodNotAllowed(req, resp, msg);
 }
 
 
@@ -363,13 +353,8 @@ public abstract class HttpServlet extends GenericServlet {
 protected void doPut(HttpServletRequest req, HttpServletResponse resp)
 throws ServletException, IOException {
 
-String protocol = req.getProtocol();
 String msg = lStrings.getString("http.method_put_not_supported");
-if (protocol.endsWith("1.1")) {
-resp.sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED, msg);
-} else {
-resp.sendError(HttpServletResponse.SC_BAD_REQUEST, msg);
-}
+sendMethodNotAllowed(req, resp, msg);
 }
 
 
@@ -411,12 +396,19 @@ public abstract class HttpServlet extends GenericServlet {
 HttpServletResponse resp)
 throws ServletException, IOException {
 
-String protocol = req.getProtocol();
 String msg = lStrings.getString("http.method_delete_not_supported");
-if (protocol.endsWith("1.1")) {
-resp.sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED, msg);
-} else {
+sendMethodNotAllowed(req, resp, msg);
+}
+
+
+private void sendMethodNotAllowed(HttpServletRequest req, 
HttpServletResponse resp, String msg) throws IOException {
+String protocol = req.getProtocol();
+// Note: Tomcat reports "" for HTTP/0.9 although some implementations
+//   may report HTTP/0.9
+if (protocol.length() == 0 || protocol.endsWith("0.9") || 
protocol.endsWith("1.0")) {
 resp.sendError(HttpServletResponse.SC_BAD_REQUEST, msg);
+} else {
+resp.sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED, msg);
 }
 }
 
diff --git a/test/javax/servlet/http/TestHttpServlet.java 
b/test/javax/servlet/http/TestHttpServlet.java
index 28be42d..00e4036 100644
--- a/test/javax/servlet/http/TestHttpServlet.java
+++ b/test/javax/servlet/http/TestHttpServlet.java
@@ -28,7 +28,10 @@ import javax.servlet.ServletException;
 import org.junit.Assert;
 import org.junit.Test;
 
+import org.apache.catalina.Context;
 import org.apache.catalina.core.StandardContext;
+import org.apache.catalina.startup.SimpleHttpClient;
+import org.apache.catalina.startup.TesterServlet;
 import org.apache.catalina.startup.Tomcat;
 import org.apache.catalina.startup.TomcatBaseTest;
 import org.apache.tomcat.util.buf.ByteChunk;
@@ -191,6 +194,105 @@ public class TestHttpServlet extends TomcatBaseTest {
 }
 
 
+@Test
+public void testUnimplementedMethodHttp09() throws Exception {
+doTestUnimplementedMethod("0.9");
+}
+
+
+@Test
+public void testUnimplementedMethod

[tomcat] branch 9.0.x updated: Return correct response code for HTTP/2 when method is not implemented

[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 dd2b95c  Return correct response code for HTTP/2 when method is not 
implemented
dd2b95c is described below

commit dd2b95cec05cce355f13db83a3294bb58d72e820
Author: Mark Thomas 
AuthorDate: Tue Jun 16 14:26:49 2020 +0100

Return correct response code for HTTP/2 when method is not implemented
---
 java/javax/servlet/http/HttpServlet.java   |  36 +++-
 test/javax/servlet/http/TestHttpServlet.java   | 102 +
 .../coyote/http11/TestHttp11InputBufferCRLF.java   |   1 -
 test/org/apache/coyote/http2/TestHttpServlet.java  |  59 
 webapps/docs/changelog.xml |   6 ++
 5 files changed, 181 insertions(+), 23 deletions(-)

diff --git a/java/javax/servlet/http/HttpServlet.java 
b/java/javax/servlet/http/HttpServlet.java
index aedbee6..57617e7 100644
--- a/java/javax/servlet/http/HttpServlet.java
+++ b/java/javax/servlet/http/HttpServlet.java
@@ -168,13 +168,8 @@ public abstract class HttpServlet extends GenericServlet {
 protected void doGet(HttpServletRequest req, HttpServletResponse resp)
 throws ServletException, IOException
 {
-String protocol = req.getProtocol();
 String msg = lStrings.getString("http.method_get_not_supported");
-if (protocol.endsWith("1.1")) {
-resp.sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED, msg);
-} else {
-resp.sendError(HttpServletResponse.SC_BAD_REQUEST, msg);
-}
+sendMethodNotAllowed(req, resp, msg);
 }
 
 
@@ -308,13 +303,8 @@ public abstract class HttpServlet extends GenericServlet {
 protected void doPost(HttpServletRequest req, HttpServletResponse resp)
 throws ServletException, IOException {
 
-String protocol = req.getProtocol();
 String msg = lStrings.getString("http.method_post_not_supported");
-if (protocol.endsWith("1.1")) {
-resp.sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED, msg);
-} else {
-resp.sendError(HttpServletResponse.SC_BAD_REQUEST, msg);
-}
+sendMethodNotAllowed(req, resp, msg);
 }
 
 
@@ -363,13 +353,8 @@ public abstract class HttpServlet extends GenericServlet {
 protected void doPut(HttpServletRequest req, HttpServletResponse resp)
 throws ServletException, IOException {
 
-String protocol = req.getProtocol();
 String msg = lStrings.getString("http.method_put_not_supported");
-if (protocol.endsWith("1.1")) {
-resp.sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED, msg);
-} else {
-resp.sendError(HttpServletResponse.SC_BAD_REQUEST, msg);
-}
+sendMethodNotAllowed(req, resp, msg);
 }
 
 
@@ -411,12 +396,19 @@ public abstract class HttpServlet extends GenericServlet {
 HttpServletResponse resp)
 throws ServletException, IOException {
 
-String protocol = req.getProtocol();
 String msg = lStrings.getString("http.method_delete_not_supported");
-if (protocol.endsWith("1.1")) {
-resp.sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED, msg);
-} else {
+sendMethodNotAllowed(req, resp, msg);
+}
+
+
+private void sendMethodNotAllowed(HttpServletRequest req, 
HttpServletResponse resp, String msg) throws IOException {
+String protocol = req.getProtocol();
+// Note: Tomcat reports "" for HTTP/0.9 although some implementations
+//   may report HTTP/0.9
+if (protocol.length() == 0 || protocol.endsWith("0.9") || 
protocol.endsWith("1.0")) {
 resp.sendError(HttpServletResponse.SC_BAD_REQUEST, msg);
+} else {
+resp.sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED, msg);
 }
 }
 
diff --git a/test/javax/servlet/http/TestHttpServlet.java 
b/test/javax/servlet/http/TestHttpServlet.java
index 28be42d..00e4036 100644
--- a/test/javax/servlet/http/TestHttpServlet.java
+++ b/test/javax/servlet/http/TestHttpServlet.java
@@ -28,7 +28,10 @@ import javax.servlet.ServletException;
 import org.junit.Assert;
 import org.junit.Test;
 
+import org.apache.catalina.Context;
 import org.apache.catalina.core.StandardContext;
+import org.apache.catalina.startup.SimpleHttpClient;
+import org.apache.catalina.startup.TesterServlet;
 import org.apache.catalina.startup.Tomcat;
 import org.apache.catalina.startup.TomcatBaseTest;
 import org.apache.tomcat.util.buf.ByteChunk;
@@ -191,6 +194,105 @@ public class TestHttpServlet extends TomcatBaseTest {
 }
 
 
+@Test
+public void testUnimplementedMethodHttp09() throws Exception {
+doTestUnimplementedMethod("0.9");
+}
+
+
+@Test
+public void testUnimplementedMethod

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

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

Re: Changing the name of the default branch in our git repos

[Raymond Auge]

+1 for main

On Tue, Jun 16, 2020 at 8:00 AM Coty Sutherland  wrote:

>
> On Tue, Jun 16, 2020 at 4:02 AM Mark Thomas  wrote:
>
>> All,
>>
>> You may have seen the recent discussions both inside and outside the ASF
>> about the user of "master" as the name of the default git branch. If you
>> haven't, the short version is that the name can be traced back to
>> master/slave and its associations with human slavery.
>>
>> I'd like to propose that the Apache Tomcat project renames the master
>> branch in all of the project repositories.
>>
>> I think there are two front runners for the new name:
>>
>> - main - this looks to be the name GitHub and a number of OSS projects
>>  will be switching to
>>
>> - trunk - reflects the Subversion heritage of both the project and the
>>   ASF
>>
>> Other options I have seen suggested include "default", "dev", "develop".
>> Other suggestions welcome.
>>
>> Personally, I am leaning towards main as that looks to be the choice of
>> the majority and using the majority choice will make it (a little bit)
>> easier for new community members to find their way around the project.
>>
>> In terms of impact, changing the name is going to break stuff. It is
>> really creating a new branch and deleting the old one.
>>
>> Deleting a branch triggers the automatic closure of github PRs against
>> that branch. However if we create "$new_branch" we can edit the PRs to
>> use "$new_branch" before we delete master. Given the small number of
>> open PRs that is easily done.
>>
>> CI systems will need to be updated (buildbot, gump). That should be
>> relatively simple.
>>
>> Docs will need to be updated (relatively simple).
>>
>> Committers and contributors will rebase any local branches to $new_branch
>>
>> Having thought about what is involved, renaming the default branch
>> doesn't look as problematic as I thought it might be. This looks like
>> something that could be done in around an hour for all our repos.
>>
>> Thoughts?
>>
>
> I'm +1 for main
>
>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>

-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)

[Bug 64522] package jars in effective dependency order

[bugzilla]

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

--- Comment #2 from rotty3000  ---
https://github.com/apache/tomcat/pull/301

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

[GitHub] [tomcat] rotty3000 opened a new pull request #301: Fix BZ 64522 - package jars in effective dependency order (only order…

[GitBox]

rotty3000 opened a new pull request #301:
URL: https://github.com/apache/tomcat/pull/301


   … is changed, no other changes)
   
   Signed-off-by: Raymond Augé 



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



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

[tomcat] branch master updated: Return correct response code for HTTP/2 when method is not implemented

[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 a3fc47d  Return correct response code for HTTP/2 when method is not 
implemented
a3fc47d is described below

commit a3fc47dd70725387679a693a00fcd64c876a4a56
Author: Mark Thomas 
AuthorDate: Tue Jun 16 14:26:49 2020 +0100

Return correct response code for HTTP/2 when method is not implemented
---
 java/jakarta/servlet/http/HttpServlet.java |  36 +++-
 test/jakarta/servlet/http/TestHttpServlet.java | 102 +
 .../coyote/http11/TestHttp11InputBufferCRLF.java   |   1 -
 test/org/apache/coyote/http2/TestHttpServlet.java  |  59 
 webapps/docs/changelog.xml |   6 ++
 5 files changed, 181 insertions(+), 23 deletions(-)

diff --git a/java/jakarta/servlet/http/HttpServlet.java 
b/java/jakarta/servlet/http/HttpServlet.java
index fde9847..ba98853 100644
--- a/java/jakarta/servlet/http/HttpServlet.java
+++ b/java/jakarta/servlet/http/HttpServlet.java
@@ -171,13 +171,8 @@ public abstract class HttpServlet extends GenericServlet {
 protected void doGet(HttpServletRequest req, HttpServletResponse resp)
 throws ServletException, IOException
 {
-String protocol = req.getProtocol();
 String msg = lStrings.getString("http.method_get_not_supported");
-if (protocol.endsWith("1.1")) {
-resp.sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED, msg);
-} else {
-resp.sendError(HttpServletResponse.SC_BAD_REQUEST, msg);
-}
+sendMethodNotAllowed(req, resp, msg);
 }
 
 
@@ -311,13 +306,8 @@ public abstract class HttpServlet extends GenericServlet {
 protected void doPost(HttpServletRequest req, HttpServletResponse resp)
 throws ServletException, IOException {
 
-String protocol = req.getProtocol();
 String msg = lStrings.getString("http.method_post_not_supported");
-if (protocol.endsWith("1.1")) {
-resp.sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED, msg);
-} else {
-resp.sendError(HttpServletResponse.SC_BAD_REQUEST, msg);
-}
+sendMethodNotAllowed(req, resp, msg);
 }
 
 
@@ -366,13 +356,8 @@ public abstract class HttpServlet extends GenericServlet {
 protected void doPut(HttpServletRequest req, HttpServletResponse resp)
 throws ServletException, IOException {
 
-String protocol = req.getProtocol();
 String msg = lStrings.getString("http.method_put_not_supported");
-if (protocol.endsWith("1.1")) {
-resp.sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED, msg);
-} else {
-resp.sendError(HttpServletResponse.SC_BAD_REQUEST, msg);
-}
+sendMethodNotAllowed(req, resp, msg);
 }
 
 
@@ -414,12 +399,19 @@ public abstract class HttpServlet extends GenericServlet {
 HttpServletResponse resp)
 throws ServletException, IOException {
 
-String protocol = req.getProtocol();
 String msg = lStrings.getString("http.method_delete_not_supported");
-if (protocol.endsWith("1.1")) {
-resp.sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED, msg);
-} else {
+sendMethodNotAllowed(req, resp, msg);
+}
+
+
+private void sendMethodNotAllowed(HttpServletRequest req, 
HttpServletResponse resp, String msg) throws IOException {
+String protocol = req.getProtocol();
+// Note: Tomcat reports "" for HTTP/0.9 although some implementations
+//   may report HTTP/0.9
+if (protocol.length() == 0 || protocol.endsWith("0.9") || 
protocol.endsWith("1.0")) {
 resp.sendError(HttpServletResponse.SC_BAD_REQUEST, msg);
+} else {
+resp.sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED, msg);
 }
 }
 
diff --git a/test/jakarta/servlet/http/TestHttpServlet.java 
b/test/jakarta/servlet/http/TestHttpServlet.java
index 2473799..f1ae25b 100644
--- a/test/jakarta/servlet/http/TestHttpServlet.java
+++ b/test/jakarta/servlet/http/TestHttpServlet.java
@@ -28,7 +28,10 @@ import jakarta.servlet.ServletException;
 import org.junit.Assert;
 import org.junit.Test;
 
+import org.apache.catalina.Context;
 import org.apache.catalina.core.StandardContext;
+import org.apache.catalina.startup.SimpleHttpClient;
+import org.apache.catalina.startup.TesterServlet;
 import org.apache.catalina.startup.Tomcat;
 import org.apache.catalina.startup.TomcatBaseTest;
 import org.apache.tomcat.util.buf.ByteChunk;
@@ -191,6 +194,105 @@ public class TestHttpServlet extends TomcatBaseTest {
 }
 
 
+@Test
+public void testUnimplementedMethodHttp09() throws Exception {
+doTestUnimplementedMethod("0.9");
+}
+
+
+@Test
+public void tes

[Bug 64527] JarWarResourceSet gc caused class loading slowly

[bugzilla]

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

aix3  changed:

   What|Removed |Added

 CC||springqi...@gmail.com

-- 
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 64527] New: JarWarResourceSet gc caused class loading slowly

[bugzilla]

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

Bug ID: 64527
   Summary: JarWarResourceSet gc caused class loading slowly
   Product: Tomcat 8
   Version: 8.5.39
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: springqi...@gmail.com
  Target Milestone: 

Hi,
I have a spring boot application with embed tomcat, when i deploy my
application(a war package with 329 jar and 227Mb size) to servers, when i first
loading a class by Class.forName, it take several seconds.

I debug some tomcat source code, finally i noticed that when i load a class not
loaded before, it will always run into getArchiveEntries, it will check
archiveEntries is null and load from war file. And i also noticed in
JarWarResourceSet gc method will periodic execution set
archiveEntries=null.Caused class load slowly when archiveEntries=null, because
it will scan all of my war package resources to build a cache.

I'm override JarWarResourceSet let gc method do nothing, it fixed my problem.

But I don’t know if I’m right, so I’m asking here.

tomcat version: 8.5.39
spring boot version: 2.0.9.RELEASE

-- 
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: Changing the name of the default branch in our git repos

[Coty Sutherland]

On Tue, Jun 16, 2020 at 4:02 AM Mark Thomas  wrote:

> All,
>
> You may have seen the recent discussions both inside and outside the ASF
> about the user of "master" as the name of the default git branch. If you
> haven't, the short version is that the name can be traced back to
> master/slave and its associations with human slavery.
>
> I'd like to propose that the Apache Tomcat project renames the master
> branch in all of the project repositories.
>
> I think there are two front runners for the new name:
>
> - main - this looks to be the name GitHub and a number of OSS projects
>  will be switching to
>
> - trunk - reflects the Subversion heritage of both the project and the
>   ASF
>
> Other options I have seen suggested include "default", "dev", "develop".
> Other suggestions welcome.
>
> Personally, I am leaning towards main as that looks to be the choice of
> the majority and using the majority choice will make it (a little bit)
> easier for new community members to find their way around the project.
>
> In terms of impact, changing the name is going to break stuff. It is
> really creating a new branch and deleting the old one.
>
> Deleting a branch triggers the automatic closure of github PRs against
> that branch. However if we create "$new_branch" we can edit the PRs to
> use "$new_branch" before we delete master. Given the small number of
> open PRs that is easily done.
>
> CI systems will need to be updated (buildbot, gump). That should be
> relatively simple.
>
> Docs will need to be updated (relatively simple).
>
> Committers and contributors will rebase any local branches to $new_branch
>
> Having thought about what is involved, renaming the default branch
> doesn't look as problematic as I thought it might be. This looks like
> something that could be done in around an hour for all our repos.
>
> Thoughts?
>

I'm +1 for main


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

Re: Changing the name of the default branch in our git repos

[Michael Osipov]

Am 2020-06-16 um 12:09 schrieb Mark Thomas:

On 16/06/2020 10:25, Michael Osipov wrote:

Am 2020-06-16 um 10:02 schrieb Mark Thomas:

All,

You may have seen the recent discussions both inside and outside the ASF
about the user of "master" as the name of the default git branch. If you
haven't, the short version is that the name can be traced back to
master/slave and its associations with human slavery.

I'd like to propose that the Apache Tomcat project renames the master
branch in all of the project repositories.

I think there are two front runners for the new name:

- main - this looks to be the name GitHub and a number of OSS projects
   will be switching to

- trunk - reflects the Subversion heritage of both the project and the
    ASF

Other options I have seen suggested include "default", "dev", "develop".
Other suggestions welcome.

Personally, I am leaning towards main as that looks to be the choice of
the majority and using the majority choice will make it (a little bit)
easier for new community members to find their way around the project.

In terms of impact, changing the name is going to break stuff. It is
really creating a new branch and deleting the old one.

Deleting a branch triggers the automatic closure of github PRs against
that branch. However if we create "$new_branch" we can edit the PRs to
use "$new_branch" before we delete master. Given the small number of
open PRs that is easily done.

CI systems will need to be updated (buildbot, gump). That should be
relatively simple.

Docs will need to be updated (relatively simple).

Committers and contributors will rebase any local branches to $new_branch

Having thought about what is involved, renaming the default branch
doesn't look as problematic as I thought it might be. This looks like
something that could be done in around an hour for all our repos.

Thoughts?


Although on the Git ML this has been discussed that master comes from
Master Copy (music, recoding, etc) and is not related to slavery, I
prefer the term "main" as many other projects now do.


It isn't that clear cut. If you trace it back there are places where
branches are referred to as master and slave as well as places where the
master record idea is used. Various references can be found in this thread:

https://twitter.com/tobie/status/1270290278029631489


Indeed, this one is the worst: 
https://github.com/bitkeeper-scm/bitkeeper/blob/master/doc/HOWTO.ask#L290-L291



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

Re: Changing the name of the default branch in our git repos

[Mark Thomas]

On 16/06/2020 10:25, Michael Osipov wrote:
> Am 2020-06-16 um 10:02 schrieb Mark Thomas:
>> All,
>>
>> You may have seen the recent discussions both inside and outside the ASF
>> about the user of "master" as the name of the default git branch. If you
>> haven't, the short version is that the name can be traced back to
>> master/slave and its associations with human slavery.
>>
>> I'd like to propose that the Apache Tomcat project renames the master
>> branch in all of the project repositories.
>>
>> I think there are two front runners for the new name:
>>
>> - main - this looks to be the name GitHub and a number of OSS projects
>>   will be switching to
>>
>> - trunk - reflects the Subversion heritage of both the project and the
>>    ASF
>>
>> Other options I have seen suggested include "default", "dev", "develop".
>> Other suggestions welcome.
>>
>> Personally, I am leaning towards main as that looks to be the choice of
>> the majority and using the majority choice will make it (a little bit)
>> easier for new community members to find their way around the project.
>>
>> In terms of impact, changing the name is going to break stuff. It is
>> really creating a new branch and deleting the old one.
>>
>> Deleting a branch triggers the automatic closure of github PRs against
>> that branch. However if we create "$new_branch" we can edit the PRs to
>> use "$new_branch" before we delete master. Given the small number of
>> open PRs that is easily done.
>>
>> CI systems will need to be updated (buildbot, gump). That should be
>> relatively simple.
>>
>> Docs will need to be updated (relatively simple).
>>
>> Committers and contributors will rebase any local branches to $new_branch
>>
>> Having thought about what is involved, renaming the default branch
>> doesn't look as problematic as I thought it might be. This looks like
>> something that could be done in around an hour for all our repos.
>>
>> Thoughts?
> 
> Although on the Git ML this has been discussed that master comes from
> Master Copy (music, recoding, etc) and is not related to slavery, I
> prefer the term "main" as many other projects now do.

It isn't that clear cut. If you trace it back there are places where
branches are referred to as master and slave as well as places where the
master record idea is used. Various references can be found in this thread:

https://twitter.com/tobie/status/1270290278029631489

Mark

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

Re: Changing the name of the default branch in our git repos

[Michael Osipov]

Am 2020-06-16 um 10:02 schrieb Mark Thomas:

All,

You may have seen the recent discussions both inside and outside the ASF
about the user of "master" as the name of the default git branch. If you
haven't, the short version is that the name can be traced back to
master/slave and its associations with human slavery.

I'd like to propose that the Apache Tomcat project renames the master
branch in all of the project repositories.

I think there are two front runners for the new name:

- main - this looks to be the name GitHub and a number of OSS projects
  will be switching to

- trunk - reflects the Subversion heritage of both the project and the
   ASF

Other options I have seen suggested include "default", "dev", "develop".
Other suggestions welcome.

Personally, I am leaning towards main as that looks to be the choice of
the majority and using the majority choice will make it (a little bit)
easier for new community members to find their way around the project.

In terms of impact, changing the name is going to break stuff. It is
really creating a new branch and deleting the old one.

Deleting a branch triggers the automatic closure of github PRs against
that branch. However if we create "$new_branch" we can edit the PRs to
use "$new_branch" before we delete master. Given the small number of
open PRs that is easily done.

CI systems will need to be updated (buildbot, gump). That should be
relatively simple.

Docs will need to be updated (relatively simple).

Committers and contributors will rebase any local branches to $new_branch

Having thought about what is involved, renaming the default branch
doesn't look as problematic as I thought it might be. This looks like
something that could be done in around an hour for all our repos.

Thoughts?


Although on the Git ML this has been discussed that master comes from 
Master Copy (music, recoding, etc) and is not related to slavery, I 
prefer the term "main" as many other projects now do.


M

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

[Bug 64522] package jars in effective dependency order

[bugzilla]

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

--- Comment #1 from Mark Thomas  ---
Do you have a patch in mind for this? Or are you looking for input on what the
correct order might be?

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

Adopting editorconfig

[Mark Thomas]

Hi,

We have an open pull request [1] that essentially means adopting
editorconfig [2].

What does everybody think about this?

I think this is doable of we start simple (along the lines of the PR)
and expand it if/when there is consensus on additional settings.

If we go this route, it raises some additional questions. Do we
a) reformat any existing code that doesn't follow it?
b) configure Checkstyle to test for it?

Thoughts?

Mark


[1] https://github.com/apache/tomcat/pull/284
[2] https://editorconfig.org/

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

Re: Changing the name of the default branch in our git repos

[Violeta Georgieva]

На вт, 16.06.2020 г. в 11:02 Mark Thomas  написа:
>
> All,
>
> You may have seen the recent discussions both inside and outside the ASF
> about the user of "master" as the name of the default git branch. If you
> haven't, the short version is that the name can be traced back to
> master/slave and its associations with human slavery.
>
> I'd like to propose that the Apache Tomcat project renames the master
> branch in all of the project repositories.
>
> I think there are two front runners for the new name:
>
> - main - this looks to be the name GitHub and a number of OSS projects
>  will be switching to
>
> - trunk - reflects the Subversion heritage of both the project and the
>   ASF
>
> Other options I have seen suggested include "default", "dev", "develop".
> Other suggestions welcome.
>
> Personally, I am leaning towards main as that looks to be the choice of
> the majority and using the majority choice will make it (a little bit)
> easier for new community members to find their way around the project.
>
> In terms of impact, changing the name is going to break stuff. It is
> really creating a new branch and deleting the old one.
>
> Deleting a branch triggers the automatic closure of github PRs against
> that branch. However if we create "$new_branch" we can edit the PRs to
> use "$new_branch" before we delete master. Given the small number of
> open PRs that is easily done.
>
> CI systems will need to be updated (buildbot, gump). That should be
> relatively simple.
>
> Docs will need to be updated (relatively simple).
>
> Committers and contributors will rebase any local branches to $new_branch
>
> Having thought about what is involved, renaming the default branch
> doesn't look as problematic as I thought it might be. This looks like
> something that could be done in around an hour for all our repos.
>
> Thoughts?


This may help for the gradual migration
https://github.com/chancancode/branch-rename/#gradual-migration

Regards,
Violeta

Changing the name of the default branch in our git repos

[Mark Thomas]

All,

You may have seen the recent discussions both inside and outside the ASF
about the user of "master" as the name of the default git branch. If you
haven't, the short version is that the name can be traced back to
master/slave and its associations with human slavery.

I'd like to propose that the Apache Tomcat project renames the master
branch in all of the project repositories.

I think there are two front runners for the new name:

- main - this looks to be the name GitHub and a number of OSS projects
 will be switching to

- trunk - reflects the Subversion heritage of both the project and the
  ASF

Other options I have seen suggested include "default", "dev", "develop".
Other suggestions welcome.

Personally, I am leaning towards main as that looks to be the choice of
the majority and using the majority choice will make it (a little bit)
easier for new community members to find their way around the project.

In terms of impact, changing the name is going to break stuff. It is
really creating a new branch and deleting the old one.

Deleting a branch triggers the automatic closure of github PRs against
that branch. However if we create "$new_branch" we can edit the PRs to
use "$new_branch" before we delete master. Given the small number of
open PRs that is easily done.

CI systems will need to be updated (buildbot, gump). That should be
relatively simple.

Docs will need to be updated (relatively simple).

Committers and contributors will rebase any local branches to $new_branch

Having thought about what is involved, renaming the default branch
doesn't look as problematic as I thought it might be. This looks like
something that could be done in around an hour for all our repos.

Thoughts?

Mark

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