where queries do not behave as expected in GSP pages when deployed to Tomcat
- Dominant language
- Groovy
- Stars
- 2.9k
- Forks
- 975
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 92
Description
DISCLOSURE: I'm aware this is a very bad practice in general. However, it's not unsupported behavior and it does work in development mode. Its a bad practice but there's nothing to indicate that it can't be done. **If this is to be marked as `wontfix`, then I think we need to officially deprecate entirely the support for importing domain classes into GSPs.**
### Task List
- [x] Steps to reproduce provided
- [ ] Stacktrace (if present) provided
- [x] Example that reproduces the problem uploaded to Github
- [x] Full description of the issue provided (see below)
### Steps to Reproduce
1. In a GSP page, use a page import to bring in a domain class
2. Execute a `where` or `findAll` query in the GSP (e.g., in a `` tag)
3. Deploy application to Tomcat
### Expected Behaviour
The query should return the expected results
### Actual Behaviour
The query returns all instances of the domain class.
### Environment Information
- **Operating System**: macOS
- **Grails Version:** 3.3.2
- **JDK Version:** 1.8
- **Container Version (If Applicable):** 8
### Example Application
- https://github.com/ZacharyKlein/gsp-query-issue
Contributor guide
Research direction
Start with the linked gsp-query-issue example and reproduce the behavior using a GSP page import with a where or findAll query inside a g:each tag. Deploy it to Tomcat with Grails 3.3.2 and compare the result with development mode. Done means the query returns the expected results rather than all instances of the domain class.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- groovy
- Domain
- backend, web-dev
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100