Yes, this flight crash is really sad.
I think it was meant to gather some real uses cases we could work on.
So examples or javaee-security-examples works for me as well.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Tue, 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
>>
>>
>