Hi,
On Mon, Apr 10, 2017 at 9:35 PM, <ondrej.mihalyi_at_gmail.com> wrote:
> However, I'd like to ask what are the implications? What other
> dependencies would it bring to the WebProfile?
>
> E.g. the Security JSR depends on JASPIC, which is not part of Web
> Profile. From the spec EDR1: " Integration with the servlet container
> leverages JASPIC;
> the container MUST configure and invoke the HttpAuthenticationMechanism
> via JASPIC, as
> described below"
>
> It seems to me that with the new Security JSR, also JASPIC needs to be
> moved to Web Profile. Is it really necessary or can the dependency on
> JASPIC be optional?
>
JASPIC is practically indeed necessary.
Theoretically, but only theoretically, it would not be absolutely needed
and could be abstracted by a layer on top of a Servlet container's native
ability to add a custom authentication mechanism.
But that would basically run into a kind of abstraction overflow, as JASPIC
is already exactly that abstraction layer. To abstract on top of the
abstraction layer would be awkward at best. In the worst case that
abstraction layer would end up to be pretty much identical to what the
Servlet Container Profile of JASPIC is today; in other words we would have
duplicated JASPIC for no real benefit.
Additionally such abstraction would mean Servlet containers would have to
support an additional SPI, as this kind of abstraction needs native hooks.
Furthermore, the time required to specify such abstraction layer is not
there, as we pretty much have to go final with JSR 375 somewhere in the mid
of next week.
A big point is that JASPIC is likely one of the most misunderstood specs in
the entire EE landscape. It's not a big chunk of code that's implemented
independently (like say JSF or JPA implementations), but it's a set of
guidelines and a few interfaces that a Servlet container (for the Servlet
Container Profile) must implement/do.
The thing is that every Java EE 7 Servlet container (i.e. including Tomcat
and Jetty) already implements JASPIC, and that even the Servlet spec
recommends to use the JASPIC SPI for using custom authentication mechanisms
with a Servlet container. We *almost* got the Servlet EG to agree to change
this one word from something like "recommend" to "mandate", and the Servlet
spec is of course a bit lower level than the Web Profile.
> I'd appreciate to make JASPIC optional and leave it out of Web Profile,
> because it's a cumbersome API and not really needed to be exposed in
> the Web Profile.
>
It's not so much an API really, but more an SPI that standardises things
that a Servlet container already does.
As for being cumbersome, that's where the Java EE Security API comes in,
which is an higher level API aimed at application developers.
But it needs "a hook into the Servlet container", and that hook is not
there, other than via JASPIC.
It's slightly comparable with JTS sitting underneath JTA, which provides
@Transactional and the default transactional behaviour in EJB beans. Very
few to almost no people would descend into low level JTS and not even low
level (programmatic) JTA, but the CDI based @Transactional annotation and
the EJB variant are very often used and greatly appreciated.
Hope this makes it more clear ;)
Kind regards,
Arjan Tijms
>
> Ondrej
>