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.annotations.cdi.
> CacheRemoveAllInterceptor</
> > > class>
> > > <class>org.jsr107.ri.annotations.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
> > >>> >> >>>
> > >>> >> >>
> > >>> >> >>
> > >>> >> >
> > >>> >>
> > >>> >
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>
