New JDK 19 EA builds and JCE Survey!
Greetings! The proposed schedule for JDK 19 is now known [1] with ‘Rampdown Phase One’ set for June 9th and ‘General Availability’ set for September 20th. The next several weeks will be interesting to watch as the scope of JDK 19 is revealed. You also play an important roll during these phases, which is your opportunity to share feedback . When developers such as yourself tell us of issues faced in the latest OpenJDK early-access (EA) builds, we then have a chance to fix them before that feature release reaches general availability (GA). We also enjoy when people tell us that all their tests are green! It gives us confidence ;-) So regardless of the tests color (red or green), please do not hesitate to send me a short mail as both types of feedback are useful. [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-April/006481.html ## Heads-Up: Java Cryptographic Extension Survey The Java Cryptographic Extension (JCE) has been in Java SE for a long time and has made incremental changes over the years. The OpenJDK Security Team is conducting a survey [2] to know more about how projects are using JCE and what changes, features, and API enhancements would be useful going forward. The survey is clossing on April 29 so if you have written or maintain code that uses the JCE API, please make sure to fill this short survey [2] as soon as possible. [2] https://www.questionpro.com/t/AUzP7ZrFWv ## Heads-Up: New macOS Rendering Pipeline on macOS JEP 382 [3] introduced in JDK 17 support for the new macOS Metal graphics pipeline for Swing and Java2D. JDK 19 starting build 18 is switching the default to be the new macOS Metal rendering pipeline instead of the old Apple OpenGL API. For more details please see JDK-8284378 [4]. Java applications running on macOS (10.14 or later) will not need to take any action, as they will automatically benefit from faster graphics with lower power consumption, and the use of a more modern stable graphics API which will be able to work better on current and future Apple systems. [3] https://openjdk.java.net/jeps/382 [4] https://bugs.openjdk.java.net/browse/JDK-8284378 ## JDK 19 Early-Access builds JDK 19 Early-Access builds 18 are now available [5], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [6]. [5] https://jdk.java.net/19/ [6] https://jdk.java.net/19/release-notes ### JEPs targeted to JDK 19, so far: - JEP 422: Linux/RISC-V Port https://openjdk.java.net/jeps/422 ### Recent changes that maybe of interest: Build 18: - JDK-8284378: Make Metal the default Java 2D rendering pipeline for macOS - JDK-8265315: Update CLDR to version 41 - JDK-8270090: C2: LCM may prioritize CheckCastPP nodes over projections [Reported by JaCoCo] - JDK-8284361: Updating ASM to 9.3 for JDK 19 - JDK-8284330: jcmd may not be able to find processes in the container - JDK-8284579: Improve VarHandle checks for interpreter Build 17: - JDK-8282819: Deprecate Locale class constructors - JDK-8254935: Deprecate the PSSParameterSpec(int) constructor - JDK-8283060: RawNativeLibraries should allow multiple clients to load/unload the same library Build 16: - JDK-8281561: Disable http DIGEST mechanism with MD5 and SHA-1 by default - JDK-8264160: Regex \b is not consistent with \w without UNICODE_CHARACTER_CLASS - JDK-8163327: Remove 3DES from the default enabled cipher suites list - JDK-8267319: Use larger default key sizes and algorithms based on CNSA - JDK-8283350: (tz) Update Timezone Data to 2022a ## Project Loom Updates The first Loom related JEP is now in Candidate phase, i.e. JEP: 425: Virtual Threads (Preview) [7]. As of now, JEP 425 doesn't yet 'propose to target' any particular feature release. [7] https://openjdk.java.net/jeps/425 In addition, Project Loom early-access builds 19-loom+5-429 (2022/4/4) are now available [8] with related Javadoc [9]. These builds are based on JDK 19 and are provided under the GNU General Public License, version 2, with the Classpath Exception and are produced for the purpose of gathering feedback. Use for any other purpose is at your own risk. Proper feedback should be sent to the `loom-dev` mailing list [10]. [8] https://jdk.java.net/loom/ [9] https://download.java.net/java/early_access/loom/docs/api/ [10] https://mail.openjdk.java.net/mailman/listinfo/loom-dev ## Topics of Interest: * New candidate JEP: 426: Vector API (4th Incubator) https://openjdk.java.net/jeps/426 * Virtual Thread Deep Dive - Inside Java Newscast #23 https://inside.java/2022/04/07/insidejava-newscast-023/ * Project Panama: Say Goodbye to JNI https://inside.java/2022/04/04/projectpanama/ * Java Cryptographic Extension Survey https://inside.java/2022/04/12/jce-survey/ As usual, let us know if you find any issues while testing your project(s) on the latest JDK early-access builds. Thanks for your support! --David
[Bug 66018] tomcat8.exe and tomcat9.exe when creating a service via command line requires --LogPath
https://bz.apache.org/bugzilla/show_bug.cgi?id=66018 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX OS||All --- Comment #1 from Mark Thomas --- This has always been an expectation but it hasn't always been enforced. The change of default service user in Daemon 1.2.0 from LocalSystem to LocalService means that the default log path is no longer valid. A change in 1.3.0 means that this now triggers an error during service configuration but the error message gets lost. The expectation is that Daemon 1.3.1 will address this by writing an error message to stdout and performing appropriate clean-up. The workaround is to ensure that the configured (or default) user has read/write access to the configured (or default) log path - which is what has always been expected. Note the location of the Daemon logs is configured separately from the location of Tomcat log files - even if they use the same directory. Resolving as WONTFIX as this will get addressed in Commons Daemon. -- 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 66018] New: tomcat8.exe and tomcat9.exe when creating a service via command line requires --LogPath
https://bz.apache.org/bugzilla/show_bug.cgi?id=66018
Bug ID: 66018
Summary: tomcat8.exe and tomcat9.exe when creating a service
via command line requires --LogPath
Product: Tomcat 9
Version: unspecified
Hardware: PC
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: safwat.ism...@jpmorgan.com
Target Milestone: -
Created attachment 38252
--> https://bz.apache.org/bugzilla/attachment.cgi?id=38252=edit
side-by-side comparison between services created with and without --LogPath
Prior to vresions 8.5.78 & 9.0.62 we ran an installation script to create
catalinabase services without passing --LogPath parameter. In the above
mentioned versions if omitted --LogPath from the command string, the service
does not pick up any Java settings.
#region Create Tomcat Service
# Copying tomcat8/w.exe to reflect service name"
$tcexe="$ServiceName.exe"
$tcwexe="$ServiceName"+"W.exe"
Copy-Item $tchome\bin\tomcat8.exe -Destination $tchome\bin\$tcexe -Force
Copy-Item $tchome\bin\tomcat8w.exe -Destination $tchome\bin\$tcwexe -Force
#Store command for creating a Tomcat service
Previous code:
$servicecommandstring = "$tchome\bin\$tcexe //IS//$ServiceName --Install
`"$tchome\bin\$tcexe`" --Description `"catalinabase$CatbaseNumber`" --Startup
auto --JavaHome `"$javahome`" --Jvm `"$javaruntimelib`" --JvmMs 512 --JvmMx
1024 --JvmOptions
`"-Xrs;-Dcatalina.home=$tchome;-Dcatalina.base=$catbase;-Djava.io.tmpdir=$catbase\temp;-Djava.security.manager;-Djava.security.policy=$catbase\conf\catalina.policy;-Duser.timezone=UTC;-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager;-Djava.util.logging.config.file=$catbase\conf\logging.properties`"
--StartMode jvm --StopMode jvm --StartClass
`"org.apache.catalina.startup.Bootstrap`" --StopClass
`"org.apache.catalina.startup.Bootstrap`" --StartParams start --StopParams stop
--Classpath `"$tchome\bin\bootstrap.jar;$tchome\bin\tomcat-juli.jar`""
New Code: LogPath had to specified
$servicecommandstring = -Join ("$tchome\bin\$tcexe //IS//$ServiceName",
" --Install `"$tchome\bin\$tcexe`"",
" --Description `"catalinabase$CatbaseNumber`"",
" --Startup auto",
" --LogPath `"$catbase\logs`"",
" --JavaHome `"$javahome`"",
" --Jvm `"$javaruntimelib`"",
" --JvmMs 512",
" --JvmMx 1024",
" --JvmOptions
`"-Xrs;-Dcatalina.home=$tchome;-Dcatalina.base=$catbase;-Djava.io.tmpdir=$catbase\temp;-Duser.timezone=UTC;-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager;-Djava.util.logging.config.file=$catbase\conf\logging.properties`"",
" --StartMode jvm",
" --StopMode jvm",
" --StartClass `"org.apache.catalina.startup.Bootstrap`"",
" --StopClass `"org.apache.catalina.startup.Bootstrap`"",
" --StartParams start",
" --StopParams stop",
" --Classpath `"$tchome\bin\bootstrap.jar;$tchome\bin\tomcat-juli.jar`""
)
#Convert the string to a scriptblock object
[scriptblock]$servicecommand = [scriptblock]::Create($servicecommandstring)
#Run the command.
Invoke-Command -ScriptBlock $servicecommand
Please let us know if this is indeed a requirement going forward as this
information normally get passed in the --JvmOption section pointing to location
of the conf\logging.properties file
--
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 66005] Apache crashes, if there is a tomcat server, which can not be resolved
https://bz.apache.org/bugzilla/show_bug.cgi?id=66005 --- Comment #15 from Lothar --- Is it possible to enable a similar logging in apr? How to implement? -- 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
