Do you plan to change the name of "bootstrap" to something like
"javaee-security-examples" eventually?
So far it only contains examples, thus there seems nothing wrong with the
name "examples" for the repo.
WDYT?
Greetings to JavaLand. Will have fun at codemotion in Rome at the end of
this week (despite flying with Germanwings shortly after one of them
crashed, hopefully nobody from Spain was on that plane to JavaLand, after
all Düsseldorf and Cologne airport are both closest to it?;-O)
Werner
On Tue, Mar 24, 2015 at 4:00 PM, David Blevins <dblevins_at_tomitribe.com>
wrote:
> 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
>
>