Wie richtet man das IronPdfEngine ein

This article was translated from English: Does it need improvement?
Translated
View the article in English

IronPdfEngine ist ein gRPC-Server, der jede PDF-Operation ausführt — Erstellen, Bearbeiten, Lesen und Rendern. Die IronPDF for Java-Bibliothek ist ein API-Wrapper um diesen Server: Wenn Ihr Java-Code eine IronPDF-Methode aufruft, führt IronPdfEngine die Arbeit aus. Standardmäßig startet IronPDF for Java IronPdfEngine als lokalen Unterprozess und verwaltet dessen Lebenszyklus automatisch. Für fortgeschrittene Bereitstellungen — geteilte Microservices, Docker-Container oder abgeschirmte Netzwerke — können Sie IronPdfEngine stattdessen als eigenständigen Remote-Server ausführen.

Schnellstart: Einrichten von IronPdfEngine for Java

Hinweis:Jede Version von IronPDF for Java erfordert eine passende Version von IronPdfEngine. Die Kompatibilität zwischen Versionen wird nicht unterstützt. Verwenden Sie Settings.getIronPdfEngineVersion(), um die erforderliche Version zu bestätigen.

Welchen Bereitstellungsmodus sollten Sie verwenden?

IronPdfEngine unterstützt zwei Bereitstellungsansätze: lokal und remote. Die Wahl zwischen ihnen hängt von der Architektur Ihrer Anwendung ab.

Lokaler Modus (Standard) ist die richtige Wahl für eigenständige Anwendungen, Desktop-Tools und Einzelserver-Bereitstellungen. IronPDF for Java startet IronPdfEngine automatisch als Unterprozess — keine separate Infrastruktur ist erforderlich. Im lokalen Modus gibt es zwei Optionen, um die IronPdfEngine-Binärdateien zu erhalten: Laden Sie sie beim ersten Lauf herunter oder binden Sie sie als Maven-Abhängigkeit ein.

Remote-Modus eignet sich für verteilte Systeme, bei denen eine einzelne IronPdfEngine-Instanz mehreren Anwendungsnodes dient. Es ist auch der bevorzugte Ansatz für Docker-basierte Bereitstellungen, Kubernetes-Pods, abgeschirmte Netzwerke, die zur Laufzeit keine Binärdateien herunterladen können, und jede Situation, in der die Zentralisierung der PDF-Verarbeitung den Aufwand pro Service reduziert.

Die unten stehenden Abschnitte behandeln beide Modi im Detail.

Wie richten Sie lokalen IronPdfEngine ein?

Es gibt zwei Optionen, um IronPdfEngine lokal auszuführen. Beide ergeben dasselbe Laufzeitverhalten — der Unterschied besteht darin, wann und wie die Engine-Binärdatei auf dem Zielgerät ankommt.

Option 1: IronPdfEngine zur Laufzeit herunterladen

Standardmäßig erkennt IronPDF nach dem Hinzufügen der Kern-ironpdf-Abhängigkeit beim ersten Lauf die Host-Plattform (zum Beispiel Windows x64 oder Linux x64) und lädt die passende IronPdfEngine-Binärdatei aus dem Internet herunter.

//:path=pom.xml
<dependency>
    <groupId>com.ironsoftware</groupId>
    <artifactId>ironpdf</artifactId>
    <version>20xx.xx.xx</version>
</dependency>
//:path=pom.xml
<dependency>
    <groupId>com.ironsoftware</groupId>
    <artifactId>ironpdf</artifactId>
    <version>20xx.xx.xx</version>
</dependency>
XML

Nach dem ersten Download wird die Binärdatei lokal zwischengespeichert und nachfolgende Läufe starten ohne Netzwerkaufruf.

Option 1 — Laufzeitdownload: Abwägungen
VorteilEinschränkung
Kleinste Anwendungsgröße Internetverbindung beim ersten Lauf erforderlich
Unterstützt mehrere Zielplattformen aus einem Artefakt Langsamerer Start beim ersten Lauf, während die Binärdatei heruntergeladen wird

Option 2: Bündeln von IronPdfEngine als Abhängigkeit (empfohlen)

IronPDF Java bietet plattformspezifische Maven-Artefakte, die IronPdfEngine als .zip-Datei innerhalb der Abhängigkeit bündeln. Die Bibliothek extrahiert und verwendet sie automatisch — zur Laufzeit ist kein Netzwerkaufruf erforderlich.

//:path=pom.xml
<dependency>
    <groupId>com.ironsoftware</groupId>
    <artifactId>ironpdf</artifactId>
    <version>20xx.xx.xxxx</version>
</dependency>
//:path=pom.xml
<dependency>
    <groupId>com.ironsoftware</groupId>
    <artifactId>ironpdf</artifactId>
    <version>20xx.xx.xxxx</version>
</dependency>
XML

Fügen Sie dann das Plattformartefakt für Ihre Zielumgebung hinzu. Installieren Sie nur das Artefakt für Ihre Zielplattform — jedes ist groß, und die Installation aller vergrößert das Build unnötig.

Windows x64

//:path=pom.xml
<dependency>
    <groupId>com.ironsoftware</groupId>
    <artifactId>ironpdf-engine-windows-x64</artifactId>
    <version>20xx.xx.xxxx</version>
</dependency>
//:path=pom.xml
<dependency>
    <groupId>com.ironsoftware</groupId>
    <artifactId>ironpdf-engine-windows-x64</artifactId>
    <version>20xx.xx.xxxx</version>
</dependency>
XML

Windows x86

//:path=pom.xml
<dependency>
    <groupId>com.ironsoftware</groupId>
    <artifactId>ironpdf-engine-windows-x86</artifactId>
    <version>20xx.xx.xxxx</version>
</dependency>
//:path=pom.xml
<dependency>
    <groupId>com.ironsoftware</groupId>
    <artifactId>ironpdf-engine-windows-x86</artifactId>
    <version>20xx.xx.xxxx</version>
</dependency>
XML

Linux x64

//:path=pom.xml
<dependency>
    <groupId>com.ironsoftware</groupId>
    <artifactId>ironpdf-engine-linux-x64</artifactId>
    <version>20xx.xx.xxxx</version>
</dependency>
//:path=pom.xml
<dependency>
    <groupId>com.ironsoftware</groupId>
    <artifactId>ironpdf-engine-linux-x64</artifactId>
    <version>20xx.xx.xxxx</version>
</dependency>
XML

macOS x64

//:path=pom.xml
<dependency>
    <groupId>com.ironsoftware</groupId>
    <artifactId>ironpdf-engine-macos-x64</artifactId>
    <version>20xx.xx.xxxx</version>
</dependency>
//:path=pom.xml
<dependency>
    <groupId>com.ironsoftware</groupId>
    <artifactId>ironpdf-engine-macos-x64</artifactId>
    <version>20xx.xx.xxxx</version>
</dependency>
XML

macOS ARM (Apple Silicon)

//:path=pom.xml
<dependency>
    <groupId>com.ironsoftware</groupId>
    <artifactId>ironpdf-engine-macos-arm64</artifactId>
    <version>20xx.xx.xxxx</version>
</dependency>
//:path=pom.xml
<dependency>
    <groupId>com.ironsoftware</groupId>
    <artifactId>ironpdf-engine-macos-arm64</artifactId>
    <version>20xx.xx.xxxx</version>
</dependency>
XML

Hinweis:Die ironpdf- und ironpdf-engine-xxx-xxx-Abhängigkeit-Versionen müssen genau übereinstimmen. Die Versionszeichenfolge bezieht sich auf die IronPDF for Java-Veröffentlichung, nicht auf die interne Versionsnummer von IronPdfEngine.

Option 2 — Bündelabhängigkeit: Abwägungen
VorteilEinschränkung
Schnellerer Start — kein Download-Schritt Größeres Anwendungs-Paket
Keine Internetverbindung erforderlich nach der Installation Muss die Zielplattform explizit angeben
Konsistentes Verhalten in luftdichten Umgebungen Die Installation mehrerer Plattformartefakte vergrößert die Build-Größe erheblich

Wie verbinden Sie sich mit einer Remote-IronPdfEngine?

Der Remote-Modus lässt mehrere Anwendungsinstanzen einen einzigen IronPdfEngine-Server über gRPC gemeinsam nutzen. Dies ist üblich in Microservice-Architekturen, containerisierten Bereitstellungen und Umgebungen, in denen die PDF-Verarbeitung zentralisiert wird.

Wie überprüfen Sie die erforderliche IronPdfEngine-Version?

Die Version muss exakt übereinstimmen — IronPDF for Java 2024.2.2 erfordert genau IronPdfEngine 2024.2.2. Verwenden Sie getIronPdfEngineVersion, um die erforderliche Version zu bestätigen, bevor Sie den Server bereitstellen:

:path=/static-assets/ironpdf-java/content-code-examples/get-started/use-ironpdfengine-8.java
// Retrieve the IronPdfEngine version required by this Java library build
String ironPdfEngineVersion = Settings.getIronPdfEngineVersion();
System.out.println("Required IronPdfEngine version: " + ironPdfEngineVersion);
JAVA

Stellen Sie das IronPdfEngine-Docker-Image oder die Binärdatei bereit oder ziehen Sie sie, die der zurückgegebenen Versionszeichenfolge entspricht.

Wie konfigurieren Sie die Remote-Verbindung?

Nehmen Sie an, IronPdfEngine läuft bei 123.456.7.8:33350. Stellen Sie den Host und den Port ein, bevor Sie eine IronPDF-Methode aufrufen. Die beste Praxis ist, diese Aufrufe beim Start der Anwendung zu platzieren, bevor eine PDF-Operation ausgeführt wird:

:path=/static-assets/ironpdf-java/content-code-examples/get-started/use-ironpdfengine-9.java
// Configure IronPDF for Java to connect to a remote IronPdfEngine instance
com.ironsoftware.ironpdf.Settings.setIronPdfEngineHost("123.456.7.8");
com.ironsoftware.ironpdf.Settings.setIronPdfEnginePort(33350);
JAVA

Nach Ausführung dieser beiden Zeilen werden alle nachfolgenden IronPDF-Aufrufe in Ihrer Anwendung auf den Remote-Server geroutet. Kein lokaler IronPdfEngine-Subprozess wird gestartet, und es wird keine plattformspezifische Engine-Abhängigkeit in Ihrem pom.xml benötigt.

TippsStellen Sie sicher, dass die IronPdfEngine-Host-Adresse von Ihrem Anwendungs-Server erreichbar ist und dass Port 33350 in allen Firewalls oder Sicherheitsgruppen zwischen den beiden offen ist.

Wie sieht ein vollständiger Remote-Einrichtungsvorgang aus?

Das folgende Beispiel verbindet sich mit einer entfernten IronPdfEngine-Instanz und rendert einen HTML-String in eine PDF-Datei — dieselbe API, die im lokalen Modus verwendet wird, wobei sich nur die Konfiguration unterscheidet:

//:path=Main.java
import com.ironsoftware.ironpdf.*;

public class Main {
    public static void main(String[] args) throws Exception {
        // Point the library to the remote IronPdfEngine server
        Settings.setIronPdfEngineHost("123.456.7.8");
        Settings.setIronPdfEnginePort(33350);

        // Render HTML to PDF — IronPdfEngine on the remote host performs the work
        PdfDocument pdf = PdfDocument.renderHtmlAsPdf("<h1>Hello from remote IronPdfEngine</h1>");
        pdf.saveAs("output.pdf");
    }
}
//:path=Main.java
import com.ironsoftware.ironpdf.*;

public class Main {
    public static void main(String[] args) throws Exception {
        // Point the library to the remote IronPdfEngine server
        Settings.setIronPdfEngineHost("123.456.7.8");
        Settings.setIronPdfEnginePort(33350);

        // Render HTML to PDF — IronPdfEngine on the remote host performs the work
        PdfDocument pdf = PdfDocument.renderHtmlAsPdf("<h1>Hello from remote IronPdfEngine</h1>");
        pdf.saveAs("output.pdf");
    }
}
JAVA

Das gerenderte PDF wird über gRPC an den Java-Prozess zurückgegeben und lokal gespeichert. Der Remote-Server verarbeitet alle auf Chrome basierenden Render-, Schriftartenlade- und Ressourcenauflösungsprozesse.

Was sind die nächsten Schritte?

Mit konfiguriertem IronPdfEngine steht der vollständige Funktionsumfang von IronPDF for Java zur Verfügung — HTML zu PDF, PDF-Bearbeitung, Zusammenführung, Stempeln und mehr.

Häufig gestellte Fragen

Was ist IronPdfEngine und warum benötigt IronPDF for Java es?

IronPdfEngine ist ein gRPC-Server, der alle PDF-Operationen ausführt — Erstellen, Bearbeiten, Lesen und Rendern. IronPDF for Java ist ein API-Wrapper um diesen Server, sodass jeder Java-Methodenaufruf von IronPdfEngine verarbeitet wird. Ohne diesen kann die Java-Bibliothek keine PDF-Arbeiten durchführen.

Was ist der Unterschied zwischen lokalem und Remote-IronPdfEngine?

Der lokale Modus startet IronPdfEngine als Unterprozess auf derselben Maschine wie Ihre Java-Anwendung — keine zusätzliche Infrastruktur erforderlich. Remote-Modus verbindet sich über gRPC mit einem eigenständigen IronPdfEngine-Server, der für Microservices, Docker-Bereitstellungen und gemeinsame PDF-Verarbeitungsknoten geeignet ist.

Wann sollte ich Remote-IronPdfEngine anstelle von lokal verwenden?

Verwenden Sie Remote-IronPdfEngine, wenn Sie mehrere Anwendungsinstanzen benötigen, um einen PDF-Verarbeitungsserver zu teilen, wenn Sie in Kubernetes- oder Docker Compose Umgebungen bereitstellen, oder wenn Sie in luftgesicherten Netzwerken arbeiten, die zur Laufzeit keine Binärdateien herunterladen können.

Wie konfiguriere ich eine Remote-IronPdfEngine-Verbindung in Java?

Rufen Sie Settings.setIronPdfEngineHost() mit der Server-IP oder dem Hostname und Settings.setIronPdfEnginePort() mit der Portnummer beim Anwendungsstart auf, bevor Sie eine IronPDF-Methode aufrufen. Der Standard-IronPdfEngine-Port ist 33350.

Welches Maven-Artefakt sollte ich verwenden, um IronPdfEngine als Abhängigkeit zu bündeln?

Fügen Sie das plattformbezogene Artefakt hinzu, das Ihrem Bereitstellungsziel entspricht — zum Beispiel ironpdf-engine-linux-x64 für Linux-Server oder ironpdf-engine-windows-x64 für Windows. Die Artefaktversion muss genau mit der ironpdf-Kernabhängigkeitsversion übereinstimmen.

Wie kann ich überprüfen, welche IronPdfEngine-Version meine Java-Bibliothek benötigt?

Rufen Sie Settings.getIronPdfEngineVersion() in Ihrem Java-Code auf. Es gibt die genaue Versionszeichenfolge zurück, die mit der IronPdfEngine-Binärdatei oder dem Docker-Image, das Sie bereitstellen, übereinstimmen muss.

Kann ich mehrere Plattform-Engine-Abhängigkeiten in einem Projekt installieren?

Technisch ja, aber jedes Artefakt ist groß und das Installieren von mehr als einem bläst Ihren Build unnötig auf. Installieren Sie nur das Artefakt, das Ihrer Zielbereitstellungsplattform entspricht.

Benötige ich eine Internetverbindung, um IronPDF for Java zu verwenden?

Nur wenn Sie die Laufzeit-Download-Option verwenden (keine plattformspezifische Abhängigkeit in pom.xml). Beim ersten Ausführen lädt IronPDF die IronPdfEngine-Binärdatei für Ihre Plattform herunter. Nach diesem Download ist kein Internetzugang mehr erforderlich. Wenn Sie die gebündelte Plattform-Abhängigkeit hinzufügen oder den Remote-Modus verwenden, ist zu keinem Zeitpunkt ein Internetzugang erforderlich.

How do I detect and recover from a dead IronPdfEngine in Java?

Call IronPdfEngineManager.isEngineActive() to check whether the engine is connected, then IronPdfEngineManager.restartEngine() to force a clean reconnect if it is not. This watchdog pattern lets long-running services recover automatically when the engine is interrupted by a host restart, an operating system kill, or a native crash. It is an advanced feature; most applications rely on the automatic lifecycle and never call it.

Can I restart IronPdfEngine when using a custom gRPC connection?

No. In CUSTOM connection mode (a channel passed to IronPdfEngineConnection.withCustomGrpcConnection), stopEngine() and restartEngine() throw UnsupportedOperationException because the caller owns the channel and IronPDF cannot rebuild it. isEngineActive() and startEngine() still work in every connection mode.

Curtis Chau
Technischer Autor

Curtis Chau hat einen Bachelor-Abschluss in Informatik von der Carleton University und ist spezialisiert auf Frontend-Entwicklung mit Expertise in Node.js, TypeScript, JavaScript und React. Leidenschaftlich widmet er sich der Erstellung intuitiver und ästhetisch ansprechender Benutzerschnittstellen und arbeitet gerne mit modernen Frameworks sowie der Erstellung gut strukturierter, optisch ansprechender ...

Weiterlesen
Bereit anzufangen?
Version: 2026.6 gerade veröffentlicht
Still Scrolling Icon

Scrollst du immer noch?

Sie brauchen schnell einen Beweis?
Führen Sie eine Probe aus Sehen Sie zu, wie Ihr HTML-Code in eine PDF-Datei umgewandelt wird.