Bad assumption that the same classloader that loaded rocker loaded the templates. about rocker HOT 5 CLOSED

@alkemist I suppose there may be an issue, but it's potentially not as easy of a solution as you proposed when you take the two flavors of hot reloading into account. Can you elaborate on why you dug into this in the first place and if so can you produce a unit test that fails? I'd be happy to help you get this addressed, but I'd need to understand the problem a bit more and definitely would like to prevent a regression down the road with a test case that can verify it.

from rocker.

I hit this when trying to use Gradle continuous build with Rocker and Ratpack. When running in that scenario, classes that may change (e.g. template class) are loaded in a child loader of a loader of the stable classes (e.g. Rocker impl).

This change should be safe as the loader in question is used to reflectively load an inner of the actual template. Therefore, using the loader that loaded the template makes sense.

from rocker.

I'll need to dig into this further to see what impact this has, but all your additional formatting changes makes it difficult to see exactly what you changed. If you could eliminate all your formatting changes (e.g. reversion to wildcard java imports, chopping newlines w/ spaces, etc.) and only submit PRs with actual lines of code that changed, I'd be happy to review this again.

from rocker.

Updated the PR with the minimal change.

from rocker.

I can't see how this would affect hot reloading as that uses a different impl of RockerBootstrap and supplies an entirely different loader to this method.

from rocker.