ENH: Enable ServiceConfig to use alternate ClassLoader - was ServiceConfig add setClassloader api

[icode]

My framework change classloader load in project class, but ServiceConfig not use my classloader because is not in project, it's in jar. So, i use config ebean.currentUserProvider get user throw class can not case exception.

[rbygrave]

If you go serverConfig.setClassLoader(...) why not go serverConfig.setCurrentUserProvider(...) ?

This does not make sense to me.

[icode]

serverConfig.setClassLoader(...) can set in framework, get from currentThread

[rbygrave]

Nope, still not clear. "get from currentThread" ... what?

Please put some effort into trying to give a meaningful explanation of the
change you desire and how it will be used.

On 3 December 2015 at 21:53, icode notifications@github.com wrote:

serverConfig.setClassLoader(...) can set in framework, get from
currentThread

—
Reply to this email directly or view it on GitHub
#476 (comment)
.

[icode]

In my framework not my app call serverConfig.setClassLoader(Thread.currentThread().getContextClassLoader())

[rbygrave]

Right.

So no I'm not going to add serverConfig.setClassLoader(...) .... (at least
not yet) because that is not the underlying problem.

On 3 December 2015 at 22:03, icode notifications@github.com wrote:

In my framework not my app call
serverConfig.setClassLoader(Thread.currentThread().getContextClassLoader())

—
Reply to this email directly or view it on GitHub
#476 (comment)
.

[icode]

Now , in my framework can not configure ebean from config file, like play1, change classloader in dev model, so ebean ClassUtils,newInstance get a error class

[rbygrave]

I understand. It is just that your proposed solution
(serverConfig.setClassLoader(...)) is not a good solution, a better
solution exists.

On 3 December 2015 at 22:15, icode notifications@github.com wrote:

Now , in my framework can not configure ebean from config file, like
play1, change classloader in dev model, so ebean ClassUtils,newInstance
get a error class

—
Reply to this email directly or view it on GitHub
#476 (comment)
.

[rbygrave]

Right so this issue needs a "Reboot" taking it back to the original problem.

Original Problem:

A ClassNotFoundException can occur when the "current class loader" is not the correct classLoader to use when creating instances of CurrentUserProvider / NamingConvention etc.
ServerConfig.createInstance(...) uses ClassUtil.newInstance(...) uses the current classLoader and there is not sufficient flexibility to use other classLoaders or mechanisms.

Potential Fixes / Changes:

• Make ServerConfig.createInstance(...) method protected such that it can be overwritten.
• Change the current default implementation in ClassUtil / ServerConfig.createInstance(...) such that it checks for a uses Thread.currentThread().getContextClassLoader()
• Extract an interface that "provides" instances (for example, that uses a Dependency injection context to provide instances).

Currently I see the suggestion of setting a classLoader on ServerConfig is an option but not the best solution in terms of providing the most flexibility. The start will be to implement the first 2 fixes / changes and then review.

[icode]

Yeah, you are right. I just to describe the problem. My English is not good, so I can only say so.

[rbygrave]

No problem. I have pushed 2 commits that make some methods protected and will use the context classLoader. If you can build from master you can give it a try.

I'm going to continue to look into the code more with a view to do a bit of cleanup and refactoring.

[rbygrave]

The last commit there refactored the internals and puts ClassLoadConfig on ServerConfig. The ClassLoadConfig has most of the classLoader specific functions including detecting types to support (Joda, Java time, Jackson etc) and creating new instances.

Out of the box ClassLoadConfig will try to use the current context classLoader and then fallback to the caller one. In addition it can be created with an explicit classLoader to use.

So I think this does what we need it to do. Potentially it could be converted into an interface in time but it might be sufficient as is (with the ability to override methods as desired).