Was primarily going for a URL that will fit on a slide.
Was going to add all the URLs I saw in Alex's "hello" email to Darran. They really didn't fit and then I thought, wait what am I doing, people should really only ever need *one* url. They can get all the other URLs from the first URL.
If we show them five URLs, no idea which if any they'll write down. Further attempts to simplify.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
310-633-3852
On Mar 24, 2015, at 4:24 PM, Werner Keil <werner.keil_at_gmail.com> wrote:
> 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
>
>