[GitHub] [tomcat] reschke edited a comment on pull request #325: Simplify ETag check

[GitBox]

reschke edited a comment on pull request #325:
URL: https://github.com/apache/tomcat/pull/325#issuecomment-661164935


   You are citing the spec very selectively (hint: there are strong and weak 
comparison functions).



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

Re: [tomcat] 01/02: Fix BZ 64540 - switch from bndwrap task to bnd task, begin generating a better manifest and make sure the resulting jar contents are correct.

[Coty Sutherland]

This commit is problematic :( It's broken some projects that depend on
Tomcat because now the tomcat-coyote.jar doesn't contain the
org.apache.tomcat.util.net.jsse or org.apache.tomcat.util.modeler.modules
packages which results in ClassNotFoundExceptions. I haven't seen any
issues with other jars yet. The removal of those packages from the jar
looks intentional, but we aren't providing the classes anywhere else for
users to use which is causing problems. Thoughts?

On Tue, Jun 23, 2020 at 6:43 AM  wrote:

> 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
>
> commit 393c022c87e5cbebf1b96c3e1e7aa3b2ab4d5b74
> Author: Raymond Augé 
> AuthorDate: Fri Jun 19 09:32:56 2020 -0400
>
> Fix BZ 64540 - switch from bndwrap task to bnd task, begin generating
> a better manifest and make sure the resulting jar contents are correct.
>
> Signed-off-by: Raymond Augé 
> ---
>  build.xml | 17 ++---
>  res/bnd/annotations-api.jar.tmp.bnd   |  2 +-
>  res/bnd/build-defaults.bnd| 15 +++
>  res/bnd/catalina-tribes.jar.tmp.bnd   |  5 -
>  res/bnd/catalina.jar.tmp.bnd  |  5 -
>  res/bnd/el-api.jar.tmp.bnd|  2 +-
>  res/bnd/jasper-el.jar.tmp.bnd |  8 +++-
>  res/bnd/jasper.jar.tmp.bnd|  7 ++-
>  res/bnd/jaspic-api.jar.tmp.bnd|  2 +-
>  res/bnd/jsp-api.jar.tmp.bnd   |  2 +-
>  res/bnd/servlet-api.jar.tmp.bnd   |  2 +-
>  res/bnd/{el-api.jar.tmp.bnd => spec-defaults.bnd} | 11 ++-
>  res/bnd/tomcat-coyote.jar.tmp.bnd |  9 -
>  res/bnd/tomcat-embed-core.jar.tmp.bnd | 15 ++-
>  res/bnd/tomcat-embed-el.jar.tmp.bnd   |  8 +++-
>  res/bnd/tomcat-embed-jasper.jar.tmp.bnd   |  7 ++-
>  res/bnd/tomcat-embed-websocket.jar.tmp.bnd|  7 ++-
>  res/bnd/tomcat-util.jar.tmp.bnd   |  6 +-
>  res/bnd/tomcat-websocket.jar.tmp.bnd  |  7 ++-
>  res/bnd/websocket-api.jar.tmp.bnd |  2 +-
>  webapps/docs/changelog.xml|  5 +
>  21 files changed, 119 insertions(+), 25 deletions(-)
>
> diff --git a/build.xml b/build.xml
> index 1900b78..7dba702 100644
> --- a/build.xml
> +++ b/build.xml
> @@ -3358,9 +3358,20 @@ Read the Building page on the Apache Tomcat
> documentation site for details on ho
>
>
>  
> -
> -  
> -
> +
> +
> + +  basedir="${basedir}"
> +  output="${jarfile}.tmp"
> +>
> +  
> +
> +
> +  
> +  
> +
> +  
> +
>  
>  
>
> diff --git a/res/bnd/annotations-api.jar.tmp.bnd
> b/res/bnd/annotations-api.jar.tmp.bnd
> index 9399b6c..9b2f84e 100644
> --- a/res/bnd/annotations-api.jar.tmp.bnd
> +++ b/res/bnd/annotations-api.jar.tmp.bnd
> @@ -13,7 +13,7 @@
>  # See the License for the specific language governing permissions and
>  # limitations under the License.
>
> --include: build-defaults.bnd
> +-include: build-defaults.bnd, spec-defaults.bnd
>
>  Bundle-Name: tomcat-annotations-api
>  Bundle-SymbolicName: org.apache.tomcat-annotations-api
> diff --git a/res/bnd/build-defaults.bnd b/res/bnd/build-defaults.bnd
> index 06e64c4..cdefb9c 100644
> --- a/res/bnd/build-defaults.bnd
> +++ b/res/bnd/build-defaults.bnd
> @@ -14,3 +14,18 @@
>  # limitations under the License.
>
>  Bundle-Version: ${version_cleanup;${version}}
> +
> +Specification-Title: Apache Tomcat
> +Specification-Version: ${version.major.minor}
> +Specification-Vendor: Apache Software Foundation
> +Implementation-Title: Apache Tomcat
> +Implementation-Version: ${version}
> +Implementation-Vendor: Apache Software Foundation
> +
> +X-Compile-Source-JDK: ${compile.source}
> +X-Compile-Target-JDK: ${compile.target}
> +
> +-includeresource.notice:
> META-INF/NOTICE;literal="${replace;${cat;../META-INF/default.notice};@YEAR
> @;${year}}\n"
> +-includeresource.license: {META-INF/LICENSE=../META-INF/default.license}
> +
> +-noclassforname: true
> \ No newline at end of file
> diff --git a/res/bnd/catalina-tribes.jar.tmp.bnd
> b/res/bnd/catalina-tribes.jar.tmp.bnd
> index 630169d..d6ae14a 100644
> --- a/res/bnd/catalina-tribes.jar.tmp.bnd
> +++ b/res/bnd/catalina-tribes.jar.tmp.bnd
> @@ -28,4 +28,7 @@ Export-Package: \
>  org.apache.catalina.tribes.transport,\
>  org.apache.catalina.tribes.transport.bio,\
>  org.apache.catalina.tribes.transport.nio,\
> -org.apache.catalina.tribes.util
> \ No newline at end of file
> +org.apache.catalina.tribes.util
> +
> +-includepackage: \
> +org.apache.catalina.tribes.membership.cloud
> \ No newline at end of file
> diff --git a/res/bnd/catalina.jar.tmp.bnd b/res/bnd/catalina

[Bug 64614] tomcat doesn't work with JSSE FIPS-compliant with NSS

[bugzilla]

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

--- Comment #5 from jfclere  ---
I need to investigate a little I will come with a better patch later this week.

-- 
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] stokito commented on pull request #325: Simplify ETag check

[GitBox]

stokito commented on pull request #325:
URL: https://github.com/apache/tomcat/pull/325#issuecomment-661232860


   Yeah, that's why I said "in fact should do". This is not a big deal while 
Tomcat generates those ETag itself. I'm not even sure that there is any clients 
who sends multiple ETags. But the change improves performance a lot.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[Bug 64616] Change ETag format to Nginx like

[bugzilla]

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

--- Comment #4 from Sergey Ponomarev  ---
I also thought to make ETag configurable like in Apache HTTPD but in fact for
clients this is still opaque value and the Nginx is not configurable anyway
while Apache Htttpd can be configured to be compliant with Nginx.

I'm asking for this because this is a real issue for me. I developing a new
service (https://github.com/yurt-page coming soon) that will use several
servers:
* WiFi router with a small blog engine running on BusyBox httpd
* Tomcat on PC with the same blog engine plus admin panel. When PC is online
requests will be redirected from router to PC.
* Front server with Nginx with basic WAF, cache offload and static IP (kind of
Cloudflare).

So here the problem with ETag is extremely important for success.
BusyBox not even had support of ETag so I sent a patch to to them
http://lists.busybox.net/pipermail/busybox/2020-July/088102.html

And I'm pretty sure that I'm not the only one who needs the ETag format
interop.

BTW the new ETag format while generated at the same speed are 14 bytes long
while old used 22. Seems like not a big deal but they are transmitted on each
request.

-- 
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] michael-o commented on pull request #324: Change ETag format to Nginx like

[GitBox]

michael-o commented on pull request #324:
URL: https://github.com/apache/tomcat/pull/324#issuecomment-661263952


   Even if file and JAR are fine, the ETag implementation is on the 
`AbstractResource` and from here we cannot make any assumptions.



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] michael-o commented on pull request #324: Change ETag format to Nginx like

[GitBox]

michael-o commented on pull request #324:
URL: https://github.com/apache/tomcat/pull/324#issuecomment-661265371


   Why don't you delete the ETags send from Tomcat in nginx config, use a 
caching module and rely on nginx ETags only?



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] reschke commented on pull request #325: Simplify ETag check

[GitBox]

reschke commented on pull request #325:
URL: https://github.com/apache/tomcat/pull/325#issuecomment-661279813


   > But the change improves performance a lot.
   
   Can you quantify that?



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

Re: Native Image - Reflectionless Concept

[Raymond Auge]

Xml-less Tomcat would also be very useful for OSGi http whiteboard
implementation which I'd like to work on in the coming months.

So I +1 more programmatic API.

Just let's not forget about tear down. So many APIs completely ignore a
tear down lifecycle.

- Ray

On Mon, Jul 20, 2020, 12:16 Romain Manni-Bucau, 
wrote:

> I think a xml-less tomcat is awaited since servlet 3 - graal or not - but
> agree risk is a bit higher.
> That said path is different so wonder if skipping a temp solution can not
> be worth after all for the community.
>
> Le lun. 20 juil. 2020 à 17:58, Filip Hanik  a écrit :
>
>>
>> On 7/20/20 8:47 AM, Romain Manni-Bucau wrote:
>>
>>
>>
>> Le lun. 20 juil. 2020 à 17:41, Filip Hanik  a écrit :
>>
>>> Thanks for chiming in:
>>> On 7/16/20 6:46 AM, Romain Manni-Bucau wrote:
>>>
>>> Hi everyone,
>>>
>>> I think the generation is the sanest option since code stay clean but it
>>> shouldn't be done in tomcat IMHO but in user code and with a nice wrapper
>>> (mvn tomcat:dump/gradle tomcatDump etc, or whatever name you like ;)).
>>>
>>> That's always an option, but it would become an external artifact and
>>> easily end up out of sync.
>>>
>>
>> Was thinking to keep the dumper in tomcat code base and the plugin to
>> consume it so it would stay in sync, but agree it is a small risk.
>>
>>
>>> This build phase would dump the descriptors in plain java and would load
>>> them with an unique - ie single for the whole webapp - plain SPI -
>>> ServiceLoader - maybe?
>>>
>>> The goal of this artifact was to reduce the size and classes from a full
>>> tomcat (already available in tomcat-embed-core), down to a code base where
>>> XML/digester/descriptors aren't used, hence tomcat-embed-programmatic
>>>
>>> This kind of build tool assumes you have all the runtime state in the
>>> build - which is typically the case for graalvm - so you can completely
>>> dump StandardContext state after start phase there and just reload it from
>>> the precomputed model.
>>> Only trick is about file paths which must either be recomputed or be
>>> configurable to another base but it does not sound crazy.
>>>
>>> The less tool-ed option would be to extract all "reflectionfull" code in
>>> methods and use graalvm substitutions to drop them and use plain java
>>> instead (with a good naming convention, it can be generated as well).
>>> Keeps the duplication but at least the main code stays clean and
>>> optimizations stays together.
>>>
>>> That's pretty much what we're doing right now. Many of these feel like
>>> hacks simply to mitigate how GraalVM/AOT does code initialization (all code
>>> loaded initialized at startup)
>>>
>>
>> Reviewing the hacks, all can be done cleanly if extracted in methods.
>> Pushing the logic next step - I don't know if worth it but trying to use
>> this picture to explain:
>>
>> 1. A noxml module can be done with protected methods/extension-points for
>> XML loading - even usable in java standalone mode
>> 2. Current tomcat can extend noxml module
>> 3. Graal can be based on 1
>>
>> This would benefit both jvm and graal users at the end.
>> Today 1 is possible with some hacks on tomcat embedded but it is highly
>> not natural so this can be an opportunity to make it a feature maybe?
>>
>> I believe that tomcat-embed-programmatic is a viable interim solution,
>> it's a low risk. The question for you, and the rest of the community, is
>> the reward itself enough? ie, is it worth it?
>>
>> There is some talk about making "native-ness" part of the Java itself,
>> and that could change a lot of assumptions. Making it a feature,
>> refactoring code to satisfy 1, is a bit more intrusive at this point in
>> time. I believe it introduces more risk than reward.
>>
>>
>> Filip
>>
>>
>>
>>
>>> Filip
>>>
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau  |  Blog
>>>  | Old Blog
>>>  | Github
>>>  | LinkedIn
>>>  | Book
>>> 
>>>
>>>
>>> Le jeu. 16 juil. 2020 à 14:31, Rémy Maucherat  a
>>> écrit :
>>>
 On Mon, Jul 13, 2020 at 11:59 PM Filip Hanik  wrote:

> for discussion, all feedback and questions welcome:
>
>
> I've created a concept of having Apache Tomcat, embedded, run without
> reflection in a native image.
> This concept creates a jar, tomcat-embedded-programmatic.jar, that can
> be fine tuned to only include what is needed in a default configuration
> when an embedded tomcat instance is used and configured programatically.
>
> Steps to run Apache Tomcat using Java 8 without reflection
>
>1. Make sure you have native-image (from the graal installation)
>on your path
>2. git clone -b feature/embed-minimal-programmatic-jar-file-master
>g...@github.com:fhanik/tomcat.git
>  

[GitHub] [tomcat] stokito commented on pull request #325: Simplify ETag check

[GitBox]

stokito commented on pull request #325:
URL: https://github.com/apache/tomcat/pull/325#issuecomment-661298600


   At least twice fast because and creates less memory garbage.
   Here is a benchmark with results 
https://gist.github.com/stokito/a82eed1aef6ad965e2a279825f1c3420
   I tested with force GC between tests to compare just CPU time. Note that 
this comparison performed for each request.
   



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] stokito edited a comment on pull request #325: Simplify ETag check

[GitBox]

stokito edited a comment on pull request #325:
URL: https://github.com/apache/tomcat/pull/325#issuecomment-661298600


   At least twice fast because creates less memory garbage.
   Here is a benchmark with results 
https://gist.github.com/stokito/a82eed1aef6ad965e2a279825f1c3420
   I tested with force GC between tests to compare just CPU time. Note that 
this comparison performed for each request.
   



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] stokito commented on pull request #324: Change ETag format to Nginx like

[GitBox]

stokito commented on pull request #324:
URL: https://github.com/apache/tomcat/pull/324#issuecomment-661312436


   > we cannot make any assumptions.
   
   But we already did when implemented the default method :) I used Tomcat for 
about 10 years in different projects and once even patched it for company's 
internal needs but never saw the AbstractResource. Can you elaborate how can 
this break anything?
   The most important is to check Spring but it uses it's own hash based 
[ShallowEtagHeaderFilter](https://github.com/spring-projects/spring-framework/blob/master/spring-web/src/main/java/org/springframework/web/filter/ShallowEtagHeaderFilter.java)
   
   > Why don't you delete the ETags send from Tomcat in nginx
   Never did that before but 
[here](https://stackoverflow.com/questions/33431722/in-nginx-etag-directive-doesnt-work-for-proxy-pass)
 is said that Nginx creates ETags only for local static files. I checked 
[docs](http://nginx.org/en/docs/http/ngx_http_proxy_module.html) and there is 
no anything about ETags.
   To create ETag from upstream Nginx needs a size (and it have it) and last 
mod time (can be retrieved from Last-Modifed but in my case BusyBox httpd not 
returns it).
   Anyway in my case some users will connect directly to upstream server. 
   
   



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] stokito edited a comment on pull request #325: Simplify ETag check

[GitBox]

stokito edited a comment on pull request #325:
URL: https://github.com/apache/tomcat/pull/325#issuecomment-661298600


   At least twice fast because creates less memory garbage. For two comma 
separated ETags may work 5 times faster.
   Here is a benchmark with results 
https://gist.github.com/stokito/a82eed1aef6ad965e2a279825f1c3420
   I tested with force GC between tests to compare just CPU time. Note that 
this comparison performed for each request.
   



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] markt-asf commented on pull request #324: Change ETag format to Nginx like

[GitBox]

markt-asf commented on pull request #324:
URL: https://github.com/apache/tomcat/pull/324#issuecomment-661338844


   I think it is unlikely this patch will get applied as-is.
   I think a patch that made is easier to provide custom ETags (without 
changing the current behaviour by default) is much more likely to be accepted.
   The other option is to provide your own default servlet that provides the 
ETag.
   At this point a small refactoring of `DefaultServlet` so obtaining ETags 
goes through a single, override-able method looks like a possible solution.



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] stokito edited a comment on pull request #324: Change ETag format to Nginx like

[GitBox]

stokito edited a comment on pull request #324:
URL: https://github.com/apache/tomcat/pull/324#issuecomment-661312436


   > we cannot make any assumptions.
   
   But we already did when implemented the default method :) I used Tomcat for 
about 10 years in different projects and once even patched it for company's 
internal needs but never saw the AbstractResource. Can you elaborate how can 
this break anything?
   The most important is to check Spring but it uses it's own hash based 
[ShallowEtagHeaderFilter](https://github.com/spring-projects/spring-framework/blob/master/spring-web/src/main/java/org/springframework/web/filter/ShallowEtagHeaderFilter.java)
   
   > Why don't you delete the ETags send from Tomcat in nginx
   
   Never did that before but 
[here](https://stackoverflow.com/questions/33431722/in-nginx-etag-directive-doesnt-work-for-proxy-pass)
 is said that Nginx creates ETags only for local static files. I checked 
[docs](http://nginx.org/en/docs/http/ngx_http_proxy_module.html) and there is 
no anything about ETags.
   To create ETag from upstream Nginx needs a size (and it have it) and last 
mod time (can be retrieved from Last-Modifed but in my case BusyBox httpd not 
returns it).
   Anyway in my case some users will connect directly to upstream server. 
   
   



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] stokito commented on pull request #325: Simplify ETag check

[GitBox]

stokito commented on pull request #325:
URL: https://github.com/apache/tomcat/pull/325#issuecomment-661356032


   I found related ticket https://bz.apache.org/bugzilla/show_bug.cgi?id=64265



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] reschke commented on pull request #325: Simplify ETag check

[GitBox]

reschke commented on pull request #325:
URL: https://github.com/apache/tomcat/pull/325#issuecomment-661607221


   > At least twice fast because creates less memory garbage
   
   And this is measurable in practice., not in an isolated unit test?
   



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] stokito edited a comment on pull request #325: Simplify ETag check

[GitBox]

stokito edited a comment on pull request #325:
URL: https://github.com/apache/tomcat/pull/325#issuecomment-661356032


   a related ticket https://bz.apache.org/bugzilla/show_bug.cgi?id=64265



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[Bug 64614] New: tomcat doesn't work with JSSE FIPS-compliant with NSS

[bugzilla]

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

Bug ID: 64614
   Summary: tomcat doesn't work with JSSE FIPS-compliant with NSS
   Product: Tomcat 9
   Version: 9.0.x
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Connectors
  Assignee: dev@tomcat.apache.org
  Reporter: jfcl...@gmail.com
  Target Milestone: -

When configured with FIPS with NSS The connector gives the following exception:
20-Jul-2020 09:11:03.863 SEVERE [main]
org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to
initialize component [Connector[HTTP/1.1-8443]]
org.apache.catalina.LifecycleException: Protocol handler initialization
failed
at
org.apache.catalina.connector.Connector.initInternal(Connector.java:1042)
at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
at
org.apache.catalina.core.StandardService.initInternal(StandardService.java:533)
at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
at
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1057)
at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
at org.apache.catalina.startup.Catalina.load(Catalina.java:690)
at org.apache.catalina.startup.Catalina.load(Catalina.java:712)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:302)
at
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:472)
Caused by: java.lang.IllegalArgumentException: FIPS mode: only SunJSSE
KeyManagers may be used
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:99)
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:71)
at
org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:216)
at
org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1141)
at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1154)
at
org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:581)
at
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:74)
at
org.apache.catalina.connector.Connector.initInternal(Connector.java:1039)
... 13 more
Caused by: java.security.KeyManagementException: FIPS mode: only
SunJSSE KeyManagers may be used
at
sun.security.ssl.SSLContextImpl.chooseKeyManager(SSLContextImpl.java:154)
at
sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:71)
at javax.net.ssl.SSLContext.init(SSLContext.java:282)
at
org.apache.tomcat.util.net.jsse.JSSESSLContext.init(JSSESSLContext.java:61)
at
org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:246)
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:97)
... 20 more

-- 
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 64614] tomcat doesn't work with JSSE FIPS-compliant with NSS

[bugzilla]

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

--- Comment #1 from jfclere  ---
To configure I did the following:

modutil -create -dbdir /home/jfclere/db
touch /home/jfclere/db/secmod.db (for what?).
modutil -fips true -dbdir /home/jfclere/db
modutil -list -dbdir /home/jfclere/db (looks OK)
modutil -changepw "NSS FIPS 140-2 Certificate DB" -dbdir /home/jfclere/db
(-list to get the tokens)
modutil -changepw "NSS Certificate DB" -dbdir /home/jfclere/db (when no fips!).
certutil -S -k rsa -n jbossweb  -t "u,u,u" -x -s "CN=localhost, OU=MYOU,
O=MYORG, L=MYCITY, ST=MYSTATE, C=MY" -d /home/jfclere/db

Add the providers in jre/lib/security/java.security

security.provider.4=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-NSSfips

security.provider.10=sun.security.pkcs11.SunPKCS11
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.252.b09-1.fc32.x86_64/jre/lib/security/nss.cfg

I have in jre/lib/security/nss.cfg:
+++
name = NSSfips
nssLibraryDirectory = /usr/lib64
nssSecmodDirectory = /home/jfclere/db
nssDbMode = readWrite
nssModule = fips
attributes = compatibility
handleStartupErrors = ignoreMultipleInitialisation
+++
I have in server.xml
+++






+++

-- 
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 64614] tomcat doesn't work with JSSE FIPS-compliant with NSS

[bugzilla]

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

jfclere  changed:

   What|Removed |Added

 CC||jfcl...@gmail.com

--- Comment #2 from jfclere  ---
Created attachment 37364
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=37364&action=edit
Possible patch for the issue.

Patch that fixes the issue.

-- 
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 master updated: Add missing code generation for remaining digester rules

[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 07d6188  Add missing code generation for remaining digester rules
07d6188 is described below

commit 07d6188233fa4de87afbc83b7a3cb36e69556d4c
Author: remm 
AuthorDate: Mon Jul 20 11:30:44 2020 +0200

Add missing code generation for remaining digester rules

A quick test with the web.xml files from Tomcat looks rather decent. I
don't know yet if it will be used by at least the functionality is more
complete this way.
Another item that can be added is generating a static loader as at the
moment each individual generated class is dynamically loaded, even
though the full list is known.
---
 .../tomcat/util/descriptor/web/WebRuleSet.java | 150 +++--
 .../tomcat/util/digester/CallMethodRule.java   |   4 +-
 webapps/docs/changelog.xml |   3 +
 3 files changed, 143 insertions(+), 14 deletions(-)

diff --git a/java/org/apache/tomcat/util/descriptor/web/WebRuleSet.java 
b/java/org/apache/tomcat/util/descriptor/web/WebRuleSet.java
index 237d1c1..6bb972f 100644
--- a/java/org/apache/tomcat/util/descriptor/web/WebRuleSet.java
+++ b/java/org/apache/tomcat/util/descriptor/web/WebRuleSet.java
@@ -799,6 +799,13 @@ final class SetAuthConstraintRule extends Rule {
 digester.getLogger()
.debug("Calling SecurityConstraint.setAuthConstraint(true)");
 }
+
+StringBuilder code = digester.getGeneratedCode();
+if (code != null) {
+code.append(System.lineSeparator());
+
code.append(digester.toVariableName(securityConstraint)).append(".setAuthConstraint(true);");
+code.append(System.lineSeparator());
+}
 }
 
 }
@@ -823,6 +830,13 @@ final class SetDistributableRule extends Rule {
 digester.getLogger().debug
(webXml.getClass().getName() + ".setDistributable(true)");
 }
+
+StringBuilder code = digester.getGeneratedCode();
+if (code != null) {
+code.append(System.lineSeparator());
+
code.append(digester.toVariableName(webXml)).append(".setDistributable(true);");
+code.append(System.lineSeparator());
+}
 }
 }
 
@@ -846,6 +860,13 @@ final class SetDenyUncoveredHttpMethodsRule extends Rule {
 digester.getLogger().debug(webXml.getClass().getName() +
 ".setDenyUncoveredHttpMethods(true)");
 }
+
+StringBuilder code = digester.getGeneratedCode();
+if (code != null) {
+code.append(System.lineSeparator());
+
code.append(digester.toVariableName(webXml)).append(".setDenyUncoveredHttpMethods(true);");
+code.append(System.lineSeparator());
+}
 }
 }
 
@@ -887,6 +908,13 @@ final class SetPublicIdRule extends Rule {
 digester.getLogger().debug("" + top.getClass().getName() + "."
+ method + "(" + paramValues[0] + ")");
 
+StringBuilder code = digester.getGeneratedCode();
+if (code != null) {
+code.append(System.lineSeparator());
+
code.append(digester.toVariableName(top)).append(".").append(method).append("(\"");
+code.append(digester.getPublicId()).append("\");");
+code.append(System.lineSeparator());
+}
 }
 
 }
@@ -910,6 +938,13 @@ final class ServletDefCreateRule extends Rule {
 digester.push(servletDef);
 if (digester.getLogger().isDebugEnabled())
 digester.getLogger().debug("new " + 
servletDef.getClass().getName());
+
+StringBuilder code = digester.getGeneratedCode();
+if (code != null) {
+code.append(System.lineSeparator());
+code.append(ServletDef.class.getName()).append(' 
').append(digester.toVariableName(servletDef)).append(" = new ");
+
code.append(ServletDef.class.getName()).append("();").append(System.lineSeparator());
+}
 }
 
 @Override
@@ -918,6 +953,11 @@ final class ServletDefCreateRule extends Rule {
 ServletDef servletDef = (ServletDef) digester.pop();
 if (digester.getLogger().isDebugEnabled())
 digester.getLogger().debug("pop " + 
servletDef.getClass().getName());
+
+StringBuilder code = digester.getGeneratedCode();
+if (code != null) {
+code.append(System.lineSeparator());
+}
 }
 
 }
@@ -1043,6 +1083,24 @@ final class CallMethodMultiRule extends CallMethodRule {
 }
 IntrospectionUtils.callMethodN(target, methodName, paramValues,
 paramTypes);
+
+StringBuilder code = digester.getGeneratedCode();
+if (code != null) {
+
code.append(digester.toVar

[tomcat] branch 9.0.x updated: Add missing code generation for remaining digester rules

[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 09b8bea  Add missing code generation for remaining digester rules
09b8bea is described below

commit 09b8beabed15572431863dd65bd08ed2dab86c7c
Author: remm 
AuthorDate: Mon Jul 20 11:30:44 2020 +0200

Add missing code generation for remaining digester rules

A quick test with the web.xml files from Tomcat looks rather decent. I
don't know yet if it will be used by at least the functionality is more
complete this way.
Another item that can be added is generating a static loader as at the
moment each individual generated class is dynamically loaded, even
though the full list is known.
---
 .../tomcat/util/descriptor/web/WebRuleSet.java | 150 +++--
 .../tomcat/util/digester/CallMethodRule.java   |   4 +-
 webapps/docs/changelog.xml |   3 +
 3 files changed, 143 insertions(+), 14 deletions(-)

diff --git a/java/org/apache/tomcat/util/descriptor/web/WebRuleSet.java 
b/java/org/apache/tomcat/util/descriptor/web/WebRuleSet.java
index 237d1c1..6bb972f 100644
--- a/java/org/apache/tomcat/util/descriptor/web/WebRuleSet.java
+++ b/java/org/apache/tomcat/util/descriptor/web/WebRuleSet.java
@@ -799,6 +799,13 @@ final class SetAuthConstraintRule extends Rule {
 digester.getLogger()
.debug("Calling SecurityConstraint.setAuthConstraint(true)");
 }
+
+StringBuilder code = digester.getGeneratedCode();
+if (code != null) {
+code.append(System.lineSeparator());
+
code.append(digester.toVariableName(securityConstraint)).append(".setAuthConstraint(true);");
+code.append(System.lineSeparator());
+}
 }
 
 }
@@ -823,6 +830,13 @@ final class SetDistributableRule extends Rule {
 digester.getLogger().debug
(webXml.getClass().getName() + ".setDistributable(true)");
 }
+
+StringBuilder code = digester.getGeneratedCode();
+if (code != null) {
+code.append(System.lineSeparator());
+
code.append(digester.toVariableName(webXml)).append(".setDistributable(true);");
+code.append(System.lineSeparator());
+}
 }
 }
 
@@ -846,6 +860,13 @@ final class SetDenyUncoveredHttpMethodsRule extends Rule {
 digester.getLogger().debug(webXml.getClass().getName() +
 ".setDenyUncoveredHttpMethods(true)");
 }
+
+StringBuilder code = digester.getGeneratedCode();
+if (code != null) {
+code.append(System.lineSeparator());
+
code.append(digester.toVariableName(webXml)).append(".setDenyUncoveredHttpMethods(true);");
+code.append(System.lineSeparator());
+}
 }
 }
 
@@ -887,6 +908,13 @@ final class SetPublicIdRule extends Rule {
 digester.getLogger().debug("" + top.getClass().getName() + "."
+ method + "(" + paramValues[0] + ")");
 
+StringBuilder code = digester.getGeneratedCode();
+if (code != null) {
+code.append(System.lineSeparator());
+
code.append(digester.toVariableName(top)).append(".").append(method).append("(\"");
+code.append(digester.getPublicId()).append("\");");
+code.append(System.lineSeparator());
+}
 }
 
 }
@@ -910,6 +938,13 @@ final class ServletDefCreateRule extends Rule {
 digester.push(servletDef);
 if (digester.getLogger().isDebugEnabled())
 digester.getLogger().debug("new " + 
servletDef.getClass().getName());
+
+StringBuilder code = digester.getGeneratedCode();
+if (code != null) {
+code.append(System.lineSeparator());
+code.append(ServletDef.class.getName()).append(' 
').append(digester.toVariableName(servletDef)).append(" = new ");
+
code.append(ServletDef.class.getName()).append("();").append(System.lineSeparator());
+}
 }
 
 @Override
@@ -918,6 +953,11 @@ final class ServletDefCreateRule extends Rule {
 ServletDef servletDef = (ServletDef) digester.pop();
 if (digester.getLogger().isDebugEnabled())
 digester.getLogger().debug("pop " + 
servletDef.getClass().getName());
+
+StringBuilder code = digester.getGeneratedCode();
+if (code != null) {
+code.append(System.lineSeparator());
+}
 }
 
 }
@@ -1043,6 +1083,24 @@ final class CallMethodMultiRule extends CallMethodRule {
 }
 IntrospectionUtils.callMethodN(target, methodName, paramValues,
 paramTypes);
+
+StringBuilder code = digester.getGeneratedCode();
+if (code != null) {
+
code.append(digester.toVaria

[Bug 64614] tomcat doesn't work with JSSE FIPS-compliant with NSS

[bugzilla]

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

--- Comment #3 from Mark Thomas  ---
Doesn't the patch defeat the point of using Tomcat's JSSEKeyManager thereby
breaking the use cases that required it in the first place?

-- 
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 64614] tomcat doesn't work with JSSE FIPS-compliant with NSS

[bugzilla]

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

--- Comment #4 from Remy Maucherat  ---
Yes, it would prevent using a key alias, which was the only reason for the
wrapper. So I get FIPS mode prevents creative key manager uses then ?

Idea: maybe don't use a wrapper if there's no key alias set ?

This is still pretty bad overall since some configurations becomes broken :(

-- 
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] stokito opened a new pull request #324: Change ETag format to Nginx like

[GitBox]

stokito opened a new pull request #324:
URL: https://github.com/apache/tomcat/pull/324


   Currently Tomcat 9 generates ETag like `W/"1047-157831529"` i.e. 
`Weak"Size-MTime in Milliseconds"`.
   This is incorrect ETag because it should be strong as for a static file i.e. 
octal compatibility.
   Also to make ETag working for load balancing between Tomcat and Nginx we 
need to change format to `"hex(MTime in seconds)-hex(Size)"` e.g. 
`"5e132e20-417"`.
   Nginx is not configurable but ether Tomcat is not. In the same time Nginx is 
more widely used while Tomcat returns incorrect ETag.
   This small PR fixes the problem.
   As a downside after update Tomcat will discard existing ETags but then 
they'll be updated on clients and everything will work fine.
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[Bug 64616] New: Change ETag format to Nginx like

[bugzilla]

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

Bug ID: 64616
   Summary: Change ETag format to Nginx like
   Product: Tomcat 10
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: stok...@gmail.com
  Target Milestone: --

Currently Tomcat 9 generates ETag like W/"1047-157831529" i.e.
Weak"Size-MTime in Milliseconds".
This is incorrect ETag because it should be strong as for a static file i.e.
octal compatibility.
Also to make ETag working for load balancing between Tomcat and Nginx we need
to change format to "hex(MTime in seconds)-hex(Size)" e.g. "5e132e20-417".
Nginx is not configurable but ether Tomcat is not. In the same time Nginx is
more widely used while Tomcat returns incorrect ETag.
See the W3C discussion for details
https://lists.w3.org/Archives/Public/ietf-http-wg/2020JulSep/0041.html

I created a PR with the fix https://github.com/apache/tomcat/pull/324

-- 
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 64616] Change ETag format to Nginx like

[bugzilla]

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

--- Comment #1 from Julian Reschke  ---
1) You are combining two different things in a single change request, this is
unwise.

2) It's not a "W3C" discussion; it's the IETF HTTP WG mailing list (which just
happens to use a W3C list for historic reasons).

3) What exactly is "incorrect" about the current format?

4) The proposed format appears fragile to me as it assumes that a file system
based resource will not change more than once per second.

-- 
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] michael-o commented on pull request #324: Change ETag format to Nginx like

[GitBox]

michael-o commented on pull request #324:
URL: https://github.com/apache/tomcat/pull/324#issuecomment-661045812


   I do not consider your points to be valid:
   * The format of the ETag is opaque, it is upto the caching instance to 
generate one
   * We cannot guarantee any strong ETags because WebResource is an interface 
which does not guarantee to properly return required information.



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

Re: JDK 15 is now in Rampdown Phase Two

[Martin Grigorov]

Hi Rory,

Apache Tomcat build and tests are fine with JDK 15 b32 and JDK 16 b06 on
x86_64 and aarch64 CPU architectures!

Regards,
Martin

On Fri, Jul 17, 2020 at 12:03 PM Rory O'Donnell 
wrote:

> Hi Mark,
>
> *Per the JDK 15 schedule, we are in Rampdown Phase Two* *[1]*
> Per the JDK Release Process [2] we now turn our focus to *P1 and P2 bugs*,
> which can be fixed with approval [3].
> Late enhancements are still possible, with approval [4], but the bar is
> now extraordinarily high.
>
> *Please advise if you have any open high priority issues. *
>
>- Schedule for JDK 15
>   - 2*020/07/16 Rampdown Phase Two*
>   - 2020/08/06 Initial Release Candidate
>   - 2020/08/20 Final Release Candidate
>   - 2020/09/15 General Availability
>
>
>- Features included in JDK 15:
>   - JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)
>   
>   - JEP 360: Sealed Classes (Preview)
>   
>   - JEP 371: Hidden Classes 
>   - JEP 372: Remove the Nashorn JavaScript Engine
>   
>   - JEP 373: Reimplement the Legacy DatagramSocket API
>   
>   - JEP 374: Disable and Deprecate Biased Locking
>   
>   - JEP 375: Pattern Matching for instanceof (Second Preview)
>   
>   - JEP 377: ZGC: A Scalable Low-Latency Garbage Collector
>   
>   - JEP 378: Text Blocks 
>   - JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector
>   
>   - JEP 381: Remove the Solaris and SPARC Ports
>   
>   - JEP 383: Foreign-Memory Access API (Second Incubator)
>   
>   - JEP 384: Records (Second Preview)
>   
>   - JEP 385: Deprecate RMI Activation for Removal
>   
>
> *JDK 15 **Early Access build 32 **is available** at : - jdk.java.net/15/
> *
>
> These early-access, open-source builds are provided under the GNU General
> Public License, version 2, with the Classpath Exception.
>
>- Release notes
>- http://jdk.java.net/15/release-notes
>- Recent fixes that might be of interest
>   -
>
>   Build 32
>   - 8231800: Better listing of arrays
>  - 8234836: Improve serialization handling
>   - Build 31
>   - JDK-8248505: Unexpected NoSuchAlgorithmException when using
>  secure random impl from BCFIPS provider
>   - Build 29
>  - JDK-8233014: Enable ShowCodeDetailsInExceptionMessages by
>  default
>
> *JDK 16 Early Access build 6 **is available** at : - jdk.java.net/16/
> *
> These early-access, open-source builds are provided under the GNU General
> Public License, version 2, with the Classpath Exception.
>
>- JEP Candidate
>   - JEP 388: Windows/AArch64 Port 
>- JEPs proposed to target
>   - JEP 347: Enable C++14 Language Features
>   
>- JEPs targeted to JDK 16, so far:
>   - JEP 369: Migrate to GitHub 
>   - JEP 357: Migrate from Mercurial to Git
>   
>
>
>- Recent fixes that might be of interest
>   -
>
>   Build 32
>   - 8231800: Better listing of arrays
>  - 8234836: Improve serialization handling
>   - Build 5
>   - JDK-8218021: Have jarsigner preserve posix permission attributes
>  - JDK-8245302: Upgrade LogRecord to support long thread ids and
>  remove its usage of ThreadLocal
>  - JDK-8248505: Unexpected NoSuchAlgorithmException when using
>  secure random impl from BCFIPS provider
>
> *Cryptoroadmap updated *
>
>- https://www.java.com/en/jre-jdk-cryptoroadmap.html
>
>
>
> *The "Best of the JDK" feature face-off tournament: Result!*
>
>- *JDK Mission Control *is the winner based on the Twitter poll
>.
>
> *The Quality Outreach Report for *June 2020 is available via the Quality
> Wiki page*: *
> *June 2020
> 
> *
>
> Rgds,Rory
>
> [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-July/004536.html
> [2] https://openjdk.java.net/jeps/3
> [3] https://openjdk.java.net/jeps/3#Fix-Request-Process
> [4] https://openjdk.java.net/jeps/3#Late-Enhancement-Request-Process
>
> --
> Rgds, Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA, Dublin, Ireland
>
>

Re: JDK 15 is now in Rampdown Phase Two

[Rory O'Donnell]

Many thanks for that Martin!

Rgds,Rory

On 20/07/2020 14:40, Martin Grigorov wrote:

Hi Rory,

Apache Tomcat build and tests are fine with JDK 15 b32 and JDK 16 b06 
on x86_64 and aarch64 CPU architectures!


Regards,
Martin

On Fri, Jul 17, 2020 at 12:03 PM Rory O'Donnell 
mailto:rory.odonn...@oracle.com>> wrote:


Hi Mark, **

*Per the JDK 15 schedule, we are in Rampdown Phase Two* *[1]*

Per the JDK Release Process [2] we now turn our focus to *P1 and
P2 bugs*, which can be fixed with approval [3].
Late enhancements are still possible, with approval [4], but the
bar is now extraordinarily high.

**Please advise if you have any open high priority issues.* *

  * Schedule for JDK 15
  o 2*020/07/16 Rampdown Phase Two*
  o 2020/08/06 Initial Release Candidate
  o 2020/08/20 Final Release Candidate
  o 2020/09/15 General Availability

  * Features included in JDK 15:
  o JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)

  o JEP 360: Sealed Classes (Preview)

  o JEP 371: Hidden Classes 
  o JEP 372: Remove the Nashorn JavaScript Engine

  o JEP 373: Reimplement the Legacy DatagramSocket API

  o JEP 374: Disable and Deprecate Biased Locking

  o JEP 375: Pattern Matching for instanceof (Second Preview)

  o JEP 377: ZGC: A Scalable Low-Latency Garbage Collector

  o JEP 378: Text Blocks 
  o JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector

  o JEP 381: Remove the Solaris and SPARC Ports

  o JEP 383: Foreign-Memory Access API (Second Incubator)

  o JEP 384: Records (Second Preview)

  o JEP 385: Deprecate RMI Activation for Removal


*JDK 15 **Early Access build 32 **is available**at : -
jdk.java.net/15/ *

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

  * Release notes
  o http://jdk.java.net/15/release-notes
  * Recent fixes that might be of interest
 o

Build 32

  + 8231800: Better listing of arrays
  + 8234836: Improve serialization handling
  o Build 31
  + JDK-8248505: Unexpected NoSuchAlgorithmException when
using secure random impl from BCFIPS provider
  o Build 29
  + JDK-8233014: Enable ShowCodeDetailsInExceptionMessages
by default

*JDK 16 Early Access build 6 is available**at : -
jdk.java.net/16/ *

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

  * JEP Candidate
  o JEP 388: Windows/AArch64 Port

  * JEPs proposed to target
  o JEP 347: Enable C++14 Language Features

  * JEPs targeted to JDK 16, so far:
  o JEP 369: Migrate to GitHub 
  o JEP 357: Migrate from Mercurial to Git


**

  * Recent fixes that might be of interest
 o

Build 32

  + 8231800: Better listing of arrays
  + 8234836: Improve serialization handling
  o Build 5
  + JDK-8218021: Have jarsigner preserve posix permission
attributes
  + JDK-8245302: Upgrade LogRecord to support long thread
ids and remove its usage of ThreadLocal
  + JDK-8248505: Unexpected NoSuchAlgorithmException when
using secure random impl from BCFIPS provider

*Cryptoroadmap updated *

  * https://www.java.com/en/jre-jdk-cryptoroadmap.html

*The "Best of the JDK" feature face-off tournament: Result!*_*
*_

  * *JDK Mission Control *is the winner based on the Twitter poll
.

*The Quality Outreach Report for *June 2020**is available via the
Quality Wiki page*: **June 2020


*


*__*
Rgds,Rory

[1]
https://mail.o

[Bug 64616] Change ETag format to Nginx like

[bugzilla]

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

--- Comment #2 from Sergey Ponomarev  ---
3) What exactly is "incorrect" about the current format?

Weak ETag means that server tells to client that the resource can't be octal
compatible. The client MAY decide not to send Range requests to download part
of the resource. For file resources like a video file this may lead to always
re-downloading when user makes seek in player.


4) it assumes that a file system based resource will not change more than once
per second.

It assumes that during a second file will not be:
* changed but mod time is remain the at same second
* changed but it's size is the same
* downloaded by a client and it requested the same resource again.

Possibility of such event is extremely small and probably client even if
performs so many consequent requests then it should mean:
* client is fine to receive a stale data (it will re-request the resource
anyway in next second)
* client have a bug

Client can just not send the If-None-Match header.


While the Weak ETag is kind of semantical bug the main purpose of the PR is to
make Tomcat, Nginx and other servers be able to accept ETags from each other.

-- 
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] stokito commented on pull request #324: Change ETag format to Nginx like

[GitBox]

stokito commented on pull request #324:
URL: https://github.com/apache/tomcat/pull/324#issuecomment-661083626


   > The format of the ETag is opaque, it is up to the caching instance to 
generate one
   
   Yes, you are right. In the same time too smart client may not send Ranges 
requests to download part of the file if it sees Weak ETag. This more 
semantical issue. But the main goal to to make ETag interoperable between 
different servers. 
   
   > We cannot guarantee any strong ETags because WebResource is an interface 
which does not guarantee to properly return required information.
   
   But we can't guarantee even a Weak ETag ether. Anyway this is a default 
implementation and subclasses are free to override the method and return 
anything they need. I checked Catalina sources and there is two WebResource 
implementors: File and Jar.
   Both of them will be fine.



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] stokito opened a new pull request #325: Simplify ETag check

[GitBox]

stokito opened a new pull request #325:
URL: https://github.com/apache/tomcat/pull/325


   The If-None-Match header many have multiple ETags 
https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.26
   Even if Tomcat returns a single ETag clients may want to send few of them.
   Since ETags are always quoted the easiest way to check is just to check a 
substring.
   
   This will reduce amount of memory consumed by full ETag parsing.
   
   A command to check:
   
   curl -vv http://localhost:8080/tomcat.png -H 'If-None-Match: 
W/"5103-1595246577000", "etag2"'
   
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[Bug 64616] Change ETag format to Nginx like

[bugzilla]

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

--- Comment #3 from Julian Reschke  ---
3) So the ETag is not incorrect, it just might be suboptimal.

4) I would think your chances of this getting accepted would be bigger if you
left the default handling as is, and added a way to configure something else.

-- 
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] reschke commented on pull request #325: Simplify ETag check

[GitBox]

reschke commented on pull request #325:
URL: https://github.com/apache/tomcat/pull/325#issuecomment-661095956


   The suggested change will cause incorrect behaviour, for instance
   
   "foobar"
   
   would match
   
   W/"foobar"
   
   That said, the existing code is broken as well, as it will fail if an ETag 
contains a comma.



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] stokito commented on pull request #325: Simplify ETag check

[GitBox]

stokito commented on pull request #325:
URL: https://github.com/apache/tomcat/pull/325#issuecomment-66650


   Thank you, good points! I checked spec 
https://tools.ietf.org/html/rfc7232#section-2.3.2 and it looks like we still 
fine here because Tomcat in fact should do a weak comparison.
   
   |If-None-Match | Real resource's ETag | Match  |
   ||-|-|
   |`W/"1"`| `W/"1"`   | Yes   |
   |`"1"`| `W/"1"`   | No.  
  |
   |`W/"1"`| `"1"`   | Yes, as in spec |
   |`"1"`| `"1"`   | Yes
|
   |`W/"1", "1"` | `"1"`   | Yes
|
   |`W/"1", "2"` | `W/"2"`   | No |
   
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[tomcat] branch master updated: Enable graal reflection on all ParallelWebappClassLoader methods

[fhanik]

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

fhanik 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 06958d1  Enable graal reflection on all ParallelWebappClassLoader 
methods
06958d1 is described below

commit 06958d1edc23f3ced1d0db094c221be47b5bb67f
Author: Filip Hanik 
AuthorDate: Mon Jul 20 08:31:30 2020 -0700

Enable graal reflection on all ParallelWebappClassLoader methods
---
 res/graal/tomcat-embed-core/native-image/tomcat-reflection.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/res/graal/tomcat-embed-core/native-image/tomcat-reflection.json 
b/res/graal/tomcat-embed-core/native-image/tomcat-reflection.json
index e98a55b..ee96509 100644
--- a/res/graal/tomcat-embed-core/native-image/tomcat-reflection.json
+++ b/res/graal/tomcat-embed-core/native-image/tomcat-reflection.json
@@ -37,7 +37,7 @@
 { "name":"org.apache.catalina.Wrapper" },
 { "name":"org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl", 
"methods" : [{"name": "","parameterTypes":[]}] },
 { "name":"org.apache.catalina.core.StandardContext", "methods" : [{"name": 
"","parameterTypes":[]}] },
-{ "name":"org.apache.catalina.loader.ParallelWebappClassLoader", 
"allPublicMethods":true, 
"methods":[{"name":"","parameterTypes":["java.lang.ClassLoader"] }]},
+{ "name":"org.apache.catalina.loader.ParallelWebappClassLoader", 
"allDeclaredConstructors" : true, "allPublicConstructors" : true, 
"allDeclaredMethods" : true, "allPublicMethods" : true},
 { "name":"org.apache.catalina.servlets.DefaultServlet", 
"allDeclaredFields":true, "allDeclaredMethods":true },
 { "name":"org.apache.catalina.valves.ErrorReportValve", "methods" : [{"name": 
"","parameterTypes":[]}] },
 { "name":"org.apache.coyote.http11.Http11NioProtocol", "methods" : [{"name": 
"","parameterTypes":[]}] },


-
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: Enable graal reflection on all ParallelWebappClassLoader methods

[fhanik]

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

fhanik 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 0599a24  Enable graal reflection on all ParallelWebappClassLoader 
methods
0599a24 is described below

commit 0599a24c3f7effecdcaef42cf2caa6afccb73432
Author: Filip Hanik 
AuthorDate: Mon Jul 20 08:31:30 2020 -0700

Enable graal reflection on all ParallelWebappClassLoader methods
---
 res/graal/tomcat-embed-core/native-image/tomcat-reflection.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/res/graal/tomcat-embed-core/native-image/tomcat-reflection.json 
b/res/graal/tomcat-embed-core/native-image/tomcat-reflection.json
index 9d80526..f4d6560 100644
--- a/res/graal/tomcat-embed-core/native-image/tomcat-reflection.json
+++ b/res/graal/tomcat-embed-core/native-image/tomcat-reflection.json
@@ -37,7 +37,7 @@
 { "name":"org.apache.catalina.Wrapper" },
 { "name":"org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl", 
"methods" : [{"name": "","parameterTypes":[]}] },
 { "name":"org.apache.catalina.core.StandardContext", "methods" : [{"name": 
"","parameterTypes":[]}] },
-{ "name":"org.apache.catalina.loader.ParallelWebappClassLoader", 
"allPublicMethods":true, 
"methods":[{"name":"","parameterTypes":["java.lang.ClassLoader"] }]},
+{ "name":"org.apache.catalina.loader.ParallelWebappClassLoader", 
"allDeclaredConstructors" : true, "allPublicConstructors" : true, 
"allDeclaredMethods" : true, "allPublicMethods" : true},
 { "name":"org.apache.catalina.servlets.DefaultServlet", 
"allDeclaredFields":true, "allDeclaredMethods":true },
 { "name":"org.apache.catalina.valves.ErrorReportValve", "methods" : [{"name": 
"","parameterTypes":[]}] },
 { "name":"org.apache.coyote.http11.Http11NioProtocol", "methods" : [{"name": 
"","parameterTypes":[]}] },


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

Re: Native Image - Reflectionless Concept

[Filip Hanik]

Thanks for chiming in:

On 7/16/20 6:46 AM, Romain Manni-Bucau wrote:

Hi everyone,

I think the generation is the sanest option since code stay clean but 
it shouldn't be done in tomcat IMHO but in user code and with a nice 
wrapper (mvn tomcat:dump/gradle tomcatDump etc, or whatever name you 
like ;)).
That's always an option, but it would become an external artifact and 
easily end up out of sync.
This build phase would dump the descriptors in plain java and would 
load them with an unique - ie single for the whole webapp - plain SPI 
- ServiceLoader - maybe?
The goal of this artifact was to reduce the size and classes from a full 
tomcat (already available in tomcat-embed-core), down to a code base 
where XML/digester/descriptors aren't used, hence tomcat-embed-programmatic
This kind of build tool assumes you have all the runtime state in the 
build - which is typically the case for graalvm - so you can 
completely dump StandardContext state after start phase there and just 
reload it from the precomputed model.
Only trick is about file paths which must either be recomputed or be 
configurable to another base but it does not sound crazy.


The less tool-ed option would be to extract all "reflectionfull" code 
in methods and use graalvm substitutions to drop them and use plain 
java instead (with a good naming convention, it can be generated as well).
Keeps the duplication but at least the main code stays clean and 
optimizations stays together.


That's pretty much what we're doing right now. Many of these feel like 
hacks simply to mitigate how GraalVM/AOT does code initialization (all 
code loaded initialized at startup)


Filip




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




Le jeu. 16 juil. 2020 à 14:31, Rémy Maucherat > a écrit :


On Mon, Jul 13, 2020 at 11:59 PM Filip Hanik mailto:fha...@vmware.com>> wrote:

for discussion, all feedback and questions welcome:


I've created a concept of having Apache Tomcat, embedded, run
without reflection in a native image.
This concept creates a jar, tomcat-embedded-programmatic.jar,
that can be fine tuned to only include what is needed in a
default configuration when an embedded tomcat instance is used
and configured programatically.

Steps to run Apache Tomcat using Java 8 without reflection

 1. Make sure you have native-image (from the graal
installation) on your path
 2. git clone -b
feature/embed-minimal-programmatic-jar-file-master
g...@github.com:fhanik/tomcat.git
 3. cd tomcat/res/graal/
 4. ./build-tomcat-native-image.sh && ./graal-measure.sh

Should yield an output similar to (Graal 20.1):
SUCCESS: the servlet is working
RSS memory: 20.7M
Image size: 20.5M


or using an older graal, 19.2
SUCCESS: the servlet is working
RSS memory: 18.0M
Image size: 16.7M


This also leaves a file named
${java.io.tmpdir}/XReflectionIntrospectionUtils.java so that
you can review the solution to IntrospectionUtils.java

Goals of this concept

 1. Do not break anything
 2. Create a new and optimized for size artifact,
tomcat-embedded-programmatic
 3. Remove reflection by introspecting classes that are
currently passed into IntrospectionUtils.set/getProperty
by generating setters/getters at build time

How it's done

 1. I've build out a small introspection tool in the package
org.apache.tomcat.util.xreflect
 2. During build time, it analyses a set of known classes that
are used with IntrospectionUtils.java, and generates
XReflectionIntrospectionUtils.java
 3. When it packages tomcat-embed-programmatic.jar it uses the
generated code when calling setProperty and getProperty

A PR would look like this:

https://github.com/apache/tomcat/compare/master...fhanik:feature/embed-minimal-programmatic-jar-file-master?expand=1


Well, this is a bit complex and hard to maintain (like, for
example, storeconfig), so that's a downside.

So starting with Tomcat and its initial server.xml, the process
would be:
server.xml -> equivalent Tomcat embedded code -> equivalent Tomcat
embedded code with custom IntrospectionUtils code
The concrete benefits may be limited though.

I looked at more code generation for web.xml since the digester is
nice for that, but the benefit becomes even more questionable. It
is harder to manage, and the generated classes h

Re: Native Image - Reflectionless Concept

[Romain Manni-Bucau]

Le lun. 20 juil. 2020 à 17:41, Filip Hanik  a écrit :

> Thanks for chiming in:
> On 7/16/20 6:46 AM, Romain Manni-Bucau wrote:
>
> Hi everyone,
>
> I think the generation is the sanest option since code stay clean but it
> shouldn't be done in tomcat IMHO but in user code and with a nice wrapper
> (mvn tomcat:dump/gradle tomcatDump etc, or whatever name you like ;)).
>
> That's always an option, but it would become an external artifact and
> easily end up out of sync.
>

Was thinking to keep the dumper in tomcat code base and the plugin to
consume it so it would stay in sync, but agree it is a small risk.


> This build phase would dump the descriptors in plain java and would load
> them with an unique - ie single for the whole webapp - plain SPI -
> ServiceLoader - maybe?
>
> The goal of this artifact was to reduce the size and classes from a full
> tomcat (already available in tomcat-embed-core), down to a code base where
> XML/digester/descriptors aren't used, hence tomcat-embed-programmatic
>
> This kind of build tool assumes you have all the runtime state in the
> build - which is typically the case for graalvm - so you can completely
> dump StandardContext state after start phase there and just reload it from
> the precomputed model.
> Only trick is about file paths which must either be recomputed or be
> configurable to another base but it does not sound crazy.
>
> The less tool-ed option would be to extract all "reflectionfull" code in
> methods and use graalvm substitutions to drop them and use plain java
> instead (with a good naming convention, it can be generated as well).
> Keeps the duplication but at least the main code stays clean and
> optimizations stays together.
>
> That's pretty much what we're doing right now. Many of these feel like
> hacks simply to mitigate how GraalVM/AOT does code initialization (all code
> loaded initialized at startup)
>

Reviewing the hacks, all can be done cleanly if extracted in methods.
Pushing the logic next step - I don't know if worth it but trying to use
this picture to explain:

1. A noxml module can be done with protected methods/extension-points for
XML loading - even usable in java standalone mode
2. Current tomcat can extend noxml module
3. Graal can be based on 1

This would benefit both jvm and graal users at the end.
Today 1 is possible with some hacks on tomcat embedded but it is highly not
natural so this can be an opportunity to make it a feature maybe?


> Filip
>
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
>
> Le jeu. 16 juil. 2020 à 14:31, Rémy Maucherat  a écrit :
>
>> On Mon, Jul 13, 2020 at 11:59 PM Filip Hanik  wrote:
>>
>>> for discussion, all feedback and questions welcome:
>>>
>>>
>>> I've created a concept of having Apache Tomcat, embedded, run without
>>> reflection in a native image.
>>> This concept creates a jar, tomcat-embedded-programmatic.jar, that can
>>> be fine tuned to only include what is needed in a default configuration
>>> when an embedded tomcat instance is used and configured programatically.
>>>
>>> Steps to run Apache Tomcat using Java 8 without reflection
>>>
>>>1. Make sure you have native-image (from the graal installation) on
>>>your path
>>>2. git clone -b feature/embed-minimal-programmatic-jar-file-master
>>>g...@github.com:fhanik/tomcat.git
>>>3. cd tomcat/res/graal/
>>>4. ./build-tomcat-native-image.sh && ./graal-measure.sh
>>>
>>> Should yield an output similar to (Graal 20.1):
>>> SUCCESS: the servlet is working
>>> RSS memory: 20.7M
>>> Image size: 20.5M
>>>
>>>
>>> or using an older graal, 19.2
>>> SUCCESS: the servlet is working
>>> RSS memory: 18.0M
>>> Image size: 16.7M
>>>
>>>
>>> This also leaves a file named ${java.io.tmpdir}/
>>> XReflectionIntrospectionUtils.java so that you can review the solution
>>> to IntrospectionUtils.java
>>>
>>> Goals of this concept
>>>
>>>1. Do not break anything
>>>2. Create a new and optimized for size artifact,
>>>tomcat-embedded-programmatic
>>>3. Remove reflection by introspecting classes that are currently
>>>passed into IntrospectionUtils.set/getProperty by generating
>>>setters/getters at build time
>>>
>>> How it's done
>>>
>>>1. I've build out a small introspection tool in the package
>>>org.apache.tomcat.util.xreflect
>>>2. During build time, it analyses a set of known classes that are
>>>used with IntrospectionUtils.java, and generates
>>>XReflectionIntrospectionUtils.java
>>>3. When it packages tomcat-embed-programmatic.jar it uses the
>>>generated code when calling setProperty and getProperty
>>>
>>> A PR would look like this:
>>>
>>> https://github.com/apache/tomcat/comp

[GitHub] [tomcat] stokito edited a comment on pull request #325: Simplify ETag check

[GitBox]

stokito edited a comment on pull request #325:
URL: https://github.com/apache/tomcat/pull/325#issuecomment-66650


   Thank you, good points! I checked spec 
https://tools.ietf.org/html/rfc7232#section-2.3.2 and it looks like we still 
fine here because Tomcat in fact should do a weak comparison.
   
   |If-None-Match | Real resource's ETag | Match  |
   ||-|-|
   |`W/"1"`| `W/"1"`   | Yes   |
   |`"1"`| `W/"1"`   | No.  
  |
   |`W/"1"`| `"1"`   | Yes, as in spec |
   |`"1"`| `"1"`   | Yes
|
   |`W/"1", "1"` | `"1"`   | Yes
|
   |`W/"1", "2"` | `W/"2"`   | No |
   
   A Comma inside of ETag won’t be a problem.
   In fact this is simple, fast and straightforward algorithm.



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

Re: Native Image - Reflectionless Concept

[Filip Hanik]

On 7/20/20 8:47 AM, Romain Manni-Bucau wrote:



Le lun. 20 juil. 2020 à 17:41, Filip Hanik > a écrit :


Thanks for chiming in:

On 7/16/20 6:46 AM, Romain Manni-Bucau wrote:

Hi everyone,

I think the generation is the sanest option since code stay clean
but it shouldn't be done in tomcat IMHO but in user code and with
a nice wrapper (mvn tomcat:dump/gradle tomcatDump etc, or
whatever name you like ;)).

That's always an option, but it would become an external artifact
and easily end up out of sync.


Was thinking to keep the dumper in tomcat code base and the plugin to 
consume it so it would stay in sync, but agree it is a small risk.



This build phase would dump the descriptors in plain java and
would load them with an unique - ie single for the whole webapp -
plain SPI - ServiceLoader - maybe?

The goal of this artifact was to reduce the size and classes from
a full tomcat (already available in tomcat-embed-core), down to a
code base where XML/digester/descriptors aren't used, hence
tomcat-embed-programmatic

This kind of build tool assumes you have all the runtime state in
the build - which is typically the case for graalvm - so you can
completely dump StandardContext state after start phase there and
just reload it from the precomputed model.
Only trick is about file paths which must either be recomputed or
be configurable to another base but it does not sound crazy.

The less tool-ed option would be to extract all
"reflectionfull" code in methods and use graalvm substitutions to
drop them and use plain java instead (with a good naming
convention, it can be generated as well).
Keeps the duplication but at least the main code stays clean and
optimizations stays together.


That's pretty much what we're doing right now. Many of these feel
like hacks simply to mitigate how GraalVM/AOT does code
initialization (all code loaded initialized at startup)


Reviewing the hacks, all can be done cleanly if extracted in methods. 
Pushing the logic next step - I don't know if worth it but trying to 
use this picture to explain:


1. A noxml module can be done with protected methods/extension-points 
for XML loading - even usable in java standalone mode

2. Current tomcat can extend noxml module
3. Graal can be based on 1

This would benefit both jvm and graal users at the end.
Today 1 is possible with some hacks on tomcat embedded but it is 
highly not natural so this can be an opportunity to make it a feature 
maybe?


I believe that tomcat-embed-programmatic is a viable interim solution, 
it's a low risk. The question for you, and the rest of the community, is 
the reward itself enough? ie, is it worth it?


There is some talk about making "native-ness" part of the Java itself, 
and that could change a lot of assumptions. Making it a feature, 
refactoring code to satisfy 1, is a bit more intrusive at this point in 
time. I believe it introduces more risk than reward.



Filip



Filip




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




Le jeu. 16 juil. 2020 à 14:31, Rémy Maucherat mailto:r...@apache.org>> a écrit :

On Mon, Jul 13, 2020 at 11:59 PM Filip Hanik
mailto:fha...@vmware.com>> wrote:

for discussion, all feedback and questions welcome:


I've created a concept of having Apache Tomcat, embedded,
run without reflection in a native image.
This concept creates a jar,
tomcat-embedded-programmatic.jar, that can be fine tuned
to only include what is needed in a default configuration
when an embedded tomcat instance is used and configured
programatically.

Steps to run Apache Tomcat using Java 8 without reflection

 1. Make sure you have native-image (from the graal
installation) on your path
 2. git clone -b
feature/embed-minimal-programmatic-jar-file-master
g...@github.com:fhanik/tomcat.git

 3. cd tomcat/res/graal/
 4. ./build-tomcat-native-image.sh && ./graal-measure.sh

Should yield an output similar to (Graal 20.1):
SUCCESS: the servlet is working
RSS memory: 20.7M
Image size: 20.5M


or using an older graal, 19.2
SUCCESS: the servlet is working
RSS memory: 18.0M
Image size: 16.7M


This also leaves a file named
${java.io.tmpdir}/XReflectionI

Re: Native Image - Reflectionless Concept

[Romain Manni-Bucau]

I think a xml-less tomcat is awaited since servlet 3 - graal or not - but
agree risk is a bit higher.
That said path is different so wonder if skipping a temp solution can not
be worth after all for the community.

Le lun. 20 juil. 2020 à 17:58, Filip Hanik  a écrit :

>
> On 7/20/20 8:47 AM, Romain Manni-Bucau wrote:
>
>
>
> Le lun. 20 juil. 2020 à 17:41, Filip Hanik  a écrit :
>
>> Thanks for chiming in:
>> On 7/16/20 6:46 AM, Romain Manni-Bucau wrote:
>>
>> Hi everyone,
>>
>> I think the generation is the sanest option since code stay clean but it
>> shouldn't be done in tomcat IMHO but in user code and with a nice wrapper
>> (mvn tomcat:dump/gradle tomcatDump etc, or whatever name you like ;)).
>>
>> That's always an option, but it would become an external artifact and
>> easily end up out of sync.
>>
>
> Was thinking to keep the dumper in tomcat code base and the plugin to
> consume it so it would stay in sync, but agree it is a small risk.
>
>
>> This build phase would dump the descriptors in plain java and would load
>> them with an unique - ie single for the whole webapp - plain SPI -
>> ServiceLoader - maybe?
>>
>> The goal of this artifact was to reduce the size and classes from a full
>> tomcat (already available in tomcat-embed-core), down to a code base where
>> XML/digester/descriptors aren't used, hence tomcat-embed-programmatic
>>
>> This kind of build tool assumes you have all the runtime state in the
>> build - which is typically the case for graalvm - so you can completely
>> dump StandardContext state after start phase there and just reload it from
>> the precomputed model.
>> Only trick is about file paths which must either be recomputed or be
>> configurable to another base but it does not sound crazy.
>>
>> The less tool-ed option would be to extract all "reflectionfull" code in
>> methods and use graalvm substitutions to drop them and use plain java
>> instead (with a good naming convention, it can be generated as well).
>> Keeps the duplication but at least the main code stays clean and
>> optimizations stays together.
>>
>> That's pretty much what we're doing right now. Many of these feel like
>> hacks simply to mitigate how GraalVM/AOT does code initialization (all code
>> loaded initialized at startup)
>>
>
> Reviewing the hacks, all can be done cleanly if extracted in methods.
> Pushing the logic next step - I don't know if worth it but trying to use
> this picture to explain:
>
> 1. A noxml module can be done with protected methods/extension-points for
> XML loading - even usable in java standalone mode
> 2. Current tomcat can extend noxml module
> 3. Graal can be based on 1
>
> This would benefit both jvm and graal users at the end.
> Today 1 is possible with some hacks on tomcat embedded but it is highly
> not natural so this can be an opportunity to make it a feature maybe?
>
> I believe that tomcat-embed-programmatic is a viable interim solution,
> it's a low risk. The question for you, and the rest of the community, is
> the reward itself enough? ie, is it worth it?
>
> There is some talk about making "native-ness" part of the Java itself, and
> that could change a lot of assumptions. Making it a feature, refactoring
> code to satisfy 1, is a bit more intrusive at this point in time. I believe
> it introduces more risk than reward.
>
>
> Filip
>
>
>
>
>> Filip
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github
>>  | LinkedIn
>>  | Book
>> 
>>
>>
>> Le jeu. 16 juil. 2020 à 14:31, Rémy Maucherat  a écrit :
>>
>>> On Mon, Jul 13, 2020 at 11:59 PM Filip Hanik  wrote:
>>>
 for discussion, all feedback and questions welcome:


 I've created a concept of having Apache Tomcat, embedded, run without
 reflection in a native image.
 This concept creates a jar, tomcat-embedded-programmatic.jar, that can
 be fine tuned to only include what is needed in a default configuration
 when an embedded tomcat instance is used and configured programatically.

 Steps to run Apache Tomcat using Java 8 without reflection

1. Make sure you have native-image (from the graal installation) on
your path
2. git clone -b feature/embed-minimal-programmatic-jar-file-master
g...@github.com:fhanik/tomcat.git
3. cd tomcat/res/graal/
4. ./build-tomcat-native-image.sh && ./graal-measure.sh

 Should yield an output similar to (Graal 20.1):
 SUCCESS: the servlet is working
 RSS memory: 20.7M
 Image size: 20.5M


 or using an older graal, 19.2
 SUCCESS: the servlet is working
 RSS memory: 18.0M
 Image size: 16.7M


 This also leaves a file named ${java.io.tmpdir}/
 XReflectionIntrospec

[GitHub] [tomcat] reschke commented on pull request #325: Simplify ETag check

[GitBox]

reschke commented on pull request #325:
URL: https://github.com/apache/tomcat/pull/325#issuecomment-661164935


   You are citing the spec very selectively (hint: there are strong and weak 
comparion functions).



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