Salesforce: $Component-merge fields behaving unexpectedly

So I was writing a slightly complicated form validation in Javascript. Therefore I needed access to the values of all fields of an <apex:form>. But worse, some fields were shown conditionally.

So I assumed that the validation would merely need to check whether the fields existed, as a conditional rendering does not add the fields to the DOM (in contrast to hiding them with display: none). So my Visualforce page looked something like this:

<apex:page controller="ConditionalRerenderController">
    <apex:form>
        Click me
        <apex:inputCheckbox value="{!condition}" id="firstId">
            <apex:actionSupport event="onclick" rerender="conditionalBlock"/>
        </apex:inputCheckbox><br/>
        <apex:pageBlock id="conditionalBlock">
            <apex:pageBlockSection rendered="{!condition}" columns="1">
                <apex:inputText id="secondId" value="{!stringValue}" /><br/>
            </apex:pageBlockSection>
        </apex:pageBlock>
    </apex:form>
</apex:page>

The JS to get the value of the text input field would be rather simple

var inputfield = document.getElementById('secondId');
if(inputField != null)
    alert(inputfield.value);

However, the attribute id in Visualforce does not translate directly to the HTML attribute of the same name. To make sure a produced id is in fact unique, Salesforce adds information on the context, practically making it unusable to hard-code the id in javascript.

But there is the global merge field $Component which allows to resolve the produced HTML id. So I expected this to work:

var inputfield = document.getElementById('{!$Component.secondId}');
if(inputfield != null)
    alert(inputfield.value);

But inputfield would always be null, no matter whether the checkbox had been clicked before, rendering the input field.

This is quite a problem, as it turns out this merge field is not re-evaluated outside of the block that gets re-rendered. Instead, the expression always evaluates to an empty string outside of the conditionally rendered block. So you would need to put all Javascript that needs an id of an element within the conditionally rendered block.

Or – maybe more workable – you could use class names as pseudo-IDs. If you would add

styleClass="pseudoId"

to the input-field you can access it with

var elements = document.getElementsByClassName('pseudoId');
if(elements != null && elements.length > 0) {
    var inputField = elements[0];
    alert(inputField.value);
}

Have a try, and notice how the id of the text input only appears in the conditionally rendered block.
The page:

<apex:page controller="ConditionalRerenderController">
    <apex:form>
        Click me
        <apex:inputCheckbox value="{!condition}" id="firstId">
            <apex:actionSupport event="onclick" rerender="conditionalBlock"/>
        </apex:inputCheckbox><br/>
        firstId: <apex:outputText value="{!$Component.firstId}" /><br/>
        secondId: <apex:outputText value="{!$Component.secondId}" /><br/>

        <apex:pageBlock id="conditionalBlock">
            <apex:pageBlockSection rendered="{!condition}" columns="1">
                <apex:inputText id="secondId" value="{!stringValue}" /><br/>
                secondId: <apex:outputText value="{!$Component.secondId}" /><br/>
            </apex:pageBlockSection>
        </apex:pageBlock>
    </apex:form>
</apex:page>

The controller:

public class ConditionalRerenderController {
 public boolean condition {get;set;}
 public String stringValue {get;set;}
 
 public ConditionalRerenderController() {
 this.condition = false;
 this.stringValue = 'empty';
 }
}

Packungen mit frischen Chilis – Verdorbene Ware

In jedem Geschäft, in das ich gehe, halte ich Ausschau nach Chilis. Möglichst frische, möglichst welche, die ich noch nicht gegessen habe. Dabei fällt mir viel zu oft auf, dass  in kleinen Packungen verdorbene Ware angeboten wird.

Gerade vor einer Woche im Kaufhof. Ich war sehr glücklich, dass es dort einen Chili-Mix gab, der auch Scotch Bonnett enthielt (und leider auch Jalapeño als Beifang). Oberflächlich sah alles gut aus, die Früchte schienen fest zu sein. Beim Aufschneiden der Scotch Bonnett zeigte sich aber, dass die innen schon schimmelten. Bei ganz genauem Hinsehen hätte man das vielleicht am Stiel erahnen können.

Vor über einem Monat erzählte ich, dass ich Carolina Reaper gefunden habe. Auch bei denen war ein Viertel schon etwas angefault. Feststellbar von außen dadurch, dass die Früchte etwas weich schienen. Von innen, weil sie braun waren und ungesund rochen. Seit dieser Zeit liegen in der Metro die selben Packungen rum und werden nicht besser. Also inzwischen schon so, dass jeder, der sich ein wenig mit Essen auskennt, erkennen müsste, dass der Inhalt faul ist.

Im Handelshof hatte ich Bhut Jolokia gefunden, die Packung, die ich mitgenommen habe, war auch völlig in Ordnung. Aber auch da liegen die restlichen Packungen seit nun fast einem Monat rum – der Inhalt fault.

Das Gleiche gilt aber auch für Rewe und vermutlich jeden anderen Supermarkt, in dem Packungen mit Chilis verkauft werden. Zum einen liegt es daran, dass auf diesen Packungen keinerlei Datum drauf steht. Es wäre doch einfachst, den Zeitpunkt des Verpackens abzudrucken. Dann wüsste auch ein Kunde, der den Chilis ihren Zustand nicht ansehen kann, wie alt – oder auch wie frisch – das Essen ist.

Natürlich wird das auch bei anderen frischen Lebensmitteln nicht gemacht, allerdings unterstelle ich mal, dass sowohl das Personal als auch der Durchschnittskunde bei Äpfeln oder Bananen halbwegs erkennen kann, ob man das noch essen bzw. kaufen sollte. Bei Chilis, insbesondere den knubbeligen Vertretern wie Carolina Reaper und Bhut Jolokia sieht das offenbar anders aus. Auch ich kann bei eingepackter Ware nicht erkennen, ob die noch in Ordnung ist.

Meine neue KFZ-Werkstatt des geringsten Misstrauens

Für Autowerkstätten bin ich ein Albtraum. Ich glaube immer, dass ich durchaus verstehe, was da so gemacht wird. Ich glaube auch, dass nicht alle KFZ-Werkstätten immer korrekt abrechnen. Daher braucht es eigentlich auch viel Überzeugungsarbeit seitens der Beschäftigten, damit ich eine Werkstatt mehr als einmal betrete.

Es fängt schon bei dem Allgemeinen Kriterium an, dass ich sicher sein möchte, dass sich jemand der Grenzen seines Wissens bewusst ist. Das ist bei allen Fachkräften so. Niemand kann selbst in seinem Spezialgebiet alles wissen. Daher ist immer ein wichtiger Faktor, ob jemand bereit ist, die Grenzen seines Wissens zu offenbaren – das ist die wichtigste Vorstufe zum Eingestehen von eigenen Fehlern. und auch da: niemand ist unfehlbar. Aber jeder kann von seinen Fehlern lernen.

Wie dem auch sei, da habe ich endlich jemand gefunden, dem ich mein Auto anvertraue. Nicht nur, dass er bei allen Fragen die „richtigen“ Antworten gegeben hat, sondern vor allem: Fragen wurden nicht genervt als scheinbaren Angriff auf die Autorität angesehen. Außerdem wurden nur Reparaturvorschläge gemacht, die auch meiner Meinung nach Aussicht auf Erfolg hatten.

Er sagt, er braucht keine weitere Werbung, daher kann ich auch mit ihm keine Geschäfte zum Guten meiner Firma machen. Wer braucht schon eine Webseite, die den aktuellen technischen Ansprüchen genügt, wenn man genügend Kunden hat.

Dennoch möchte ich hier öffentlich mein Lob und meinen Dank an Holger Ludwig senden. Seine Werkstatt Fahrzeug & Motor – Technik & Design in Bergisch Gladbach ist derzeit meine Werkstatt des geringsten Misstrauens. Und das, obwohl ich 45 Kilometer bis dahin fahren muss.

Danke!

4 Minuten Werbung bei Youtube?

Da wollte ich mir doch nur Electro-Boom ansehen, und dann kommt da 4 Minuten Werbung wegen Potenzproblemen. Nicht-überspringbar. Was will mir Youtube damit sagen? Dass es ernsthaft Zeit für einen Adblocker wird? Bin ich so alt, dass ich so etwas brauche? Wahrscheinlich. Bislang kam ich ohne aus.

David-emmerich.com geht mir gerade tierisch auf die Nerven, und wenn ich diese Person jemals im echten Leben sehe, gibt’s was auf die Zwölf!

Aber da schon wieder: 1 Minute 18, Mercedes, nicht überspringbar. Das war es dann wohl!

Carolina Reaper – erste Eindrücke

Ich mag Chilis. Sie sind meistens richtig lecker, zumindest, wenn man sie reif isst. Ich weiß wirklich nicht, warum Leute unreife (=grüne) Jalapeños essen. Die schmecken einfach nicht. Nur scharf ist einfach nicht gut genug.

Die hier habe ich dann in der Metro gesehen und musste sie einfach kaufen. Schließlich finde ich die sonst nirgendwo, und wenn es denn doch der Weltrekordhalter in Schärfe war, musste ich sie probieren.

Ein Punkt dabei war für mich klar das Gewinnen von Samen. Entsprechend habe ich sie alle aufgeschnitten und die Samen entfernt. Natürlich mit Einmalhandschuhen, und natürlich habe ich sicher gestellt, dass ich mir mit den Handschuhen nirgendwo hin lange.

Die Effekte, die diese Chili haben kann, kann man bei Trainierten sehen, oder auch bei Untrainierten. Von daher war ich mir auch nicht sicher, ob ich sie wirklich essen wollte. Ich habe dann ein wenig davon auf Brot mit Wurst gegessen. Also wirklich homöopatische Dosen.

Diese Chili ist scharf. Sie riecht und schmeckt fruchtig und pfefferig. Wirklich sehr lecker. Aber wirklich geringe Dosen reichen, um eine nette Schärfe zu erreichen. Eine Ganze werde ich sicher nicht essen – der Schmerz führt zwar zu Glücksgefühlen, aber komplett diese Chili: ich glaube nicht.

Eigener Mapserver mit Openstreetmap, Mapnik und OpenLayers

Damit die Anfragen unserer Programme nicht immer die Openstreetmap-Server belasten, und ich damit mit besserem Gewissen auch ein paar Versuche durchführen konnte, habe ich mich mit Mapnik etwas auseinander gesetzt. Unter Switch2OSM gibt es schon Anleitungen, wie das umgesetzt werden kann, allerdings hatte ich die erst später gefunden. Und viele andere Informationen, die man so findet, sind falsch oder veraltet.

In dieser Anleitung finden Sie, wie Sie aus den Source-Dateien von mod_tile und vorkompilierten Paketen einen eigenen Tile-Renderer aufbauen können.

Zunächst die Vorbereitungen

Ubuntu 16.04 / 17.04

Alle benötigten Pakete sollten sich installieren lassen mit

$ sudo apt-get install libmapnik-dev mapnik-utils git subversion \
dh-autoreconf apache2-dev apache2 unzip postgis make cmake g++ \
libboost-dev libboost-system-dev libboost-filesystem-dev \
libexpat1-dev zlib1g-dev libbz2-dev libpq-dev libproj-dev \
lua5.2 liblua5.2-dev

Debian 8

Mapnik ist hier nur als Version 2.2 vorhanden. Da es dann Probleme mit Umlauten in der Karte geben kann, ist das keine valide Option. Daher müssen Pakete von Testing mit installiert werden. Da dies einiges im System auf neue Versionen updatet, ist diese Methode nicht für jeden empfehlenswert. Zum Testen kein Problem, aber auf Produktivsystemen ist die Gefahr, bestehende Funktionen zu zerstören, durchaus gegeben.

Also: Sie wurden gewarnt.

In /etc/apt/sources.list müssen die Testing-Quellen hinzu gefügt werden:

deb http://deb.debian.org/debian testing main contrib non-free

Und dann neu laden:

$ apt-get update

Mit dem Folgenden sollten sich alle benötigten Pakete installieren lassen:

$ apt-get install libmapnik3.0 libmapnik-dev mapnik-uitls subversion \ 
    unzip git dh-autoreconf apache2-dev apache2 cmake make cmake \ 
    g++ libboost-dev libboost-system-dev libboost-filesystem-dev \ 
    libexpat1-dev zlib1g-dev libbz2-dev libpq-dev libproj-dev lua5.2 \
    liblua5.2-dev postgresql postgis

Mapnik-Style

Als nächsten laden wir den Mapnik-Karten-Style:

$ mkdir ~/src
$ cd ~/src
$ svn co http://svn.openstreetmap.org/applications/rendering/mapnik mapnik-style
$ cd ~/src/mapnik-style
$ sudo ./get-coastlines.sh /usr/local/share

im Verzeichnis ‚inc‘ befinden sich Definitionen, die noch aus den Templates angepasst werden müssen:

$ cd inc
$ cp fontset-settings.xml.inc.template fontset-settings.xml.inc
$ cp datasource-settings.xml.inc.template datasource-settings.xml.inc
$ cp settings.xml.inc.template settings.xml.inc

Die settings.xml.inc wird geändert (wie auch in den Kommentaren beschrieben) in:

<!--
Settings for symbols, the spatial reference of your postgis tables, coastline s$
-->

<!-- use 'symbols' unless you have moved the symbols directory -->
<!ENTITY symbols "symbols">

<!-- use the '&srs900913;' entity if you have called osm2pgsql without special $
<!ENTITY osm2pgsql_projection "&srs900913;">

<!-- used for 'node in way' ST_DWithin spatial operations -->
<!-- Use 0.1 (meters) when your database is in 900913     -->
<!-- Use 0.000001 (degrees) when your database is in 4326 -->
<!ENTITY dwithin_900913 "0.1">
<!ENTITY dwithin_4326 "0.00001">
<!ENTITY dwithin_node_way "&dwithin_900913;">

<!-- use 'world_boundaries', which is the usual naming for the local folder the$
<!ENTITY world_boundaries "/usr/local/share/world_boundaries">

<!-- use 'planet_osm' unless you have customized your database table prefix usi$
<!ENTITY prefix "planet_osm">

datasource-settings.xml.inc:

<!--
Settings for your postgres setup.

Note: feel free to leave password, host, port, or use blank
-->

<Parameter name="type">postgis</Parameter>
<!-- <Parameter name="password">%(password)s</Parameter> -->
<!-- <Parameter name="host">%(host)s</Parameter> -->
<!-- <Parameter name="port">%(port)s</Parameter> -->
<!-- <Parameter name="user">%(user)s</Parameter> -->
<Parameter name="dbname">gis</Parameter>
<!-- this should be 'false' if you are manually providing the 'extent' -->
<Parameter name="estimate_extent">false</Parameter>
<!-- manually provided extent in epsg 900913 for whole globe -->
<!-- providing this speeds up Mapnik database queries -->
<Parameter name="extent">-20037508,-19929239,20037508,19929239</Parameter>

mod_tile und renderd

Der Teil, der dann die Karten-Tiles erzeugt und ausliefert, wird über mod_tile im Apache gesteuert. renderd wird nur dann angesprochen, wenn die entsprechende Kachel noch nicht erstellt worden war.
Alos müssen wir dann jetzt mod_tile und renderd von github holen und kompilieren:

$ cd ~/src
$ git clone git://github.com/openstreetmap/mod_tile.git
$ cd mod_tile
$ ./autogen.sh
$ ./configure
$ make
$ sudo make install
$ sudo make install-mod_tile

Die Konfiguration für den Render-Daemon muss noch nach /etc/ geschrieben werden, damit der auch weiß, was er tun soll. In ~/src/mod_tile/ besteht schon eine renderd.conf, die allerdings angepasst werden muss:
Unter [mapnik]:

plugins_dir=/usr/lib/mapnik/3.0/input/

Unter [default]:

URI=<Pfad, unter dem die tiles geliefert werden sollen, default: /osm_tiles/>
HOST=<hostname>
XML=<Pfad zum Mapnik-Style>

Der XML-Pfad muss lesbar sein für den User, unter dem renderd laufen wird. In diesem Beispiel ist es der aktuelle Benutzer, der auch die mapnik-styles in seinem src-Verzeichnis hat. Also wäre es

XML=/home/<MeinBenutzer>/src/mapnik-style/osm.xml

Die so geänderte Datei muss dann nach /etc/renderd.conf kopiert werden:

$ sudo cp renderd.conf /etc/renderd.conf

Damit ist mod_tile und mapnik verfügbar. Damit der Apache das Modul auch läd ist in /etc/apache2/mods-available ein entsprechendes Load-Script notwendig:

$ sudo sh -c 'echo "LoadModule tile_module /usr/lib/apache2/modules/mod_tile.so" > /etc/apache2/mods-available/tile.load'

Das Modul muss dann noch aktiviert werden:

$ sudo a2enmod tile

… und in der Website-Konfiguration konfigriert werden:

$ sudo nano /etc/apache2/sites-enabled/000-default.conf

unter ServerAdmin folgendes hinzu fügen:

LoadTileConfigFile /etc/renderd.conf
ModTileRenderdSocketName /var/run/renderd/renderd.sock
# Timeout before giving up for a tile to be rendered
ModTileRequestTimeout 3
# Timeout before giving up for a tile to be rendered that is otherwise missing
ModTileMissingRequestTimeout 30

Noch nicht den Apachen neu starten. Erst testen wir, ob die Konfiguration unseren Vorstellungen entspricht:

$ sudo apachectl -t

Die Ausgabe sollte lauten:

[Thu Apr 20 10:39:32.261241 2017] [tile:notice] [pid 10497:tid 139902994429824] Loading tile config default at /osm_tiles/ for zooms 0 - 20 from tile directory /var/lib/mod_tile with extension .png and mime type image/png
Syntax OK

Das Laufzeit-Verzeichnis für den renderd muss noch erstellt werden, und die Rechte dem Benutzer zugewiesen werden. Das gleiche auch für den tile-cache:

$ sudo mkdir /var/run/renderd /var/lib/mod_tile
$ sudo chown `whoami` /var/run/renderd /var/lib/mod_tile
$ sudo chmod 777 /var/run/renderd /var/lib/mod_tile

Importieren von Kartendaten

Damit auch sinnvolle Tiles erzeugt werden können, müssen Kartendaten vorhanden sein. Diese können aus verschiedenen Quellen bezogen werden. Geofabrik stellt netterweise Auszüge zur Verfügung. Um erstmal das Setup zu prüfen sollte nicht mit dem Import des World-Files begonnen werden, eine kleine Region reicht aus. Bremen z.B. hat im Moment 16.3 MB (zu finden unter http://download.geofabrik.de/europe/germany.html)

$ mkdir ~/osm && cd ~/osm
wget http://download.geofabrik.de/europe/germany/bremen-latest.osm.pbf

Und dann osm2pgsql zum Laufen kriegen:

Also besorgen wir uns das von github und kompilieren es:

$ cd ~/src
$ git clone git://github.com/openstreetmap/osm2pgsql.git
$ cd osm2pgsql
$ mkdir build && cd build
$ cmake ..
$ make -j3
$ sudo make install

Benutzer, Datenbank und Erweiterungen für Postgres müssen erstellt werden:

$ sudo -u postgres createuser `whoami`
$ sudo -u postgres createdb gis
$ sudo -u postgres psql -d gis -c 'CREATE EXTENSION postgis; CREATE EXTENSION hstore;'

Und dann importieren wir die Bremen-Daten, die wir vorher herunter geladen haben.

$ osm2pgsql --create --database gis ~/osm/bremen-latest.osm.pbf

Für diesen kleinen Datensatz reicht der Aufruf auf den meisten Rechnern, weitere Parameter (insbesondere -C und –flat-nodes) werden in der Dokumentation von osm2pgsql erklärt.

Und dann mal alles starten

Somit ist alles installiert, was wir brauchen, und wir können den Render-Daemon starten.

$ cd ~/src/mod_tile
$ ./renderd

Dann koppelt sich renderd von der startenden Shell ab und läuft im Hintergrund. Für Fehlersuche empfiehlt sich die Version mit Output:

$ ./renderd -f -c /etc/renderd.conf

Weiterhin muss der Webserver neu gestartet werden, damit die Konfiguration auch greift:

$ sudo systemctl restart apache2

Darstellung mit OpenLayers 4

Zum Abschluss noch ein einfaches Beispiel, wie die Ergebnisse dann auch im Browser angezeigt werden können. Dazu schreiben wir folgendes in eine Datei map.html:

<!DOCTYPE html>
<html>
  <head>
    <link rel="stylesheet" href="https://openlayers.org/en/v4.1.0/css/ol.css" type="text/css">
    <style>
      .map { height: 95vh; width: 100%; }
    </style>
    <script src="https://openlayers.org/en/v4.1.0/build/ol.js" type="text/javascript"></script>
    <title>OpenLayers example</title>
  </head>
  <body>
    <div id="map" class="map"></div>
    <script type="text/javascript">
    var map = new ol.Map({
      target: 'map',
      layers: [
        new ol.layer.Tile({
            source: new ol.source.OSM({url: '/osm_tiles/{z}/{x}/{y}.png', maxZoom: 20})
        })
      ],
      view: new ol.View({
        center: ol.proj.fromLonLat([8, 53]),
        zoom: 8
      })
    });
    </script>
  </body>
</html>

Dann sollte unter http://mein.server/map.html eine Karte mit den Kartendaten von Bremen gerendert werden.

Openstreetmap Karte nur mit Bundesland Bremen

Beim ersten Aufruf kann das durchaus seine Zeit dauern, da die Kacheln noch alle erstellt werden müssen. Je nach Zoomstufe und erzeugendem Server ist eine Minute Bearbeitungszeit nicht ungewöhnlich. Je näher man rein zoomt, desto mehr Details müssen auch von der Datenbank abgefragt werden, daher variiert das Erstellen der Kacheln mit dem Zoomlevel.
Sind die Kartendaten einmal als Bild vorhanden, werden sie danach aus dem Cache geliefert (der steht in /var/lib/mod_tile, der Aufbau der Karte im Browser ist dann erheblich schneller.

Windows 10 Drucker und HTTP-Service

Manchmal frage ich mich schon, was in den Köpfen bei Microsoft so vor sich geht. Bei Windows 10 ist der Druckdienst mit dem HTTP-Service gekoppelt. Also: es läuft ein Webserver auf meinem Rechner, wenn ich überhaupt Drucken können möchte.

Einem Kunden hatte ich eine komplexe Webanwendung erstellt, die neben einem Richclient in HTML5 und Javascript auch eine Serverkomponente zur Aufbereitung von Daten beinhaltet. Entwickelt wurde alles unter Linux, der Kunde jedoch hostete das Projekt unter Windows. Da gab es dann einen sporadischen Fehler, der nicht auf meinem Linux-Server nachvollziehbar war. Entsprechend musste ich das Setup nachstellen, und einen Apachen auf meinem Entwicklungsrechner zum Laufen bringen. Nein, der Kunde hostet nicht unter Windows 10, dieser Entwicklungsrechner läuft aber damit.

Erstaunlicherweise meldete XAMPP, dass Port 80 schon von einem Dienst belegt sei, Apache daher nicht starten könne. Also auf einem Rechner, der bisher keinerlei Server-Funktion übernommen hatte. Da war schon von Microsoft ein HTTP-Service vorinstalliert. In meiner Welt ist es einfach so, dass Programme, die einen Rechner von außen erreich- und ggf. steuerbar machen, nur dann installiert und aktiviert werden dürfen, wenn sie absolut notwendig sind. Ist halt eine simple Sicherheitsüberlegung – je weniger Türen ein Haus hat, desto weniger potentielle Schwachstellen. Aber ich wollte ja vor allem Port 80 für meine Zwecke nutzen, also habe ich den Dienst deinstalliert.

Ich konnte mich noch daran erinnern, dass Windows sich dann beschwert hatte, dass irgendwas mit dem Drucker dann sei. Aber da ich diese Meldung in sich unsinnig fand, habe ich die einfach ignoriert. Von diesem Rechner aus muss ich auch selten Drucken. Gut, Neustart – bis ich mich einloggen konnte, dauerte es ewig. Es lief erstmal so, wie ich mir das vorgestellt hatte.

Kürzlich musste ich etwas von diesem Rechner aus drucken. Natürlich hatte ich überhaupt nicht mehr an diese dubiose Meldung gedacht. Aber obwohl ich in der Druckerliste alle mir bekannten Drucker stehen hatte, meldete der Acrobat Reader, dass ich keinen Drucker hätte. Dabei konnte ich ihn doch von meinem Schreibtisch aus sehen. Angeschaltet war er auch. Dann fiel mir ein, dass da doch irgendwas mit diesem HTTP-Service war.

Und ja, tatsächlich: per Standard benötigt die Druckerwarteschlange den HTTP-Service. Absolut unglaublich und unverständlich. Und – wie sich herausstellte – auch in dieser Absolutheit falsch. Nur steht in der Registry, dass der Druckdienst abhängig vom HTTP-Dienst ist. Und wenn der nicht installiert ist, kann da nichts starten. Aber man kann das in der Registry ändern, und dann braucht der Druckdienst den HTTP-Dienst nicht mehr, und funktioniert dennoch einwandfrei:

Unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Spooler gibt es einen Eintrag „DependOnService„, in dem RPCSS und HTTP stehen. Entfernt man nun HTTP und startet den Rechner neu – bei mir hat es wieder ewig bis zum Einloggen gedauert – ist nun alles so, wie ich es eigentlich erwarte. Der Lokale Druckdienst funktioniert, ohne dass ein Webserver auf Port 80 ein unerwartetes Leben führt.

Es ist schon wirklich unverständlich.