On Mar 24, 2015, at 1:36 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> > I grabbed HttpServerAuthModule and just kept grabbing. Clearly, the HttpServerAuthModule class is meant to be a concrete and vendor-specific class like HttpServlet.
>
> That's not entirely correct ;) HttpServerAuthModule is completely vendor neutral. I've tested it on almost every JASPIC implementation I could get my hands on.
Sorry, that was vendor in the platform perspective. Even the javax.* classes are the responsibility of each vendor.
For example, GlassFish, JBoss and Apache (Geronimo/TomEE) all have their own javax.* classes of the JACC API. That API has a bootstrapping component inside the javax.* classes themselves that is a bit more intricate than a simple interface. All of them could work in each other's containers, but they do tend to have different performance profiles.
Anytime there is an abstract class that involves more code to be created by vendors inside the javax.* package. There will generally be performance differences and on occasion some bugs specific to certain of the javax.* classes.
Generally, the more code we force into javax.* the more those API jars are less stable and require more frequent release than the other API jars. This can be quite painful. Javamail is the worst example of that.
-David