Improve Rocker.template() for more complex classloading environments

[ldaley]

This method effectively loads templates via: https://github.com/alkemist/rocker/blob/69881f8863d2f3adcebeea6a308b326b588e5f87/runtime/src/main/java/com/fizzed/rocker/runtime/DefaultRockerBootstrap.java#L99-L99

This assumes that the classloader that loaded the Rocker runtime can see the target class.

Two (non mutually exclusive) potential options:

1. Change DefaultRockerBootstrap.model() to use Thread.currentThread().getContextClassLoader()
2. Add a Rocker.template() variant that takes a classloader

I think it probably makes sense to do both. In most environments where classloading is complex, the context classloader is set to something with good general visibility. Option (2) is potentially useful for even more complex environments. I'd probably be tempted to just do (1) though, and see if anyone ever needs (2).

[jjlauer]

You've submitted a couple classloader PRs, but perhaps it'd be good to try and create unit tests to verify all this. Running under maven, tomcat, gradle, etc. introduce all sorts of interesting classloader issues and it'd be good to have some coverage of what you're attempting to solve. I'm supportive of your effort to let you passthru the classloader, but I'd love your help making sure we don't regress in future versions.

[ldaley]

If you can give some guidance about how the testing works for this project, I'll gladly contribute tests. I could quite work it out on my own.

Just to be clear, there's no PR for this one. The change is debatable, so I wanted to discuss first.

[jjlauer]

Unit tests for runtime classes are all on runtime/src/test/java. Any changes affecting a classloader for those classes in that module would go in there.

Unit/integration tests that target Java 6+ compatibility all go in java6tests/src/test/java. I'd foresee some of your classloading changes needing to be tested in here.

Unit/integration tests that target Java 8+ compatibility all go in java8tests/src/test/java. I doubt any classloader tests would need to go in there.

Testing classloaders is complicated as many of the issues only seem triggered in the environment the project runs in. So we'd need to figure out a good way of mocking up what those look like and then confirming the various parts of the project work under that type of classloader.

[ssijak]

I experience the same problem. Because Rocker uses its own classloaders, they cant see .class files in Play Framework 1.x (I guess 2.x is the same) project. Because Play messes with classpaths and has dev and prod environments where in dev it autocompiles and reloads stuff in memory, and in prod it will precompile, we must use Play.classLoader to load the classes.

[jjlauer]

Hi @ssijak - when rocker's hot reloading feature is turned off (as it should be in prod) - the only special classloader used is to load up the byte arrays of static template content. Even if Play uses its own classloader, I wouldn't think that would conflict. So to be clear -- are you having issues in dev or prod? If its just dev -- have you turned off hot reloading to see if that works?