fix broken xrefs in the documentation that need resolved before the a…

…ntora migration

documentation/jetty-documentation/src/main/asciidoc/operations-guide/annotations/chapter.adoc

@@ -63,6 +63,7 @@ This may be very time-consuming if you have many jars.
 
 We will now look at ways to limit the jars that are scanned.
 
+[[og-container-include-jar-pattern]]
 ===== The container classpath
 
 By default, Jetty will _not_ scan any classes that are on the container's classpath.
@@ -92,6 +93,7 @@ Here's an example from a context xml file that includes any jar whose name start
 
 Note that the order of the patterns defines the ordering of the scanning of the jars or class directories.
 
+[[og-web-inf-include-jar-pattern]]
 ===== The webapp classpath
 
 By default Jetty will scan __all__ classes from `WEB-INF/classes` and _all_ jars from `WEB-INF/lib` according to the order, if any, established by absolute or relative ordering clauses in web.xml.

documentation/jetty-documentation/src/main/asciidoc/operations-guide/jaas/chapter.adoc

@@ -89,7 +89,7 @@ The `org.eclipse.jetty.jaas.JAASLoginService` can be declared in a couple of dif
 
 * If you have more than one webapp that you would like to use the same security infrastructure, then you can declare your `org.eclipse.jetty.jaas.JAASLoginService` as a bean that is added to the `org.eclipse.jetty.server.Server`.
 The file in which you declare this needs to be on Jetty's execution path.
-The recommended procedure is to create a file in your `$jetty.base/etc` directory and then ensure it is on the classpath either by adding it to the Jetty xref:og-start-jar[start command line], or more conveniently to a xref:custom-modules[custom module].
+The recommended procedure is to create a file in your `$jetty.base/etc` directory and then ensure it is on the classpath either by adding it to the Jetty xref:og-start[start command line], or more conveniently to a xref:og-modules-custom[custom module].
 +
 Here's an example of this type of XML file:
 +
@@ -158,6 +158,7 @@ Refer to the link:https://docs.oracle.com/javase/7/docs/api/javax/security/auth/
 * link:{javadoc-url}/org/eclipse/jetty/jaas/spi/DataSourceLoginModule.html[`org.eclipse.jetty.jaas.spi.DataSourceLoginModule`]
 * link:{javadoc-url}/org/eclipse/jetty/jaas/spi/LdapLoginModule.html[`org.eclipse.jetty.jaas.ldap.LdapLoginModule`]
 
+[[og-password]]
 [NOTE]
 ====
 Passwords can be stored in clear text, obfuscated or checksummed.

documentation/jetty-documentation/src/main/asciidoc/operations-guide/sessions/session-cache.adoc

@@ -23,7 +23,7 @@ The xref:og-session-usecases[scenarios] go into more detail on this.
 [[og-session-cache-hash]]
 ===== Caching in Memory
 
-If you wish to change any of the default configuration values you should enable the `session-cache-hash` xref:startup-modules[module].
+If you wish to change any of the default configuration values you should enable the `session-cache-hash` xref:og-modules[module].
 The name `"hash"` harks back to historical Jetty session implementations, whereby sessions were kept in memory using a HashMap.
 
 ====== Configuration

documentation/jetty-documentation/src/main/asciidoc/programming-guide/maven/jetty-maven-helloworld.adoc

@@ -32,11 +32,6 @@ First we'll have a look at a very simple HelloWorld java application that embeds
 [[configuring-embedded-jetty-with-maven]]
 ==== Using Embedded Jetty with Maven
 
-To understand the basic operations of building and running against Jetty, first review:
-
-* xref:advanced-embedding[Embedding with Jetty]
-* xref:jetty-helloworld[Jetty HelloWorld example]
-
 Maven uses convention over configuration, so it is best to use the project structure Maven recommends.
 You can use _xref:archetypes[http://maven.apache.org/guides/introduction/introduction-to-archetypes.html[archetypes]]_ to quickly setup Maven projects, but we will set up the structure manually for this simple tutorial example:
 
@@ -311,4 +306,4 @@ You can create a Web Application Archive (WAR) file from the project with the co
 > mvn package
 ----
 
-The resulting war file is in the `target` directory and may be deployed on any standard servlet server, including xref:configuring-deployment[Jetty].
+The resulting war file is in the `target` directory and may be deployed on any standard servlet server, including xref:og-deploy[Jetty].

documentation/jetty-documentation/src/main/asciidoc/programming-guide/maven/jetty-maven-plugin.adoc

@@ -51,7 +51,7 @@ However, `jetty:run-war` is designed to be run at the command line, whereas `jet
 ====
 While the Jetty Maven Plugin can be very useful for development we do not recommend its use in a _production capacity_.
 In order for the plugin to work it needs to leverage many internal Maven apis and Maven itself it not a production deployment tool.
-We recommend either the traditional link:{DISTGUIDE}[distribution] deployment approach or using xref:advanced-embedding[embedded Jetty].
+We recommend either the traditional xrefr:og-deploy[distribution] deployment approach or using xref:og-arch[embedded Jetty].
 ====
 
 [[get-up-and-running]]
@@ -144,11 +144,11 @@ host:::
 The particular interface for the connector to listen on.
 By default, all interfaces.
 name:::
-The name of the connector, which is useful for xref:serving-webapp-from-particular-port[configuring contexts to respond only on particular connectors].
+The name of the connector, which is useful for configuring contexts to respond only on particular connectors.
 idleTimeout:::
 Maximum idle time for a connection.
-You could instead configure the connectors in a standard xref:jetty-xml-config[jetty xml config file] and put its location into the `jettyXml` parameter.
-Note that since Jetty 9.0 it is no longer possible to configure a xref:maven-config-https[https connector] directly in the pom.xml: you need to xref:maven-config-https[use jetty xml config files to do it].
+You could instead configure the connectors in a standard xref:og-xml[jetty xml config file] and put its location into the `jettyXml` parameter.
+Note that since Jetty 9.0 it is no longer possible to configure a https connector directly in the pom.xml: you need to use jetty xml config files to do it.
 loginServices::
 Optional.
 A list of `org.eclipse.jetty.security.LoginService` implementations. Note that there is no default realm.
@@ -165,7 +165,7 @@ There are three other ways to configure the RequestLog:
   * In a context xml config file, as specified in the `contextXml` parameter.
   * In the `webApp` element.
 +
-See xref:configuring-jetty-request-logs[Configuring Request Logs] for more information.
+See xref:pg-server-http-request-logging[Configuring Request Logs] for more information.
 server::
 Optional as of Jetty 9.3.1.
 This would configure an instance of `org.eclipse.jetty.server.Server` for the plugin to use, however it is usually _not_ necessary to configure this, as the plugin will automatically configure one for you.
@@ -374,12 +374,12 @@ See the section on xref:using-overlaid-wars[overlaid wars] for more information.
 containerIncludeJarPattern;;
 Defaults to `.*/jetty-servlet-api-[^/]*\.jar$|.*javax.servlet.jsp.jstl-[^/]*\.jar|.*taglibs-standard-impl-.*\.jar`.
 This is a pattern that is applied to the names of the jars on the container's classpath (ie the classpath of the plugin, not that of the webapp) that should be scanned for fragments, tlds, annotations etc.
-This is analogous to the context attribute xref:container-include-jar-pattern[org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern] that is documented xref:container-include-jar-pattern[here].
+This is analogous to the context attribute xref:og-container-include-jar-pattern[org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern] that is documented xref:og-container-include-jar-pattern[here].
 You can define extra patterns of jars that will be included in the scan.
 webInfIncludeJarPattern;;
 Defaults to matching _all_ of the dependency jars for the webapp (ie the equivalent of WEB-INF/lib).
 You can make this pattern more restrictive to only match certain jars by using this setter.
-This is analogous to the context attribute xref:web-inf-include-jar-pattern[org.eclipse.jetty.server.webapp.WebInfIncludeJarPattern] that is documented xref:web-inf-include-jar-pattern[here].
+This is analogous to the context attribute xref:og-web-inf-include-jar-pattern[org.eclipse.jetty.server.webapp.WebInfIncludeJarPattern] that is documented xref:og-web-inf-include-jar-pattern[here].
 contextXml::
 The path to a context xml file that is applied to your webapp AFTER the `webApp` element.
 classesDirectory::
@@ -492,12 +492,12 @@ You can use this to replace or add configuration.
 containerIncludeJarPattern:::
 Defaults to `.*/jetty-servlet-api-[^/]*\.jar$|.*javax.servlet.jsp.jstl-[^/]*\.jar|.*taglibs-standard-impl-.*\.jar`.
 This is a pattern that is applied to the names of the jars on the container's classpath (ie the classpath of the plugin, not that of the webapp) that should be scanned for fragments, tlds, annotations etc.
-This is analogous to the context attribute xref:container-include-jar-pattern[org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern] that is documented xref:container-include-jar-pattern[here].
+This is analogous to the context attribute xref:og-container-include-jar-pattern[org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern] that is documented xref:og-container-include-jar-pattern[here].
 You can define extra patterns of jars that will be included in the scan.
 webInfIncludeJarPattern:::
 Defaults to matching _all_ of the dependency jars for the webapp (ie the equivalent of WEB-INF/lib).
 You can make this pattern more restrictive to only match certain jars by using this setter.
-This is analogous to the context attribute xref:web-inf-include-jar-pattern[org.eclipse.jetty.server.webapp.WebInfIncludeJarPattern] that is documented xref:web-inf-include-jar-pattern[here].
+This is analogous to the context attribute xref:og-web-inf-include-jar-pattern[org.eclipse.jetty.server.webapp.WebInfIncludeJarPattern] that is documented xref:og-web-inf-include-jar-pattern[here].
 tempDirectory:::
 The path to a dir that Jetty can use to expand or copy jars and jsp compiles when your webapp is running.
 The default is `${project.build.outputDirectory}/tmp`.
@@ -600,12 +600,12 @@ See the section on xref:using-overlaid-wars[overlaid wars] for more information.
 containerIncludeJarPattern;;
 Defaults to `.*/jetty-servlet-api-[^/]*\.jar$|.*javax.servlet.jsp.jstl-[^/]*\.jar|.*taglibs-standard-impl-.*\.jar`.
 This is a pattern that is applied to the names of the jars on the container's classpath (ie the classpath of the plugin, not that of the webapp) that should be scanned for fragments, tlds, annotations etc.
-This is analogous to the context attribute xref:container-include-jar-pattern[org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern] that is documented xref:container-include-jar-pattern[here].
+This is analogous to the context attribute xref:og-container-include-jar-pattern[org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern] that is documented xref:og-container-include-jar-pattern[here].
 You can define extra patterns of jars that will be included in the scan.
 webInfIncludeJarPattern;;
 Defaults to matching _all_ of the dependency jars for the webapp (ie the equivalent of WEB-INF/lib).
 You can make this pattern more restrictive to only match certain jars by using this setter.
-This is analogous to the context attribute xref:web-inf-include-jar-pattern[org.eclipse.jetty.server.webapp.WebInfIncludeJarPattern] that is documented xref:web-inf-include-jar-pattern[here].
+This is analogous to the context attribute xref:og-web-inf-include-jar-pattern[org.eclipse.jetty.server.webapp.WebInfIncludeJarPattern] that is documented xref:og-web-inf-include-jar-pattern[here].
 contextXml::
 The path to a context xml file that is applied to your webapp AFTER the `webApp` element.
 classesDirectory::
@@ -672,12 +672,12 @@ You can use this to replace or add configuration.
 containerIncludeJarPattern:::
 Defaults to `.*/jetty-servlet-api-[^/]*\.jar$|.*javax.servlet.jsp.jstl-[^/]*\.jar|.*taglibs-standard-impl-.*\.jar`.
 This is a pattern that is applied to the names of the jars on the container's classpath (ie the classpath of the plugin, not that of the webapp) that should be scanned for fragments, tlds, annotations etc.
-This is analogous to the context attribute xref:container-include-jar-pattern[org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern] that is documented xref:container-include-jar-pattern[here].
+This is analogous to the context attribute xref:og-container-include-jar-pattern[org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern] that is documented xref:og-container-include-jar-pattern[here].
 You can define extra patterns of jars that will be included in the scan.
 webInfIncludeJarPattern:::
 Defaults to matching _all_ of the dependency jars for the webapp (ie the equivalent of WEB-INF/lib).
 You can make this pattern more restrictive to only match certain jars by using this setter.
-This is analogous to the context attribute xref:web-inf-include-jar-pattern[org.eclipse.jetty.server.webapp.WebInfIncludeJarPattern] that is documented xref:web-inf-include-jar-pattern[here].
+This is analogous to the context attribute xref:og-web-inf-include-jar-pattern[org.eclipse.jetty.server.webapp.WebInfIncludeJarPattern] that is documented xref:og-web-inf-include-jar-pattern[here].
 tempDirectory:::
 The path to a dir that Jetty can use to expand or copy jars and jsp compiles when your webapp is running.
 The default is `${project.build.outputDirectory}/tmp`.
@@ -753,7 +753,7 @@ No programmatic declarations of servlets, filters and listeners can be taken int
 You can calculate the effective web.xml for any pre-built war file by setting the `<webApp><war>` parameter, or you can calculate it for the unassembled webapp by setting all of the usual `<webApp>` parameters as for `jetty:run`.
 
 Other useful information about your webapp that is produced as part of the analysis is also stored as context parameters in the effective-web.xml.
-The effective-web.xml can be used in conjunction with the xref:quickstart-webapp[Quickstart] feature to quickly start your webapp (note that Quickstart is not appropriate for the mvn jetty goals).
+The effective-web.xml can be used in conjunction with the xref:og-quickstart[Quickstart] feature to quickly start your webapp (note that Quickstart is not appropriate for the mvn jetty goals).
 
 The effective web.xml from these combined sources is generated into a file, which by default is `target/effective-web.xml`, but can be changed by setting the `effectiveWebXml` configuration parameter.
 
@@ -778,12 +778,12 @@ You can use this to replace or add configuration.
 containerIncludeJarPattern:::
 Defaults to `.*/jetty-servlet-api-[^/]*\.jar$|.*javax.servlet.jsp.jstl-[^/]*\.jar|.*taglibs-standard-impl-.*\.jar`.
 This is a pattern that is applied to the names of the jars on the container's classpath (ie the classpath of the plugin, not that of the webapp) that should be scanned for fragments, tlds, annotations etc.
-This is analogous to the context attribute xref:container-include-jar-pattern[org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern] that is documented xref:container-include-jar-pattern[here].
+This is analogous to the context attribute xref:og-container-include-jar-pattern[org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern] that is documented xref:og-container-include-jar-pattern[here].
 You can define extra patterns of jars that will be included in the scan.
 webInfIncludeJarPattern:::
 Defaults to matching _all_ of the dependency jars for the webapp (ie the equivalent of WEB-INF/lib).
 You can make this pattern more restrictive to only match certain jars by using this setter.
-This is analogous to the context attribute xref:web-inf-include-jar-pattern[org.eclipse.jetty.server.webapp.WebInfIncludeJarPattern] that is documented xref:web-inf-include-jar-pattern[here].
+This is analogous to the context attribute xref:og-web-inf-include-jar-pattern[org.eclipse.jetty.server.webapp.WebInfIncludeJarPattern] that is documented xref:og-web-inf-include-jar-pattern[here].
 tempDirectory:::
 The path to a dir that Jetty can use to expand or copy jars and jsp compiles when your webapp is running.
 The default is `${project.build.outputDirectory}/tmp`.

documentation/jetty-documentation/src/main/asciidoc/programming-guide/server/server.adoc

@@ -35,4 +35,5 @@ include::http2/server-http2.adoc[]
 include::http3/server-http3.adoc[]
 include::sessions/sessions.adoc[]
 include::websocket/server-websocket.adoc[]
+include::fastcgi/server-fastcgi.adoc[]
 include::server-io-arch.adoc[]