[cdi-dev] JSF 2.3 and specifying alternatives for build-in producers

arjan tijms arjan.tijms at gmail.com
Fri Nov 7 08:04:59 EST 2014


Hi,

On Fri, Nov 7, 2014 at 12:59 PM, Jozef Hartinger <jharting at redhat.com> wrote:
> Yes, the @Alternative is globally enabled and will be injected everywhere
> from where the defining class is visible. That should cover your case. You
> may be observing an integration bug? What is the container?

The container is WildFly 8.1.0 in this test case. The exact situation
is a BeanValidation contraint validator, being injected with said
request:

@SupportedValidationTarget(PARAMETERS)
public class RolesAllowedValidator implements
ConstraintValidator<RolesAllowed, Object[]> {

    private String[] roles;

    @Inject
    private HttpServletRequest request; // will be produced by CDI's
build-in Bean

    @EJB
    private EJBSecurityBean securityBean;

    // [more code]
}

The above code is jar'ed up and put in the WEB-INF/lib folder of the
mentioned project, where a method from a JAX-RS method is annotated
with the corresponding bean validation annotation:

@Path("/someroot")
public class SomeEndpoint {

    @Inject
    private HttpServletRequest request; // will be produced by
alternative producer

    @GET
    @Path("/somePath")
    @RolesAllowed({"foo", "bar"}) // triggers RolesAllowedValidator to be called
    public Foo method() { ...}
}

I understand there's a lot of different cross-spec integration going
on here. I'll next try to create another test that just uses CDI and
see what happens there.

Thanks for all your help!

Kind regards,
Arjan




>
>>
>> Kind regards,
>> Arjan
>
>


More information about the cdi-dev mailing list