[tomcat] branch 7.0.x updated: Increment version number for next development cycle

2021-04-22 Thread 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 c0934d9  Increment version number for next development cycle
c0934d9 is described below

commit c0934d93f4a1fc69645b7969e2e92cdc87859677
Author: Violeta Georgieva [VMware] 
AuthorDate: Thu Apr 22 22:16:42 2021 +0300

Increment version number for next development cycle
---
 build.properties.default | 2 +-
 res/maven/mvn.properties.default | 2 +-
 webapps/docs/changelog.xml   | 4 +++-
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/build.properties.default b/build.properties.default
index 5b6f041..f24f60b 100644
--- a/build.properties.default
+++ b/build.properties.default
@@ -25,7 +25,7 @@
 # - Version Control Flags -
 version.major=7
 version.minor=0
-version.build=109
+version.build=110
 version.patch=0
 version.suffix=-dev
 
diff --git a/res/maven/mvn.properties.default b/res/maven/mvn.properties.default
index f703d03..49ef4ce 100644
--- a/res/maven/mvn.properties.default
+++ b/res/maven/mvn.properties.default
@@ -39,7 +39,7 @@ 
maven.asf.release.repo.url=https://repository.apache.org/service/local/staging/d
 maven.asf.release.repo.repositoryId=apache.releases.https
 
 # Release version info
-maven.asf.release.deploy.version=7.0.109
+maven.asf.release.deploy.version=7.0.110
 
 #Where do we load the libraries from
 tomcat.lib.path=../../output/build/lib
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index c436374..7eac531 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -118,7 +118,9 @@
   They eventually become mixed with the numbered issues (i.e., numbered
   issues do not "pop up" wrt. others).
 -->
-
+
+
+
   
 
   

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

[VOTE] Release Apache Tomcat 7.0.109

2021-04-22 Thread 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

Regards,
Violeta

[tomcat] 01/01: Tag 7.0.109

2021-04-22 Thread violetagg 
This is an automated email from the ASF dual-hosted git repository.

violetagg pushed a commit to tag 7.0.109
in repository https://gitbox.apache.org/repos/asf/tomcat.git

commit 2cdef2c0241cdf70b5edd88d3733a52e6b675047
Author: Violeta Georgieva 
AuthorDate: Thu Apr 22 11:34:21 2021 -0700

Tag 7.0.109
---
 build.properties.default   | 2 +-
 webapps/docs/changelog.xml | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/build.properties.default b/build.properties.default
index 5b6f041..fe1809b 100644
--- a/build.properties.default
+++ b/build.properties.default
@@ -27,7 +27,7 @@ version.major=7
 version.minor=0
 version.build=109
 version.patch=0
-version.suffix=-dev
+version.suffix=
 
 # - Source control flags -
 git.branch=7.0.x
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index c436374..be267d7 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -118,7 +118,7 @@
   They eventually become mixed with the numbered issues (i.e., numbered
   issues do not "pop up" wrt. others).
 -->
-
+
   
 
   

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

[tomcat] tag 7.0.109 created (now 2cdef2c)

2021-04-22 Thread violetagg 
This is an automated email from the ASF dual-hosted git repository.

violetagg pushed a change to tag 7.0.109
in repository https://gitbox.apache.org/repos/asf/tomcat.git.


  at 2cdef2c  (commit)
This tag includes the following new commits:

 new 2cdef2c  Tag 7.0.109

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


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

svn commit: r47342 [1/2] - in /dev/tomcat/tomcat-7/v7.0.109: ./ bin/ bin/embed/ bin/extras/ src/

2021-04-22 Thread violetagg 
Author: violetagg
Date: Thu Apr 22 19:04:32 2021
New Revision: 47342

Log:
Stage Tomcat 7.0.109

Added:
dev/tomcat/tomcat-7/v7.0.109/
dev/tomcat/tomcat-7/v7.0.109/KEYS
dev/tomcat/tomcat-7/v7.0.109/README.html
dev/tomcat/tomcat-7/v7.0.109/RELEASE-NOTES
dev/tomcat/tomcat-7/v7.0.109/bin/
dev/tomcat/tomcat-7/v7.0.109/bin/README.html
dev/tomcat/tomcat-7/v7.0.109/bin/apache-tomcat-7.0.109-deployer.tar.gz   
(with props)
dev/tomcat/tomcat-7/v7.0.109/bin/apache-tomcat-7.0.109-deployer.tar.gz.asc

dev/tomcat/tomcat-7/v7.0.109/bin/apache-tomcat-7.0.109-deployer.tar.gz.sha512
dev/tomcat/tomcat-7/v7.0.109/bin/apache-tomcat-7.0.109-deployer.zip   (with 
props)
dev/tomcat/tomcat-7/v7.0.109/bin/apache-tomcat-7.0.109-deployer.zip.asc
dev/tomcat/tomcat-7/v7.0.109/bin/apache-tomcat-7.0.109-deployer.zip.sha512
dev/tomcat/tomcat-7/v7.0.109/bin/apache-tomcat-7.0.109-fulldocs.tar.gz   
(with props)
dev/tomcat/tomcat-7/v7.0.109/bin/apache-tomcat-7.0.109-fulldocs.tar.gz.asc

dev/tomcat/tomcat-7/v7.0.109/bin/apache-tomcat-7.0.109-fulldocs.tar.gz.sha512
dev/tomcat/tomcat-7/v7.0.109/bin/apache-tomcat-7.0.109-windows-x64.zip   
(with props)
dev/tomcat/tomcat-7/v7.0.109/bin/apache-tomcat-7.0.109-windows-x64.zip.asc

dev/tomcat/tomcat-7/v7.0.109/bin/apache-tomcat-7.0.109-windows-x64.zip.sha512
dev/tomcat/tomcat-7/v7.0.109/bin/apache-tomcat-7.0.109-windows-x86.zip   
(with props)
dev/tomcat/tomcat-7/v7.0.109/bin/apache-tomcat-7.0.109-windows-x86.zip.asc

dev/tomcat/tomcat-7/v7.0.109/bin/apache-tomcat-7.0.109-windows-x86.zip.sha512
dev/tomcat/tomcat-7/v7.0.109/bin/apache-tomcat-7.0.109.exe   (with props)
dev/tomcat/tomcat-7/v7.0.109/bin/apache-tomcat-7.0.109.exe.asc
dev/tomcat/tomcat-7/v7.0.109/bin/apache-tomcat-7.0.109.exe.sha512
dev/tomcat/tomcat-7/v7.0.109/bin/apache-tomcat-7.0.109.tar.gz   (with props)
dev/tomcat/tomcat-7/v7.0.109/bin/apache-tomcat-7.0.109.tar.gz.asc
dev/tomcat/tomcat-7/v7.0.109/bin/apache-tomcat-7.0.109.tar.gz.sha512
dev/tomcat/tomcat-7/v7.0.109/bin/apache-tomcat-7.0.109.zip   (with props)
dev/tomcat/tomcat-7/v7.0.109/bin/apache-tomcat-7.0.109.zip.asc
dev/tomcat/tomcat-7/v7.0.109/bin/apache-tomcat-7.0.109.zip.sha512
dev/tomcat/tomcat-7/v7.0.109/bin/embed/
dev/tomcat/tomcat-7/v7.0.109/bin/embed/apache-tomcat-7.0.109-embed.tar.gz   
(with props)

dev/tomcat/tomcat-7/v7.0.109/bin/embed/apache-tomcat-7.0.109-embed.tar.gz.asc

dev/tomcat/tomcat-7/v7.0.109/bin/embed/apache-tomcat-7.0.109-embed.tar.gz.sha512
dev/tomcat/tomcat-7/v7.0.109/bin/embed/apache-tomcat-7.0.109-embed.zip   
(with props)
dev/tomcat/tomcat-7/v7.0.109/bin/embed/apache-tomcat-7.0.109-embed.zip.asc

dev/tomcat/tomcat-7/v7.0.109/bin/embed/apache-tomcat-7.0.109-embed.zip.sha512
dev/tomcat/tomcat-7/v7.0.109/bin/extras/
dev/tomcat/tomcat-7/v7.0.109/bin/extras/catalina-jmx-remote.jar   (with 
props)
dev/tomcat/tomcat-7/v7.0.109/bin/extras/catalina-jmx-remote.jar.asc
dev/tomcat/tomcat-7/v7.0.109/bin/extras/catalina-jmx-remote.jar.sha512
dev/tomcat/tomcat-7/v7.0.109/bin/extras/catalina-ws.jar   (with props)
dev/tomcat/tomcat-7/v7.0.109/bin/extras/catalina-ws.jar.asc
dev/tomcat/tomcat-7/v7.0.109/bin/extras/catalina-ws.jar.sha512
dev/tomcat/tomcat-7/v7.0.109/bin/extras/tomcat-juli-adapters.jar   (with 
props)
dev/tomcat/tomcat-7/v7.0.109/bin/extras/tomcat-juli-adapters.jar.asc
dev/tomcat/tomcat-7/v7.0.109/bin/extras/tomcat-juli-adapters.jar.sha512
dev/tomcat/tomcat-7/v7.0.109/bin/extras/tomcat-juli.jar   (with props)
dev/tomcat/tomcat-7/v7.0.109/bin/extras/tomcat-juli.jar.asc
dev/tomcat/tomcat-7/v7.0.109/bin/extras/tomcat-juli.jar.sha512
dev/tomcat/tomcat-7/v7.0.109/src/
dev/tomcat/tomcat-7/v7.0.109/src/apache-tomcat-7.0.109-src.tar.gz   (with 
props)
dev/tomcat/tomcat-7/v7.0.109/src/apache-tomcat-7.0.109-src.tar.gz.asc
dev/tomcat/tomcat-7/v7.0.109/src/apache-tomcat-7.0.109-src.tar.gz.sha512
dev/tomcat/tomcat-7/v7.0.109/src/apache-tomcat-7.0.109-src.zip   (with 
props)
dev/tomcat/tomcat-7/v7.0.109/src/apache-tomcat-7.0.109-src.zip.asc
dev/tomcat/tomcat-7/v7.0.109/src/apache-tomcat-7.0.109-src.zip.sha512

Added: dev/tomcat/tomcat-7/v7.0.109/KEYS
==
--- dev/tomcat/tomcat-7/v7.0.109/KEYS (added)
+++ dev/tomcat/tomcat-7/v7.0.109/KEYS Thu Apr 22 19:04:32 2021
@@ -0,0 +1,650 @@
+This file contains the PGP&GPG keys of various Apache developers.
+Please don't use them for email unless you have to. Their main
+purpose is code signing.
+
+Apache users: pgp < KEYS
+Apache developers:
+(pgpk -ll  && pgpk -xa ) >> this file.
+  or
+(gpg --fingerprint --list-sigs 
+ && gpg --armor --export ) >> this file.
+
+Apache developers: please ensure that your key is also available via the
+PGP keyservers (such as pgpkeys.mit.edu).
+
+
+Type Bits/KeyIDD

svn commit: r47342 [2/2] - in /dev/tomcat/tomcat-7/v7.0.109: ./ bin/ bin/embed/ bin/extras/ src/

2021-04-22 Thread violetagg 
Added: dev/tomcat/tomcat-7/v7.0.109/bin/extras/tomcat-juli-adapters.jar.sha512
==
--- dev/tomcat/tomcat-7/v7.0.109/bin/extras/tomcat-juli-adapters.jar.sha512 
(added)
+++ dev/tomcat/tomcat-7/v7.0.109/bin/extras/tomcat-juli-adapters.jar.sha512 Thu 
Apr 22 19:04:32 2021
@@ -0,0 +1 @@
+1e716a0ff106ddd4dc9c7883645f9818cc3be7d25f1553dd7b427a40c3f5761146752ff4b9cc574d450eab14ca09e15fca634d15e85cfc422d1e941c50fa4ff5
 *tomcat-juli-adapters.jar
\ No newline at end of file

Added: dev/tomcat/tomcat-7/v7.0.109/bin/extras/tomcat-juli.jar
==
Binary file - no diff available.

Propchange: dev/tomcat/tomcat-7/v7.0.109/bin/extras/tomcat-juli.jar
--
svn:mime-type = application/octet-stream

Added: dev/tomcat/tomcat-7/v7.0.109/bin/extras/tomcat-juli.jar.asc
==
--- dev/tomcat/tomcat-7/v7.0.109/bin/extras/tomcat-juli.jar.asc (added)
+++ dev/tomcat/tomcat-7/v7.0.109/bin/extras/tomcat-juli.jar.asc Thu Apr 22 
19:04:32 2021
@@ -0,0 +1,16 @@
+-BEGIN PGP SIGNATURE-
+
+iQIzBAABCAAdFiEEcT2oi+UJEVNf5xb1IIsKsdYwEccFAmCBxBwACgkQIIsKsdYw
+EcdJJQ/+KmKGOUUrOVXq2ub92tXnddnylorfSOIOyBp2WI5ceKejBw5PJ8PEnZbg
+rF6Z3ExUtPTxFnjQlMB7y22OI8UrGxqRvb1RW3of+NrZzwo4IoxSLFq4UJ/Bf3pm
+aLEOhC6smg0Hq/8FHBd9zE5bO/5xiK5dKxCzOY+ZfSigHrWmsQ0L6Xzu1zE1j4Ih
+qHbpfQZNcQe9E3+q8Ns75DbVSIKtEsoWOd3Pa4gjz3A7ru5v+3bBqguJucVEYqBr
+RPWR5FqqquYf3wEIAq6HzIE+RWitK95y3uiojNI/3OQwJAUBEAwRniE2kwEhEnix
++NrykhFV3rBR+R9XhPvKhIYxijkCq4K1MQ1sfTEsw2wm6e/a2OTYcPWDZadkKMKn
+kAlYjCFo4YT+AslQ3DFamM6LBcKjIUM5NuZmJEzmcDfa/G2bs4cx0dvndy6gTP0m
+aYN3jokoMGdFzxJ9yGZkMA+liiZJl6Cc0jSQNHcR+P9hEyxrrksPwr+HClLF7kMT
+QE5CMfPvwNB3fS9OCeJ5/XImw736TX0iSutTQYWNg1y0O911GEVkod0fGvxOd2h5
+QERMI0jq1+8RKQYXWvP69k7GlNWToBqrRUvo0TuNZhzAGxrKXMTXQDJzSD2bGfzZ
+Z3Riy3Rzq6GjJOvX5r4CWKDVIj6bmeynS6BWFlyXl62osad0TAw=
+=VsZn
+-END PGP SIGNATURE-

Added: dev/tomcat/tomcat-7/v7.0.109/bin/extras/tomcat-juli.jar.sha512
==
--- dev/tomcat/tomcat-7/v7.0.109/bin/extras/tomcat-juli.jar.sha512 (added)
+++ dev/tomcat/tomcat-7/v7.0.109/bin/extras/tomcat-juli.jar.sha512 Thu Apr 22 
19:04:32 2021
@@ -0,0 +1 @@
+7d8e14e2299cac3ad94c757f0341c58cff0fd2a7e7ec05b72e1d83dc4359c60762358c351c7bd7bdeca197405089a7667be9f36612907c21f2f1aa16cf01633b
 *tomcat-juli.jar
\ No newline at end of file

Added: dev/tomcat/tomcat-7/v7.0.109/src/apache-tomcat-7.0.109-src.tar.gz
==
Binary file - no diff available.

Propchange: dev/tomcat/tomcat-7/v7.0.109/src/apache-tomcat-7.0.109-src.tar.gz
--
svn:mime-type = application/octet-stream

Added: dev/tomcat/tomcat-7/v7.0.109/src/apache-tomcat-7.0.109-src.tar.gz.asc
==
--- dev/tomcat/tomcat-7/v7.0.109/src/apache-tomcat-7.0.109-src.tar.gz.asc 
(added)
+++ dev/tomcat/tomcat-7/v7.0.109/src/apache-tomcat-7.0.109-src.tar.gz.asc Thu 
Apr 22 19:04:32 2021
@@ -0,0 +1,16 @@
+-BEGIN PGP SIGNATURE-
+
+iQIzBAABCAAdFiEEcT2oi+UJEVNf5xb1IIsKsdYwEccFAmCBxZAACgkQIIsKsdYw
+Ecd5Hg//c/EGNqjHx5YwO+0J0/SBQKp15jmZu6bqudevEPSBfFZV6XSM4tUDOV++
+yZpM8gQ+2YZSgjoQXVrxjjjmdRQzNw92VkyKV4zjiR5Amwwkr6ZNq+kdPLsTC1t9
+g5BYtSknXG+nP5CO4x2F+Uyrq6oB1VCgpEe9gS9R6P6DbbiVb6hVBrnw6g7NNcDD
+0yQ3hwxPIbkd+pUz8+J0l/xUvq+ELvneFUZ+bQFV++DO7CGgabC334bNEitHZBbt
+qkZP1T6CZmhVSfQYQvkmszdReKVpdvdOXJwQDzg50QZLIip5oFBSjag/xb62LMKD
+xjaHd9QUf26bbD3hNygQ1Fq1fTKW837+zznWbTIJtdqE0lSZgcKvvVLamNh+98cm
+IabPHm8orrz2ByEFIhEGKldg48LuQ9x2cdujLkY2n6Zho4J68phOB+M4qkPd05fL
+PvmjiAgCt6iyGMLj8lOIqNLhAW14czSeTWuxWb7GtbM+2Tu0m2F9T0a1fIXfaX7v
+4wBedT7A15g/wDZraPrnRc1L7cY1mwCIxchk7RxgyLKCIhMhPgsGsp/0Sm+A30FI
+lSECtwGAXX4U9IYnp5Dsx4UefoLBbIKx2aRMfQgNe4xHYPbkT5h2VIDzX1agReFE
+mTeo246o6OejkHvxLcLObII/ncpdvvuEV5sRwdjvsL+iW86M2s0=
+=E863
+-END PGP SIGNATURE-

Added: dev/tomcat/tomcat-7/v7.0.109/src/apache-tomcat-7.0.109-src.tar.gz.sha512
==
--- dev/tomcat/tomcat-7/v7.0.109/src/apache-tomcat-7.0.109-src.tar.gz.sha512 
(added)
+++ dev/tomcat/tomcat-7/v7.0.109/src/apache-tomcat-7.0.109-src.tar.gz.sha512 
Thu Apr 22 19:04:32 2021
@@ -0,0 +1 @@
+ecf9c0bee0e3e1aa24f299fe633705c5a2f6aa264d9e4968cfc96aa5d0a425c2b0ff07765a8b6c67221766733bdfaed6e6c6377a8d0870d889e7063ce90a46ce
 *apache-tomcat-7.0.109-src.tar.gz
\ No newline at end of file

Added: dev/tomcat/tomcat-7/v7.0.109/src/apache-tomcat-7.0.109-src.zip
==
Binary file - no diff available.

Propchange: dev/tomcat/tomcat-7/v7.0.109/src/apache-tomcat-7.0.109-s

Re: [websocket] proper SPI for encoder/decoder instantiation?

2021-04-22 Thread Mark Thomas 

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

Le jeu. 22 avr. 2021 à 17:32, Mark Thomas  a écrit :


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

Hi,

Is it possible to reuse/add/have a SPI to create ws coders/decoders?

Currently it is a hardcoded factory doing a "new"
(org.apache.tomcat.websocket.Util#getDecoders for decoders, for encoders

it

is a bit worse since there is an instance as a check here
org.apache.tomcat.websocket.server.WsServerContainer#validateEncoders and
the instantiation happens here
org.apache.tomcat.websocket.WsRemoteEndpointImplBase#setEncoders).

Best would likely be to reuse tomcat instance manager since it would make
it working OOTB for integrations/users and also enable to have a proper
lifecycle management (destroyInstance).

Wdyt?


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



It is already required to cover 7.1.1.


ACK. Tomcat pretty much ignored that section.


Currently tomee worked around it by dropping default sci and having a
custom one override what it can but it is not generally reusable in cdi app
easily so spi is needed and destroy phase too by spec ;).


Switching to use the InstanceManager looks doable. It is already 
available on the WebSocketContainer.


Worth opening a BZ issue to track it.

Mark

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

2021-04-22 Thread Romain Manni-Bucau 
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
> >
> >
>

Re: [websocket] proper SPI for encoder/decoder instantiation?

2021-04-22 Thread Romain Manni-Bucau 
Le jeu. 22 avr. 2021 à 17:32, Mark Thomas  a écrit :

> On 22/04/2021 16:24, Romain Manni-Bucau wrote:
> > Hi,
> >
> > Is it possible to reuse/add/have a SPI to create ws coders/decoders?
> >
> > Currently it is a hardcoded factory doing a "new"
> > (org.apache.tomcat.websocket.Util#getDecoders for decoders, for encoders
> it
> > is a bit worse since there is an instance as a check here
> > org.apache.tomcat.websocket.server.WsServerContainer#validateEncoders and
> > the instantiation happens here
> > org.apache.tomcat.websocket.WsRemoteEndpointImplBase#setEncoders).
> >
> > Best would likely be to reuse tomcat instance manager since it would make
> > it working OOTB for integrations/users and also enable to have a proper
> > lifecycle management (destroyInstance).
> >
> > Wdyt?
>
> -> https://github.com/eclipse-ee4j/websocket-api/issues


It is already required to cover 7.1.1.
Currently tomee worked around it by dropping default sci and having a
custom one override what it can but it is not generally reusable in cdi app
easily so spi is needed and destroy phase too by spec ;).


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

[tomcat] 03/04: Remove unnecessary code.

2021-04-22 Thread markt 
This is an automated email from the ASF dual-hosted git repository.

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

commit 1c1fb14930b5ccf19d7dacaf6582c20f8b8658d6
Author: Mark Thomas 
AuthorDate: Wed Apr 21 19:46:04 2021 +0100

Remove unnecessary code.

ScriptingVariabler$ScriptingVariableVisitor will already have skipped
any variables where declare is set to false.
---
 java/org/apache/jasper/compiler/Generator.java | 36 --
 1 file changed, 17 insertions(+), 19 deletions(-)

diff --git a/java/org/apache/jasper/compiler/Generator.java 
b/java/org/apache/jasper/compiler/Generator.java
index df5bd9d..c98ddf7 100644
--- a/java/org/apache/jasper/compiler/Generator.java
+++ b/java/org/apache/jasper/compiler/Generator.java
@@ -2714,33 +2714,31 @@ class Generator {
 return;
 }
 
+// Note: ScriptingVariabler$ScriptingVariableVisitor will already
+// have skipped any variables where declare is set to false.
 List vec = n.getScriptingVars(scope);
 if (vec != null) {
 for (Object elem : vec) {
 if (elem instanceof VariableInfo) {
 VariableInfo varInfo = (VariableInfo) elem;
-if (varInfo.getDeclare()) {
-out.printin(varInfo.getClassName());
-out.print(" ");
-out.print(varInfo.getVarName());
-out.println(" = null;");
-}
+out.printin(varInfo.getClassName());
+out.print(" ");
+out.print(varInfo.getVarName());
+out.println(" = null;");
 } else {
 TagVariableInfo tagVarInfo = (TagVariableInfo) elem;
-if (tagVarInfo.getDeclare()) {
-String varName = tagVarInfo.getNameGiven();
-if (varName == null) {
-varName = n.getTagData().getAttributeString(
-tagVarInfo.getNameFromAttribute());
-} else if (tagVarInfo.getNameFromAttribute() != 
null) {
-// alias
-continue;
-}
-out.printin(tagVarInfo.getClassName());
-out.print(" ");
-out.print(varName);
-out.println(" = null;");
+String varName = tagVarInfo.getNameGiven();
+if (varName == null) {
+varName = n.getTagData().getAttributeString(
+tagVarInfo.getNameFromAttribute());
+} else if (tagVarInfo.getNameFromAttribute() != null) {
+// alias
+continue;
 }
+out.printin(tagVarInfo.getClassName());
+out.print(" ");
+out.print(varName);
+out.println(" = null;");
 }
 }
 }

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

[tomcat] 02/04: Remove unused code

2021-04-22 Thread markt 
This is an automated email from the ASF dual-hosted git repository.

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

commit 7dcf54b7a7f5fdd9560241d25427aba3e8899a84
Author: Mark Thomas 
AuthorDate: Wed Apr 21 12:51:04 2021 +0100

Remove unused code
---
 java/org/apache/jasper/compiler/Generator.java | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/java/org/apache/jasper/compiler/Generator.java 
b/java/org/apache/jasper/compiler/Generator.java
index 6304797..df5bd9d 100644
--- a/java/org/apache/jasper/compiler/Generator.java
+++ b/java/org/apache/jasper/compiler/Generator.java
@@ -2334,7 +2334,9 @@ class Generator {
 public void visit(Node.AttributeGenerator n) throws JasperException {
 Node.CustomTag tag = n.getTag();
 Node.JspAttribute[] attrs = tag.getJspAttributes();
-for (int i = 0; attrs != null && i < attrs.length; i++) {
+// The TagPluginManager only creates AttributeGenerator nodes for
+// attributes that are present.
+for (int i = 0; i < attrs.length; i++) {
 if (attrs[i].getName().equals(n.getName())) {
 out.print(evaluateAttribute(getTagHandlerInfo(tag),
 attrs[i], tag, null));

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

[tomcat] 01/04: Remove unnecessary code.

2021-04-22 Thread markt 
This is an automated email from the ASF dual-hosted git repository.

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

commit b58cc1149894633ff426b1dd993f2745dfc4a0cc
Author: Mark Thomas 
AuthorDate: Wed Apr 21 09:42:48 2021 +0100

Remove unnecessary code.

If useTagPlugin has been set to true, then getAtSTag() and getAtETag()
will also have been configured to return non-null values.
---
 java/org/apache/jasper/compiler/Generator.java | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/java/org/apache/jasper/compiler/Generator.java 
b/java/org/apache/jasper/compiler/Generator.java
index b7ad241..6304797 100644
--- a/java/org/apache/jasper/compiler/Generator.java
+++ b/java/org/apache/jasper/compiler/Generator.java
@@ -2361,13 +2361,9 @@ class Generator {
 }
 
 private void generateTagPlugin(Node.CustomTag n) throws 
JasperException {
-if (n.getAtSTag() != null) {
-n.getAtSTag().visit(this);
-}
+n.getAtSTag().visit(this);
 visitBody(n);
-if (n.getAtETag() != null) {
-n.getAtETag().visit(this);
-}
+n.getAtETag().visit(this);
 }
 
 private void generateCustomStart(Node.CustomTag n,

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

[tomcat] 04/04: Remove unnecessary code

2021-04-22 Thread markt 
This is an automated email from the ASF dual-hosted git repository.

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

commit bf5b9feca166557134120f0fc5210588c7b3673d
Author: Mark Thomas 
AuthorDate: Thu Apr 22 17:19:05 2021 +0100

Remove unnecessary code
---
 java/org/apache/jasper/compiler/Generator.java | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/java/org/apache/jasper/compiler/Generator.java 
b/java/org/apache/jasper/compiler/Generator.java
index c98ddf7..474ac5c 100644
--- a/java/org/apache/jasper/compiler/Generator.java
+++ b/java/org/apache/jasper/compiler/Generator.java
@@ -2802,10 +2802,12 @@ class Generator {
 if (varName == null) {
 varName = n.getTagData().getAttributeString(
 tagVarInfo.getNameFromAttribute());
-} else if (tagVarInfo.getNameFromAttribute() != null) {
-// alias
-continue;
 }
+// Alias is not possible here.
+// Alias can only be configured for tag files. As SimpleTag
+// implementations, isFragment will always be true above
+// hence execution never reaches this point.
+
 String tmpVarName = "_jspx_" + varName + "_"
 + n.getCustomNestingLevel();
 out.printin(tmpVarName);
@@ -2872,10 +2874,12 @@ class Generator {
 if (varName == null) {
 varName = n.getTagData().getAttributeString(
 tagVarInfo.getNameFromAttribute());
-} else if (tagVarInfo.getNameFromAttribute() != null) {
-// alias
-continue;
 }
+// Alias is not possible here.
+// Alias can only be configured for tag files. As SimpleTag
+// implementations, isFragment will always be true above
+// hence execution never reaches this point.
+
 String tmpVarName = "_jspx_" + varName + "_"
 + n.getCustomNestingLevel();
 out.printin(varName);

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

[tomcat] branch master updated (e663ab0 -> bf5b9fe)

2021-04-22 Thread markt 
This is an automated email from the ASF dual-hosted git repository.

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


from e663ab0  Code clean-up. No functional change. Primarily to trigger a 
CI build.
 new b58cc11  Remove unnecessary code.
 new 7dcf54b  Remove unused code
 new 1c1fb14  Remove unnecessary code.
 new bf5b9fe  Remove unnecessary code

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


Summary of changes:
 java/org/apache/jasper/compiler/Generator.java | 64 +-
 1 file changed, 32 insertions(+), 32 deletions(-)

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

2021-04-22 Thread Raymond Augé 
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
>
>

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

2021-04-22 Thread Mark Thomas 

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é 
a écrit :


Are you maybe in JPMS mode?

On Thu., Apr. 22, 2021, 9:51 a.m. Raymond Augé, 
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

Re: [websocket] proper SPI for encoder/decoder instantiation?

2021-04-22 Thread Mark Thomas 

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

Hi,

Is it possible to reuse/add/have a SPI to create ws coders/decoders?

Currently it is a hardcoded factory doing a "new"
(org.apache.tomcat.websocket.Util#getDecoders for decoders, for encoders it
is a bit worse since there is an instance as a check here
org.apache.tomcat.websocket.server.WsServerContainer#validateEncoders and
the instantiation happens here
org.apache.tomcat.websocket.WsRemoteEndpointImplBase#setEncoders).

Best would likely be to reuse tomcat instance manager since it would make
it working OOTB for integrations/users and also enable to have a proper
lifecycle management (destroyInstance).

Wdyt?


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

Mark

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

[websocket] proper SPI for encoder/decoder instantiation?

2021-04-22 Thread Romain Manni-Bucau 
Hi,

Is it possible to reuse/add/have a SPI to create ws coders/decoders?

Currently it is a hardcoded factory doing a "new"
(org.apache.tomcat.websocket.Util#getDecoders for decoders, for encoders it
is a bit worse since there is an instance as a check here
org.apache.tomcat.websocket.server.WsServerContainer#validateEncoders and
the instantiation happens here
org.apache.tomcat.websocket.WsRemoteEndpointImplBase#setEncoders).

Best would likely be to reuse tomcat instance manager since it would make
it working OOTB for integrations/users and also enable to have a proper
lifecycle management (destroyInstance).

Wdyt?

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

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

2021-04-22 Thread Romain Manni-Bucau 
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?


Le jeu. 22 avr. 2021 à 16:10, Raymond Augé 
a écrit :

> Are you maybe in JPMS mode?
>
> On Thu., Apr. 22, 2021, 9:51 a.m. Raymond Augé, 
> 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
> >>> >
> >>>
> >>
>

Tag Tomcat 7

2021-04-22 Thread Violeta Georgieva 
Hi,

I'm gonna tag Tomcat 7 later today.

Regards,
Violeta

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

2021-04-22 Thread Romain Manni-Bucau 
Le jeu. 22 avr. 2021 à 16:06, Raymond Augé 
a écrit :

> @ServiceProvider is just a hint no?
>

Hmm, didn't check the tomcat specific setup but thought it was adding
META-INF/services/ entry too which is current issue.
Seems you are right and
https://github.com/apache/tomcat/blob/master/res/META-INF/tomcat-websocket.jar/services/jakarta.websocket.server.ServerEndpointConfig$Configurator
is just "there".


>
> It does not change the implementation behavior... Unless you've found
> otherwise, which would be surprising.
>

If it does not add the file all good and we can drop
https://github.com/apache/tomcat/blob/master/res/META-INF/tomcat-websocket.jar/services/jakarta.websocket.server.ServerEndpointConfig$Configurator
all good for me


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

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

2021-04-22 Thread Raymond Augé 
On Thu., Apr. 22, 2021, 9:46 a.m. Raymond Augé, 
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
>> >
>>
>

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

2021-04-22 Thread Raymond Augé 
Are you maybe in JPMS mode?

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

>
>
> On Thu., Apr. 22, 2021, 9:46 a.m. Raymond Augé, 
> 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
>>> >
>>>
>>

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

2021-04-22 Thread Raymond Augé 
@ServiceProvider is just a hint no?

It does not change the implementation behavior... Unless you've found
otherwise, which would be surprising.

Ray

On Thu., Apr. 22, 2021, 9:29 a.m. Romain Manni-Bucau, 
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
> >
>

Websocket server configurator as @ServiceProvider: a bug?

2021-04-22 Thread Romain Manni-Bucau 
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  |
LinkedIn  | Book

Re: More CI issues

2021-04-22 Thread Mark Thomas 

On 21/04/2021 19:53, Mark Thomas wrote:
Both GitHUb CI and Travis CI have started to report failures due to hash 
mismatches for downloaded resources.


I'm not sure what is going on at this point. It doesn't seem to be 
related to a faulty mirror or an incorrect download hash in 
build.properties.


Still looking (although I might not make much more progress today)


It looks like this has resolved itself overnight. It might be related to 
this: https://issues.apache.org/jira/browse/INFRA-21767


Mark

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