Re: commons-daemon packaging question

2019-04-05 Thread Konstantin Kolinko
пт, 5 апр. 2019 г. в 22:48, Coty Sutherland :
>
> Hi,
>
> I'm looking into commons-daemon in Tomcat and it appears that the Windows
> executables (prunsrv and prunmgr) don't require the commons-daemon.jar to
> run Tomcat like the *nix binary (jsvc) does. Can someone confirm that (I
> tested it and it seems to work fine without the jar)? If it's unused I can
> remove it to clean up the packaging a bit.

1) I always remove it when I install Tomcat on Windows as a service,
at the same time as I remove *.sh, *.xml, *.tar.gz files.

For the last N years, N > 5.

2) It is referenced by Class-Path attribute of
bootstrap.jar/META-INF/MANIFEST.MF

(If it is missing, people may ask. If something else is placed under
that name, it will be in Tomcat classpath.)

Best regards,
Konstantin Kolinko

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



commons-daemon packaging question

2019-04-05 Thread Coty Sutherland
Hi,

I'm looking into commons-daemon in Tomcat and it appears that the Windows
executables (prunsrv and prunmgr) don't require the commons-daemon.jar to
run Tomcat like the *nix binary (jsvc) does. Can someone confirm that (I
tested it and it seems to work fine without the jar)? If it's unused I can
remove it to clean up the packaging a bit.



Thanks,
Coty


[Bug 63320] StatementCache interceptor does not cache statements that return values in dedicated columns

2019-04-05 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63320

Ronny Schuetz  changed:

   What|Removed |Added

   Severity|normal  |major

-- 
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 63320] New: StatementCache interceptor does not cache statements that return values in dedicated columns

2019-04-05 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63320

Bug ID: 63320
   Summary: StatementCache interceptor does not cache statements
that return values in dedicated columns
   Product: Tomcat Modules
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: jdbc-pool
  Assignee: dev@tomcat.apache.org
  Reporter: ronny.schu...@tomtom.com
  Target Milestone: ---

The StatementCache interceptor does not cache calls to 

 Connection#prepareStatement(String, String[])

and most likely 

 Connection#prepareStatement(String, int[])

The reason is CacheKey#equals and #hashCode, that use Array#equals resp.
#hashCode when processing the args array, which does not work correctly as the
args array contains a nested array in this case. Switching to Arrays#deepEquals
resp. #deepHashCode fixes the issue.

We need to use the StatementCache together with Spring, as Springs JdbcTemplate
creates a new statement for each call and Oracle looks up the type of the
return values for each created statement, which got dramatically slower with
Oracle 18.

-- 
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 63318] New: Invalid character found in the request target 400 error ignores ErrorReportValve

2019-04-05 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63318

Bug ID: 63318
   Summary: Invalid character found in the request target 400
error ignores ErrorReportValve
   Product: Tomcat 9
   Version: 9.0.17
  Hardware: PC
Status: NEW
  Severity: normal
  Priority: P2
 Component: Connectors
  Assignee: dev@tomcat.apache.org
  Reporter: l...@mercur.se
  Target Milestone: -

Trying to load a page with an invalid character as query cause a 400 error (as
expected) but this error is not passed to the ErrorReportValve. This results in
a standard error page being displayed. 

Example surf to http://localhost/?]

Output is then:
HTTP Status 400 – Bad Request
Type Exception Report

Message Invalid character found in the request target. The valid characters are
defined in RFC 7230 and RFC 3986

Description The server cannot or will not process the request due to something
that is perceived to be a client error (e.g., malformed request syntax, invalid
request message framing, or deceptive request routing).

Exception

java.lang.IllegalArgumentException: Invalid character found in the request
target. The valid characters are defined in RFC 7230 and RFC 3986
   
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:467)
   
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:294)
   
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
   
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:834)
   
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1417)
   
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
   
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
   
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
   
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
java.base/java.lang.Thread.run(Thread.java:834)
Note The full stack trace of the root cause is available in the server logs.

Apache Tomcat/9.0.17

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



Re: JDK 13 - Early Access build 14 is available

2019-04-05 Thread Rory O'Donnell

Thanks for that Mark!

On 05/04/2019 12:02, Mark Thomas wrote:

On 29/03/2019 11:22, Rory O'Donnell wrote:

Hi Mark,

*OpenJDK builds *- JDK 13 - Early Access build 14 is available at
http://jdk.java.net/13/

Thanks for the heads up.

I built Tomcat with EA15 (a new release was available by the time this
reached the top of my TODO list) and ran the unit tests.

We saw one failure but this was expected / desired as it was in one of
our optimisation tests that looks for changes in the JRE to ensure that
the optimisation remains correct. It detected some additional character
sets since we last ran it against JDK 13.

I've added the new character sets to the optimisation and the tests now
all pass.

Thanks,

Mark



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



  * Release notes [1]
  * JDK 13 Schedule proposal accepted [2]
  o 2019/06/13 Rampdown Phase One
  o 2019/07/18 Rampdown Phase Two
  o 2019/08/08 Initial Release Candidate
  o 2019/08/22 Final Release Candidate
  o 2019/09/17 General Availability

*jpackage EA *

  * This is an early access build of JEP 343: Packaging Tool
    , aimed at testing a prototype
    implementation of jpackage, which is a new tool for packaging
    self-contained Java applications along with a Java Runtime Environment.
  * Build 30 is now available http://jdk.java.net/jpackage/
  * Please send feedback via e-mail to core-libs-...@openjdk.java.net
    

*Quality Outreach report for **March 2019*

  * The report for March 2019 is available here
   



  * Thanks to all those contributed !

*Recent Blog:* A new (Japanese) era for Java!


Rgds,Rory

[1] http://jdk.java.net/13/release-notes
[2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002736.html



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


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


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



[Bug 63205] Unable to load certificate store on openjdk

2019-04-05 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63205

--- Comment #4 from Mark Thomas  ---
Note: The Java fix is in JDK13 EA15 which means Tomcat will need a minimum Java
version of 13 before this workaround can be removed.

-- 
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 7.0.x updated (8b74c5f -> a3794d8)

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

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


from 8b74c5f  Generics: PooledConnectionImpl
 new bd0afd9  Add note regarding when this workaround can be removed
 new a3794d8  Add additional known charsets for lazy loading from JDK 13 
EA15

The 11945 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/tomcat/util/buf/CharsetCache.java  | 8 ++--
 java/org/apache/tomcat/util/security/KeyStoreUtil.java | 5 -
 2 files changed, 10 insertions(+), 3 deletions(-)


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



[tomcat] branch 8.5.x updated (5bb9cae -> d88b718)

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

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


from 5bb9cae  https://bz.apache.org/bugzilla/show_bug.cgi?id=63286 access 
log formats
 new 2234172  Add note regarding when this workaround can be removed
 new d88b718  Add additional known charsets for lazy loading from JDK 13 
EA15

The 19128 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/tomcat/util/buf/CharsetCache.java  | 8 ++--
 java/org/apache/tomcat/util/security/KeyStoreUtil.java | 5 -
 2 files changed, 10 insertions(+), 3 deletions(-)


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



[tomcat] branch master updated (de1f55e -> 9fc4a43)

2019-04-05 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 de1f55e  Fix maven URLs in example
 new ed1e77c  Add note regarding when this workaround can be removed
 new 9fc4a43  Add additional known charsets for lazy loading from JDK 13 
EA15

The 20695 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/tomcat/util/buf/CharsetCache.java  | 8 ++--
 java/org/apache/tomcat/util/security/KeyStoreUtil.java | 5 -
 2 files changed, 10 insertions(+), 3 deletions(-)


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



Re: JDK 13 - Early Access build 14 is available

2019-04-05 Thread Mark Thomas
On 29/03/2019 11:22, Rory O'Donnell wrote:
> Hi Mark,
> 
> *OpenJDK builds *- JDK 13 - Early Access build 14 is available at
> http://jdk.java.net/13/

Thanks for the heads up.

I built Tomcat with EA15 (a new release was available by the time this
reached the top of my TODO list) and ran the unit tests.

We saw one failure but this was expected / desired as it was in one of
our optimisation tests that looks for changes in the JRE to ensure that
the optimisation remains correct. It detected some additional character
sets since we last ran it against JDK 13.

I've added the new character sets to the optimisation and the tests now
all pass.

Thanks,

Mark


> 
>  * These early-access, open-source builds are provided under the GNU
>    General Public License, version 2, with the Classpath Exception
>    .
>  * Changes in this build
>   
> 
> 
>  * Release notes [1]
>  * JDK 13 Schedule proposal accepted [2]
>  o 2019/06/13 Rampdown Phase One
>  o 2019/07/18 Rampdown Phase Two
>  o 2019/08/08 Initial Release Candidate
>  o 2019/08/22 Final Release Candidate
>  o 2019/09/17 General Availability
> 
> *jpackage EA *
> 
>  * This is an early access build of JEP 343: Packaging Tool
>    , aimed at testing a prototype
>    implementation of jpackage, which is a new tool for packaging
>    self-contained Java applications along with a Java Runtime Environment.
>  * Build 30 is now available http://jdk.java.net/jpackage/
>  * Please send feedback via e-mail to core-libs-...@openjdk.java.net
>    
> 
> *Quality Outreach report for **March 2019*
> 
>  * The report for March 2019 is available here
>   
> 
> 
>  * Thanks to all those contributed !
> 
> *Recent Blog:* A new (Japanese) era for Java!
> 
> 
> Rgds,Rory
> 
> [1] http://jdk.java.net/13/release-notes
> [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002736.html
> 


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



Re: JDK 12: First Release Candidate available

2019-04-05 Thread Mark Thomas
Hi Muneer,

I can confirm the fix.

Many thanks,

Mark


On 05/04/2019 05:56, abdul.kolarku...@oracle.com wrote:
> Hi Mark,
> 
> The bug JDK-8157404 has been fixed and fix is available in the JDK 13
> build 15 : http://jdk.java.net/13/
> 
> Thanks,
> 
> Muneer
> 
> 
> On 04/03/19 2:43 PM, Rory O'Donnell wrote:
>> Hi Mark,
>>
>> Can you update the bug , using your JBS account, with the latest
>> information you have etc.
>>
>> I'll check from this end.
>>
>> Rgds,Rory
>>
>> On 01/03/2019 21:28, Mark Thomas wrote:
>>> Rory,
>>>
>>> We have received a report [1] of users being affected by a known JRE bug
>>> [2]. I've done some local testing and I believe it affects all current
>>> Java versions. We can work-around it but it would be much better if this
>>> was fixed in the JRE. Is there any chance the priority of [2] could be
>>> bumped up?
>>>
>>> Thanks,
>>>
>>> Mark
>>>
>>>
>>> [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=63205
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8157404
>>
> 


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