Fixing images throughout.
|
@ -361,7 +361,7 @@ If you imported the key and certificate originally using the PKCS12 method, use
|
|||
The `keystore` only contains the server's private key and certificate.
|
||||
|
||||
[[img-certificate-chain]]
|
||||
image::images/certificate-chain.png[title="Certificate chain", alt="Certificate chain"]
|
||||
image::certificate-chain.png[title="Certificate chain", alt="Certificate chain"]
|
||||
|
||||
[literal]
|
||||
.The structure of KeyStore file:
|
||||
|
|
Before Width: | Height: | Size: 50 KiB After Width: | Height: | Size: 50 KiB |
Before Width: | Height: | Size: 5.9 KiB After Width: | Height: | Size: 5.9 KiB |
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
Before Width: | Height: | Size: 140 KiB After Width: | Height: | Size: 140 KiB |
Before Width: | Height: | Size: 431 KiB After Width: | Height: | Size: 431 KiB |
Before Width: | Height: | Size: 94 KiB After Width: | Height: | Size: 94 KiB |
Before Width: | Height: | Size: 329 KiB After Width: | Height: | Size: 329 KiB |
Before Width: | Height: | Size: 441 KiB After Width: | Height: | Size: 441 KiB |
Before Width: | Height: | Size: 300 KiB After Width: | Height: | Size: 300 KiB |
Before Width: | Height: | Size: 136 KiB After Width: | Height: | Size: 136 KiB |
|
@ -57,7 +57,7 @@ To monitor Jetty's server status with JConsole, start Jetty and then start JCons
|
|||
After you start Jetty, you will see a dialog box in JConsole with a list of running processes to which you can connect.
|
||||
It should look something like so:
|
||||
|
||||
image:images/jconsole1.jpg[image,width=576]
|
||||
image:jconsole1.jpg[image,width=576]
|
||||
|
||||
____
|
||||
[IMPORTANT]
|
||||
|
@ -68,7 +68,7 @@ ____
|
|||
Select the start.jar entry and click the "Connect" button.
|
||||
A new JConsole window opens:
|
||||
|
||||
image:images/jconsole2.jpg[image,width=576]
|
||||
image:jconsole2.jpg[image,width=576]
|
||||
|
||||
From this window you can monitor memory usage, thread usage, classloading and VM statistics.
|
||||
You can also perform operations such as a manual garbage collect.
|
||||
|
@ -80,7 +80,7 @@ The MBean tab of JConsole allows access to managed objects within the Java appli
|
|||
If you also want to interact with the Jetty JMX implementation via JConsole, you need to start Jetty JMX in a form that JConsole can access.
|
||||
See xref:using-jmx[] for more information.
|
||||
|
||||
image:images/jconsole3.png[image,width=576]
|
||||
image:jconsole3.png[image,width=576]
|
||||
|
||||
[[jetty-jmc-monitoring]]
|
||||
==== Monitoring Jetty with JMC
|
||||
|
@ -92,7 +92,7 @@ To monitor Jetty's server status with JMC, start Jetty and then start JMC by typ
|
|||
After you start Jetty, you will see a dialog box in JMC with a list of running processes to which you can connect.
|
||||
It should look something like so:
|
||||
|
||||
image:images/jmc1.png[image,width=576]
|
||||
image:jmc1.png[image,width=576]
|
||||
|
||||
____
|
||||
[IMPORTANT]
|
||||
|
@ -103,7 +103,7 @@ ____
|
|||
Double-click the start.jar entry or right-click the start.jar entry and select "Start JMX Console".
|
||||
A new JMC window opens on the right:
|
||||
|
||||
image:images/jmc2.png[image,width=576]
|
||||
image:jmc2.png[image,width=576]
|
||||
|
||||
From this window you can monitor memory usage, thread usage, classloading and VM statistics.
|
||||
You can also perform operations such as a manual garbage collect.
|
||||
|
@ -115,4 +115,4 @@ The MBean tab of JMC allows access to managed objects within the Java applicatio
|
|||
If you also want to interact with the Jetty JMX implementation via JMC, you need to start Jetty JMX in a form that JMC can access.
|
||||
See xref:using-jmx[] for more information.
|
||||
|
||||
image:images/jmc3.png[image,width=576]
|
||||
image:jmc3.png[image,width=576]
|
||||
|
|
|
@ -47,7 +47,7 @@ There is only one (1) `SessionDataStore` per `SessionCache`.
|
|||
|
||||
Visually the session architecture can be represented like this:
|
||||
|
||||
image::images/SessionsHierarchy.png[]
|
||||
image::SessionsHierarchy.png[]
|
||||
|
||||
==== Configuring Sessions in the Jetty Distribution
|
||||
|
||||
|
|
|
@ -295,4 +295,4 @@ Once you have run `prunsrv.exe //IS/<service-name>` (done for you in the above b
|
|||
|
||||
Open the Service View and start your service.
|
||||
|
||||
image:images/windows-service-jetty.png[image,width=576]
|
||||
image:windows-service-jetty.png[image,width=576]
|
||||
|
|
|
@ -19,13 +19,13 @@
|
|||
[[basic-architecture]]
|
||||
=== Jetty Architecture
|
||||
|
||||
==== View from 20,000 feet
|
||||
==== View from 20,000 feet
|
||||
|
||||
The Jetty link:{JDURL}/org/eclipse/jetty/server/Server.html[Server] is the plumbing between
|
||||
a collection of `Connector`s that accept connections and a collection of `Handler`s that
|
||||
service requests from the connections and produce responses, with threads from a thread pool doing the work.
|
||||
|
||||
image:images/jetty-high-level-architecture.png[image,width=576]
|
||||
image:jetty-high-level-architecture.png[image,width=576]
|
||||
|
||||
While the Jetty request/responses are derived from the Servlet API, the full features of the Servlet API
|
||||
are only available if you configure the appropriate handlers.
|
||||
|
@ -45,12 +45,12 @@ and configuration of components by a variety of techniques:
|
|||
|
||||
==== Patterns
|
||||
|
||||
The implementation of Jetty follows some fairly standard patterns.
|
||||
The implementation of Jetty follows some fairly standard patterns.
|
||||
Most abstract concepts such as `Connector`s and `Handler`s are captured by interfaces.
|
||||
Generic handling for those interfaces is then provided in an abstract implementation
|
||||
such as `AbstractConnector` and `AbstractHandler`.
|
||||
|
||||
image:images/basic-architecture-patterns.png[image,width=576]
|
||||
image:basic-architecture-patterns.png[image,width=576]
|
||||
|
||||
The JSR77 inspired life cycle of most Jetty components is represented by the `LifeCycle`
|
||||
interface and the `AbstractLifeCycle` implementation used as the base of many Jetty components.
|
||||
|
@ -90,7 +90,7 @@ therefore using Jetty as a generic network server.
|
|||
A `Handler` is the component that deals with HTTP requests and responses.
|
||||
The core API of a handler is the handle method:
|
||||
|
||||
image:images/basic-architecture-handlers.png[image,width=576]
|
||||
image:basic-architecture-handlers.png[image,width=576]
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
----
|
||||
|
@ -119,13 +119,13 @@ This gives three styles of Handler:
|
|||
You can combine handlers to handle different aspects of a request by nesting them,
|
||||
calling them in sequence, or by combining the two models.
|
||||
|
||||
image:images/basic-architecture-nested-handlers.png[image,width=576]
|
||||
image:basic-architecture-nested-handlers.png[image,width=576]
|
||||
|
||||
Handlers called in sequence perform actions that do not depend on the next invocation, nor on the handler order.
|
||||
They handle a request and generate the response without interacting with other handlers.
|
||||
Handlers called in sequence perform actions that do not depend on the next invocation, nor on the handler order.
|
||||
They handle a request and generate the response without interacting with other handlers.
|
||||
The main class for this model is `HandlerCollection`.
|
||||
|
||||
Nested handlers are called according to a before/invokeNext/after pattern.
|
||||
Nested handlers are called according to a before/invokeNext/after pattern.
|
||||
The main class for nested handlers is `HandlerWrapper`.
|
||||
Nested handlers are much more common than those called in sequence.
|
||||
|
||||
|
@ -136,7 +136,7 @@ See also xref:writing-custom-handlers[].
|
|||
The `ServletHandler` is a `Handler` that generates content by passing the request to any
|
||||
configured Servlet Filters and then to a Servlet mapped by a URI pattern.
|
||||
|
||||
image:images/basic-architecture-servlet-handler.png[image,width=576]
|
||||
image:basic-architecture-servlet-handler.png[image,width=576]
|
||||
|
||||
A `ServletHandler` is normally deployed within the scope of a `ServletContext`, which is a
|
||||
`ContextHandler` that provides convenience methods for mapping URIs to servlets.
|
||||
|
@ -170,7 +170,7 @@ A `WebAppContext` is a derivation of `ServletContextHandler` that supports the s
|
|||
of a web application and configuration of session, security, listeners, filter, servlets, and JSP
|
||||
via a `web.xml` descriptor normally found in the `/WEB-INF` directory of a web application.
|
||||
|
||||
image:images/basic-architecture-web-application.png[image,width=576]
|
||||
image:basic-architecture-web-application.png[image,width=576]
|
||||
|
||||
Essentially `WebAppContext` is a convenience class that assists the construction and configuration
|
||||
of other handlers to achieve a standard web application configuration.
|
||||
|
|
|
@ -30,15 +30,15 @@ Next we need to link the Eclipse project with the deployed webapp.
|
|||
1. Within Eclipse, right-click on the project containing the webapp deployed into jetty and select *Debug -> Debug Configurations* and create a new configuration of **Remote Java Application**.
|
||||
Make sure the port you choose is the same as the one you added in xref:enable-remote-debugging[].
|
||||
+
|
||||
image:images/debug-eclipse-1.png[image,width=576]
|
||||
image:debug-eclipse-1.png[image,width=576]
|
||||
|
||||
2. Next in your webapp you can set a breakpoint within a servlet which when it is tripped will halt the remote jvm's processing thread to await for debugging commands from your Eclipse instance.
|
||||
+
|
||||
image:images/debug-eclipse-2.png[image,width=576]
|
||||
image:debug-eclipse-2.png[image,width=576]
|
||||
|
||||
3. Accessing that servlet within your browser, pointed at your remote debug configurated jetty-distribution, should transition your Eclipse instance to the standard Debug view.
|
||||
+
|
||||
image:images/debug-eclipse-3.png[image,width=576]
|
||||
image:debug-eclipse-3.png[image,width=576]
|
||||
|
||||
[[eclipse-within-eclipse]]
|
||||
==== Within Eclipse
|
||||
|
|
|
@ -31,17 +31,17 @@ Next we need to link the IntelliJ project with the deployed webapp.
|
|||
Add a new configuration by clicking the "+" icon. Choose **Remote**.
|
||||
Make sure the port you choose is the same as the one you added in xref:enable-remote-debugging[].
|
||||
+
|
||||
image:images/intellij_new_remote_config.png[image,width=800]
|
||||
image:intellij_new_remote_config.png[image,width=800]
|
||||
|
||||
2. Next in your webapp you can set a breakpoint within a servlet which when it is tripped will halt the remote jvm's processing thread to await for debugging commands from your IntelliJ instance.
|
||||
To set a breakpoint, simply open the servlet or any other class you want to debug and click left to the line you want to set the breakpoint at (where the red dot is on the next screenshot).
|
||||
The red dot and red background on the line mark the breakpoint.
|
||||
+
|
||||
image:images/intellij_set_breakpoint.png[image,width=800]
|
||||
image:intellij_set_breakpoint.png[image,width=800]
|
||||
|
||||
3. Accessing that servlet within your browser, pointed at your remote debug configured jetty-distribution, should transition your IntelliJ instance to the standard debugger view.
|
||||
+
|
||||
image:images/intellij_debug_view.png[image,width=800]
|
||||
image:intellij_debug_view.png[image,width=800]
|
||||
|
||||
[[intellij-within-intellij]]
|
||||
==== Within IntelliJ
|
||||
|
@ -55,7 +55,7 @@ In your *Console* tab within IntelliJ you should see your application startup an
|
|||
The same thing works for unit tests.
|
||||
Instead of the main method run debug on the test method you want to debug.
|
||||
|
||||
image:images/intellij_select_debug.png[image,width=800]
|
||||
image:intellij_select_debug.png[image,width=800]
|
||||
|
||||
Debugging in IntelliJ is extremely powerful.
|
||||
For example it's possible to have conditional breakpoints that only trigger a break if the configured conditions are met.
|
||||
|
|
Before Width: | Height: | Size: 54 KiB After Width: | Height: | Size: 54 KiB |
Before Width: | Height: | Size: 12 KiB After Width: | Height: | Size: 12 KiB |
Before Width: | Height: | Size: 44 KiB After Width: | Height: | Size: 44 KiB |
Before Width: | Height: | Size: 40 KiB After Width: | Height: | Size: 40 KiB |
Before Width: | Height: | Size: 21 KiB After Width: | Height: | Size: 21 KiB |
Before Width: | Height: | Size: 120 KiB After Width: | Height: | Size: 120 KiB |
Before Width: | Height: | Size: 332 KiB After Width: | Height: | Size: 332 KiB |
Before Width: | Height: | Size: 269 KiB After Width: | Height: | Size: 269 KiB |
Before Width: | Height: | Size: 433 KiB After Width: | Height: | Size: 433 KiB |
Before Width: | Height: | Size: 275 KiB After Width: | Height: | Size: 275 KiB |
Before Width: | Height: | Size: 542 KiB After Width: | Height: | Size: 542 KiB |
Before Width: | Height: | Size: 396 KiB After Width: | Height: | Size: 396 KiB |
Before Width: | Height: | Size: 4.4 KiB After Width: | Height: | Size: 4.4 KiB |
|
@ -82,7 +82,7 @@ XML files::
|
|||
|
||||
Below is an illustration of how the various Jetty configuration files (`ini`, `mod` and XML) are related:
|
||||
|
||||
image:../images/Jetty_Configuration_File_Relationships.png[image,width=693]
|
||||
image:Jetty_Configuration_File_Relationships.png[image,width=693]
|
||||
|
||||
==== A Closer Look
|
||||
|
||||
|
|
Before Width: | Height: | Size: 33 KiB After Width: | Height: | Size: 33 KiB |