Hi, On Fri, Oct 16, 2015 at 3:35 PM, remm [via Tomcat] <ml-node+s10n5040855...@n6.nabble.com> wrote: > I still think it is far preferable at the moment to implement 4 or 5 > proprietary auth "modules"
Well, the higher level functionality does not necessarily mean that JSR 375 is going to provide standard authentication modules that build on top of JASPIC (although this was mentioned at some point). It's for now more like introducing convenience APIs so users can more easily create their own custom modules. > that will behave predictably than try to use > this standard API that is far more complex and has behavior differences on > each server. Historically very little code has indeed been 100% portable between implementations of various APIs. Be it JPA, CDI, or even Servlet. That said, proprietary implementations of FORM may not all behave in exactly the same way either. They should, but I remember having seen small differences in the past where it concerns forwards, includes and redirects. So while I generally agree that there can be behavioral differences between each server, I'm not really sure if using the standard API vs proprietary API will make a huge difference there. Also, JASPIC is not a terribly complex API. Tedious for some things maybe, and low level and abstract, but it's rather small really and not overly complex (IMHO). > Of course it would be better if this was not the case. Of course, so another ongoing business is testing the implementations of all vendors and reporting behavioral differences and spec violations to them. I've added many of those to a series of tests here: https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic Some of those are likely to be fed back into the official TCK (which for EE 7 is really small, unfortunately). Kind regards, Arjan Tijms -- View this message in context: http://tomcat.10.x6.nabble.com/Consider-support-for-the-Servlet-profile-of-JSR-196-JASPIC-in-Tomcat-7-0-x-tp4993387p5040856.html Sent from the Tomcat - Dev mailing list archive at Nabble.com.
