[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] newbie AspectJ questions
|
The "adviceDidNotMatch" message does indeed mean that *for that
particular compile/weave* the advice did not match anything. If you
are compiling the aspect into a jar, and using that in a subsequent
iajc step to perform binary weaving, then this message is perfectly ok
(at the time you compiled your aspect, it didn't match anything, but
it will later). If you're doing source compilation of the aspect and
weaving the application in the same step, then this would certainly
indicate a problem with the pointcut.
On 01/02/06, Mark Slater <lists@xxxxxxxxxxxxxxxxxx> wrote:
> I took out the Xlint option and no longer get the lazyTjp warnings. I also
> limited the scope (using the static type matching method you suggested) and
> no longer get the serialVersionUID warning.
>
> However, now I'm getting this warning:
>
> aspectj:compile:
> [iajc] Copying 30 files to
> /Users/mark/Documents/school/whisper/ftr116_mslater/target/classes
> /Users/mark/Documents/school/whisper/ftr116_mslater/src/aspectj/edu/ucsc/whisper/security/aspectj/DomainObjectInstanceSecurityAspect.java:32
> [warning] advice defined in
> edu.ucsc.whisper.security.aspectj.DomainObjectInstanceSecurityAspect
> has not been applied [Xlint:adviceDidNotMatch]
> Object around() : domainObjectInstanceExecution()
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Does this mean I've limited the pointcut too much and the advice is no
> longer being applied to anything? I've got the AjcClosure classes on the
> expected types, but I'm not sure that means they're actually doing anything.
>
> pointcut javaLangObjectMethodExecution() :
> execution( * Object.*(..) );
>
>
> pointcut inUnitTests() : within( edu.ucsc.whisper..*.test..* );
>
>
> pointcut inCoreAspects() : within(
> edu.ucsc.whisper.core.aspectj..* );
>
>
> // Apply the aspect to all AclSecurable subclasses unless they are in
> the Unit test suite.
> // Screen out methods in java.lang.Object.
> pointcut domainObjectInstanceExecution() :
> execution( public * AclSecurable+.*(..) )
> && !inUnitTests()
> && !inCoreAspects()
> && !javaLangObjectMethodExecution();
>
> Mark
>
>
>
> On Jan 31, 2006, at 6:10 AM, Adrian Colyer wrote:
> OK, the ant task explains the final mystery. You've got Xlint="warning"
> which has the effect of making every Xlint message be a warning (even if the
> default was "ignore"). Changing this to "error" will, as you suggest, make
> most of the warnings go away - but it will turn them into error messages
> instead! Using Xlint="ignore" will make them go away, or just omit the Xlint
> attribute altogether to use the default settings (which should not warn on
> lazyTjp, but I think will still warn on the serialVersionUID issue....).
>
> Regards, Adrian.
>
> On 31/01/06, Mark Slater <lists@xxxxxxxxxxxxxxxxxx> wrote:
> > Adrian,
> >
> >
> > First, I'd like to thank you for the detailed reply. I mean *huge* thanks.
> The sad fact is that I'm not able to spend nearly as much time as I'd like
> learning the details of AspectJ, and from what I'm reading, once I have this
> one mechanism set up, that's all I'm going to need. I was not looking
> forward to spending the next week or two tracing execution and combing
> through the AspectJ Compiler manual.
> >
> >
> > To clear up some of the uncertainty in my post, yes I'm using AspectJ 1.5;
> it was required because I make heavy use of generics in my code. I've got a
> customized version of the maven plugin (still using Maven 1.0.2, and the
> latest AspectJ plugin for it uses 1.2.1) and I'll probably send the patch to
> the people who make it once I make sure things are working. I'm wondering if
> the lazyTjp warnings might be an artifact of the plugin. It's using an ant
> task (I've replaced most of the variable properties with their current
> settings):
> >
> >
> > <ant:iajc
> > fork="false"
> > incremental="false"
> > XnoWeave="false"
> > Xlint="warning"
> > destDir="${destDir}"
> >
> sourceRootCopyFilter="${maven.aspectj.sourceRootCopyFilter}"
> > debug="false"
> > emacssym="no"
> > verbose="false"
> > source="1.5"
> > target="1.5"
> > time="false">
> >
> >
> > I'm assuming that if I change Xlint to "error", most of those warnings
> will go away? I can't test that at the moment, but I'll give it a try in a
> few hours.
> >
> >
> > And yes, AclSecurable is an interface. All of the domain objects that can
> be secured with Access Control Lists will be tagged with that interface and
> the security aspect will only be valid for those objects; the interfaces
> that define each type of domain object extend AclSecurable, and are then
> implemented in turn by the domain object classes. Fortunately, they are all
> in the same package, and now that I understand a little more about the
> pointcut matching, I should be able to whittle it down to just the classes
> that need it, and probably down to the methods that need it.
> >
> >
> > Again, thanks! If I run into any other problems, I'll reply again, but
> hopefully that'll cover it.
> >
> >
> > Mark
> >
> >
> >
> >
> >
> >
> > On Jan 31, 2006, at 2:46 AM, Adrian Colyer wrote:
> >
> > To try and explain some of what's going on for you here...
> >
> > The closure classes are generated by the AspectJ compiler when around
> advice cannot be inlined (the default). In this case, the call to
> "proceed()" in the around advice is escaping the advice body (by being
> passed to the security interceptor inside the callback object) and so
> AspectJ must generate a closure class (think of it like a continuation
> implementation).
> >
> > The reason you have so many of them.... is that the pointcut you have
> written matches a very broad set of join points. In particular, you have
> used "target(AclSecurable)" (and I'm presuming AclSecurable is an
> interface). "target" matches based on the runtime type of the target at a
> join point. Since you are using execution I'll use that for the example.
> >
> > Give some class A
> >
> > public class A {
> >
> > public void foo() { ... }
> >
> > }
> >
> > When AspectJ weaves this class, it is possible that the "target" when foo
> executes *is* an AclSecurable, even though A isn't. The way this could
> happen is if someone defines a subclass B:
> >
> > public class B extends A implements AclSecurable {
> >
> > }
> >
> > Now given b of type B, a call to b.foo() results in an execution of foo()
> that should have security interception applied to it. Given the requirements
> to support separate and incremental compilation, AspectJ will apply a
> runtime test before the execution of A.foo to see if the target object
> really does implement AclSecurable, and the around advice will execute if
> so. Given the potential for this to happen at almost any method execution
> join point, you will have a lot of closure classes!
> >
> > You can narrow this down using one or both of the following techniques:
> >
> > * constrain the join point matching to only those types within your domain
> model. For example, you might add a pointcut:
> >
> > pointcut inDomainModel() : within( edu.uscs.whisper.domain..*);
> >
> > (or whatever package prefix or prefixes you are using for the domain
> types).
> >
> > and then refine the domainObjectInstanceExecution pointcut as follows:
> >
> > pointcut domainObjectInstanceExecution() :
> > target(AclSecurable) &&
> > execution(public * *(..)) &&
> > inDomainModel();
> >
> > (assuming the aspect itself is not in the same package as the domain model
> types, the additional !within will no longer be required).
> >
> > * The second narrowing technique is to switch from using target to using
> static type matching. This will work well if you use the AclSecurable
> interface at the root of any domain type hierarchy (eg., in the example
> above, "A" implements AclSecurable, and not "B" only). The only drawback to
> this solution is that if you have a domain type hierarchy such as A and B
> above, and only B implements the AclSecurable interface, then methods on A
> that are not overriden by B will NOT go through the SecurityInterceptor. Use
> the interface at the root of the domain hierarchy you want to secure.
> >
> > The pointcut will now look like this:
> >
> > pointcut domainObjectInstanceExecution() :
> > execution(public * AclSecurable+.*(..)) &&
> > inDomainModel();
> >
> > (the execution expression reads: "the execution of any public method
> defined in AclSecurable or any subtype of AclSecurable").
> >
> > Now to address the other issues:
> >
> > * lazyTjp is a compiler optimisation that applies when using
> thisJoinPoint. Prior to AspectJ 5, this optimisation had to be explicitly
> turned on, but from AspectJ 5 onwards, the optimisation is enabled by
> default. You don't say what version of AspectJ you are using, but we
> shouldn't be warning for this under AspectJ 5 - we will fix that as a bug if
> so. If you are using e.g. 1.2.1 and have enabled the -XlazyTjp flag then
> this is why the warning is coming out. The warning is a simple advisory that
> an optimisation was not applied, and your program will behave perfectly
> correctly.
> >
> > * the needsSerialVersionUIDField warnings are coming out because the
> AspectJ weaving process has had to generate synthetic fields in your domain
> types. These can affect serialization (in particular if you haven't
> explicitly specified a serialVersionUID, then the generated alternative will
> be different after weaving). This can be an issue if you want to serialize
> and deserialize woven and unwoven versions of the type. Defining a
> serialVersionUID is recommended best practice in any case, and will ensure
> you never encounter any issues of this type. I notice from that message that
> even the execution of hashCode and equals methods are being advice by your
> pointcut. You probably don't want to apply security to these methods (if you
> do, fine). You can exclude methods from Object from having security
> interception applied by refining the pointcut expression once more:
> >
> > pointcut javaLangObjectMethodExecution() :
> > execution(* Object.*(..));
> >
> > pointcut domainObjectInstanceExecution() :
> > execution(public * AclSecurable+.*(..)) &&
> > !javaLangObjectMethodExecution() &&
> > inDomainModel();
> >
> > Sorry for the long reply - your post touched on a number of interesting
> issues!
> >
> >
> >
> > On 31/01/06, Mark Slater < lists@xxxxxxxxxxxxxxxxxx> wrote:I'm new to
> AspectJ, and direct use of aspects in general. I've been using them
> indirectly with the Spring Framework and the Acegi security system that
> complements spring. But now I need to implement my own aspect to provide
> security on my domain objects.
> >
> >
> > Based on the Acegi documentation, I've got the following aspect:
> >
> >
> > package edu.ucsc.whisper.security.aspectj;
> >
> >
> > import
> org.acegisecurity.intercept.method.aspectj.AspectJSecurityInterceptor
> ;
> > import
> org.acegisecurity.intercept.method.aspectj.AspectJCallback;
> >
> >
> > import
> org.springframework.beans.factory.InitializingBean;
> >
> >
> > import edu.ucsc.whisper.core.AclSecurable ;
> >
> >
> > public aspect DomainObjectInstanceSecurityAspect
> > implements InitializingBean
> > {
> > private AspectJSecurityInterceptor securityInterceptor;
> >
> >
> > pointcut domainObjectInstanceExecution(): target(
> AclSecurable )
> > && execution( public * *(..) ) && !within(
> DomainObjectInstanceSecurityAspect );
> >
> >
> > Object around(): domainObjectInstanceExecution()
> > {
> > if( this.securityInterceptor != null )
> > {
> > AspectJCallback callback = new AspectJCallback()
> > {
> > public Object proceedWithObject()
> > {
> > return( proceed() );
> > }
> > };
> >
> >
> > return( this.securityInterceptor.invoke( thisJoinPoint,
> callback ) );
> > }
> > else
> > {
> > return( proceed() );
> > }
> > }
> >
> >
> > public AspectJSecurityInterceptor getSecurityInterceptor()
> > {
> > return( securityInterceptor );
> > }
> >
> >
> > public void setSecurityInterceptor( AspectJSecurityInterceptor
> newInterceptor )
> > {
> > securityInterceptor = newInterceptor;
> > }
> >
> >
> > public void afterPropertiesSet()
> > throws Exception
> > {
> > if( securityInterceptor == null )
> > {
> > throw( new IllegalArgumentException( "SecurityInterceptor
> required." ) );
> > }
> > }
> > }
> >
> >
> >
> >
> > As you can see, I only want this aspect applied to objects that implement
> the AclSecurable interface. However, when I look at the output classes (I'm
> using maven to build), I've got one or more ...$AjcClosure#.class files for
> each class in the project, and my JUnit test cases. I'm not sure why they
> would be needed for classes that aren't even indirectly related to the
> AclSecurable class/interface hierarchy. And I really don't see why the JUnit
> test cases (which are defined in a separate source tree and compiled to a
> separate class tree) should be getting this treatment.
> >
> >
> > But worse (in my mind) is that when I build, I'm getting the following
> output for every method in my project:
> >
> >
> > {package}/{class}.java:55 [warning] can not implement lazyTjp on this
> joinpoint method-execution(void {package}.{class}.{method}( {parameters} ))
> because around advice is used [Xlint:canNotImplementLazyTjp]
> > public void setEditUserAccountInfoValidator(
> EditUserAccountInfoValidator newValidator )
> >
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > see also:
> /Users/mark/Documents/school/whisper/ftr116_mslater/src/aspectj/edu/ucsc/whisper/security/aspectj/DomainObjectInstanceSecurityAspect.java:18::0
> >
> >
> > I've done some searching and I can't even figure out what it means that it
> can't implement lazyTjp, so I don't know if this can be safely ignored, or
> if it means I've got a bug someplace.
> >
> >
> > I'm also getting a few messages that look like this:
> >
> >
> >
> edu/ucsc/whisper/security/aspectj/DomainObjectInstanceSecurityAspect.java:18
> [warning] serialVersionUID of type
> edu.ucsc.whisper.core.DefaultAuthority needs to be set
> because of added non-private method hashCode_aroundBody10
> [Xlint:needsSerialVersionUIDField]
> >
> >
> > And once again, I'm not sure what this is talking about... is it
> suggesting that I need to add new fields to objects that (in this case) I
> don't even want the aspect applied to?
> >
> >
> > I'm finding this more confusing than I'd expected it to be. Any help?
> >
> >
> > Thanks,
> > Mark_______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> >
> > --
> > -- Adrian
> > adrian.colyer@xxxxxxxxx
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> >
> >
>
>
>
> --
> -- Adrian
> adrian.colyer@xxxxxxxxx
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
>
--
-- Adrian
adrian.colyer@xxxxxxxxx
