CDI Interceptors and Jersey JAX/RS - jersey

Question

Using CDI API and Weld 3.0.x as the impl.
I have a simple CDI managed bean/#Named that has a method marked to be intercepted. The interceptor is a simple logging like interceptor. This all just works fine and as expected in a 'container' (like a jboss or wildfly); it also works in a Java SE program (booting CDI via SeContainerInitializer, etc).
Now using the SAME exact managed bean and interceptor, BUT the injection point of the managed bean is in a very simple JAX/RS controller (Jersey Runtime 2.27 with jersey-cdi2-se); the interceptor doesn't fire.
In this environment, the injection resolves fine, as do most other simple cdi things, like producers and post constructs, observes, etc. The rest end-point method can invoke the injectable's methods, but the interceptor will not fire.
There is no servlet or EE container in play; just Jersey and CDI/Weld -- so it is much like JavaSE case - nothing is booting a jetty/grizzly or other simple bootable HTTP container thing.
A bit more backstory:
Basically, I have a vanilla CDI BDU/JAR with some #Nameds in it; some of which have some interceptor annotations. The DBU doesn't contain an impl for the Interceptor annotations. I want to be able include the BDU in few different projects while allowing the host project to provide a specific implementation of interceptors (or omit it) that makes the most sense for the project.
This strategy works OK for host projects that target an EE container or JavaSE. Now I have this odd JavaSE/JAX-RS/Jersey mashup; everything but the interceptor works. It is like there is some interference in the jersey-cdi2-se stuff (or somewhere); or maybe some 'switch' that needs to be thrown. Weld bootstrap logging suggests that interceptor is in play.
Is there something special or other trick to getting CDI interceptors to work along side JAX-RS/Jersey?
This odd SE/jax-rs mashup is really just using AWS servless java container -- so the "http container" is provided by AWS API Gateway and proxied lambda.
(NOTE: I am aware it maybe questionable to use some/all/any of the above techs in a FAAS/Lambda environment. I will tackle the 'should I do this' just after I finish answering the 'can I do this'.)
EDIT & Update:
Is the interceptor enabled? Yes as far as I can tell, it is. I've scraped the following bits out of log (after turning on a bit of WELD logging):
[main] DEBUG org.jboss.weld.Bootstrap - WELD-000105: Enabled interceptor types for Weld BeanManager for /var/task [bean count=5]:
- class org.jboss.weld.contexts.activator.ActivateRequestContextInterceptor,
- class org.jboss.weld.contexts.activator.CdiRequestContextActivatorInterceptor,
- class org.jboss.weld.environment.se.contexts.activators.ActivateThreadScopeInterceptor,
- class com.pin.faas.MyTransactionalInterceptor
.....
[main] DEBUG org.jboss.weld.Bootstrap - WELD-000107: Interceptor: Interceptor [class com.pin.faas.MyTransactionalInterceptor intercepts #MyTransactional
As for some bits of code:
The interceptor binding:
package com.pin.api.annotation;
import java.lang.annotation.*;
import static java.lang.annotation.ElementType.METHOD;
import static java.lang.annotation.ElementType.TYPE;
import static java.lang.annotation.RetentionPolicy.RUNTIME;
import javax.interceptor.InterceptorBinding;
#Inherited
#InterceptorBinding
#Target({ TYPE, METHOD })
#Retention(RUNTIME)
public #interface MyTransactional
{
}
The interceptor impl:
package com.pin.faas;
import java.util.logging.Logger;
import javax.interceptor.*;
import com.pin.api.annotation.MyTransactional;
#Interceptor
#MyTransactional
public class MyTransactionalInterceptor
{
private static final Logger LOGGER = Logger.getLogger("DateServices");
public MyTransactionalInterceptor()
{
LOGGER.info("TransactionalInterceptor constructed");
}
#AroundInvoke
public Object handleTransactionBoudary(InvocationContext context)
throws Exception
{
LOGGER.info("handleTransactionBoudary called!");
return context.proceed();
}
}
The CDI managed bean that has an interceptor marker:
package com.pin.services.impl.businesslogic;
import com.pin.api.DatesService;
import com.pin.api.businesslogic.validations.BadCodeException;
import javax.inject.Inject;
import javax.enterprise.context.RequestScoped;
import javax.inject.Named;
import com.pin.api.annotation.MyTransactional;
#Named
#RequestScoped
public class DatesServiceImpl implements DatesService
{
#Inject
private SomeDao dao;
#Override
#MyTransactional
public String insertRecordIntoXferLog(Integer exceptionCode)
throws BadCodeException
{
dao.insertABrnch();
if(exceptionCode !=null && -1 == exceptionCode)
{
throw new BadCodeException("exception trigger value happenend, tossing an exception and expecting a rollback");
}
return("inserted");
}
}
Finally the JAX-RS controller injects a service:
package com.pin.api.rest;
import javax.enterprise.context.RequestScoped;
import javax.ws.rs.*;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.Response;
import java.util.logging.Logger;
import javax.inject.Inject;
import com.pin.api.DatesService;
import com.pin.api.businesslogic.validations.BadCodeException;
import java.util.logging.Level;
#Path("/tx")
#RequestScoped
public class TxTestController
{
private static final Logger LOGGER = Logger.getLogger("DateServices");
#Inject
private DatesService service;
#GET
#Produces(MediaType.APPLICATION_JSON)
public Response testAtTransactional(#QueryParam("c") Integer code)
{
Integer val = 1;
LOGGER.info("testAtTransactional invoked");
if(null == code)
{
LOGGER.info("testAtTransactional DID NOT get a code value, assuming value = " + val);
}
else
{
val = code;
LOGGER.info("testAtTransactional DID get a code value = " + val);
}
String result = "called service.insertRecordIntoXferLog(" + val + ")";
try
{
service.insertRecordIntoXferLog(val);
}
catch(BadCodeException bce)
{
result = bce.getMessage();
}
catch(Exception other)
{
result = other.getMessage();
LOGGER.log(Level.SEVERE,"ERROR",other);
}
return Response.status(200).entity(result).build();
}
}
UPDATES
As per some comments I added an #Priority annotation. That didn't change anything. I also adjusted the packaging in a variety of ways in case there was some issue with BDU/Jar loading and CDI bean initialization; these packaging changes made no difference.
I think there is interference with JAX-RS CDI2-SE and interceptors. Looking at how jax-rs-cdi2-se boots a CDI container, it does NOT do anything for interceptors. Maybe it shouldn't need too, as the interceptor is in beans.xml. However in a standalone SE CDI2 sample (no jax-rs - just a console app), I found I had to explicitly enable the interceptor via initializer.enableInterceptors() before the interceptor would work. Explicitly enabling interceptors was needed even with the beans.xml interceptor activation. Maybe this is more of a JAX-RS issue or a Weld issue?