2009/1/15 Jason Weinstein <[email protected]>
> Thanks for your response.
> I have included pieces of the actual implementations below to be more
> clear. I have a little framework for managing the interceptors external to
> the definitions in AspectJ.
>
> >>Do you need to know who is calling the ctor (if so, where is the binding
> for who is making the call)?
> Can you clarify how this works with an example
>
Well if you don't need to know who is making the call then it doesn't
matter.... but binding the caller is simply:
before(Object caller): call(Bootstrap+.new(..)) && this(caller) {}
or use thisEnclosingJoinPointStaticPart to see the joinpoint where the
caller lives. And if your advice on construction is going to potentially
skip construction if your framework decides to, then call is what you will
have to use, rather than execution. I didn't realise you were writing such
general advice - in that case I guess you probably will need thisJoinPoint
and it will be expensive. If you are logging the arguments in logEntering()
then you will need thisJoinPoint, however if you are just logging the name
(and containing class) making the call, you could just use
thisJoinPointStaticPart.
However, I see your onInstall method has no arguments - so surely you could
get away with logEntering(thisJoinPointStaticPart) in your second piece of
advice?
Andy.
>
> >>Do you intend to sometimes replace the object returned from the ctor?
> Sometimes
> >>Do you use thisJoinPoint?
> I use thisJoinPoint to access the parameters
>
> public pointcut Bootstrap_new() :
> call(Bootstrap+.new(..));
>
> public pointcut Bootstrap_onInstall(
> Bootstrap object) :
> execution(public void onInstall()) &&
> this(object);
>
> Object around() :
> Bootstrap_new() {
> logEntering(thisJoinPoint);
> Proceed proceed = new Proceed() {
> public Object invoke(Object target, Object[] args) throws
> Exception {
> return proceed();
> }
> };
> Object result = null;
> try {
> result = system.invoke(JBIConstants.KEY_BOOTSTRAP_NEW, -- This
> delegates to my framework, ultimately calling Proceed by default, unless
> skipped by interceptor in chain
> thisJoinPoint, proceed);
> } catch (Exception e) {
> e.printStackTrace();
> throw new RuntimeException(e);
> }
> return result;
> }
>
> Object around(Bootstrap object) :
> Bootstrap_onInstall(object) {
> logEntering(thisJoinPoint);
> Proceed proceed = new Proceed() {
> public Object invoke(Object target, Object[] args) throws
> Exception {
> Bootstrap bootstrap = (Bootstrap) target;
> return proceed(bootstrap);
> }
> };
> Object result = null;
> try {
> result = system.invoke(JBIConstants.KEY_BOOTSTRAP_ONINSTALL,
> thisJoinPoint, proceed);
> } catch (JBIException e) {
> throw e;
> } catch (RuntimeException e) {
> throw e;
> } catch (Exception e) {
> throw new RuntimeException(e);
> }
> return result;
> }
>
>
> Andy Clement wrote:
>
> Hi Jason,
>
> > General pointers:
>
> 1. execution is better than call. execution will just advise one place
> (where the 'thing' is defined) whilst call will advise every location
> calling the 'thing'.
>
> 2. Avoid thisJoinPoint in your advice if you can. It is expensive to
> create. If you must use it then try to include an if() guard component to
> your pointcut so that creation of thisJoinPoint can be conditional. (This
> is a better approach than putting an if() condition as the first line in
> your advice). The static information available with thisJoinPointStaticPart
> is not so bad as that is only calculated once at class load time so don't
> worry if you need to use this.
>
> 3. Use within()/withincode() wherever possible to limit the code that is
> processed looking for join points - don't just rely on specifying the
> declaring type in, for example, the execution pointcut. Always try to use
> within()/withincode().
>
> 4. Ordering of components in pointcuts doesn't matter. There is no need to
> put your within()s first and your execution()s in the middle and cflows() at
> the end. AspectJ rewrites your pointcuts before evaluation ensuring the
> cheap tests are first and expensive ones last.
>
>
> > How are within() pointcuts and <... within ...> clauses related?
>
> The include/exclude within clauses in aop.xml are kind of a higher level
> guard on whether a type should be passed to the weaver. If it fails to meet
> the patterns specified in any of the <... within ...> clauses then it will
> not even be passed to the weaver. If it is passed then to the weaver then
> it may be immediately dismissed if it doesn't match a within() pointcut -
> but there it is slightly more overhead than using the <... within ...>
> clause. Implicitly there is an <include within="*"> that means everything
> will be passed to the weaver, so I wouldn't start using other include within
> clauses unless you are also using exclude clauses as well.
>
> > Weaving java.* and javax.*
>
> With basic LTW setup, we do not weave types in java.* and javax.*
> packages. Getting the weaver associated with the loader for java.* is hard
> anyway. So specifying include or exclude within clauses related java and
> javax are redundant (and introduce overhead). So unless you are using the
> -Xset options to weave java and javax types, don't bother with these within
> clauses.
>
> In addition we don't weave org.aspectj.* and we don't weave sun.reflect.*
> so you don't need to bother excluding those.
>
> > Using your own message handler
>
> This is fine, but be careful it doesn't introduce overhead. make sure it
> is set to ignore messages it is not interested in rather than saying it is
> interested in everything then ignoring them when it is called with them.
> Some messages (eg. weave info) are expensive to create.
>
> So on your specific config.
>
> call(). What context do you collect around a call to a constructor of
> Bootstrap - why is execution() not OK for you? Do you need to know who is
> calling the ctor (if so, where is the binding for who is making the call)?
> Do you intend to sometimes replace the object returned from the ctor? Do
> you use thisJoinPoint?
>
> execution(). add a within(Bootstrap+).
>
> include/exclude in aop.xml. per the documentation at
> http://www.eclipse.org/aspectj/doc/released/devguide/ltw-configuration.html
>
> <aspects>
>
> <!-- Of the set of aspects declared to the weaver
> use aspects matching the type pattern "com..*" for
> weaving. -->
>
> <include within="com..*"/>
>
> <!-- Of the set of aspects declared to the weaver
> do not use any aspects with the @CoolAspect annotation for
> weaving -->
>
> <exclude within="@CoolAspect *"/>
>
> </aspects>
> <weaver options="-verbose">
> <!-- weave types in someoldpackage and types in the foo package
>
> that do not have @NoWeave -->
> <include within="someoldpackage.*"/>
> <include within="(!...@noweave foo.*) AND foo.*"
> <%28...@noweavefoo.*%29andfoo.*>/>
>
> <!-- Do not weave types within the "bar" pakage -->
>
> <exclude within="bar.*"/>
> </weaver>
>
>
>
> I had completely forgotten about the include/exclude section in aspects - I
> guess I haven't known many people use that...
>
> The only downside with exploiting the include/exclude section in the weaver
> section is that when developing your aspects in the IDE (with AJDT) it can
> lead to confusion because compile time weaving ignores those clauses and is
> just obeying the pointcuts. We have a forthcoming enhancement to fix the
> compiler to respect aop.xml files which will help in this regard.
>
> Andy.
>
> 2009/1/15 Jason Weinstein <[email protected]>
>
> I have a number of pointcuts which look at lot like these below. I don't
> know what packages they will be found in. I do know that they will not be in
> java.* or javax.*. Can someone tell me how best to create the highest
> performing pointcuts without knowing which packages they will be part of or
> just other general tips.
>
> Bootstrap is an "interface"
>
> -- note using call
> public pointcut Bootstrap_new() :
> // notwithinThis() &&
> // withincode(* com..*(..)) &&
> call(Bootstrap+.new(..));
>
> -- note using execution
> public pointcut Bootstrap_onInstall(
> Bootstrap object) : // notwithinThis() &&
> execution(public void onInstall()) &&
> this(object);
>
>
> My aop.xml file looks like. How does my aop.xml affect the weaving (LTW).
>
> <aspectj>
> <aspects>
> <aspect name="mypackage.MyAspect" />
> <!--
> <include within="com..*"/> -- WHAT MIGHT THESE DO?
> <include within="java..*"/>
> <include within="javax..*"/>
> <include within="org..*"/>
> -->
> </aspects>
> <weaver options="-XmessageHandlerClass:mypackage.AspectJMessageHandler">
> <!--
> <include within="java..*"/> -- WHAT MIGHT THESE DO?
> <include within="javax..*"/>
> <include within="org..*"/>
> <include within="com..*"/>
> <exclude within="mypackage.*"/>
> -->
> <!--
> <dump within="java..*"/>
> <dump within="javax..*"/>
> <dump within="org..*"/>
> <dump within="com..*"/>
> -->
> </weaver>
> </aspectj>
> _______________________________________________
> aspectj-users mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
> ------------------------------
>
> _______________________________________________
> aspectj-users mailing
> [email protected]https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
> _______________________________________________
> aspectj-users mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
_______________________________________________
aspectj-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users
