apache · sanjana2505006 · Jan 24, 2026 · Feb 4, 2026 · Feb 23, 2026 · Mar 28, 2026
diff --git a/...ernate5/docs/src/docs/asciidoc/advancedGORMFeatures/eventsAutoTimestamping.adoc b/...ernate5/docs/src/docs/asciidoc/advancedGORMFeatures/eventsAutoTimestamping.adoc
@@ -17,6 +17,8 @@ specific language governing permissions and limitations
 under the License.
 ////
 
+= Events and Auto Timestamping
+
 GORM supports the registration of events as methods that get fired when certain events occurs such as deletes, inserts and updates. The following is a list of supported events:
 
 * `beforeInsert` - Executed before an object is initially persisted to the database.  If you return false, the insert will be cancelled.
@@ -33,7 +35,7 @@ To add an event simply register the relevant method with your domain class.
 WARNING: Do not attempt to flush the session within an event (such as with obj.save(flush:true)). Since events are fired during flushing this will cause a StackOverflowError.
 
 
-==== The beforeInsert event
+== The beforeInsert event
 
 
 Fired before an object is saved to the database
@@ -56,7 +58,7 @@ class Person {
 ----
 
 
-==== The beforeUpdate event
+== The beforeUpdate event
 
 
 Fired before an existing object is updated
@@ -88,7 +90,7 @@ class Person {
 Notice the usage of `autowire true` above. This is required for the bean `securityService` to be injected.
 
 
-==== The beforeDelete event
+== The beforeDelete event
 
 
 Fired before an object is deleted.
@@ -111,7 +113,7 @@ Notice the usage of `withNewSession` method above. Since events are triggered wh
 Fortunately the `withNewSession` method lets you share the same transactional JDBC connection even though you're using a different underlying `Session`.
 
 
-==== The beforeValidate event
+== The beforeValidate event
 
 
 Fired before an object is validated.
@@ -171,7 +173,7 @@ no-arg version if no arguments are passed to `validate` but will fall back on th
 `List` version if the no-arg version does not exist.  In that case, `null` is passed to `beforeValidate`.
 
 
-==== The onLoad/beforeLoad event
+== The onLoad/beforeLoad event
 
 
 Fired immediately before an object is loaded from the database:
@@ -192,7 +194,7 @@ class Person {
 `beforeLoad()` is effectively a synonym for `onLoad()`, so only declare one or the other.
 
 
-==== The afterLoad event
+== The afterLoad event
 
 
 Fired immediately after an object is loaded from the database:
@@ -211,7 +213,7 @@ class Person {
 ----
 
 
-==== Custom Event Listeners
+== Custom Event Listeners
 
 To register a custom event listener you need to subclass `AbstractPersistenceEventListener` (in package _org.grails.datastore.mapping.engine.event_) and implement the methods `onPersistenceEvent` and `supportsEventType`. You also must provide a reference to the datastore to the listener.  The simplest possible implementation can be seen below:
 
@@ -277,7 +279,7 @@ datastore.getApplicationEventPublisher()
 ----
 
 
-==== Hibernate Events
+== Hibernate Events
 
 
 It is generally encouraged to use the non-Hibernate specific API described above, but if you need access to more detailed Hibernate events then you can define custom Hibernate-specific event listeners.
@@ -359,7 +361,7 @@ def doWithSpring = {
 ----
 
 
-==== Automatic timestamping
+== Automatic timestamping
 
 
 If you define a `dateCreated` property it will be set to the current date for you when you create new instances. Likewise, if you define a `lastUpdated` property it will be automatically be updated for you when you change persistent instances.

diff --git a/grails-data-hibernate5/docs/src/docs/asciidoc/index.adoc b/grails-data-hibernate5/docs/src/docs/asciidoc/index.adoc
@@ -190,9 +190,7 @@ include::querying/hql.adoc[]
 include::advancedGORMFeatures.adoc[]
 
 [[eventsAutoTimestamping]]
-=== Events and Auto Timestamping
-
-include::advancedGORMFeatures/eventsAutoTimestamping.adoc[]
+include::advancedGORMFeatures/eventsAutoTimestamping.adoc[leveloffset=+2]
 
 [[ormdsl]]
 === Custom ORM Mapping
@@ -265,9 +263,7 @@ include::advancedGORMFeatures/ormdsl/customNamingStrategy.adoc[]
 include::advancedGORMFeatures/defaultSortOrder.adoc[]
 
 [[programmaticTransactions]]
-== Programmatic Transactions
-
-include::programmaticTransactions.adoc[]
+include::programmaticTransactions.adoc[leveloffset=+1]
 
 [[dataServices]]
 == GORM Data Services

diff --git a/grails-data-hibernate5/docs/src/docs/asciidoc/programmaticTransactions.adoc b/grails-data-hibernate5/docs/src/docs/asciidoc/programmaticTransactions.adoc
@@ -17,11 +17,13 @@ specific language governing permissions and limitations
 under the License.
 ////
 
+= Programmatic Transactions
+
 GORM's transaction management is built on Spring and uses Spring's Transaction abstraction for dealing with programmatic transactions.
 
 However, GORM classes have been enhanced to make this simpler with the link:../api/org/grails/datastore/gorm/GormEntity.html#withTransaction(groovy.lang.Closure)[withTransaction(Closure)]  method. This method has a single parameter, a Closure, which has a single parameter which is a Spring https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/transaction/TransactionStatus.html[TransactionStatus] instance.
 
-==== Using the withTransaction Method
+== Using the withTransaction Method
 
 Here's an example of using `withTransaction` in a controller methods:
 
@@ -56,7 +58,7 @@ You can also use "save points" to rollback a transaction to a particular point i
 
 The `withTransaction` method deals with the begin/commit/rollback logic for you within the scope of the block.
 
-==== Using TransactionService
+== Using TransactionService
 
 Since GORM 6.1, if you need more flexibility then instead you can instead take advantage of the link:../api/grails/gorm/transactions/TransactionService.html[TransactionService], which can be obtained by looking it up from from the `HibernateDatastore`:
 

diff --git a/grails-doc/src/en/guide/conf/config/builtInOptions.adoc b/grails-doc/src/en/guide/conf/config/builtInOptions.adoc
@@ -17,11 +17,13 @@ specific language governing permissions and limitations
 under the License.
 ////
 
+= Built in options
+
 Grails has a set of core settings that are worth knowing about. Their defaults are suitable for most projects, but it's important to understand what they do because you may need one or more of them later.
 
 
 
-=== Runtime settings
+== Runtime settings
 
 
 On the runtime front, i.e. `grails-app/conf/application.yml`, there are quite a few more core settings:

diff --git a/grails-doc/src/en/guide/deployment/deploymentContainer.adoc b/grails-doc/src/en/guide/deployment/deploymentContainer.adoc
@@ -20,7 +20,9 @@ under the License.
 Grails apps can be deployed to a Servlet Container or Application Server.
 
 
-=== WAR file
+= Container Deployment (e.g. Tomcat)
+
+== WAR file
 
 
 A common approach to Grails application deployment in production is to deploy to an existing Servlet container via a WAR file. Containers allow multiple applications to be deployed on the same port with different paths.

diff --git a/grails-doc/src/en/guide/deployment/deploymentStandalone.adoc b/grails-doc/src/en/guide/deployment/deploymentStandalone.adoc
@@ -19,7 +19,9 @@ under the License.
 
 
 
-=== "grails run-app"
+= Standalone
+
+== "grails run-app"
 
 
 You should be very familiar with this approach by now, since it is the most common method of running an application during the development phase. An embedded Tomcat server is launched that loads the web application from the development sources, thus allowing it to pick up any changes to application files.
@@ -39,7 +41,7 @@ You can specify an environment supplying `grails.env` system property.
 
 `./gradlew -Dgrails.env=prod bootRun`
 
-=== Runnable WAR or JAR file
+== Runnable WAR or JAR file
 
 Another way to deploy in Grails 3.0 or above is to use the new support for runnable JAR or WAR files. To create runnable archives, run `grails package`:
 
@@ -59,12 +61,12 @@ You can then run either the WAR file or the JAR using your Java installation:
 java -Dgrails.env=prod -jar build/libs/mywar-0.1.war    (or .jar)
 ----
 
-=== A TAR/ZIP distribution
+== A TAR/ZIP distribution
 
 WARNING: Note: TAR/ZIP distribution assembly has been removed from Grails 3.1.
 
 
-=== "./gradlew bootRun"
+== "./gradlew bootRun"
 
 
 You should be very familiar with this approach by now, since it is the most common method of running an application during the development phase. An embedded Tomcat server is launched that loads the web application from the development sources, thus allowing it to pick up any changes to application files.
@@ -84,7 +86,7 @@ You can specify an environment supplying `grails.env` system property.
 
 `./gradlew -Dgrails.env=prod bootRun`
 
-=== Runnable WAR or JAR file
+== Runnable WAR or JAR file
 
 Another way to deploy in Grails 3.0 or above is to use the new support for runnable JAR or WAR files. To create runnable archives, run `grails package`:
 
@@ -104,6 +106,6 @@ You can then run either the WAR file or the JAR using your Java installation:
 java -Dgrails.env=prod -jar build/libs/mywar-0.1.war    (or .jar)
 ----
 
-=== A TAR/ZIP distribution
+== A TAR/ZIP distribution
 
 WARNING: Note: TAR/ZIP distribution assembly has been removed from Grails 3.1.
diff --git a/grails-doc/src/en/guide/index.adoc b/grails-doc/src/en/guide/index.adoc
@@ -146,9 +146,7 @@ include::conf/config.adoc[]
 include::conf/config/ymlPropertyOptions.adoc[]
 
 [[builtInOptions]]
-==== Built in options
-
-include::conf/config/builtInOptions.adoc[]
+include::conf/config/builtInOptions.adoc[leveloffset=+3]
 
 [[logging]]
 ==== Logging
@@ -961,9 +959,7 @@ include::testing/unitTesting.adoc[]
 include::testing/unitTesting/unitTestingControllers.adoc[]
 
 [[unitTestingTagLibraries]]
-==== Unit Testing Tag Libraries
-
-include::testing/unitTesting/unitTestingTagLibraries.adoc[]
+include::testing/unitTesting/unitTestingTagLibraries.adoc[leveloffset=+3]
 
 [[unitTestingDomains]]
 ==== Unit Testing Domains
@@ -1076,49 +1072,33 @@ include::security/securityPlugins/shiro.adoc[]
 include::plugins.adoc[]
 
 [[creatingAndInstallingPlugins]]
-=== Creating and Installing Plugins
-
-include::plugins/creatingAndInstallingPlugins.adoc[]
+include::plugins/creatingAndInstallingPlugins.adoc[leveloffset=+2]
 
 [[repositories]]
-=== Plugin Repositories
-
-include::plugins/repositories.adoc[]
+include::plugins/repositories.adoc[leveloffset=+2]
 
 [[providingBasicArtefacts]]
-=== Providing Basic Artefacts
-
-include::plugins/providingBasicArtefacts.adoc[]
+include::plugins/providingBasicArtefacts.adoc[leveloffset=+2]
 
 [[evaluatingConventions]]
 === Evaluating Conventions
 
 include::plugins/evaluatingConventions.adoc[]
 
 [[hookingIntoRuntimeConfiguration]]
-=== Hooking into Runtime Configuration
-
-include::plugins/hookingIntoRuntimeConfiguration.adoc[]
+include::plugins/hookingIntoRuntimeConfiguration.adoc[leveloffset=+2]
 
 [[addingMethodsAtCompileTime]]
-=== Adding Methods at Compile Time
-
-include::plugins/addingMethodsAtCompileTime.adoc[]
+include::plugins/addingMethodsAtCompileTime.adoc[leveloffset=+2]
 
 [[addingDynamicMethodsAtRuntime]]
-=== Adding Dynamic Methods at Runtime
-
-include::plugins/addingDynamicMethodsAtRuntime.adoc[]
+include::plugins/addingDynamicMethodsAtRuntime.adoc[leveloffset=+2]
 
 [[participatingInAutoReloadEvents]]
-=== Participating in Auto Reload Events
-
-include::plugins/participatingInAutoReloadEvents.adoc[]
+include::plugins/participatingInAutoReloadEvents.adoc[leveloffset=+2]
 
 [[understandingPluginLoadOrder]]
-=== Understanding Plugin Load Order
-
-include::plugins/understandingPluginLoadOrder.adoc[]
+include::plugins/understandingPluginLoadOrder.adoc[leveloffset=+2]
 
 [[artefactApi]]
 === The Artefact API
@@ -1201,14 +1181,10 @@ include::scaffolding.adoc[]
 include::deployment.adoc[]
 
 [[deploymentStandalone]]
-=== Standalone
-
-include::deployment/deploymentStandalone.adoc[]
+include::deployment/deploymentStandalone.adoc[leveloffset=+2]
 
 [[deploymentContainer]]
-=== Container Deployment (e.g. Tomcat)
-
-include::deployment/deploymentContainer.adoc[]
+include::deployment/deploymentContainer.adoc[leveloffset=+2]
 
 [[deploymentTasks]]
 === Deployment Configuration Tasks

diff --git a/grails-doc/src/en/guide/introduction/whatsNew.adoc b/grails-doc/src/en/guide/introduction/whatsNew.adoc
@@ -19,20 +19,20 @@ under the License.
 
 This section covers all the new features introduced in Grails 7
 
-=== Overview
+==== Overview
 
 Grails 7 is a major release that includes new features, improvements, and dependency upgrades.
 This release focuses on enhancing the developer experience, improving performance, and ensuring compatibility with the latest technologies.
 
 For detailed information on how to upgrade to Grails 7, including major dependency changes, please see the xref:upgrading#upgrading60x[Upgrading from Grails 6 to Grails 7] section.
 Notable new features are included below.
 
-=== External Configuration
+==== External Configuration
 
 The https://github.com/sbglasius/external-config[external configuration plugin] is now integrated into Grails.
 See the xref:conf.adoc#externalConfiguration[Configuration] section for details.
 
-=== Ubiquitous Containerized Browser Testing with Geb
+==== Ubiquitous Containerized Browser Testing with Geb
 
 The https://github.com/apache/grails-core/tree/HEAD/grails-geb#readme[Grails Geb Plugin] has received a significant update, introducing test fixtures that enable ubiquitous containerized browser testing.
 

diff --git a/grails-doc/src/en/guide/plugins/addingDynamicMethodsAtRuntime.adoc b/grails-doc/src/en/guide/plugins/addingDynamicMethodsAtRuntime.adoc
@@ -17,8 +17,10 @@ specific language governing permissions and limitations
 under the License.
 ////
 
+= Adding Dynamic Methods at Runtime
 
-==== The Basics
+
+== The Basics
 
 
 Grails plugins let you register dynamic methods with any Grails-managed or other class at runtime. This work is done in a `doWithDynamicMethods` method.
@@ -62,7 +64,7 @@ class ExamplePlugin extends Plugin  {
 ----
 
 
-==== Interacting with the ApplicationContext
+== Interacting with the ApplicationContext
 
 
 The `doWithDynamicMethods` closure gets passed the Spring `ApplicationContext` instance. This is useful as it lets you interact with objects within it. For example if you were implementing a method to interact with Hibernate you could use the `SessionFactory` instance in combination with a `HibernateTemplate`:

diff --git a/grails-doc/src/en/guide/plugins/addingMethodsAtCompileTime.adoc b/grails-doc/src/en/guide/plugins/addingMethodsAtCompileTime.adoc
@@ -17,6 +17,8 @@ specific language governing permissions and limitations
 under the License.
 ////
 
+= Adding Methods at Compile Time
+
 Grails makes it easy to add new traits to existing artefact types from a plugin. For example say you wanted to add methods for manipulating dates to controllers. This can be done by defining a trait in `src/main/groovy`:
 
 [source,groovy]
@@ -56,7 +58,7 @@ class ControllerTraitInjector implements TraitInjector {
 
 The above `TraitInjector` will add the `SomeTrait` to all controllers. The `getArtefactTypes` method defines the types of artefacts that the trait should be applied to.
 
-==== Applying traits conditionally
+== Applying traits conditionally
 A `TraitInjector` implementation can also implement the link:{api}grails/compiler/ast/SupportsClassNode.html[SupportsClassNode] interface to apply traits to only those artefacts which satisfy a custom requirement.
 For example, if a trait should only be applied if the target artefact class has a specific annotation, it can be done as below