[GitHub] [tomcat] cluesblues closed pull request #416: Add .whitesource configuration file

[GitBox]

cluesblues closed pull request #416:
URL: https://github.com/apache/tomcat/pull/416


   


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

[GitHub] [tomcat] cluesblues opened a new pull request #416: Add .whitesource configuration file

[GitBox]

cluesblues opened a new pull request #416:
URL: https://github.com/apache/tomcat/pull/416


   


-- 
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 7.0.x updated: Fix failing tests on Windows with Java 8u29x onwards

[kkolinko]

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

kkolinko 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 8e3c467  Fix failing tests on Windows with Java 8u29x onwards
8e3c467 is described below

commit 8e3c4677d29aa690ae821300afca3c58dc8e0002
Author: Konstantin Kolinko 
AuthorDate: Mon Apr 26 23:31:46 2021 +0300

Fix failing tests on Windows with Java 8u29x onwards
---
 build.xml  | 5 -
 webapps/docs/changelog.xml | 8 
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/build.xml b/build.xml
index 68602ab..964e143 100644
--- a/build.xml
+++ b/build.xml
@@ -189,7 +189,10 @@
 
   
   
-  
+  
+  
+  
+  
 
   
   
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 94c9272..ef125b2 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -119,6 +119,14 @@
   issues do not "pop up" wrt. others).
 -->
 
+  
+
+  
+Fix failing to run any tests on Windows with Java 8u292 onwards.
+(markt/kkolinko)
+  
+
+  
 
 
   

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

Re: Websocket server configurator as @ServiceProvider: a bug?

[Romain Manni-Bucau]

What about the system property container orders (.priority or so)?

Le lun. 26 avr. 2021 à 20:31, Mark Thomas  a écrit :

> Ah. That is a general problem with the ServiceLoader mechanism. It is
> good for situations where you have one, unknown implementation. If there
> are multiple implementations there is no mechanism for the user to
> express a preference - short of hacking the class loader to ensure the
> "right" one is found first.
>
> Generally, I don't like the idea of hard-coding assumptions regarding
> priority. Whether those assumptions put Tomcat's implementation first or
> last.
>
> As you point out, with Java 9+ a solution that allows a Comparator to be
> provided to the ContainerProvider that would sort the ServiceLoader
> results would be possible. But that will need API changes. I created:
>
> https://github.com/eclipse-ee4j/websocket-api/issues/365
>
> Meanwhile what to do for Tomcat 10 and earlier?
>
> What if we added a static method to o.a.t.w.WsContainerProvider that
> caused getContainer() to return null rather than an instance. That would
> essentially hide the Tomcat implementation from the ServiceLoader
> mechanism but not block its use as a default.
>
> Expanding on that slightly, a static getter and setter for
> disableGetContainer would - assuming you control when the ServiceLoader
> mechanism is invoked- allow disabling/enabling of the Tomcat
> implementation on a case by case basis.
>
> Thoughts?
>
> Mark
>
>
>
> On 22/04/2021 18:48, Romain Manni-Bucau wrote:
> > It is not wrong per se but it is not usable to plug a custom impl which
> is
> > my issue.
> >
> >
> > @Mark: what about ignoring the default if there is another impl in
> > serviceloader iteration? Would fix it even if it would create some
> useless
> > stuff but recent serviceloader api solves it if we want to avoid it (with
> > Provider support). If not, the alternative is to make the spi
> registration
> > in another jar usable when not relying on tomcat-ws-api. Both options
> work
> > too even if first one would be simpler probably.
> >
> > Le jeu. 22 avr. 2021 à 18:29, Raymond Augé  .invalid>
> > a écrit :
> >
> >> Romain are you saying that having a service descriptor in this case is
> >> wrong?
> >>
> >> On Thu., Apr. 22, 2021, 11:47 a.m. Mark Thomas, 
> wrote:
> >>
> >>> On 22/04/2021 16:18, Romain Manni-Bucau wrote:
>  I am not in JPMS Ray.
> 
>  About I think the issue is a "double bug" (well one bug, two step
>  resolutions) since I can drop the SPI registration but
>  then @ServiceProvider will recreate it so I propose:
> 
>  1. to drop the explicit SPI registration and keep the default which is
> >>> 1-1
>  (even faster but that's more than minor) since it is not needed at all
> >>> and
>  will enable to use the SPI properly (at least when a single impl is
> >>> there,
>  when multiple are there a system property can help but that's another
> >>> topic
>  and rare enough to be ignored for now probably)
>  2. to drop ServiceProvider annotation and replace it by the needed
> OSGi
>  metadata rather than this particular API
> 
>  Wdyt?
> >>>
> >>> I don't see what problem you are attempting to solve.
> >>>
> >>> The SPI registration is required in case the Tomcat implementation is
> >>> used with an API that doesn't have the Tomcat implementation as the
> >>> hard-coded default.
> >>>
> >>> What is the concern with using the @ServiceProvider annotation to
> enable
> >>> Bnd to generate the correct meta data?
> >>>
> >>> Mark
> >>>
> >>>
> 
> 
>  Le jeu. 22 avr. 2021 à 16:10, Raymond Augé  >>> .invalid>
>  a écrit :
> 
> > Are you maybe in JPMS mode?
> >
> > On Thu., Apr. 22, 2021, 9:51 a.m. Raymond Augé, <
> >>> raymond.a...@liferay.com>
> > wrote:
> >
> >>
> >>
> >> On Thu., Apr. 22, 2021, 9:46 a.m. Raymond Augé, <
> > raymond.a...@liferay.com>
> >> wrote:
> >>
> >>> @ServiceProvider is just a hint no?
> >>>
> >>> It does not change the implementation behavior... Unless you've
> >> found
> >>> otherwise, which would be surprising.
> >>>
> >>
> >> To be clear, there is no runtime behavior associated with
> > @ServiceProvider
> >> _unless_ you are running tomcat in OSGi, which would bring in the
> >>> Service
> >> Loader Mediator to handle the SPI call, BUT still would not change
> to
> > logic
> >> around using a fallback impl if so coded.
> >>
> >>
> >>> Ray
> >>>
> >>> On Thu., Apr. 22, 2021, 9:29 a.m. Romain Manni-Bucau, <
> >>> rmannibu...@gmail.com> wrote:
> >>>
>  Hi all,
> 
>  Websocket server configurator uses the SPI to load the impl and if
> >>> not
>  found fallbacks on the hardcoded tomcat default.
>  Isn't the SPI intended to override the default and
>  therefore @ServiceProvider breaks this feature?
>  If not, how to override it globally with

Re: [PROPOSAL] Deprecate JAAS Realm in 10.0.x and remove in 10.1.x

[Jean-Louis MONTEIRO]

Le lun. 26 avr. 2021 à 20:48, Mark Thomas  a écrit :

> On 26/04/2021 18:49, Jean-Louis MONTEIRO wrote:
> > JAAS, JASPIC and Jakarta Security are all different.
>
> My mistake. I knew JASPIC had a slightly bigger rename than most specs
> and incorrectly thought it became Jakarta Security. It actually became
> Jakarta Authentication. All previous references from me in this thread
> to "Jakarta Security" should be read as "Jakarta Authentication".
>

No problem.


>
> > Tomcat does not implement Jakarta Security so removing JAAS creates a gap
> > in my opinion.
> >
> > I'd second Romain, JASPIC requires a SAM to be implemented by the
> > application.
> >
> > Long story short, I'd probably deprecate for 10.x and target a removal
> for
> > 11.x
>
> In the normal course of things 10.1 would have been 11.0 but we are
> taking the opportunity align Jakarta EE major version and Tomcat major
> version as well as have a (much) shorter support lifespan for 10.0
> (Jakarta EE 9) as that is seen as a transitional release.
>
> Tomcat 10.1 will implement the usual subset of specs from Jakarta EE 10.
>

Sorry I missed that information.
So it appeared to be a bit too aggressive to deprecate and remove.


>
> Mark
>
>
> > Le lun. 26 avr. 2021 à 18:17, Mark Thomas  a écrit :
> >
> >> In reviewing references to Java EE (and J2EE) remaining in the Tomcat 10
> >> repo I found the following:
> >>
> >> 
> >> JAASRealm is prototype for Tomcat of the JAAS-based J2EE authentication
> >> framework for J2EE v1.4, based on the  >> href="https://www.jcp.org/en/jsr/detail?id=196";>JCP Specification
> >> Request 196 to enhance container-managed security and promote
> >> 'pluggable' authentication mechanisms whose implementations would be
> >> container-independent.
> >> 
> >>
> >> JSR became JASPIC (now Jakarta Security) and Tomcat has an
> implementation.
> >>
> >> Searching through the mailing lists I found the following references to
> >> usage of the JAASRealm (going back ~5 years).
> >>
> >> [1] Tomcat 7 user using JAAS based auth to an LDAP server
> >> [2] Tomcat 9 user using SPNEGO with the JAAS realm
> >> [3] Tomcat 8.5 user using SPNEGO with the JAAS realm
> >> [4] Tomcat 7 users with custom CLIENT-CERT auth based on JAAS realm
> >> [5] User wanting access to HttpServletRequest during auth
> >>
> >> Most, if not all, of those have better solutions available than the JAAS
> >> Realm. And those wanting some form of custom auth do have the "proper"
> >> Jakarta Security API to work with.
> >>
> >> Therefore, I'm not currently seeing a good reason to keep the JAASRealm.
> >> Any objections to immediate deprecation with removal planned for 10.1.x?
> >>
> >> Mark
> >>
> >>
> >> [1] http://markmail.org/message/ndvr5ilxovoo4ins
> >> [2] http://markmail.org/message/5ocdnmqvvlvjsxas
> >> [3] http://markmail.org/message/wki275i5yhlg3yyo
> >> [4] http://markmail.org/message/av2sv6g4kgm6ouu4
> >> [5] http://markmail.org/message/fm4ggo3ge4r47gar
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: dev-h...@tomcat.apache.org
> >>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
Jean-Louis

svn commit: r1889214 - in /tomcat/site/trunk: docs/index.html xdocs/index.xml

[markt]

Author: markt
Date: Mon Apr 26 18:49:55 2021
New Revision: 1889214

URL: http://svn.apache.org/viewvc?rev=1889214&view=rev
Log:
Correct new name for JASPIC

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

Modified: tomcat/site/trunk/docs/index.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/index.html?rev=1889214&r1=1889213&r2=1889214&view=diff
==
--- tomcat/site/trunk/docs/index.html (original)
+++ tomcat/site/trunk/docs/index.html Mon Apr 26 18:49:55 2021
@@ -10,7 +10,7 @@ of the
 https://projects.eclipse.org/projects/ee4j.el"; rel="nofollow">Jakarta 
Expression Language,
 https://projects.eclipse.org/projects/ee4j.websocket"; 
rel="nofollow">Jakarta WebSocket,
 https://projects.eclipse.org/projects/ee4j.ca"; rel="nofollow">Jakarta 
Annotations and
-https://projects.eclipse.org/projects/ee4j.es"; rel="nofollow">Jakarta 
Security
+https://projects.eclipse.org/projects/ee4j.authentication"; 
rel="nofollow">Jakarta Authentication
 specifications. These specifications are part of the
 https://projects.eclipse.org/projects/ee4j.jakartaee-platform"; 
rel="nofollow">Jakarta EE platform.
 

Modified: tomcat/site/trunk/xdocs/index.xml
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/index.xml?rev=1889214&r1=1889213&r2=1889214&view=diff
==
--- tomcat/site/trunk/xdocs/index.xml (original)
+++ tomcat/site/trunk/xdocs/index.xml Mon Apr 26 18:49:55 2021
@@ -25,8 +25,8 @@ rel="nofollow">Jakarta Expression Langua
 rel="nofollow">Jakarta WebSocket,
 https://projects.eclipse.org/projects/ee4j.ca";
 rel="nofollow">Jakarta Annotations and
-https://projects.eclipse.org/projects/ee4j.es";
- rel="nofollow">Jakarta Security
+https://projects.eclipse.org/projects/ee4j.authentication";
+ rel="nofollow">Jakarta Authentication
 specifications. These specifications are part of the
 https://projects.eclipse.org/projects/ee4j.jakartaee-platform";
 rel="nofollow">Jakarta EE platform.



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

Re: [PROPOSAL] Deprecate JAAS Realm in 10.0.x and remove in 10.1.x

[Mark Thomas]

On 26/04/2021 18:49, Jean-Louis MONTEIRO wrote:

JAAS, JASPIC and Jakarta Security are all different.


My mistake. I knew JASPIC had a slightly bigger rename than most specs 
and incorrectly thought it became Jakarta Security. It actually became 
Jakarta Authentication. All previous references from me in this thread 
to "Jakarta Security" should be read as "Jakarta Authentication".



Tomcat does not implement Jakarta Security so removing JAAS creates a gap
in my opinion.

I'd second Romain, JASPIC requires a SAM to be implemented by the
application.

Long story short, I'd probably deprecate for 10.x and target a removal for
11.x


In the normal course of things 10.1 would have been 11.0 but we are 
taking the opportunity align Jakarta EE major version and Tomcat major 
version as well as have a (much) shorter support lifespan for 10.0 
(Jakarta EE 9) as that is seen as a transitional release.


Tomcat 10.1 will implement the usual subset of specs from Jakarta EE 10.

Mark



Le lun. 26 avr. 2021 à 18:17, Mark Thomas  a écrit :


In reviewing references to Java EE (and J2EE) remaining in the Tomcat 10
repo I found the following:


JAASRealm is prototype for Tomcat of the JAAS-based J2EE authentication
framework for J2EE v1.4, based on the https://www.jcp.org/en/jsr/detail?id=196";>JCP Specification
Request 196 to enhance container-managed security and promote
'pluggable' authentication mechanisms whose implementations would be
container-independent.


JSR became JASPIC (now Jakarta Security) and Tomcat has an implementation.

Searching through the mailing lists I found the following references to
usage of the JAASRealm (going back ~5 years).

[1] Tomcat 7 user using JAAS based auth to an LDAP server
[2] Tomcat 9 user using SPNEGO with the JAAS realm
[3] Tomcat 8.5 user using SPNEGO with the JAAS realm
[4] Tomcat 7 users with custom CLIENT-CERT auth based on JAAS realm
[5] User wanting access to HttpServletRequest during auth

Most, if not all, of those have better solutions available than the JAAS
Realm. And those wanting some form of custom auth do have the "proper"
Jakarta Security API to work with.

Therefore, I'm not currently seeing a good reason to keep the JAASRealm.
Any objections to immediate deprecation with removal planned for 10.1.x?

Mark


[1] http://markmail.org/message/ndvr5ilxovoo4ins
[2] http://markmail.org/message/5ocdnmqvvlvjsxas
[3] http://markmail.org/message/wki275i5yhlg3yyo
[4] http://markmail.org/message/av2sv6g4kgm6ouu4
[5] http://markmail.org/message/fm4ggo3ge4r47gar

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







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

Re: Websocket server configurator as @ServiceProvider: a bug?

[Mark Thomas]

Ah. That is a general problem with the ServiceLoader mechanism. It is 
good for situations where you have one, unknown implementation. If there 
are multiple implementations there is no mechanism for the user to 
express a preference - short of hacking the class loader to ensure the 
"right" one is found first.


Generally, I don't like the idea of hard-coding assumptions regarding 
priority. Whether those assumptions put Tomcat's implementation first or 
last.


As you point out, with Java 9+ a solution that allows a Comparator to be 
provided to the ContainerProvider that would sort the ServiceLoader 
results would be possible. But that will need API changes. I created:


https://github.com/eclipse-ee4j/websocket-api/issues/365

Meanwhile what to do for Tomcat 10 and earlier?

What if we added a static method to o.a.t.w.WsContainerProvider that 
caused getContainer() to return null rather than an instance. That would 
essentially hide the Tomcat implementation from the ServiceLoader 
mechanism but not block its use as a default.


Expanding on that slightly, a static getter and setter for 
disableGetContainer would - assuming you control when the ServiceLoader 
mechanism is invoked- allow disabling/enabling of the Tomcat 
implementation on a case by case basis.


Thoughts?

Mark



On 22/04/2021 18:48, Romain Manni-Bucau wrote:

It is not wrong per se but it is not usable to plug a custom impl which is
my issue.


@Mark: what about ignoring the default if there is another impl in
serviceloader iteration? Would fix it even if it would create some useless
stuff but recent serviceloader api solves it if we want to avoid it (with
Provider support). If not, the alternative is to make the spi registration
in another jar usable when not relying on tomcat-ws-api. Both options work
too even if first one would be simpler probably.

Le jeu. 22 avr. 2021 à 18:29, Raymond Augé 
a écrit :


Romain are you saying that having a service descriptor in this case is
wrong?

On Thu., Apr. 22, 2021, 11:47 a.m. Mark Thomas,  wrote:


On 22/04/2021 16:18, Romain Manni-Bucau wrote:

I am not in JPMS Ray.

About I think the issue is a "double bug" (well one bug, two step
resolutions) since I can drop the SPI registration but
then @ServiceProvider will recreate it so I propose:

1. to drop the explicit SPI registration and keep the default which is

1-1

(even faster but that's more than minor) since it is not needed at all

and

will enable to use the SPI properly (at least when a single impl is

there,

when multiple are there a system property can help but that's another

topic

and rare enough to be ignored for now probably)
2. to drop ServiceProvider annotation and replace it by the needed OSGi
metadata rather than this particular API

Wdyt?


I don't see what problem you are attempting to solve.

The SPI registration is required in case the Tomcat implementation is
used with an API that doesn't have the Tomcat implementation as the
hard-coded default.

What is the concern with using the @ServiceProvider annotation to enable
Bnd to generate the correct meta data?

Mark





Le jeu. 22 avr. 2021 à 16:10, Raymond Augé 
.invalid>

a écrit :


Are you maybe in JPMS mode?

On Thu., Apr. 22, 2021, 9:51 a.m. Raymond Augé, <

raymond.a...@liferay.com>

wrote:




On Thu., Apr. 22, 2021, 9:46 a.m. Raymond Augé, <

raymond.a...@liferay.com>

wrote:


@ServiceProvider is just a hint no?

It does not change the implementation behavior... Unless you've

found

otherwise, which would be surprising.



To be clear, there is no runtime behavior associated with

@ServiceProvider

_unless_ you are running tomcat in OSGi, which would bring in the

Service

Loader Mediator to handle the SPI call, BUT still would not change to

logic

around using a fallback impl if so coded.



Ray

On Thu., Apr. 22, 2021, 9:29 a.m. Romain Manni-Bucau, <
rmannibu...@gmail.com> wrote:


Hi all,

Websocket server configurator uses the SPI to load the impl and if

not

found fallbacks on the hardcoded tomcat default.
Isn't the SPI intended to override the default and
therefore @ServiceProvider breaks this feature?
If not, how to override it globally without doing it on a per

endpoint

basis?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github <
https://github.com/rmannibucau> |
LinkedIn  | Book
<






https://www.packtpub.com/application-development/java-ee-8-high-performance













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









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

Re: [PROPOSAL] Deprecate JAAS Realm in 10.0.x and remove in 10.1.x

[Jean-Louis MONTEIRO]

JAAS, JASPIC and Jakarta Security are all different.
Tomcat does not implement Jakarta Security so removing JAAS creates a gap
in my opinion.

I'd second Romain, JASPIC requires a SAM to be implemented by the
application.

Long story short, I'd probably deprecate for 10.x and target a removal for
11.x

Le lun. 26 avr. 2021 à 18:17, Mark Thomas  a écrit :

> In reviewing references to Java EE (and J2EE) remaining in the Tomcat 10
> repo I found the following:
>
> 
> JAASRealm is prototype for Tomcat of the JAAS-based J2EE authentication
> framework for J2EE v1.4, based on the  href="https://www.jcp.org/en/jsr/detail?id=196";>JCP Specification
> Request 196 to enhance container-managed security and promote
> 'pluggable' authentication mechanisms whose implementations would be
> container-independent.
> 
>
> JSR became JASPIC (now Jakarta Security) and Tomcat has an implementation.
>
> Searching through the mailing lists I found the following references to
> usage of the JAASRealm (going back ~5 years).
>
> [1] Tomcat 7 user using JAAS based auth to an LDAP server
> [2] Tomcat 9 user using SPNEGO with the JAAS realm
> [3] Tomcat 8.5 user using SPNEGO with the JAAS realm
> [4] Tomcat 7 users with custom CLIENT-CERT auth based on JAAS realm
> [5] User wanting access to HttpServletRequest during auth
>
> Most, if not all, of those have better solutions available than the JAAS
> Realm. And those wanting some form of custom auth do have the "proper"
> Jakarta Security API to work with.
>
> Therefore, I'm not currently seeing a good reason to keep the JAASRealm.
> Any objections to immediate deprecation with removal planned for 10.1.x?
>
> Mark
>
>
> [1] http://markmail.org/message/ndvr5ilxovoo4ins
> [2] http://markmail.org/message/5ocdnmqvvlvjsxas
> [3] http://markmail.org/message/wki275i5yhlg3yyo
> [4] http://markmail.org/message/av2sv6g4kgm6ouu4
> [5] http://markmail.org/message/fm4ggo3ge4r47gar
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
Jean-Louis

[tomcat] branch 7.0.x updated: Add release date for 7.0.109

[violetagg]

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

violetagg 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 bb0d3ef  Add release date for 7.0.109
bb0d3ef is described below

commit bb0d3efeb67eb9bc2e1fd0d17906631c40969195
Author: Violeta Georgieva [VMware] 
AuthorDate: Mon Apr 26 20:15:44 2021 +0300

Add release date for 7.0.109
---
 webapps/docs/changelog.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 7eac531..94c9272 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -120,7 +120,7 @@
 -->
 
 
-
+
   
 
   

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

svn commit: r47421 - /dev/tomcat/tomcat-7/v7.0.109/ /release/tomcat/tomcat-7/v7.0.109/

[violetagg]

Author: violetagg
Date: Mon Apr 26 17:12:02 2021
New Revision: 47421

Log:
Release Tomcat 7.0.109

Added:
release/tomcat/tomcat-7/v7.0.109/
  - copied from r47420, dev/tomcat/tomcat-7/v7.0.109/
Removed:
dev/tomcat/tomcat-7/v7.0.109/


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

Re: [RESULT][VOTE] Release Apache Tomcat 7.0.109

[Violeta Georgieva]

На чт, 22.04.2021 г. в 22:12 ч. Violeta Georgieva 
написа:
>
> The proposed Apache Tomcat 7.0.109 release is now available for voting.
> Please note that this is the last Tomcat 7 release.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.109/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1307/
> The git tag is:
> https://github.com/apache/tomcat/tree/7.0.109
> 2cdef2c0241cdf70b5edd88d3733a52e6b675047
>
> The proposed 7.0.109 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 7.0.109 Stable


+1 (binding):   isapir, fschumacher, violetagg, remm, mgrigorov

No other voters were cast.

The vote has passed.

I'll do the release shortly and announce it once the mirrors catch up.

Regards,
Violeta

Re: [PROPOSAL] Deprecate JAAS Realm in 10.0.x and remove in 10.1.x

[Romain Manni-Bucau]

Le lun. 26 avr. 2021 à 18:57, Mark Thomas  a écrit :

> On 26/04/2021 17:38, Romain Manni-Bucau wrote:
> > JAASRealm is quite commonly used whereas JASPIC is almost never used
>
> References?
>

Sadly not public but all project not using a custom valve/auth where using
jaas and some good part of it (Id say 35%) sharing a login module.



> In my trawl of the Tomcat archives those using the JAAS realm appeared
> to have better solutions available whereas those using JASPIC were doing
> so for the "right" reasons.
>
> If there is evidence that the JAAS realm is meeting a user need I'd like
> to see it (and understand why JAAS is a better solution than the
> alternatives).
>

Mainly cause it has impl and shareable modules between apps (karaf, tomcat,
standalone) whereas jaspic is not.

At least being able to enable jaas is important I'd say cause it reduces
cost compare to jaspic dev which must be redone for other env (not spread
enough).



> Mark
>
>
> > (and
> > not even speaking of Jakarta Security which has no link with two previous
> > ones).
> > Main difference is the fact JAAS is in the JVM (with some impl like OS
> one
> > which is not always trivial to do portably) whereas two others are not so
> > it means you easily find a JAAS login module implementation and you don't
> > find integrations for others so think it makes sense to keep JAAS
> > integration more than others in default delivery.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le lun. 26 avr. 2021 à 18:31, Filip Hanik  a écrit :
> >
> >> On Mon, Apr 26, 2021 at 09:17 Mark Thomas  wrote:
> >>
> >>> In reviewing references to Java EE (and J2EE) remaining in the Tomcat
> 10
> >>> repo I found the following:
> >>>
> >>> 
> >>> JAASRealm is prototype for Tomcat of the JAAS-based J2EE authentication
> >>> framework for J2EE v1.4, based on the  >>> href="https://www.jcp.org/en/jsr/detail?id=196";>JCP Specification
> >>> Request 196 to enhance container-managed security and promote
> >>> 'pluggable' authentication mechanisms whose implementations would be
> >>> container-independent.
> >>> 
> >>>
> >>> JSR became JASPIC (now Jakarta Security) and Tomcat has an
> >> implementation.
> >>>
> >>> Searching through the mailing lists I found the following references to
> >>> usage of the JAASRealm (going back ~5 years).
> >>>
> >>> [1] Tomcat 7 user using JAAS based auth to an LDAP server
> >>> [2] Tomcat 9 user using SPNEGO with the JAAS realm
> >>> [3] Tomcat 8.5 user using SPNEGO with the JAAS realm
> >>> [4] Tomcat 7 users with custom CLIENT-CERT auth based on JAAS realm
> >>> [5] User wanting access to HttpServletRequest during auth
> >>>
> >>> Most, if not all, of those have better solutions available than the
> JAAS
> >>> Realm. And those wanting some form of custom auth do have the "proper"
> >>> Jakarta Security API to work with.
> >>>
> >>> Therefore, I'm not currently seeing a good reason to keep the
> JAASRealm.
> >>> Any objections to immediate deprecation with removal planned for
> 10.1.x?
> >>
> >>
> >> No objections,
> >> go for it
> >>
> >>
> >>>
> >>> Mark
> >>>
> >>>
> >>> [1] http://markmail.org/message/ndvr5ilxovoo4ins
> >>> [2] http://markmail.org/message/5ocdnmqvvlvjsxas
> >>> [3] http://markmail.org/message/wki275i5yhlg3yyo
> >>> [4] http://markmail.org/message/av2sv6g4kgm6ouu4
> >>> [5] http://markmail.org/message/fm4ggo3ge4r47gar
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> >>> For additional commands, e-mail: dev-h...@tomcat.apache.org
> >>>
> >>>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [PROPOSAL] Deprecate JAAS Realm in 10.0.x and remove in 10.1.x

[Mark Thomas]

On 26/04/2021 17:38, Romain Manni-Bucau wrote:

JAASRealm is quite commonly used whereas JASPIC is almost never used


References?

In my trawl of the Tomcat archives those using the JAAS realm appeared 
to have better solutions available whereas those using JASPIC were doing 
so for the "right" reasons.


If there is evidence that the JAAS realm is meeting a user need I'd like 
to see it (and understand why JAAS is a better solution than the 
alternatives).


Mark



(and
not even speaking of Jakarta Security which has no link with two previous
ones).
Main difference is the fact JAAS is in the JVM (with some impl like OS one
which is not always trivial to do portably) whereas two others are not so
it means you easily find a JAAS login module implementation and you don't
find integrations for others so think it makes sense to keep JAAS
integration more than others in default delivery.

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



Le lun. 26 avr. 2021 à 18:31, Filip Hanik  a écrit :


On Mon, Apr 26, 2021 at 09:17 Mark Thomas  wrote:


In reviewing references to Java EE (and J2EE) remaining in the Tomcat 10
repo I found the following:


JAASRealm is prototype for Tomcat of the JAAS-based J2EE authentication
framework for J2EE v1.4, based on the https://www.jcp.org/en/jsr/detail?id=196";>JCP Specification
Request 196 to enhance container-managed security and promote
'pluggable' authentication mechanisms whose implementations would be
container-independent.


JSR became JASPIC (now Jakarta Security) and Tomcat has an

implementation.


Searching through the mailing lists I found the following references to
usage of the JAASRealm (going back ~5 years).

[1] Tomcat 7 user using JAAS based auth to an LDAP server
[2] Tomcat 9 user using SPNEGO with the JAAS realm
[3] Tomcat 8.5 user using SPNEGO with the JAAS realm
[4] Tomcat 7 users with custom CLIENT-CERT auth based on JAAS realm
[5] User wanting access to HttpServletRequest during auth

Most, if not all, of those have better solutions available than the JAAS
Realm. And those wanting some form of custom auth do have the "proper"
Jakarta Security API to work with.

Therefore, I'm not currently seeing a good reason to keep the JAASRealm.
Any objections to immediate deprecation with removal planned for 10.1.x?



No objections,
go for it




Mark


[1] http://markmail.org/message/ndvr5ilxovoo4ins
[2] http://markmail.org/message/5ocdnmqvvlvjsxas
[3] http://markmail.org/message/wki275i5yhlg3yyo
[4] http://markmail.org/message/av2sv6g4kgm6ouu4
[5] http://markmail.org/message/fm4ggo3ge4r47gar

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









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

Re: Clarify what Tomcat means with "Jakarta EE 9 "mention

[Romain Manni-Bucau]

Thanks a lot!

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



Le lun. 26 avr. 2021 à 18:00, Mark Thomas  a écrit :

> On 26/04/2021 14:33, Mark Thomas wrote:
> > We need to find a way to re-work the first paragraph on the home page to
> > reference both Java EE and Jakarta EE. There are probably the places in
> > the site, and probably the docs, where we need to address this.
> >
> > I'll take a look this afternoon.
>
> I've taken a pass over the website and the Tomcat 10.x repo (searching
> for "EE") and updated everything I found that looked like it needed
> updating. I also want to follow-up something on the JAAS Realm but I'll
> do that in a new thread.
>
> Mark
>
>
> >
> > Mark
> >
> >
> >
> > On 26/04/2021 14:02, Romain Manni-Bucau wrote:
> >> Hi all,
> >>
> >> Going on http://tomcat.apache.org/ you can read "The Apache Tomcat
> >> Project
> >> is proud to announce the release of version 10.0.5 of Apache Tomcat.
> This
> >> release is targeted at Jakarta EE 9." and later "Java EE applications
> >> designed for Tomcat 9 ".
> >>
> >> It seems it is a very common phrasing and I get regularly (not for all
> >> releases but often enough) pinged offline to know what is the difference
> >> between Apache TomEE and Apache Tomcat if Tomcat supports JakartaEE.
> >>
> >> I don't have a clear solution but do you think the phrasing can be
> >> reworked
> >> a bit to clarify it only concerns a few specs and avoid this
> >> misunderstanding (guess a link to a reference page can work without
> being
> >> too heavy)?
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau  |  Blog
> >>  | Old Blog
> >>  | Github
> >>  |
> >> LinkedIn  | Book
> >> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
> >>
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [PROPOSAL] Deprecate JAAS Realm in 10.0.x and remove in 10.1.x

[Romain Manni-Bucau]

JAASRealm is quite commonly used whereas JASPIC is almost never used (and
not even speaking of Jakarta Security which has no link with two previous
ones).
Main difference is the fact JAAS is in the JVM (with some impl like OS one
which is not always trivial to do portably) whereas two others are not so
it means you easily find a JAAS login module implementation and you don't
find integrations for others so think it makes sense to keep JAAS
integration more than others in default delivery.

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



Le lun. 26 avr. 2021 à 18:31, Filip Hanik  a écrit :

> On Mon, Apr 26, 2021 at 09:17 Mark Thomas  wrote:
>
> > In reviewing references to Java EE (and J2EE) remaining in the Tomcat 10
> > repo I found the following:
> >
> > 
> > JAASRealm is prototype for Tomcat of the JAAS-based J2EE authentication
> > framework for J2EE v1.4, based on the  > href="https://www.jcp.org/en/jsr/detail?id=196";>JCP Specification
> > Request 196 to enhance container-managed security and promote
> > 'pluggable' authentication mechanisms whose implementations would be
> > container-independent.
> > 
> >
> > JSR became JASPIC (now Jakarta Security) and Tomcat has an
> implementation.
> >
> > Searching through the mailing lists I found the following references to
> > usage of the JAASRealm (going back ~5 years).
> >
> > [1] Tomcat 7 user using JAAS based auth to an LDAP server
> > [2] Tomcat 9 user using SPNEGO with the JAAS realm
> > [3] Tomcat 8.5 user using SPNEGO with the JAAS realm
> > [4] Tomcat 7 users with custom CLIENT-CERT auth based on JAAS realm
> > [5] User wanting access to HttpServletRequest during auth
> >
> > Most, if not all, of those have better solutions available than the JAAS
> > Realm. And those wanting some form of custom auth do have the "proper"
> > Jakarta Security API to work with.
> >
> > Therefore, I'm not currently seeing a good reason to keep the JAASRealm.
> > Any objections to immediate deprecation with removal planned for 10.1.x?
>
>
> No objections,
> go for it
>
>
> >
> > Mark
> >
> >
> > [1] http://markmail.org/message/ndvr5ilxovoo4ins
> > [2] http://markmail.org/message/5ocdnmqvvlvjsxas
> > [3] http://markmail.org/message/wki275i5yhlg3yyo
> > [4] http://markmail.org/message/av2sv6g4kgm6ouu4
> > [5] http://markmail.org/message/fm4ggo3ge4r47gar
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> >
>

Re: [PROPOSAL] Deprecate JAAS Realm in 10.0.x and remove in 10.1.x

[Filip Hanik]

On Mon, Apr 26, 2021 at 09:17 Mark Thomas  wrote:

> In reviewing references to Java EE (and J2EE) remaining in the Tomcat 10
> repo I found the following:
>
> 
> JAASRealm is prototype for Tomcat of the JAAS-based J2EE authentication
> framework for J2EE v1.4, based on the  href="https://www.jcp.org/en/jsr/detail?id=196";>JCP Specification
> Request 196 to enhance container-managed security and promote
> 'pluggable' authentication mechanisms whose implementations would be
> container-independent.
> 
>
> JSR became JASPIC (now Jakarta Security) and Tomcat has an implementation.
>
> Searching through the mailing lists I found the following references to
> usage of the JAASRealm (going back ~5 years).
>
> [1] Tomcat 7 user using JAAS based auth to an LDAP server
> [2] Tomcat 9 user using SPNEGO with the JAAS realm
> [3] Tomcat 8.5 user using SPNEGO with the JAAS realm
> [4] Tomcat 7 users with custom CLIENT-CERT auth based on JAAS realm
> [5] User wanting access to HttpServletRequest during auth
>
> Most, if not all, of those have better solutions available than the JAAS
> Realm. And those wanting some form of custom auth do have the "proper"
> Jakarta Security API to work with.
>
> Therefore, I'm not currently seeing a good reason to keep the JAASRealm.
> Any objections to immediate deprecation with removal planned for 10.1.x?


No objections,
go for it


>
> Mark
>
>
> [1] http://markmail.org/message/ndvr5ilxovoo4ins
> [2] http://markmail.org/message/5ocdnmqvvlvjsxas
> [3] http://markmail.org/message/wki275i5yhlg3yyo
> [4] http://markmail.org/message/av2sv6g4kgm6ouu4
> [5] http://markmail.org/message/fm4ggo3ge4r47gar
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

[PROPOSAL] Deprecate JAAS Realm in 10.0.x and remove in 10.1.x

[Mark Thomas]

In reviewing references to Java EE (and J2EE) remaining in the Tomcat 10 
repo I found the following:



JAASRealm is prototype for Tomcat of the JAAS-based J2EE authentication
framework for J2EE v1.4, based on the href="https://www.jcp.org/en/jsr/detail?id=196";>JCP Specification 
Request 196 to enhance container-managed security and promote 
'pluggable' authentication mechanisms whose implementations would be

container-independent.


JSR became JASPIC (now Jakarta Security) and Tomcat has an implementation.

Searching through the mailing lists I found the following references to 
usage of the JAASRealm (going back ~5 years).


[1] Tomcat 7 user using JAAS based auth to an LDAP server
[2] Tomcat 9 user using SPNEGO with the JAAS realm
[3] Tomcat 8.5 user using SPNEGO with the JAAS realm
[4] Tomcat 7 users with custom CLIENT-CERT auth based on JAAS realm
[5] User wanting access to HttpServletRequest during auth

Most, if not all, of those have better solutions available than the JAAS 
Realm. And those wanting some form of custom auth do have the "proper" 
Jakarta Security API to work with.


Therefore, I'm not currently seeing a good reason to keep the JAASRealm. 
Any objections to immediate deprecation with removal planned for 10.1.x?


Mark


[1] http://markmail.org/message/ndvr5ilxovoo4ins
[2] http://markmail.org/message/5ocdnmqvvlvjsxas
[3] http://markmail.org/message/wki275i5yhlg3yyo
[4] http://markmail.org/message/av2sv6g4kgm6ouu4
[5] http://markmail.org/message/fm4ggo3ge4r47gar

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

Re: Clarify what Tomcat means with "Jakarta EE 9 "mention

[Mark Thomas]

On 26/04/2021 14:33, Mark Thomas wrote:
We need to find a way to re-work the first paragraph on the home page to 
reference both Java EE and Jakarta EE. There are probably the places in 
the site, and probably the docs, where we need to address this.


I'll take a look this afternoon.


I've taken a pass over the website and the Tomcat 10.x repo (searching 
for "EE") and updated everything I found that looked like it needed 
updating. I also want to follow-up something on the JAAS Realm but I'll 
do that in a new thread.


Mark




Mark



On 26/04/2021 14:02, Romain Manni-Bucau wrote:

Hi all,

Going on http://tomcat.apache.org/ you can read "The Apache Tomcat 
Project

is proud to announce the release of version 10.0.5 of Apache Tomcat. This
release is targeted at Jakarta EE 9." and later "Java EE applications
designed for Tomcat 9 ".

It seems it is a very common phrasing and I get regularly (not for all
releases but often enough) pinged offline to know what is the difference
between Apache TomEE and Apache Tomcat if Tomcat supports JakartaEE.

I don't have a clear solution but do you think the phrasing can be 
reworked

a bit to clarify it only concerns a few specs and avoid this
misunderstanding (guess a link to a reference page can work without being
too heavy)?

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

LinkedIn  | Book
 






-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.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: Various JavaEE/J2EE -> Jakarta EE documentation updates

[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 26ba86c  Various JavaEE/J2EE -> Jakarta EE documentation updates
26ba86c is described below

commit 26ba86cdbd40ca718e43b82e62b3eb49d004c3d6
Author: Mark Thomas 
AuthorDate: Mon Apr 26 16:58:03 2021 +0100

Various JavaEE/J2EE -> Jakarta EE documentation updates
---
 java/jakarta/servlet/jsp/tagext/VariableInfo.java  |  2 +-
 .../apache/catalina/core/mbeans-descriptors.xml|  2 +-
 .../catalina/deploy/NamingResourcesImpl.java   |  2 +-
 .../apache/catalina/deploy/mbeans-descriptors.xml  |  2 +-
 .../tomcat/util/descriptor/web/ContextEjb.java |  2 +-
 .../util/descriptor/web/ContextLocalEjb.java   |  2 +-
 .../util/descriptor/web/ContextResource.java   |  2 +-
 .../tomcat/websocket/LocalStrings.properties   |  2 +-
 .../docs/architecture/startup/serverStartup.txt|  2 +-
 webapps/docs/class-loader-howto.xml|  4 +--
 webapps/docs/config/context.xml|  5 ++--
 webapps/docs/jndi-resources-howto.xml  | 31 +++---
 12 files changed, 28 insertions(+), 30 deletions(-)

diff --git a/java/jakarta/servlet/jsp/tagext/VariableInfo.java 
b/java/jakarta/servlet/jsp/tagext/VariableInfo.java
index 0f50086..a1448d8 100644
--- a/java/jakarta/servlet/jsp/tagext/VariableInfo.java
+++ b/java/jakarta/servlet/jsp/tagext/VariableInfo.java
@@ -49,7 +49,7 @@ package jakarta.servlet.jsp.tagext;
  * Frequently a fully qualified class name will refer to a class that is known
  * to the tag library and thus, delivered in the same JAR file as the tag
  * handlers. In most other remaining cases it will refer to a class that is in
- * the platform on which the JSP processor is built (like J2EE). Using fully
+ * the platform on which the JSP processor is built. Using fully
  * qualified class names in this manner makes the usage relatively resistant to
  * configuration errors.
  * 
diff --git a/java/org/apache/catalina/core/mbeans-descriptors.xml 
b/java/org/apache/catalina/core/mbeans-descriptors.xml
index bcef191..5a706a6 100644
--- a/java/org/apache/catalina/core/mbeans-descriptors.xml
+++ b/java/org/apache/catalina/core/mbeans-descriptors.xml
@@ -272,7 +272,7 @@
type="boolean"/>
 
 
 
 
 
diff --git a/webapps/docs/config/context.xml b/webapps/docs/config/context.xml
index 9f8d2b1..0f210df 100644
--- a/webapps/docs/config/context.xml
+++ b/webapps/docs/config/context.xml
@@ -858,7 +858,7 @@
 provided JNDI context with a call to bind(), unbind(),
 createSubContext(), destroySubContext() or close() will trigger a
 javax.naming.OperationNotSupportedException as required by
-section EE.5.3.4 of the Java EE specification. This exception can be
+section EE.5.3.4 of the Jakarta EE specification. This exception can be
 disabled by setting this attribute to false in which case any calls to
 modify the JNDI context will return without making any changes
 and methods that return values will return null. If not
@@ -900,8 +900,7 @@
   
 Set to true (the default) to have Catalina enable a
 JNDI InitialContext for this web application that is
-compatible with Java2 Enterprise Edition (J2EE) platform
-conventions.
+compatible with Jakarta EE platform conventions.
   
 
   
diff --git a/webapps/docs/jndi-resources-howto.xml 
b/webapps/docs/jndi-resources-howto.xml
index ff03cd4..3888eaa 100644
--- a/webapps/docs/jndi-resources-howto.xml
+++ b/webapps/docs/jndi-resources-howto.xml
@@ -39,19 +39,18 @@
 Tomcat provides a JNDI InitialContext implementation
 instance for each web application running under it, in a manner that is
 compatible with those provided by a
-http://www.oracle.com/technetwork/java/javaee/overview/index.html";>
-Java Enterprise Edition application server. The Java EE standard provides
-a standard set of elements in the /WEB-INF/web.xml file to
-reference/define resources.
+https://jakarta.ee/";>Jakarta EE application server. The Jakarta EE
+standard provides a standard set of elements in the
+/WEB-INF/web.xml file to reference/define resources.
 
 See the following Specifications for more information about programming APIs
-for JNDI, and for the features supported by Java Enterprise Edition (Java EE)
-servers, which Tomcat emulates for the services that it provides:
+for JNDI, and for the features supported by Jakarta EE servers, which Tomcat
+emulates for the services that it provides:
 
 http://docs.oracle.com/javase/7/docs/technotes/guides/jndi/index.html";>
 Java Naming and Directory Interface (included in JDK 1.4 onwards)
-http://www.oracle.com/technetwork/java/javaee/documentation/index.html";>
-Java EE Platform Specification (in particular, see Chap

Re: Clarify what Tomcat means with "Jakarta EE 9 "mention

[Romain Manni-Bucau]

In the spirit yes, exactly, in practise Tomcat is far to be web profile
(far as it misses ~10 specs from memory which even includes JPA/JAX-RS for
example) so the word/profile for Tomcat does not exist yet AFAIK.


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



Le lun. 26 avr. 2021 à 17:24, Raymond Augé 
a écrit :

> I believe the distinction might be w.r.t. what used to be referred to as
> "Web Profile" vs. "Full Profile".
>
> Is that correct Romain?
>
> - Ray
>
> On Mon, Apr 26, 2021 at 9:33 AM Mark Thomas  wrote:
>
> > We need to find a way to re-work the first paragraph on the home page to
> > reference both Java EE and Jakarta EE. There are probably the places in
> > the site, and probably the docs, where we need to address this.
> >
> > I'll take a look this afternoon.
> >
> > Mark
> >
> >
> >
> > On 26/04/2021 14:02, Romain Manni-Bucau wrote:
> > > Hi all,
> > >
> > > Going on http://tomcat.apache.org/ you can read "The Apache Tomcat
> > Project
> > > is proud to announce the release of version 10.0.5 of Apache Tomcat.
> This
> > > release is targeted at Jakarta EE 9." and later "Java EE applications
> > > designed for Tomcat 9 ".
> > >
> > > It seems it is a very common phrasing and I get regularly (not for all
> > > releases but often enough) pinged offline to know what is the
> difference
> > > between Apache TomEE and Apache Tomcat if Tomcat supports JakartaEE.
> > >
> > > I don't have a clear solution but do you think the phrasing can be
> > reworked
> > > a bit to clarify it only concerns a few specs and avoid this
> > > misunderstanding (guess a link to a reference page can work without
> being
> > > too heavy)?
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > >
> >
> >
> > -
> > 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)
> OSGi Fellow
>

Re: Clarify what Tomcat means with "Jakarta EE 9 "mention

[Raymond Augé]

I believe the distinction might be w.r.t. what used to be referred to as
"Web Profile" vs. "Full Profile".

Is that correct Romain?

- Ray

On Mon, Apr 26, 2021 at 9:33 AM Mark Thomas  wrote:

> We need to find a way to re-work the first paragraph on the home page to
> reference both Java EE and Jakarta EE. There are probably the places in
> the site, and probably the docs, where we need to address this.
>
> I'll take a look this afternoon.
>
> Mark
>
>
>
> On 26/04/2021 14:02, Romain Manni-Bucau wrote:
> > Hi all,
> >
> > Going on http://tomcat.apache.org/ you can read "The Apache Tomcat
> Project
> > is proud to announce the release of version 10.0.5 of Apache Tomcat. This
> > release is targeted at Jakarta EE 9." and later "Java EE applications
> > designed for Tomcat 9 ".
> >
> > It seems it is a very common phrasing and I get regularly (not for all
> > releases but often enough) pinged offline to know what is the difference
> > between Apache TomEE and Apache Tomcat if Tomcat supports JakartaEE.
> >
> > I don't have a clear solution but do you think the phrasing can be
> reworked
> > a bit to clarify it only concerns a few specs and avoid this
> > misunderstanding (guess a link to a reference page can work without being
> > too heavy)?
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
>
>
> -
> 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)
OSGi Fellow

buildbot failure in on tomcat-9-trunk

[buildbot]

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

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

Buildslave for this Build: asf946_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-9-commit' 
triggered this build
Build Source Stamp: [branch 9.0.x] 5692a3c3be1c3de699e0578de4c6b74cfb8b32d7
Blamelist: Mark Thomas 

BUILD FAILED: failed compile_1

Sincerely,
 -The Buildbot




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

Re: GitHub CI failures

[Mark Thomas]

On 21/04/2021 08:52, Mark Thomas wrote:

Hi all,

You may have noticed that the CI tests have started to failed for Java 8 
on Windows at GitHub.


This appears to have started when GitHub updated the JDK from Zulu 
8.0.282 to 8.0.292.


I have confirmed with local testing that I can recreate the failure with 
Zulu 8.0.292 on Windows and that switching to Zulu 8.0.282 allows the 
tests to complete.


Initial indications are, therefore, that this is a Zuku JDK issue. I 
have opened an issue with Azul and I'll keep the list update with progress.


The root cause was starting Java with a zero length string as a command 
line argument.


As of 8u29x, Java on Windows rejects this to align with other platforms.

Fixed in https://github.com/apache/tomcat/commit/46febe04 (and back-ported)

Mark

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

svn commit: r1889197 - in /tomcat/site/trunk: docs/migration-9.html xdocs/migration-9.xml

[markt]

Author: markt
Date: Mon Apr 26 14:08:32 2021
New Revision: 1889197

URL: http://svn.apache.org/viewvc?rev=1889197&view=rev
Log:
Update migration guide for Tomcat 9 to note some specs did not change

Modified:
tomcat/site/trunk/docs/migration-9.html
tomcat/site/trunk/xdocs/migration-9.xml

Modified: tomcat/site/trunk/docs/migration-9.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/migration-9.html?rev=1889197&r1=1889196&r2=1889197&view=diff
==
--- tomcat/site/trunk/docs/migration-9.html (original)
+++ tomcat/site/trunk/docs/migration-9.html Mon Apr 26 14:08:32 2021
@@ -2,7 +2,7 @@
 Apache Tomcat® - Migration Guide - Tomcat 
9.0.xhttp://tomcat.apache.org/";>Apache 
Tomcat®https://www.apache.org/foundation/contributing.html"; target="_blank" 
class="pull-left">https://www.apache.org/images/SupportApache-small.png"; class="support-asf" 
alt="Support Apache">http://www.apache.org/"; target="_blank" class="pull-left">https://www.google.com/search"; method="get">GOhttps://www.apache.org/events/current-event.html";>https://www.apache.org/events/current-event-234x60.png"; alt="Next ASF 
event">
   Save the date!
 Apache TomcatHomeTaglibsMaven 
PluginDownloadWhich version?https://tomcat.apache.org/download-10.cgi";>Tomcat 10https://tomcat.apache.org/download-90.cgi";>Tomcat 9https://tomcat.apache.org/download-80.cgi";>Tomcat 8https://tomcat.apache.org/download-70.cgi";>Tomcat 7https://tomcat.apache.org/download-migration.cgi";>Tomcat Migration Tool 
for Jakarta EEhttps://tomcat.apache.org/download-connectors.cgi";>Tomcat 
Connectorshttps://tomcat.apache.org/download-native.cgi";>Tomcat 
Nativehttps://tomcat.apache.org/download-taglibs.cgi";>Taglibshttps://archive.apache.org/dist/tomcat/";>A
 rchivesDocumentationTomcat 10.0Tomcat 9.0Tomcat 8.5Tomcat 7.0Tomcat ConnectorsTomcat Nativehttps://cwiki.apache.org/confluence/display/TOMCAT";>WikiMigration GuidePresentationshttps://cwiki.apache.org/confluence/x/Bi8lBg";>SpecificationsProblems?Security ReportsFind helphttps://cwiki.apache.org/confluence/display/TOMCAT/FAQ";>FAQMailing ListsBug 
Databas
 eIRCGet 
InvolvedOverviewSource codeBuildbothttps://cwiki.apache.org/confluence/x/vIPzBQ";>TranslationsToolsMediahttps://twitter.com/theapachetomcat";>Twitterhttps://www.youtube.com/c/ApacheTomcatOfficial";>YouTubehttps://blogs.apache.org/tomcat/";>BlogMiscWho We Arehttps://www.redbubble.com/people/comdev/works/30885254-apache-tomcat";>SwagHeritagehttp://www.apache.org";>Apache HomeResourcesContactLegal<
 /li>https://www.apache.org/foundation/contributing.html";>Support 
Apachehttps://www.apache.org/foundation/sponsorship.html";>Sponsorshiphttp://www.apache.org/foundation/thanks.html";>Thankshttp://www.apache.org/licenses/";>LicenseContentTable of Contents
-GeneralMigrating from 8.0.x or 8.5.x to 
9.0.xJava 8 requiredSpecification APIsServlet 4.0 APIJavaServer Pages 2.4Expression Language 3.1WebSocket 2.0BIO connector removedComet support removedHTTP/2 support addedTLS virtual 
hosting and multiple certificate support addedInternal APIsJSR-77 implementation 
removedClusteringInstanceListener removedSessionManagerCookiesWeb 
applicationsEngine and 
Host configurationsContext 
configurationsLoggingUpgrading 9.0.xTomcat 9.0.x noteable 
changesTomcat 9.0.x configuration 
file differences
+GeneralMigrating from 8.0.x or 8.5.x to 
9.0.xJava 8 requiredSpecification APIsServlet 4.0 APIJavaServer Pages 2.3Expression Language 3.0WebSocket 1.1BIO connector removedComet support removedHTTP/2 support addedTLS virtual 
hosting and multiple certificate support addedInternal APIsJSR-77 implementation 
removedClusteringInstanceListener removedSessionManagerCookiesWeb 
applicationsEngine and 
Host configurationsContext 
configurationsLoggingUpgrading 9.0.xTomcat 9.0.x noteable 
changesTomcat 9.0.x configuration 
file differences
 General
 
 Please read general Migration Guide page first,
@@ -52,26 +52,21 @@ of Apache Tomcat.
 
   
 
-  JavaServer Pages 
2.4
+  JavaServer Pages 
2.3
   
-No information is currently available. It is anticipated that Java EE 8
-will include a maintenance release of JSP with a version of 2.4.
+This is unchanged from Tomcat 8.x.
 
   
 
-  Expression Language 
3.1
+  Expression Language 
3.0
   
-No information is currently available. It is anticipated that Java EE 8
-will include a maintenance release of expression language with a version of
-3.1.
+This is unchanged from Tomcat 8.x.
 
   
 
-  WebSocket 2.0
+  WebSocket 1.1
   
-No information is currently available. It is anticipated that Java EE 8
-will include an updated Java API for WebSocket specification with a
-version of 2.0.
+This is unchanged from Tomcat 8.x.
 
   
 

Modified: tomcat/site/trunk/xdocs/migration-9.xml
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/migration-9.xml?rev=1889197&r1=1889196&r2=1889197&view=diff

svn commit: r1889196 - /tomcat/site/trunk/docs/index.html

[markt]

Author: markt
Date: Mon Apr 26 14:08:05 2021
New Revision: 1889196

URL: http://svn.apache.org/viewvc?rev=1889196&view=rev
Log:
Improve clarity around Java EE vs Jakarta EE

Modified:
tomcat/site/trunk/docs/index.html

Modified: tomcat/site/trunk/docs/index.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/index.html?rev=1889196&r1=1889195&r2=1889196&view=diff
==
--- tomcat/site/trunk/docs/index.html (original)
+++ tomcat/site/trunk/docs/index.html Mon Apr 26 14:08:05 2021
@@ -4,11 +4,19 @@
 Apache TomcatHomeTaglibsMaven 
PluginDownloadWhich version?https://tomcat.apache.org/download-10.cgi";>Tomcat 10https://tomcat.apache.org/download-90.cgi";>Tomcat 9https://tomcat.apache.org/download-80.cgi";>Tomcat 8https://tomcat.apache.org/download-70.cgi";>Tomcat 7https://tomcat.apache.org/download-migration.cgi";>Tomcat Migration Tool 
for Jakarta EEhttps://tomcat.apache.org/download-connectors.cgi";>Tomcat 
Connectorshttps://tomcat.apache.org/download-native.cgi";>Tomcat 
Nativehttps://tomcat.apache.org/download-taglibs.cgi";>Taglibshttps://archive.apache.org/dist/tomcat/";>A
 rchivesDocumentationTomcat 10.0Tomcat 9.0Tomcat 8.5Tomcat 7.0Tomcat ConnectorsTomcat Nativehttps://cwiki.apache.org/confluence/display/TOMCAT";>WikiMigration GuidePresentationshttps://cwiki.apache.org/confluence/x/Bi8lBg";>SpecificationsProblems?Security ReportsFind helphttps://cwiki.apache.org/confluence/display/TOMCAT/FAQ";>FAQMailing ListsBug 
Databas
 eIRCGet 
InvolvedOverviewSource codeBuildbothttps://cwiki.apache.org/confluence/x/vIPzBQ";>TranslationsToolsMediahttps://twitter.com/theapachetomcat";>Twitterhttps://www.youtube.com/c/ApacheTomcatOfficial";>YouTubehttps://blogs.apache.org/tomcat/";>BlogMiscWho We Arehttps://www.redbubble.com/people/comdev/works/30885254-apache-tomcat";>SwagHeritagehttp://www.apache.org";>Apache HomeResourcesContactLegal<
 /li>https://www.apache.org/foundation/contributing.html";>Support 
Apachehttps://www.apache.org/foundation/sponsorship.html";>Sponsorshiphttp://www.apache.org/foundation/thanks.html";>Thankshttp://www.apache.org/licenses/";>LicenseContentApache Tomcat
 
 The Apache Tomcat® software is an open source implementation
-of the Java Servlet, JavaServer Pages, Java Expression Language and Java
-WebSocket technologies. The Java Servlet, JavaServer Pages, Java Expression
-Language and Java WebSocket specifications are developed under the
-http://jcp.org/en/introduction/overview"; rel="nofollow">Java Community
-Process.
+of the
+https://projects.eclipse.org/projects/ee4j.servlet"; 
rel="nofollow">Jakarta Servlet,
+https://projects.eclipse.org/projects/ee4j.jsp"; 
rel="nofollow">Jakarta Server Pages,
+https://projects.eclipse.org/projects/ee4j.el"; rel="nofollow">Jakarta 
Expression Language,
+https://projects.eclipse.org/projects/ee4j.websocket"; 
rel="nofollow">Jakarta WebSocket,
+https://projects.eclipse.org/projects/ee4j.ca"; rel="nofollow">Jakarta 
Annotations and
+https://projects.eclipse.org/projects/ee4j.es"; rel="nofollow">Jakarta 
Security
+specifications. These specifications are part of the
+https://projects.eclipse.org/projects/ee4j.jakartaee-platform"; 
rel="nofollow">Jakarta EE platform.
+
+The Jakarta EE platform is the evolution of the Java EE platform. Tomcat 10
+and later implement specifications developed as part of Jakarta EE. Tomcat 9 
and
+earlier implement specifications developed as part of Java EE.
 
 
 The Apache Tomcat software is developed in an open and participatory
@@ -31,12 +39,13 @@ project logo are trademarks of the Apach
 2021-04-06 Tomcat 10.0.5 Released
 
 The Apache Tomcat Project is proud to announce the release of version 10.0.5
-of Apache Tomcat. This release is targeted at Jakarta EE 9.
+of Apache Tomcat. This release implements specifications that are part of the
+Jakarta EE 9 platform.
 Applications that run on Tomcat 9 and earlier will not run on Tomcat 10
-without changes. Java EE applications designed for Tomcat 9 and earlier may be
-placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat
-will automatically convert them to Jakarta EE and copy them to the webapps
-directory. This conversion is performed using the
+without changes. Java EE based applications designed for Tomcat 9 and earlier
+may be placed in the $CATALINA_BASE/webapps-javaee directory and
+Tomcat will automatically convert them to Jakarta EE and copy them to the
+webapps directory. This conversion is performed using the
 https://github.com/apache/tomcat-jakartaee-migration";>Apache Tomcat
 migration tool for Jakarta EE tool which is also available as a separate
 https://tomcat.apache.org/download-migration.cgi";>download for 
off-line use.
@@ -62,7 +71,8 @@ changelog.
 2021-04-06 Tomcat 9.0.45 Released
 
 The Apache Tomcat Project is proud to announce the release of version 9.0.45
-of Apache Tomcat. The notable changes compared to 9.0.44 include:
+of Apache Tomcat. This rele

svn commit: r1889195 - /tomcat/site/trunk/xdocs/index.xml

[markt]

Author: markt
Date: Mon Apr 26 14:07:58 2021
New Revision: 1889195

URL: http://svn.apache.org/viewvc?rev=1889195&view=rev
Log:
Improve clarity around Java EE vs Jakarta EE

Modified:
tomcat/site/trunk/xdocs/index.xml

Modified: tomcat/site/trunk/xdocs/index.xml
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/index.xml?rev=1889195&r1=1889194&r2=1889195&view=diff
==
--- tomcat/site/trunk/xdocs/index.xml (original)
+++ tomcat/site/trunk/xdocs/index.xml Mon Apr 26 14:07:58 2021
@@ -14,11 +14,26 @@
 
 
 The Apache Tomcat® software is an open source implementation
-of the Java Servlet, JavaServer Pages, Java Expression Language and Java
-WebSocket technologies. The Java Servlet, JavaServer Pages, Java Expression
-Language and Java WebSocket specifications are developed under the
-http://jcp.org/en/introduction/overview"; rel="nofollow">Java Community
-Process.
+of the
+https://projects.eclipse.org/projects/ee4j.servlet";
+rel="nofollow">Jakarta Servlet,
+https://projects.eclipse.org/projects/ee4j.jsp";
+rel="nofollow">Jakarta Server Pages,
+https://projects.eclipse.org/projects/ee4j.el";
+rel="nofollow">Jakarta Expression Language,
+https://projects.eclipse.org/projects/ee4j.websocket";
+rel="nofollow">Jakarta WebSocket,
+https://projects.eclipse.org/projects/ee4j.ca";
+rel="nofollow">Jakarta Annotations and
+https://projects.eclipse.org/projects/ee4j.es";
+ rel="nofollow">Jakarta Security
+specifications. These specifications are part of the
+https://projects.eclipse.org/projects/ee4j.jakartaee-platform";
+rel="nofollow">Jakarta EE platform.
+
+The Jakarta EE platform is the evolution of the Java EE platform. Tomcat 10
+and later implement specifications developed as part of Jakarta EE. Tomcat 9 
and
+earlier implement specifications developed as part of Java EE.
 
 
 The Apache Tomcat software is developed in an open and participatory
@@ -43,12 +58,13 @@ project logo are trademarks of the Apach
 
 
 The Apache Tomcat Project is proud to announce the release of version 10.0.5
-of Apache Tomcat. This release is targeted at Jakarta EE 9.
+of Apache Tomcat. This release implements specifications that are part of the
+Jakarta EE 9 platform.
 Applications that run on Tomcat 9 and earlier will not run on Tomcat 10
-without changes. Java EE applications designed for Tomcat 9 and earlier may be
-placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat
-will automatically convert them to Jakarta EE and copy them to the webapps
-directory. This conversion is performed using the
+without changes. Java EE based applications designed for Tomcat 9 and earlier
+may be placed in the $CATALINA_BASE/webapps-javaee directory and
+Tomcat will automatically convert them to Jakarta EE and copy them to the
+webapps directory. This conversion is performed using the
 https://github.com/apache/tomcat-jakartaee-migration";>Apache Tomcat
 migration tool for Jakarta EE tool which is also available as a separate
 download for off-line use.
@@ -76,7 +92,8 @@ changelog.
 
 
 The Apache Tomcat Project is proud to announce the release of version 9.0.45
-of Apache Tomcat. The notable changes compared to 9.0.44 include:
+of Apache Tomcat. This release implements specifications that are part of the
+Java EE 8 platform. The notable changes compared to 9.0.44 include:
 
 Fix a regression in 9.0.44 that meant that an error during an asynchronous
 read broke all future asynchronous reads associated with the same request
@@ -100,7 +117,8 @@ changelog.
 
 
 The Apache Tomcat Project is proud to announce the release of version 8.5.65
-of Apache Tomcat. The notable changes compared to 8.5.64 include:
+of Apache Tomcat. This release implements specifications that are part of the
+Java EE 7 platform. The notable changes compared to 8.5.64 include:
 
 Fix a regression in 8.5.64 that meant that an error during an asynchronous
 read broke all future asynchronous reads associated with the same request
@@ -162,7 +180,8 @@ Full details of these changes, and all t
 
 
 The Apache Tomcat Project is proud to announce the release of version 7.0.108 
of
-Apache Tomcat. This release contains a number of bug fixes and improvements
+Apache Tomcat. This release implements specifications that are part of the Java
+EE 6 platform. This release contains a number of bug fixes and improvements
 compared to version 7.0.107.
 
 Fix a potential file descriptor leak when WebSocket connections are



-
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 failing tests on Windows with Java 8u29x onwards

[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 948c928  Fix failing tests on Windows with Java 8u29x onwards
948c928 is described below

commit 948c92811f6f1c8004e86194861af95f13d327ef
Author: Mark Thomas 
AuthorDate: Mon Apr 26 14:36:52 2021 +0100

Fix failing tests on Windows with Java 8u29x onwards
---
 build.xml | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/build.xml b/build.xml
index 461eac7..ad55d0b 100644
--- a/build.xml
+++ b/build.xml
@@ -188,7 +188,10 @@
 
   
   
-  
+  
+  
+  
+  
 
   
   

-
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 failing tests on Windows with Java 8u29x onwards

[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 5692a3c  Fix failing tests on Windows with Java 8u29x onwards
5692a3c is described below

commit 5692a3c3be1c3de699e0578de4c6b74cfb8b32d7
Author: Mark Thomas 
AuthorDate: Mon Apr 26 14:36:52 2021 +0100

Fix failing tests on Windows with Java 8u29x onwards
---
 build.xml | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/build.xml b/build.xml
index ecc7511..89feb96 100644
--- a/build.xml
+++ b/build.xml
@@ -194,7 +194,10 @@
 
   
   
-  
+  
+  
+  
+  
 
   
   

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

[tomcat] branch master updated: Fix failing tests on Windows with Java 8u29x onwards

[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 46febe0  Fix failing tests on Windows with Java 8u29x onwards
46febe0 is described below

commit 46febe042a9ed32bb53fcedf28f954e3095028ad
Author: Mark Thomas 
AuthorDate: Mon Apr 26 14:36:52 2021 +0100

Fix failing tests on Windows with Java 8u29x onwards
---
 build.xml | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/build.xml b/build.xml
index e2f57e0..d53c4c3 100644
--- a/build.xml
+++ b/build.xml
@@ -194,7 +194,10 @@
 
   
   
-  
+  
+  
+  
+  
 
   
   

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

Re: Clarify what Tomcat means with "Jakarta EE 9 "mention

[Mark Thomas]

We need to find a way to re-work the first paragraph on the home page to 
reference both Java EE and Jakarta EE. There are probably the places in 
the site, and probably the docs, where we need to address this.


I'll take a look this afternoon.

Mark



On 26/04/2021 14:02, Romain Manni-Bucau wrote:

Hi all,

Going on http://tomcat.apache.org/ you can read "The Apache Tomcat Project
is proud to announce the release of version 10.0.5 of Apache Tomcat. This
release is targeted at Jakarta EE 9." and later "Java EE applications
designed for Tomcat 9 ".

It seems it is a very common phrasing and I get regularly (not for all
releases but often enough) pinged offline to know what is the difference
between Apache TomEE and Apache Tomcat if Tomcat supports JakartaEE.

I don't have a clear solution but do you think the phrasing can be reworked
a bit to clarify it only concerns a few specs and avoid this
misunderstanding (guess a link to a reference page can work without being
too heavy)?

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





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

Clarify what Tomcat means with "Jakarta EE 9 "mention

[Romain Manni-Bucau]

Hi all,

Going on http://tomcat.apache.org/ you can read "The Apache Tomcat Project
is proud to announce the release of version 10.0.5 of Apache Tomcat. This
release is targeted at Jakarta EE 9." and later "Java EE applications
designed for Tomcat 9 ".

It seems it is a very common phrasing and I get regularly (not for all
releases but often enough) pinged offline to know what is the difference
between Apache TomEE and Apache Tomcat if Tomcat supports JakartaEE.

I don't have a clear solution but do you think the phrasing can be reworked
a bit to clarify it only concerns a few specs and avoid this
misunderstanding (guess a link to a reference page can work without being
too heavy)?

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

[Bug 65264] Header size is bigger will cause TimeoutException

[bugzilla]

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

--- Comment #3 from linking12 <297442...@qq.com> ---
Do have any suggestions for me to circumvent this problem？

if i use jetty high level api, can resolve this problem?

-- 
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 65240] Multi line CATALINA_OPTS is failing in with new catalina.sh

[bugzilla]

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

Mark Thomas  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #4 from Mark Thomas  ---
Local testing confirms that using a trailing '\' has the same effect as the
quoting before the bug 63815 fix (the new lines are removed).

Another option I have seen used is:
CATALINA_OPTS="-Dfoo1=bar1"
CATALINA_OPTS="$CATALINA_OPTS -Dfoo2=bar2"
etc.

The fix for bug 63815 has been in place for over a year and this is the first
report I recall of issues with multi-line variables.

I don't see a simple way to filter out the newlines using /bin/sh so I am going
to resolve this as WONTFIX. The recommended workaround is to use one of the two
alternative approaches described above.

-- 
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: [VOTE] Release Apache Tomcat 7.0.109

[Martin Grigorov]

On Thu, Apr 22, 2021 at 10:13 PM Violeta Georgieva 
wrote:

> The proposed Apache Tomcat 7.0.109 release is now available for voting.
> Please note that this is the last Tomcat 7 release.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.109/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1307/
> The git tag is:
> https://github.com/apache/tomcat/tree/7.0.109
> 2cdef2c0241cdf70b5edd88d3733a52e6b675047
>
> The proposed 7.0.109 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 7.0.109 Stable
>

Martin


>
> Regards,
> Violeta
>

Re: [VOTE] Release Apache Tomcat 7.0.109

[Rémy Maucherat]

On Thu, Apr 22, 2021 at 9:13 PM Violeta Georgieva 
wrote:

> The proposed Apache Tomcat 7.0.109 release is now available for voting.
> Please note that this is the last Tomcat 7 release.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.109/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1307/
> The git tag is:
> https://github.com/apache/tomcat/tree/7.0.109
> 2cdef2c0241cdf70b5edd88d3733a52e6b675047
>
> The proposed 7.0.109 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 7.0.109 Stable
>

Congratulations on wrapping up the branch :)

Rémy


>
> Regards,
> Violeta
>

Re: [VOTE] Release Apache Tomcat 7.0.109

[Violeta Georgieva]

На чт, 22.04.2021 г. в 22:12 ч. Violeta Georgieva 
написа:
>
> The proposed Apache Tomcat 7.0.109 release is now available for voting.
> Please note that this is the last Tomcat 7 release.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.109/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1307/
> The git tag is:
> https://github.com/apache/tomcat/tree/7.0.109
> 2cdef2c0241cdf70b5edd88d3733a52e6b675047
>
> The proposed 7.0.109 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 7.0.109 Stable

+1

Regards,
Violeta

>

[Bug 65265] getVMInfo() in Diagnostics.java throws exceptions on jdk > 8

[bugzilla]

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

Remy Maucherat  changed:

   What|Removed |Added

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

--- Comment #2 from Remy Maucherat  ---
This will be in 10.0.6, 9.0.46 and 8.5.66.

-- 
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: Avoid getting the boot classpath when it is not available

[remm]

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

remm 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 2b5a913  Avoid getting the boot classpath when it is not available
2b5a913 is described below

commit 2b5a913980b536dcc4027a215d1d7f1a1c83754e
Author: remm 
AuthorDate: Mon Apr 26 12:12:40 2021 +0200

Avoid getting the boot classpath when it is not available

BZ 65265, results in an unsupported operation exception.
---
 java/org/apache/tomcat/util/Diagnostics.java | 4 +++-
 webapps/docs/changelog.xml   | 4 
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/java/org/apache/tomcat/util/Diagnostics.java 
b/java/org/apache/tomcat/util/Diagnostics.java
index 788778c..aa07d6a 100644
--- a/java/org/apache/tomcat/util/Diagnostics.java
+++ b/java/org/apache/tomcat/util/Diagnostics.java
@@ -559,7 +559,9 @@ public class Diagnostics {
 
 sb.append(requestedSm.getString("diagnostics.vmInfoPath"));
 sb.append(":" + CRLF);
-sb.append(INDENT1 + "bootClassPath: " + 
runtimeMXBean.getBootClassPath() + CRLF);
+if (runtimeMXBean.isBootClassPathSupported()) {
+sb.append(INDENT1 + "bootClassPath: " + 
runtimeMXBean.getBootClassPath() + CRLF);
+}
 sb.append(INDENT1 + "classPath: " + runtimeMXBean.getClassPath() + 
CRLF);
 sb.append(INDENT1 + "libraryPath: " + runtimeMXBean.getLibraryPath() + 
CRLF);
 sb.append(CRLF);
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 1f05fb7..31d840b 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -154,6 +154,10 @@
 65235: Correct name of changeLocalName in the
 documentation for the RemoteIpValve. (markt)
   
+  
+65265: Avoid getting the boot classpath when it is not
+available in the Manager diagnostics. (remm)
+  
 
   
   

-
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: Avoid getting the boot classpath when it is not available

[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 a8dcccd  Avoid getting the boot classpath when it is not available
a8dcccd is described below

commit a8dcccd93eddb74064b28acbb52ef707c11e98c5
Author: remm 
AuthorDate: Mon Apr 26 12:12:40 2021 +0200

Avoid getting the boot classpath when it is not available

BZ 65265, results in an unsupported operation exception.
---
 java/org/apache/tomcat/util/Diagnostics.java | 4 +++-
 webapps/docs/changelog.xml   | 4 
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/java/org/apache/tomcat/util/Diagnostics.java 
b/java/org/apache/tomcat/util/Diagnostics.java
index 788778c..aa07d6a 100644
--- a/java/org/apache/tomcat/util/Diagnostics.java
+++ b/java/org/apache/tomcat/util/Diagnostics.java
@@ -559,7 +559,9 @@ public class Diagnostics {
 
 sb.append(requestedSm.getString("diagnostics.vmInfoPath"));
 sb.append(":" + CRLF);
-sb.append(INDENT1 + "bootClassPath: " + 
runtimeMXBean.getBootClassPath() + CRLF);
+if (runtimeMXBean.isBootClassPathSupported()) {
+sb.append(INDENT1 + "bootClassPath: " + 
runtimeMXBean.getBootClassPath() + CRLF);
+}
 sb.append(INDENT1 + "classPath: " + runtimeMXBean.getClassPath() + 
CRLF);
 sb.append(INDENT1 + "libraryPath: " + runtimeMXBean.getLibraryPath() + 
CRLF);
 sb.append(CRLF);
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 83c..ae0f7ad 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -158,6 +158,10 @@
 65235: Correct name of changeLocalName in the
 documentation for the RemoteIpValve. (markt)
   
+  
+65265: Avoid getting the boot classpath when it is not
+available in the Manager diagnostics. (remm)
+  
 
   
   

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

[tomcat] branch master updated: Avoid getting the boot classpath when it is not available

[remm]

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

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


The following commit(s) were added to refs/heads/master by this push:
 new 8ddc531  Avoid getting the boot classpath when it is not available
8ddc531 is described below

commit 8ddc5313ffe8ca505df31987c23ef1b9cd1d5755
Author: remm 
AuthorDate: Mon Apr 26 12:12:40 2021 +0200

Avoid getting the boot classpath when it is not available

BZ 65265, results in an unsupported operation exception.
---
 java/org/apache/tomcat/util/Diagnostics.java | 4 +++-
 webapps/docs/changelog.xml   | 4 
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/java/org/apache/tomcat/util/Diagnostics.java 
b/java/org/apache/tomcat/util/Diagnostics.java
index 788778c..aa07d6a 100644
--- a/java/org/apache/tomcat/util/Diagnostics.java
+++ b/java/org/apache/tomcat/util/Diagnostics.java
@@ -559,7 +559,9 @@ public class Diagnostics {
 
 sb.append(requestedSm.getString("diagnostics.vmInfoPath"));
 sb.append(":" + CRLF);
-sb.append(INDENT1 + "bootClassPath: " + 
runtimeMXBean.getBootClassPath() + CRLF);
+if (runtimeMXBean.isBootClassPathSupported()) {
+sb.append(INDENT1 + "bootClassPath: " + 
runtimeMXBean.getBootClassPath() + CRLF);
+}
 sb.append(INDENT1 + "classPath: " + runtimeMXBean.getClassPath() + 
CRLF);
 sb.append(INDENT1 + "libraryPath: " + runtimeMXBean.getLibraryPath() + 
CRLF);
 sb.append(CRLF);
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index e92e1a7..03059fd 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -158,6 +158,10 @@
 65235: Correct name of changeLocalName in the
 documentation for the RemoteIpValve. (markt)
   
+  
+65265: Avoid getting the boot classpath when it is not
+available in the Manager diagnostics. (remm)
+  
 
   
   

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

[Bug 65264] Header size is bigger will cause TimeoutException

[bugzilla]

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

Mark Thomas  changed:

   What|Removed |Added

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

--- Comment #2 from Mark Thomas  ---
As the Jetty team have already told you:

"...if you use Jetty's low-level HTTP2Client, it is the application
responsibility to control that the maximum number of streams is not exceeded."

You don't do this, so Tomcat refuses any excess streams. If this happens
multiple times on a connection (the exact number will vary depending on
circumstances) Tomcat will consider the client abusive and close the entire
connection.

-- 
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] omargeng closed pull request #415: 9.0.x

[GitBox]

omargeng closed pull request #415:
URL: https://github.com/apache/tomcat/pull/415


   


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

[GitHub] [tomcat] omargeng opened a new pull request #415: 9.0.x

[GitBox]

omargeng opened a new pull request #415:
URL: https://github.com/apache/tomcat/pull/415


   9.0.x


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