can you update your test to remove @InterceptorBinding? and check if it works?
javax.cache.annotation.CacheResult is standard so I don't want to extend it to have the @InterceptorBinding.....if this is really the problem. On Fri, Apr 20, 2018 at 1:11 PM, Luís Alves <[email protected]> wrote: > @Retention(RUNTIME) > @Target({ TYPE, METHOD }) > // @InterceptorBinding > public @interface CustomInterceptor > { > } > > I suspect is this @InterceptorBinding....but not 100% sure....what is the > purpose of that? > > On Fri, Apr 20, 2018 at 1:06 PM, Luís Alves <[email protected]> wrote: > >> don't you want to rewrite your tests with the @CacheResult interceptor ;) >> ? to see if it works? >> >> On Fri, Apr 20, 2018 at 12:57 PM, Thomas Andraschko < >> [email protected]> wrote: >> >>> No idea, debug if the interceptor is really called ;) >>> >>> 2018-04-20 13:56 GMT+02:00 Luís Alves <[email protected]>: >>> >>> > moved the @CustomInterceptor declaration of the interceptor for the >>> web app >>> > beans.xml and now it gets called....SO it should work for the cache as >>> > well. Any hint? >>> > >>> > On Fri, Apr 20, 2018 at 12:43 PM, Luís Alves <[email protected]> >>> > wrote: >>> > >>> > > So I've created a custom one (in fact is a "copy" of yours that logs >>> a >>> > > line): >>> > > >>> > > @Interceptor >>> > > @CustomInterceptor >>> > > public class CustomInterceptorImpl implements Serializable >>> > > { >>> > > >>> > > private static final long serialVersionUID = >>> 7327752605570037403L; >>> > > >>> > > @Inject >>> > > private Logger logger; >>> > > >>> > > @AroundInvoke >>> > > public Object interceptIt(InvocationContext invocationContext) >>> throws >>> > > Exception >>> > > { >>> > > logger.info("yay :) CustomInterceptorImpl was called"); >>> > > return invocationContext.proceed(); >>> > > } >>> > > } >>> > > >>> > > registered on the beans.xml (for service and repo layers): >>> > > >>> > > <?xml version="1.0" encoding="UTF-8"?> >>> > > <beans xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi=" >>> > > http://www.w3.org/2001/XMLSchema-instance" >>> > > xsi:schemaLocation="http://java.sun.com/xml/ns/javaee >>> > > http://java.sun.com/xml/ns/javaee/beans_1_0.xsd"> >>> > > >>> > > <interceptors> >>> > > <class>org.jsr107.ri.annotations.cdi. >>> > > CacheResultInterceptor</class> >>> > > ... >>> > > <class>eu.gls.ddtm.config.CustomInterceptorImpl</class> >>> > > </interceptors> >>> > > >>> > > </beans> >>> > > >>> > > It's called on the service layer but not on the @Repository :( >>> > > >>> > > ...I'm using Wildfly 10 (CDI 1.x)... >>> > > >>> > > >>> > > >>> > > On Fri, Apr 20, 2018 at 11:50 AM, Thomas Andraschko < >>> > > [email protected]> wrote: >>> > > >>> > >> You can try with a custom interceptor and check if it's invoked? >>> > >> >>> > >> I assume you don't use weld-2.0.0.Final or weld-2.0.0.SP1? We have a >>> > >> exclusion for this in the unit test as there is something broken, >>> as you >>> > >> can check in the link i posted before. >>> > >> Otherwise, it would be great if you could provide a unittest for the >>> > data >>> > >> module. >>> > >> I don't have time to prepare it by myself. >>> > >> >>> > >> >>> > >> 2018-04-20 12:40 GMT+02:00 Luís Alves <[email protected]>: >>> > >> >>> > >> > So far no success...@CacheResult on >>> > >> > >>> > >> > @ApplicationScoped >>> > >> > @Repository >>> > >> > public abstract class SomeRepository >>> > >> > >>> > >> > doesn't seem to work :S not sure what I'm doing wrong. >>> > >> > >>> > >> > >>> > >> > On Fri, Apr 20, 2018 at 11:03 AM, Luís Alves < >>> [email protected]> >>> > >> > wrote: >>> > >> > >>> > >> > > I ditched the CustomBaseRepository for now...but still can't >>> get the >>> > >> > cache >>> > >> > > interceptor to work...here is my beans.xml: >>> > >> > > >>> > >> > > <?xml version="1.0" encoding="UTF-8"?> >>> > >> > > <beans xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi=" >>> > >> > > http://www.w3.org/2001/XMLSchema-instance" >>> > >> > > xsi:schemaLocation="http://java.sun.com/xml/ns/javaee >>> > >> > > http://java.sun.com/xml/ns/javaee/beans_1_0.xsd"> >>> > >> > > >>> > >> > > <interceptors> >>> > >> > > <class>org.jsr107.ri.annotations.cdi. >>> > >> > > CacheResultInterceptor</class> >>> > >> > > <class>org.jsr107.ri.annotations.cdi. >>> > >> > CacheRemoveEntryInterceptor</ >>> > >> > > class> >>> > >> > > <class>org.jsr107.ri.annotati >>> ons.cdi.CacheRemoveAllIntercep >>> > >> tor</ >>> > >> > > class> >>> > >> > > <class>org.jsr107.ri.annotati >>> ons.cdi.CachePutInterceptor</ >>> > >> class> >>> > >> > > </interceptors> >>> > >> > > >>> > >> > > </beans> >>> > >> > > >>> > >> > > >>> > >> > > LA >>> > >> > > >>> > >> > > On Fri, Apr 20, 2018 at 10:45 AM, Luís Alves < >>> [email protected] >>> > > >>> > >> > > wrote: >>> > >> > > >>> > >> > >> Thanks Thomas, >>> > >> > >> >>> > >> > >> if I understood correctly if they are on the bean.xml they >>> should >>> > >> works >>> > >> > >> :)...only annotated one don't work. >>> > >> > >> >>> > >> > >> I'm now (not sure why I didn't had it before) getting: >>> > >> > >> org.apache.deltaspike.data.impl.RepositoryDefinitionException: >>> > >> > >> Repository creation for class class CustomBaseRepository >>> failed. Is >>> > >> it >>> > >> > >> associated with a valid Entity? I got this base class for some >>> > >> > repositories >>> > >> > >> for some similar behavior: >>> > >> > >> >>> > >> > >> public abstract class CustomBaseRepository <E extends >>> > >> DomainObject<K>, K >>> > >> > >> extends Serializable> >>> > >> > >> extends AbstractEntityRepository<E, K> >>> > >> > >> { >>> > >> > >> >>> > >> > >> not sure if this inheritance is supposed to work with the >>> Repos... >>> > >> > >> >>> > >> > >> >>> > >> > >> >>> > >> > >> On Fri, Apr 20, 2018 at 10:23 AM, Thomas Andraschko < >>> > >> > >> [email protected]> wrote: >>> > >> > >> >>> > >> > >>> See: >>> > >> > >>> https://github.com/apache/deltaspike/tree/master/deltaspike/ >>> > >> > >>> modules/partial-bean/impl/src/test/java/org/apache/deltaspik >>> > >> > >>> e/test/core/api/partialbean/uc008 >>> > >> > >>> >>> > >> > >>> 2018-04-20 11:22 GMT+02:00 Thomas Andraschko < >>> > >> > >>> [email protected]>: >>> > >> > >>> >>> > >> > >>> > Interceptors in generell should be supported but only via >>> custom >>> > >> > >>> binding - >>> > >> > >>> > not via "@Interceptors, @Intercepted and @Decorator" >>> > >> > >>> > >>> > >> > >>> > 2018-04-20 11:21 GMT+02:00 Luís Alves < >>> [email protected]>: >>> > >> > >>> > >>> > >> > >>> >> So far I found that @Repository is actually a >>> > @PartialBeanBinding >>> > >> > and >>> > >> > >>> I >>> > >> > >>> >> found: "Currently CDI Interceptors applied via >>> @Interceptors, >>> > >> > >>> @Intercepted >>> > >> > >>> >> and @Decorator are not supported by our proxies! "...does >>> it >>> > >> means >>> > >> > >>> that >>> > >> > >>> >> I'm >>> > >> > >>> >> screwed ;)? >>> > >> > >>> >> >>> > >> > >>> >> LA >>> > >> > >>> >> >>> > >> > >>> >> On Fri, Apr 20, 2018 at 10:11 AM, Luís Alves < >>> > >> [email protected] >>> > >> > > >>> > >> > >>> >> wrote: >>> > >> > >>> >> >>> > >> > >>> >> > even with @ApplicationScoped the interceptor is not >>> working >>> > :( >>> > >> > can't >>> > >> > >>> >> > figure out why...can't @Repository methods be >>> intercepted? >>> > >> > >>> >> > >>> > >> > >>> >> > >>> > >> > >>> >> > >>> > >> > >>> >> > On Fri, Apr 20, 2018 at 9:53 AM, Luís Alves < >>> > >> > [email protected]> >>> > >> > >>> >> wrote: >>> > >> > >>> >> > >>> > >> > >>> >> >> since it's proxied...it should be OK...I guess it's like >>> > >> > Spring's >>> > >> > >>> >> >> repositories. >>> > >> > >>> >> >> >>> > >> > >>> >> >> On Fri, Apr 20, 2018 at 9:44 AM, Luís Alves < >>> > >> > [email protected] >>> > >> > >>> > >>> > >> > >>> >> >> wrote: >>> > >> > >>> >> >> >>> > >> > >>> >> >>> Hi, >>> > >> > >>> >> >>> >>> > >> > >>> >> >>> @Repository is @Dependent scoped...and seems that >>> > @Dependent >>> > >> > >>> don't run >>> > >> > >>> >> >>> interceptors, so @CacheResult(cacheName = "my-cache") >>> > >> annotation >>> > >> > >>> isn't >>> > >> > >>> >> >>> working :( >>> > >> > >>> >> >>> I remember that some one proposed that @Repository >>> > >> could/should >>> > >> > be >>> > >> > >>> >> >>> @ApplicationScoped...if I change them do I have to >>> worry >>> > >> with >>> > >> > >>> >> anything? My >>> > >> > >>> >> >>> EntityManager producer is the following: >>> > >> > >>> >> >>> >>> > >> > >>> >> >>> @Produces >>> > >> > >>> >> >>> @RequestScoped >>> > >> > >>> >> >>> public EntityManager get() >>> > >> > >>> >> >>> { >>> > >> > >>> >> >>> return entityManager; >>> > >> > >>> >> >>> } >>> > >> > >>> >> >>> >>> > >> > >>> >> >>> I suppose I'll have a different EM for each HTTP >>> request / >>> > >> MDB >>> > >> > >>> >> >>> onMessage() / @Scheduled(cronExpression ="....")...am I >>> > >> correct? >>> > >> > >>> >> >>> >>> > >> > >>> >> >>> regards, >>> > >> > >>> >> >>> LA >>> > >> > >>> >> >>> >>> > >> > >>> >> >> >>> > >> > >>> >> >> >>> > >> > >>> >> > >>> > >> > >>> >> >>> > >> > >>> > >>> > >> > >>> > >>> > >> > >>> >>> > >> > >> >>> > >> > >> >>> > >> > > >>> > >> > >>> > >> >>> > > >>> > > >>> > >>> >> >> >
