Re: Rethinking the Servlet API packaging
On Sun, 12 Aug 2018, Emmanuel Bourg wrote: > (servlet-api), and spin-off a versionned packages only if required due Either way (versioned or not), wouldn’t libservlet-api-java be a less conflicting, more in line with the common practice at Debian, package name? (Consider Perl stuff.) Just my 2¢, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * **Besuchen Sie uns auf der dmexco 2018!** 12**. **& 13. September 2018, Koelnmesse / **Halle 7,** **Stand A-031** Digital Business, Marketing und Innovation [www.tarent.de/dmexco](http://www.tarent.de/dmexco) * **Visit us at dmexco 2018!** 12th & 13th September, 2018, Koelnmesse / **Hall 7,** **Booth A-031** Digital business, marketing and innovation [www.tarent.de/dmexco](http://www.tarent.de/dmexco) *
Re: tomcat9 preview
Hi Emmanuel, > with the tomcat8 package. In the latest update of tomcat8 (8.5.32-2) > I've added a systemd service file, and with tomcat9 I've tried > leveraging more systemd features. The current work in progress is as long as it will still work under sysvinit, fine. > * The system user running Tomcat is now fixed and no longer > configurable. I did this for several reasons: Good. > * The debconf integration has been removed. With the user/group Very good. > dialog. Moreover it's affected by a debconf bug that has bitten > many of us (see #658554). This will likely also fix #814446 by simply not writing to the configuration file any more. > * The catalina.out log file is no more. It duplicates the content N! This is *extremely* not good, because having one reliable name for the latest log without having to fudge around with calls to date(1) was *the* selling factor for easy integration of Tomcat on Debian with shell scripts, as opposed by Tomcat on CentOS, for example. I *urge* you to take this back. > version 5.5, and with the systemd integration the latest logs are > available in /var/log/syslog These are user logs, they do not belong into syslog. The separate catalina.out file was the correct way to do this, consider e.g. the various Apache logs. > and through 'journalctl -t tomcat9' anyway. Not with sysvinit… (and having an init system-specific way to access logs is not going to fly well, independent on what init system it is). > * The logs are now rotated directly by Tomcat instead of a cron job. > The cron job is still used to compress the logs though. Will this fix the problem with log files that haven’t been written to for an entire day? > * The sysv init script has been removed and the service is now > exclusively started with systemd. systemd brings so many Objection! Strong objection! I *will* file an RC bug if it won’t work without systemd! > * Tomcat is now automatically restarted if the JVM crashes > (another systemd feature). Double objection: this existed pre-systemd, for those who wanted it, but it is not desirable in many cases. Please make this optional even for systemd users, so an admin who wants this can enable it, but do not default to it and especially do not force it on admins. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * **Besuchen Sie uns auf der dmexco 2018!** 12**. **& 13. September 2018, Koelnmesse / **Halle 7,** **Stand A-031** Digital Business, Marketing und Innovation [www.tarent.de/dmexco](http://www.tarent.de/dmexco) * **Visit us at dmexco 2018!** 12th & 13th September, 2018, Koelnmesse / **Hall 7,** **Booth A-031** Digital business, marketing and innovation [www.tarent.de/dmexco](http://www.tarent.de/dmexco) *
tomcat9 preview
Hi all, I've started working on the tomcat9 packaging. Since this is a new package I've investigated disruptive changes that we couldn't afford with the tomcat8 package. In the latest update of tomcat8 (8.5.32-2) I've added a systemd service file, and with tomcat9 I've tried leveraging more systemd features. The current work in progress is available on Salsa [1], here is a quick summary of the changes: * The system user running Tomcat is now fixed and no longer configurable. I did this for several reasons: - Updating the owner of the webapp directories when upgrading from tomcat to tomcat is inconvenient. - The system user is rarely configurable is other packages. Apache, MySQL/MariaDB, Exim, Postgres, OpenLDAP... all have a non configurable user. - systemd dosen't seem to support environment variables in the User/Group directives on the service files. * The debconf integration has been removed. With the user/group becoming non configurable, there is only the JAVA_OPTS variable left configurable with debconf. JAVA_OPTS often contains parameters for fine tuning the JVM (memory settings, garbage collector, crash reporting and other advanced VM options), that's a quite complex item to configure for a simple debconf dialog. Moreover it's affected by a debconf bug that has bitten many of us (see #658554). * The Servlet API package has been removed (as discussed) * The catalina.out log file is no more. It duplicates the content of the catalina*.log files already generated by Tomcat since the version 5.5, and with the systemd integration the latest logs are available in /var/log/syslog and through 'journalctl -t tomcat9' anyway. * The logs are now rotated directly by Tomcat instead of a cron job. The cron job is still used to compress the logs though. * The sysv init script has been removed and the service is now exclusively started with systemd. systemd brings so many benefits in terms of simplicity and security that I think it's worth going with it exclusively. Our tomcat8 package has been affected by several vulnerabilities in its init script that could have been avoided with systemd. - In terms of simplicity, with systemd the authbind package is no longer necessary to bind to privileged ports, and the startup script is now ridiculously short and readable [2]. - Security wise, Tomcat is sandboxed and unable to write on the system besides its work directories. It also has a private tmp directory which prevents a whole class of vulnerabilities. I've tried to further isolate Tomcat from the system by using the chroot features (with the RootDirectory directive) but I haven't figured out how to use it properly. * Tomcat is now automatically restarted if the JVM crashes (another systemd feature). * The common, shared and server directories in CATALINA_BASE are no longer added to the classpath. This is in line with the upstream releases since the version 5.5. Please give it a try and post your feedback, I plan to upload tomcat9 next month when I'm back from vacation. Emmanuel Bourg [1] https://salsa.debian.org/ebourg/tomcat9 [2] https://salsa.debian.org/ebourg/tomcat9/blob/master/debian/libexec/tomcat-start.sh
Re: Rethinking the Servlet API packaging
Le 11/08/2018 à 09:19, Markus Koschany a écrit :
> That is a very good idea. I also think that it makes sense to decouple
> the Servlet API from src:tomcat{7,8,9}
>
> +1
>
> +1
Thank you for the feedback!
> As long as we don't have to change reverse-dependencies and everything
> is just a drop-in, I think it's good.
Yes that's the plan, i.e. the standalone libservlet3.1-java will depend
on the JSP/EL/WebSocket packages so we don't have to change the reverse
dependencies. But libservlet4.0-java won't depend on them anymore.
> I can start packaging
> libservlet4.0-java (I would name source and binary package the same). Is
> it this one?
>
> https://github.com/javaee/servlet-spec/releases/tag/4.0.1
Yes that's this one, thank you for jumping in but I've already prepared
the package. No package needs the Servlet API 4.0 yet, even Spring
Framework which is rather cutting edge still uses the version 3.1 in its
latest releases. So there is no hurry to upload it.
As for the source package name I'm not decided yet. Either keep the
historical libservletX-java scheme which was already used for the
versions 2.2 and 2.4, or use servlet-api-X which is more in line with
the recent Java EE packages uploaded (jaxb-api, cdi-api, jaxws-api,
jaxrs-api, etc).
Alternatively, we may even try to go with a versionless name
(servlet-api), and spin-off a versionned packages only if required due
to substantial incompatibilities introduced in the new releases.
For example, src:servlet-api would build libservlet-api-java/4.0-1, if
the Servlet API 4.1 is source compatible with the version 4.0, we just
upgrade the package. If later the version 4.2 breaks too many things we
create a package with the version 4.1 and we keep upgrading the
versionless package.
(Just some thoughts for discussion, I have no preference)
Emmanuel Bourg
Re: OpenJDK 11 -- testing needed
Le 11/08/2018 à 17:56, Markus Koschany a écrit : > Can't we just use that and move on and package OpenJFX 11? > This is the package I would volunteer to work on. Unfortunately we can't use the version of Gradle in experimental without modifying gradle-debian-helper first. Gradle breaks the APIs used by gradle-debian-helper, and the fix isn't trivial. I'm considering adding a hook in Gradle that gradle-debian-helper could use to rewrite the dependencies on the fly, that would decouple gradle-debian-helper from the internal Gradle APIs and avoid similar breakage in the future. I have no concrete implementation yet, so if you want to dive in, please go ahead. Emmanuel Bourg
Re: OpenJDK 11 -- testing needed
Am 11.08.2018 um 17:27 schrieb Emmanuel Bourg: [...] > My next target will be Gradle 4.x because it's blocking OpenJFX 11 and > other packages which have been fixed upstream to work with Java 9+ but > require a more recent version of Gradle. We have to adapt > gradle-debian-helper to work with the new version. I plan to do that in > September. OpenJFX 11 is one of the most important packaging tasks for me at the moment, because without it all packaging work for PDFsam, Mediathekview and Netbeans come to naught. Kai-Chung has packaged Gradle 4.4 in experimental. Can't we just use that and move on and package OpenJFX 11? This is the package I would volunteer to work on. >> Maybe we should >> evaluate on a case-by-case basis what upstream projects intend to do >> before we start packaging removed functionality in separate packages. If >> it is not clear yet we can still use OpenJDK 8 for building the package. >> We just have to make sure it works with OpenJDK 11 at runtime. > > Let's review what is left fixing after the switch to OpenJDK 11. I still > hope we'll be able to avoid including OpenJDK 8 in Buster. > > >> We shouldn't put ourselves under pressure when even upstream projects >> have not decided yet how they want to support OpenJDK 11. > > I agree, but sometimes the decision will never be made, because the > project is no longer or barely maintained. And we can't keep OpenJDK 8 > forever either. We are between the hammer and the anvil :( It would be awesome if everything worked with OpenJDK 11 but I fear that won't be possible in time. At the moment we are at the forefront and many, many projects simply are not ready yet or hesitate because Java 8 is still supported (e.g. Netbeans). We don't have to keep it forever but we can keep OpenJDK 8 without security support for Buster and retire it next year when more projects hopefully will have embraced OpenJDK 11. signature.asc Description: OpenPGP digital signature
Re: OpenJDK 11 -- testing needed
Le 11/08/2018 à 09:37, Markus Koschany a écrit : > I'm a bit lost what is needed to switch to OpenJDK 11. Mostly JAX-WS at this point. I'm almost done, all the dependencies are ready thanks to the FTP masters who have kindly validated the packages during DebConf. I just have a last tricky Maven build issue to tackle and it's ok (jaxws turns pom artifacts into jars during the build and it confuses the dependency resolution of maven-debian-helper). We'll also have to package the CORBA replacement but that's less critical. I don't plan to work on this if someone wants to step up. My next target will be Gradle 4.x because it's blocking OpenJFX 11 and other packages which have been fixed upstream to work with Java 9+ but require a more recent version of Gradle. We have to adapt gradle-debian-helper to work with the new version. I plan to do that in September. > Maybe we should > evaluate on a case-by-case basis what upstream projects intend to do > before we start packaging removed functionality in separate packages. If > it is not clear yet we can still use OpenJDK 8 for building the package. > We just have to make sure it works with OpenJDK 11 at runtime. Let's review what is left fixing after the switch to OpenJDK 11. I still hope we'll be able to avoid including OpenJDK 8 in Buster. > We shouldn't put ourselves under pressure when even upstream projects > have not decided yet how they want to support OpenJDK 11. I agree, but sometimes the decision will never be made, because the project is no longer or barely maintained. And we can't keep OpenJDK 8 forever either. We are between the hammer and the anvil :( Emmanuel Bourg
Re: Rethinking the Servlet API packaging
Hi!
Am 06.08.2018 um 12:47 schrieb Emmanuel Bourg:
> Hi all,
>
> I'm starting to plan the packaging of Tomcat 9 which should be the
> version of Tomcat shipped with Buster. Before doing that I'd like to
> rethink how the Servlet/JSP API are packaged in Debian.
[...]
That is a very good idea. I also think that it makes sense to decouple
the Servlet API from src:tomcat{7,8,9}
[...]
> So I'd like to take the opportunity of the Tomcat 9 packaging to suggest
> the following changes:
> * The src:tomcat(n>=9) packages no longer build libservlet-java.
+1
> * The Servlet, JSP, EL and WebSocket APIs are packaged separately,
> using the JavaEE (now Eclipse EE4J/JakartaEE) repositories on GitHub.
> These API packages are kept in the archive as long as necessary. Being
> pure API with no actual implementation, they aren't security sensitive
> and don't create a maintenance burden.
+1
> * When src:tomcat(n<9) is removed, introduce standalone API packages.
>
> In details, that would give:
>
> 1. Create a new src:servlet-4.0-api package building libservlet4.0-java
>with the Servlet API *only*, no JSP/EL/WebSocket API, not even as a
>dependency.
>
> 2. libservlet3.1-java gets split into 4 packages, one per API:
>libservlet3.1-java, libjsp2.3-java, libel3.0-java and
>libwebsocket1.1-java. libservlet3.1-java would depend on the three
>other packages to preserve the compatibility and avoid updating
>all the packages depending on the JSP/EL APIs.
>
> 3. libservlet3.0-java is similarly split into: libservlet3.0-java,
>libjsp2.2-java, libel2.2-java
>
> 4. Create new source packages to take over the API packages from
>src:tomcat7 and src:tomcat8:
>* servlet-3.0-api and servlet-3.1-api
> (built from https://github.com/javaee/servlet-spec)
>* jsp-2.2-api and jsp-2.3-api
> (built from https://github.com/javaee/javaee-jsp-api)
>* el-2.2-api and el-3.0-api
> (built from https://github.com/javaee/el-spec)
>* websocket-1.1-api
> (built from https://github.com/javaee/websocket-spec)
>
> 5. remove src:tomcat7, and later src:tomcat8 once src:tomcat9
>is available
>
> What do you think?
As long as we don't have to change reverse-dependencies and everything
is just a drop-in, I think it's good. I can start packaging
libservlet4.0-java (I would name source and binary package the same). Is
it this one?
https://github.com/javaee/servlet-spec/releases/tag/4.0.1
Regards,
Markus
signature.asc
Description: OpenPGP digital signature
