Hi,
I'm probably missing something otherwise this makes no sense...
I've been trying to use a custom login service for my webapp for a while already without success...
After lots of tries/readings I figured out the following:
1. Custom Login Service can be registered from either context deployer xml (preferred) or jetty-web.xml. I understood that the deployer is preferred because it is read first rather than the jetty-web which is read last... (though I don't understand the real impact in this context)
2. The custom Login Service class must be deployed as part of the server's classpath i.e. {jetty.base}/lib/etc. If deployed at {webapp}/WEB-INF/lib or {extra.classpath} (when extra.classpath is configured in the context deployer xml), it will not work and a ClassDefNotFound exception will be thrown.
3. It turns out that Jetty loads the class by using a server classloader rather than a webappcontext classloader of the webapp where it was configured. This means that the customLoginService has no access to the custom logic of the specific webapp which IMHO kind of kills the entire purpose of having a custom login service.
Lastly, I'm not willing to turn parentPriority setting to true mainly because that is the opposite of the standard and thus, I want to keep my project as close to the standard as possible.
What I'm currently thinking of is moving from the proprietary solution in Jetty to the standard JAAS based solution which I believe will let me have my custom logic in the authentication phase. However, it is more cumbersome IMO than the proposed LoginService alternative...
Your feedback is welcome.
thanks,
GBa.
