On 3/27/15 5:56 PM, arjan tijms wrote:
> Hi,
>
> On Fri, Mar 27, 2015 at 9:37 PM, Ron Monzillo <ron.monzillo_at_oracle.com
> <mailto: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.
I think I get it, and agree that it would help by applying a simpler,
common pattern.
that said, can we be sure that the CDI environment, or at least its Bean
Manager will
be functional at the time the policy provider needs to access the role
mapping?
Fwiw, in JACC, there may be some complex ordering problems wrt to CDI
initialization
and Policy Configuration. Policy Configuration needs to be done before
application initialization
is complete, but in Servlet things can be done during in the Servlet
Context Initializers that can
require that the PolicyConfigure be redone; Policy Configuration needs
access to the role mapping;
which may become dependent on CDI being initialized. Maybe that all
works, I'm not sure.
Ron
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
> Ron
>
>