[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