Announcement Announcement Module
No announcement yet.
can asjectJ handle the "block everything except certain call path pattern" ? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • can asjectJ handle the "block everything except certain call path pattern" ?


    suppose I have a DAO class:

    class DAO {
    ... access methods...

    and a specific controller class(say user info maintainance):

    class MySpecificController {
    DAO dao;
    public updateUser() {

    Currently, I have a pointcut that basically block/check DAO.* and deny/limits read/write.

    What I would like to do is that if the access is from within MySpecficController, I would let go of this constrain.

    For the above simple case, I can use "call(public * DAO.*(..))" and access the pjp.getThis() which should be MySpecificController something.

    But if I have a case like this :

    MySpcificController.someMethod -> some genericClass.Method -> ... -> DAO.method. That is the access may not be a direct call but going through certain layer which ends up in the method I trap.

    How would I be able to know that it is done in the 'allowable call path' and lex the constraint ?

  • #2
    Read the documentation about the within and this keyword for AspectJ expression language.


    • #3
      I have read that but it is not very clear on what these two are supposed to do. pjp.getThis() seems to be equivalent to this() as far as my test show and I am not sure within works my case case.

      It seems that within would only work if I use the call() form but not the execution() form.

      even the following pointcut(which is supposed to stop infinite loop because my aspect needs to access certain function of GenericDao) doesn't work:

      execution(public * something.GenericDao.*(..)) && !within(MyAspect)

      It ends up in stack overflow. I tried both the full (org.gng.MyAspect) and (MyAspect), both gives the same result.


      • #4
        cflow or cflowbelow is supposed to be the solution, except that it suffers from the same problem as mentioned here :

        So, it seems that at the moment, there is no solution for this pattern.