users@jaspic-spec.java.net

Re: Update deployment model for container-side artifacts?

From: arjan tijms <arjan.tijms_at_gmail.com>
Date: Fri, 27 Mar 2015 22:56:35 +0100

Hi,

On Fri, Mar 27, 2015 at 9:37 PM, Ron Monzillo <ron.monzillo_at_oracle.com>
wrote:

> Then your portable JACC
> provider could use PolicyContext.getContext. to invoke the getContext
> method of the handler; which would
> return an implementation of a common, if not standard, principal to
> mapping interface.
>

Indeed, that may have been an even better approach ;) If I do another
iteration of the code I could sure look into that.


>
> IIRC, this technique is demonstarted in the (simple) JACC policy provider
> you referred to.
>
> If a principal-2-role interface is standardized, then someone would need
> to write and register a corresponding
> handler in each of the container implementations. If the containers were
> required to provided the handlers out of
> the box, then access to the containers principal to role mapping facility
> could be conveniently available.
>
> That was the idea, back before CDI. Now, I suspect there is an interest in
> being able to inject the appropriate
> instance of some standard role mapper interface; which could be packaged
> in the application archive.


Yes, absolutely. This is what we're doing in the JSF EG as well. Where
applicable we deprecate our own lookup mechanisms for artifacts and use CDI
instead and/or provide bridges to CDI.

The advantage is that it's less text and code in our spec, the lookup
mechanism is unified, features such as priority for overriding and
intercepting basically come for free and the artifacts can be provided by
the container or the application fairly transparently. For instance, JSF
provides a default implementation of FacesContext, but the user can provide
a custom instance via CDI. See
http://jdevelopment.nl/providing-alternatives-jsf-23s-injected-artifacts

Also note that a lower level artifact does not necessarily have to be
injectable itself to get hold of a bean that's managed by CDI. It's also
common to request such bean from the CDI BeanManager. In JSF we're doing
that e.g. here
https://github.com/javaeekickoff/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/cdi/CdiUtils.java#L71

In the case of JACC, a JACC provider itself doesn't *have* to be an
injection target if it wants the role mapper, but could use the BeanManager
programmatically to obtain it.

Kind regards,
Arjan Tijms







>
>
> Ron
>