https://grails.org/ logo
Join Slack
Powered by
# questions
  • u
    we switched our projects over many years ago and transition was relatively painless at the time...
  • s
    I am good with that!
    ✅ 1
  • s
    Btw, remember the weekly Grails Committers meeting here at 16: if you have time 😉
    u
    • 2
    • 1
  • u
    does the (potential) donation of the IntelliJ grails plugin mean it will be available for community edition, too?
    j
    u
    • 3
    • 4
  • g
    HI, has anyone upgraded Recaptcha plugin for Grails 7, we have been using org.grails.pluginsrecaptcha3.2.0
    j
    s
    +3
    • 6
    • 9
  • m
    Cross-Domain Logic in Grails: A Missing Pattern The Problem When you need to trigger business logic across multiple domains after a domain object changes state, Grails doesn't offer a clean, native solution. The options available each come with significant trade-offs: • GORM lifecycle events (
    afterUpdate
    , etc.) are too coupled to the domain and can't easily access services. • Interceptors require duplication when you have multiple controller layers (e.g. backoffice + API). • 
    grails-events
    plugin     with async subscribers requires 
    withNewSession
    , which reads data before the original transaction commits — leading to stale/inconsistent reads. • The 
    withNewSession
    + 
    TransactionSynchronizationManager.afterCommit
    workaround works but is verbose and fragile. The recommended approach — centralising logic in a Service — works well, but only if the Service is the sole entry point for state changes. The moment a domain object changes its own state directly, there's no clean way to hook into that and trigger cross-domain logic. How Other Frameworks Handle It Laravel solves this natively with Model Observers and 
    $afterCommit = true
    on listeners, making post-commit cross-domain logic straightforward and readable. Spring Boot (without Grails) solves it with 
    @TransactionalEventListener(phase = AFTER_COMMIT)
    and 
    AbstractAggregateRoot
    , which lets the domain register events that are automatically published on 
    save()
    — clean, explicit, and transaction-aware. The Irony Grails runs on Spring Boot, so 
    @TransactionalEventListener
    is available and works well. However, 
    AbstractAggregateRoot
    doesn't compose cleanly with GORM's class hierarchy, which blocks the most elegant part of the pattern — having the domain register its own events. The workaround is to drop GORM and use Spring Data JPA directly within Grails, which gives you the full Spring pattern and eliminates 
    withNewSession
    issues — but at the cost of losing GORM's dynamic finders, scaffolding, and DSL. The Question Has Grails 7 addressed this gap natively? Is there a recommended pattern for post-commit cross-domain logic that works cleanly with GORM, without requiring manual session management or losing the Active Record conveniences? Would love to hear how others are handling this in production projects.
    j
    j
    • 3
    • 9
  • u
    Hi everyone, We are facing a strange issue with Grails 4.1.3 that only seems to happen on macOS environments. When running the command below:
    Copy code
    grails test-app SomeIntegrationSpec --integration --stacktrace
    the compilation fails during 
    :web:compileGroovy
    with several 
    unable to resolve class
    errors for existing domain classes. Stacktrace excerpt:
    Copy code
    <=========----> 76% EXECUTING [26s]
> :web:compileGroovy
startup failed:

/Users/***/Documents/project/web/grails-app/controllers/com/example/controller/accesstoken/CustomerApiAccessTokenController.groovy: 18: unable to resolve class com.example.domain.criticalaction.CriticalActionGroup
 @ line 18, column 1.
   import com.example.domain.criticalaction.CriticalActionGroup
   ^

/Users/***/Documents/project/web/grails-app/controllers/com/example/controller/backoffice/AuthorizationTokenAdminController.groovy: 6: unable to resolve class com.example.domain.criticalaction.CriticalActionGroup
 @ line 6, column 1.
   import com.example.domain.criticalaction.CriticalActionGroup
   ^

/Users/***/Documents/project/web/grails-app/controllers/com/example/controller/backoffice/childaccountconfig/ChildAccountParameterController.groovy: 11: unable to resolve class com.example.domain.criticalaction.CustomerCriticalActionConfig
 @ line 11, column 1.
   import com.example.domain.criticalaction.CustomerCriticalActionConfig
   ^

/Users/***/Documents/project/web/grails-app/controllers/com/example/controller/checkout/PixAutomaticRecurringCheckoutLimitChangeRequestController.groovy: 8: unable to resolve class com.example.domain.criticalaction.CriticalActionGroup
 @ line 8, column 1.
   import com.example.domain.criticalaction.CriticalActionGroup
   ^

/Users/***/Documents/project/web/grails-app/controllers/com/example/controller/config/CriticalActionConfigController.groovy: 11: unable to resolve class com.example.domain.criticalaction.CustomerCriticalActionConfig
 @ line 11, column 1.
   import com.example.domain.criticalaction.CustomerCriticalActionConfig
   ^

/Users/***/Documents/project/web/grails-app/controllers/com/example/controller/customerexternalauthorization/CustomerExternalAuthorizationRequestConfigController.groovy: 8: unable to resolve class com.example.domain.criticalaction.CriticalActionGroup
 @ line 8, column 1.
   import com.example.domain.criticalaction.CriticalActionGroup
   ^

/Users/***/Documents/project/web/grails-app/controllers/com/example/controller/pix/PixAddressKeyController.groovy: 6: unable to resolve class com.example.domain.criticalaction.CriticalActionGroup
 @ line 6, column 1.
   import com.example.domain.criticalaction.CriticalActionGroup
   ^

/Users/***/Documents/project/web/grails-app/controllers/com/example/controller/pix/PixAddressKeyController.groovy: 7: unable to resolve class com.example.domain.criticalaction.CustomerCriticalActionConfig
 @ line 7, column 1.
   import com.example.domain.criticalaction.CustomerCriticalActionConfig
   ^

/Users/***/Documents/project/web/grails-app/controllers/com/example/controller/pix/PixAuthorizedDeviceController.groovy: 5: unable to resolve class com.example.domain.criticalaction.CriticalActionGroup
 @ line 5, column 1.
   import com.example.domain.criticalaction.CriticalActionGroup
   ^

> Task :web:compileGroovy FAILED
18 actionable tasks: 1 executed, 17 up-to-date
<-------------> 0% WAITING
> IDLE

ternal.DefaultWorkerServer.execute(DefaultWorkerServer.java:47)
at org.gradle.workers.internal.AbstractClassLoaderWorker$1.create(AbstractClassLoaderWorker.java:46)
at org.gradle.workers.internal.AbstractClassLoaderWorker$1.create(AbstractClassLoaderWorker.java:36)
at org.gradle.internal.classloader.ClassLoaderUtils.executeInClassloader(ClassLoaderUtils.java:98)
at org.gradle.workers.internal.AbstractClassLoaderWorker.executeInClassLoader(AbstractClassLoaderWorker.java:36)
at org.gradle.workers.internal.IsolatedClassloaderWorker.execute(IsolatedClassloaderWorker.java:54)
at org.gradle.workers.internal.WorkerDaemonServer.execute(WorkerDaemonServer.java:56)
at org.gradle.process.internal.worker.request.WorkerAction.run(WorkerAction.java:118)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:182)
at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:164)
at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:412)
... 3 more
    The classes do exist in the project and everything works correctly on Linux environments. Has anyone experienced something similar?
    j
    • 2
    • 1
  • j
    I've seen complex, large gradle projects not find classes due to groovy incremental compile. The only solution was to upgrade groovy or to clean to fix this.
  • s
    Could it be something to do with the max number of open files that needs to be increased. I know that's the case on Linux.
  • u
    Hello Team, I recently migrated a multi-module application from Grails 6 to Grails 7.0.1 and am facing a MongoDB lazy-loading issue during GSP rendering. Project structure: • Main Application ◦ Module 1 (contains MongoDB domain classes such as 
    Test
    , 
    Test1
    , etc.) ◦ Module 2 (uses domain classes from Module 1) In a GSP page, I have something like: 
    test1 class is a Foreign Key(FK) in test class
    Copy code
    <g:each in="${testList}" var="test">
    <option value="${test.id}">
        ${test?.test1?.name}
    </option>
</g:each>
    After migrating to Grails 7, the page throws the following error:
    Copy code
    No datastore session found. Call Datastore.connect(..) before calling Datastore.getCurrentSession()
    Interestingly, if I access the association in the controller before rendering the GSP, or if I convert the data to DTOs/maps and pass that to the view, the page works correctly. My questions are: 1. Has datastore session handling during GSP rendering changed in Grails 7 compared to Grails 6? 2. Is there a recommended global solution for this issue instead of manually initializing associations or creating DTOs for every page? 3. Has anyone faced similar issues in multi-module Grails 7 applications using MongoDB references? Any suggestions or best practices would be greatly appreciated.
  • j
    it sounds like your OSIV config is missing
    u
    u
    +2
    • 5
    • 9
  • r
    Stopping Grails app from the command line in Emacs Returning to Grails 7/Java 25 after a couple of years away, I'm developing again. I run Grails from the command line in Ubuntu/Emacs like I've always done, using this alias alias grails="$GRAILS_HOME/bin/grails --non-interactive --plain-output" Starting the app with run-app works as expected. Stopping is another story. If I use Ctrl-C or stop-app surprise! HTML for the the login page is listed. Aside from that, the app looks like it's maybe stopped, but some process keeps running, holding on...
  • u
    Grails 8 — Data Access with GORM (guide PRs open) Sample: https://github.com/grails-guides/grails-data-access/pull/1 Prose: https://github.com/apache/grails-static-website/pull/517 I’m still learning the guide process — please point out anything I should change on the PRs.
  • r
    Grails 7: Avoiding legacy Hibernate criteria queries Developing in Grails 7 after a couple of years away. Flooded by warnings about deprecated legacy Hibernate criteria queries. So be it, but I'm working in Grails/GORM, not Hibernate. How does this deprecation reflect to the Grails/GORM level? Do I have to know how GORM is implemented? What kind of GORM queries should I use or avoid, respectively?
  • u
    Hello. GORM @Service finder fails for a belongsTo association. Is this a bug or intended? I have a domain whose only reference to a related entity is declared through belongsTo
    Copy code
    class Entity {
  String name
  static belongsTo = [other: Other]
}

class Other {
   String name
}
    And a GORM data service with a derived finder over taht association:
    Copy code
    @Service(Entity)
class EntityDataService {
   List<Entity> findAllByOther(Other other)
}
    This fails at compile time with:
    Cannot implement finder for non-existent property [other] of class [com.demo.Entity]
    A dynamic Entity.findAllByOther(other) works fine, so I'd expect t he @Service codegen to resolve it too. I am using Grails 5.2.4
    j
    u
    • 3
    • 2
  • u
    While update Facing issue and not able to identify due to which constrant issue occurring. How to resolve it? The EntityInsertAction was vetoed.. Stacktrace follows: org.springframework.orm.hibernate5.HibernateSystemException: The EntityInsertAction was vetoed.; nested exception is org.hibernate.action.internal.EntityActionVetoException: The EntityInsertAction was vetoed. at org.springframework.orm.hibernate5.SessionFactoryUtils.convertHibernateAccessException(SessionFactoryUtils.java:267) at org.grails.orm.hibernate.GrailsHibernateTemplate.doExecute(GrailsHibernateTemplate.java:305)
    j
    • 2
    • 1
  • u
    Hello, I'm in the process of upgrading from grails 6 to grails 7. We use bootJar to build the jar and it is deployed to our server in a docker container with the cmd java -jar. In grails 6 the application started up with the production as the active profile, but now it is starting up with development as the active profile. We haven't made any changes to our process so this seems odd. Is there something that changed that would cause this?
    j
    u
    • 3
    • 3
  • u
    How do you generally manage upgrading the versions of things you specify in 
    gradle.properties
    in your projects? I enabled dependabot for gradle but it apparently does not manage 
    gradle.properties
    correctly. I hacked a GitHub workflow to check Maven central for new version of Grails and make a decision based on curl/grep/tr output. I would like to have something working for other version I've specified in 
    gradle.properties
    , do you know if there is something? My AI is suggesting to move from `gradle.properties`to 
    libs.versions.toml
    but I'm unsure this is a good option.
    j
    • 2
    • 1
  • u
    @User you may be interested in this ^^
  • g
    hmans.dev/blog/chatto-is-open-source I saw this on the HN, could we use this replace slack?
    j
    • 2
    • 3
  • d
    Hi team, could you please give your best estimate when you expect Grails 8 will be officially released? I'm considering upgrade paths for a client and would like to give a ballpark quarter/year.
    j
    • 2
    • 1
  • r
    How to use micronaut declarative client into grails 7.2.0 I have prepared a configuration for use Micronaut Declarative client into grails 7.2.0 I got an error: Error creating bean with name 'example.grails.IndexController': Error creating bean with name 'mainService': Unsatisfied dependency expressed through field 'client': No qualifying bean of type 'example.grails.MainClient' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true)}...
  • u
    Hello, we are fixing failing integration tests as part of an upgrade from grails 6 to 7. We're seeing an issue where when instantiating a domain class using a named parameters constructor, the field values are not being set. Has anyone else experienced this or have any idea why this may be happening? Or have any suggestions for troubleshooting this issue?
    j
    u
    +2
    • 5
    • 10
  • u
    Hi everyone! We’re looking into how to do test impact analysis for a large Grails 4 monolith (Groovy, Gradle, Spock integration tests with Testcontainers). The goal is to make our CI smarter by running only the specs actually affected by a given diff, instead of executing the entire test suite on every PR, which is getting increasingly slow and expensive as the codebase grows. Has anyone tackled a similar challenge (Grails/Groovy or any large monolith)? What approach worked for you to reliably map code changes → impacted tests?
    j
    • 2
    • 1
  • r
    Grails 7.2.2 package/assemble fails with Snakeyaml "LoaderOptions must be provided" Developing with Grails 7.2.2/PostgreSQL 17 on Ubuntu 24.04.4 LTS worked well (although I've been away from Grails for a couple of major versions). Then came the final step, deployment the new way. gradle assemble ...
    Task :compileGroovyPages FAILED
    Exception in thread "main" java.lang.NullPointerException: LoaderOptions must be provided. at org.yaml.snakeyaml.constructor.BaseConstructor.(BaseConstructor.java:120) This leaves me completely stumped. I do use traditional GSP views (that...
  • b
    Hi team, We are getting ready to roll out the upgrade for our app from Grails 5 to Grails 7.2.2. We are doing pretty extensive load testing, and I am going through the Grails release notes, but is there anything specific that I should be aware of to ensure a smooth upgrade?
    s
    j
    • 3
    • 2
  • a
    Hi everyone, I’m not sure if this will be useful to anyone else, but I put together a small Grails example application showing how to integrate Grails with Keycloak. I created it while working through Keycloak authentication for an application I’m currently building, and I documented the setup along the way, including PostgreSQL, client roles, authorization, and email configuration. The example is here: github.com/amondel2/grails-keycloak-example If this is something that would be useful to the Grails community, I’d be interested in any feedback. Also, if there is a better place for something like this, please let me know.
    👍 1
    🙌🏻 1
    🙌 3
    m
    • 2
    • 1
  • s
    Looks good! Thanks! You should really consider creating a Grails Guide (grails.apache.org/guides)
    💯 3
    a
    • 2
    • 1
  • m
    Hello here testing Grails 8.0.0-M5 with spring security core and database migration plugins, and devtools configured. On Bootstrap phase, the applications fails to start, raising this error: java.lang.IllegalArgumentException: Not an entity: class com.example.Role Running Claude Code AI, it determined this: The IllegalArgumentException: Not an entity: class com.example.Role wasn't a problem in your Role.groovy/User.groovy/BootStrap.groovy — those are all correctly written. It's a compatibility bug between Spring Boot DevTools' restart classloader and GORM/Hibernate5 on this exact stack: Grails 8.0.0-M5 + Hibernate ORM 5.6.15 + Spring Boot 4.1.0. How I confirmed it: - Reproduced the crash reliably via bootRun against your dev MySQL. - Proved it wasn't Role-specific — swapping in User.count() first hit the identical "Not an entity" error, and it also failed from a live HTTP request long after startup completed, ruling out a boot-order race. - Isolated it to Criteria-based GORM calls specifically: Role.count()/Role.list() failed, but Role.get() and raw HQL worked — and .save() threw a field/getter reflection IllegalArgumentException, the textbook signature of the same class name being loaded by two different ClassLoaders. - Removing spring-boot-devtools from the classpath made count(), list(), and save() all work immediately (thread name also switched from restartedMain to plain main, confirming DevTools' restart classloader was the split). - Re-verified end-to-end with a clean DB: BootStrap now logs Generated admin credentials: admin / <uuid> with zero errors. What I changed: - build.gradle — commented out developmentOnly "org.springframework.boot:spring-boot-devtools" with an explanatory comment. - Everything else (BootStrap, application.groovy, domain classes) is back to exactly how you had it — my diagnostic edits (temp DiagController, debug logging, a scoped /diag security rule) were all reverted. - Cleaned up the one leftover test row I'd accidentally committed to the role table during diagnosis. Tradeoff: you lose DevTools' auto-restart/LiveReload during development until this Grails milestone/Hibernate5 combo is fixed upstream (worth watching Grails' issue tracker, since 8.0.0-M5 + Spring Boot 4 is very fresh). If LiveReload matters a lot to you, let me know — there may be workarounds worth exploring (e.g., excluding grails-app domain classes from DevTools' restart classpath), but I'd want to test that carefully rather than guess.
    👍 1
    j
    j
    • 3
    • 10
  • b
    Not a question, but wanted to flag as this just actively burned us. Hopefully this helps others avoid the hard lesson! StringBuilder saves the day again 😅
    😅 2
    👍 1
    m
    • 2
    • 2