[MAGNOLIA-3756] ClasspathResourcesUtil.findResources doesn't work with the classloader provided in a Grails environment Created: 10/Jul/11  Updated: 04/Nov/15  Resolved: 04/Nov/15

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 4.4.3
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Kimmo Björnsson Assignee: Philipp Bärfuss
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

I'm involved in a project convinced to get Magnolia running in Grails.

We have an issue that Magnolia is not finding all resources it should when running in development mode. It is because it is a different classloader provided by Grails for the environment in that case.

ClasspathResourcesUtil.findResources does not find all resources it should with that particular classloader.

Grails wraps a URLClassLoader in an own 'ParentDelegatingClassLoader' which tricks Magnolia into that it isn't an URLClassLoader and it tries to find the resources in the wrong way.

Working on a patch for Magnolia to fix this.



 Comments   
Comment by Kimmo Björnsson [ 10/Jul/11 ]

At the moment I solved it by copying all dependencies to WEB-INF/lib in the grails build-process. There are other possible solutions involving grails only. But still, the classpath-scanning could be better I think.

Snippet

    /* copy deps to lib in dev too since magnolia reads easier there */
    defaultWarDependencies.curry(ant)
    def libDir = "${basedir}/web-app/WEB-INF/lib"
    ant.mkdir(dir:libDir)
    ant.copy(todir:libDir, defaultWarDependencies)
Comment by Tobias Mattsson [ 15/Jul/11 ]

It's interesting to see how Spring does classpath scanning with this classloader. The assumption is that iterating everything on the classpath is not going to work since classloaders dont allow you to ask for empty string, so they ask for the first known part and iterate what they get back.

Given a pattern like /META-INF/magnolia/*.xml it will do:
ClassLoader.getResources("/META-INF/magnolia/")
get back a list of URLs, then it iterates those potentially scanning through jars.

Source is here:
https://fisheye.springsource.org/browse/spring-framework/trunk/org.springframework.core/src/main/java/org/springframework/core/io/support/PathMatchingResourcePatternResolver.java?hb=true

Comment by Michael Mühlebach [ 04/Nov/15 ]

Given the thousands of other issues we have open that are more highly requested, we won't be able to address this issue in the foreseeable future. Instead we will focus on issues with a higher impact, and more votes.
Thanks for taking the time to raise this issue. As you are no doubt aware this issue has been on our backlog for some time now with very little movement.
I'm going to close this to set expectations so the issue doesn't stay open for years with few updates. If the issue is still relevant please feel free to reopen it or create a new issue.

Generated at Mon Feb 12 03:49:22 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.