> You understand something here. I mean *mis*understand.
Alexander Kriegisch schrieb am 25.11.2018 23:16: > Hi Eric. > > You understand something here. > > get(* model.UserAccount.accountOwner) > > is in the control flow of > > execution(* model.UserAccount.getAccountOwner(..)) > > but not the other way around. The control flow of reading the member > value starts right before it is read and ends right after it has been > read. It is a pretty much atomic operation. Whatever other methods are > called by the getter *method* are not yet or no longer within the > control flow of the member read operation. I can explain in more detail > if you provide the code of UserAccount.getAccountOwner(). > > Regards > -- > Alexander Kriegisch > https://scrum-master.de > > Eric B schrieb am 25.11.2018 19:59: >> >> >> I've tried to write a pointcut that combines a couple of different >> cflow()/cflowbelow() together, but it does not seem to work as expected. >> That is, the advise is still being executed even though one of the cflow() >> pointcuts is clearly in the stacktrace. >> >> >> My pointcut in question is: >> >> > @Pointcut("get(* model.UserAccount.accountOwner)") >> public voiduserAccountOwner(){} >> >> >> >> >> I then use the defined pointcut as: >> >> > @Before("aspectInitialized() && cflowbelow(ejbMethods()) && >> !cflowbelow(userAccountOwner()) && (newModelsWhichReferenceUserA() || >> (userAccountAccessibleMethods() ))") >> public voidpreventConstructorsForRelatedObjects(JoinPoint >> joinPoint)throwsSecurityAccessTableDataException{ >> >> > // some logic >> >> > throw new RuntimeException( "USERA tables not yet ready"); >> >> > } >> >> >> And in my stack trace in which the advice is clearly being executed (the >> GeneralException is being triggered by an exception thrown in the advice), >> I can observe the UserAccount.getAccountOwner() method being called. >> >> >> Caused by: <0|false|0.9.5-incubating> kodo.jdo.GeneralException: USERA >> tables are not yet ready >> >> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:852) >> >> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:749) >> >> at >> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.find(JDBCStoreManager.java:746) >> >> at >> org.apache.openjpa.jdbc.meta.strats.RelationFieldStrategy.load(RelationFieldStrategy.java:550) >> >> at org.apache.openjpa.jdbc.meta.FieldMapping.load(FieldMapping.java:791) >> >> at >> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:483) >> >> at >> org.apache.openjpa.kernel.DelegatingStoreManager.load(DelegatingStoreManager.java:113) >> >> at >> org.apache.openjpa.datacache.DataCacheStoreManager.load(DataCacheStoreManager.java:363) >> >> at >> org.apache.openjpa.kernel.DelegatingStoreManager.load(DelegatingStoreManager.java:113) >> >> at org.apache.openjpa.kernel.ROPStoreManager.load(ROPStoreManager.java:75) >> >> at >> org.apache.openjpa.kernel.StateManagerImpl.loadFields(StateManagerImpl.java:2742) >> >> at >> org.apache.openjpa.kernel.StateManagerImpl.loadField(StateManagerImpl.java:2820) >> >> at >> kodo.kernel.ProfilingStateManager.loadField(ProfilingStateManager.java:68) >> >> at >> org.apache.openjpa.kernel.StateManagerImpl.beforeAccessField(StateManagerImpl.java:1337) >> >> at >> kodo.kernel.ProfilingStateManager.beforeAccessField(ProfilingStateManager.java:49) >> >> at >> org.apache.openjpa.kernel.StateManagerImpl.accessingField(StateManagerImpl.java:1322) >> >> at model.UserAccount.pcGetaccountOwner(UserAccount.java:1) >> >> ====> at model.UserAccount.getAccountOwner(UserAccount.java:500) >> >> at >> business.impl.PersistentManipulationUtil.findAccountablePersonWithUserName(PersistentManipulationUtil.java:991) >> >> at business.impl.EJBUtil.createBusinessContext(EJBUtil.java:120) >> >> at business.impl.EJBUtil.createBusinessContext(EJBUtil.java:78) >> >> at >> business.ejb3.base.BaseManagerBean.getBusinessContext(BaseManagerBean.java:410) >> >> at >> business.ejb3.EnterpriseManagerBean.getEnterpriseWindowThresholds(EnterpriseManagerBean.java:1680) >> >> >> Changing the userAccountOwner() pointcut to read: >> >> > @Pointcut("execution(* model.UserAccount.getAccountOwner(..))") >> public voiduserAccountOwner(){} >> >> >> >> >> And the cflow() works as expected. >> >> >> Is this behaviour expected based on the way field getter/setter pointcuts >> are designed to work or is this a bug in my code (or my use of the field >> getter) or AspectJ? >> >> >> This is with AspectJ 1.8.13. >> >> >> Thanks, >> >> >> Eric >> >> > > _______________________________________________ > aspectj-users mailing list > aspectj-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://www.eclipse.org/mailman/listinfo/aspectj-users > _______________________________________________ aspectj-users mailing list aspectj-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/aspectj-users
