[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [aspectj-users] AJDT / AspectJ trying to load classes from strange locations
|
OK, I think I get it. I am aware of the difference it makes when the referenc to an object is typed different that the actual instance is.
In my mail below I have put an example of the calls made to Paremeter. If I understand correct now, the warning tells me that there is some call somewhere that is different than in my given example. That makes perfect sense of course.
I will look at the code again but I already have an idea where this could happen.
The Parameter instance might be passed to a logger / trace in an Object array. I believe the toString method is called implicitly in that case somewhere. This would explain it.
If I understand correctly these warnings are expensive to calculate and the can be turned off in the xlint config. Could you please point me to where exactly I can configure this in AJDT. Do you believe it makes a great difference?
Thanks, Thomas
I'm trying out the zips with extra timing info now....
-----Original Message-----
From: aspectj-users-bounces@xxxxxxxxxxx [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Andy Clement
Sent: Freitag, 9. Oktober 2009 18:57
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] AJDT / AspectJ trying to load classes from strange locations
Not sure I have enough to go on to understand your
unmatchedSupertypeInCall. You need to tell me the precise shadow that
is unexpectedly giving rise to the problem. When the declaring type
is claimed to be Object it usually means a
toString()/hashCode()/equals() etc. Eg.
class B extends Object {
public void a() {}
}
public class Runner {
public static void main(String[]argv) {
Object i = new B();
i.toString(); // < will trigger unmatchedSuperTypeInCall, whether
B overrides toString or not
}
}
aspect X {
before(): call(* B.*(..)) {} // won't match toString() call, but
"call(* *(..)) && target(B)" will
}
Remember that aspectj is a bytecode weaver, so it is possible a call
to an Object method has been generated on your behalf based on some
piece of java source you have written. That is why you may get xlints
like this. call() and target() is often preferable to call()
specifying a declaring type pattern. But it depends on what shadows
you want to catch. This is not a cheap xlint to compute so really
once you are happy it is doing what you expect, you should turn it off
via the xlint config.
Andy
2009/10/9 Thomas Hofmann <email@xxxxxxxxxxxxxxxxx>:
> Hi,
>
> I have some more information on this. All the types that are searched for in all these locations are mention in aspect MeasuringPoint in project com.dcx.ivkmds.fwk.ass (please see my previous posts for an explaination of this project).
> They are imported in the aspect and used like this:
>
> public pointcut callUser() :
> call(* User.*(..))
> && this(com.dcx.ivkmds.fwk.ass.security.internal.DefaultSecurityComponent);
>
> As I have written in the mail below, the class User is contained in a jar file in bundle project com.dcx.iap. This project is specified in the plug-in deoendencies of the project com.dcx.ivkmds.fwk.ass so I don't see any reason why AJDT should look for these classes at all the different locations it does.
>
>
> But there is something else that is strange in this aspect.
>
> There are three pointcuts that report warnings that I do not understand:
>
>
> public pointcut callParameters() :
> call(* Parameters.*(..))
> && this(com.dcx.ivkmds.fwk.ass.security.internal.DefaultSecurityComponent);
>
>
> public pointcut callUserSecurityContext() :
> call(* UserSecurityContext.*(..))
> && this(com.dcx.ivkmds.fwk.ass.security.internal.DefaultSecurityComponent);
>
>
> public pointcut callPaiResource() :
> call(* Resource.*(..))
> && this(com.dcx.ivkmds.fwk.ass.security.internal.DefaultSecurityComponent);
>
>
> Parameters, UserSecurityContext and Resource is imported like this:
>
> import com.dcx.iap.parameterinformation.Parameters;
> import com.dcx.iap.usersecuritycontext.authorization.UserSecurityContext; import com.dcx.iap.usersecuritycontext.authorization.Resource;
>
>
>
> Strangely enough, the first pointcut above (callUser()) does not have any warning associated although it follows the same pattern.
>
>
> The warning is:
>
> Type does not match because declaring type is java.lang.Object, if match desired use target(com.dcx.iap.parameterinformation.Parameters) [Xlint:unmatchedSuperTypeInCall] MeasuringPoint.aj /com.dcx.ivkmds.fwk.ass/aspect-src/com/dcx/ivkmds/fwk/ass/perflog/internal
>
> The same message appears for the other two pointcuts (with UserSecurityContext and Resource respectively).
>
>
> As far as I understand this would happens when a reference to the actual instance is typed differently.
>
>
> The places where this call occurs look like this:
>
> DefaultPaiUserInfo pui = new DefaultPaiUserInfo();
> com.dcx.iap.parameterinformation.Parameters par = use.getParameters();
> pui.setBusinessField(par.getString("dcxBusinessAllocationLevel1", ""));
> pui.setBusinessUnit(par.getString("businessCategory", ""));
> pui.setCdUserId(par.getString("uid", ""));
>
>
>
> I can see in the editor that it is being adviced. Now I wonder why I get these errors.
>
>
> Any ideas?
> ________________________________________
> From: aspectj-users-bounces@xxxxxxxxxxx [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Thomas Hofmann
> Sent: Donnerstag, 8. Oktober 2009 16:41
> To: aspectj-users@xxxxxxxxxxx
> Subject: [aspectj-users] AJDT / AspectJ trying to load classes from strange locations
>
> Hi Andrew, Andy,
>
> in my endavor to find out how I can improve performance I traced the file I/O for eclipse.exe.
>
> There is an interessting finding I believe.
>
> During compilation I see a huge amount of requests to read class files that lead to PATH NOT FOUND results. For me it is clear that these classes can never be found at the locations eclipse (and presumably AJDT) is looking for them.
>
> Here is a sample:
>
> Consider class Parameters.class. It lives in package com.dcx.iap.parameterinformation. In my workspace this class is included in a JAR file named parameterinformation.jar which lives in a bundle called com.dcx.iap. The bundle project is not an AJDT project.
>
> The IO file trace shows that eclipse searches for this class in lots of workspace projects like:
>
> Line 91: CC:\ws\ivk- eclipse 3.5\com.dcx.ivkmds.fwk.ass\aspect-bin\com\dcx\iap\parameterinformation\Parameters.class
> >From line 91 to 134 this class file is searched for in lots of projects. It is never found there because it resides in the bundle described above.
>
> Looking at the Process Monitor trace and the times one can see that this happens a lot of times. The trace file with the events for about 60 seconds in 98 MB big. So there is a lot of I/O that is absolutely unncessary and repeating so often. This sure has a negative performance impact.
>
> The strange thing is that is only happening for a fixed set of classes from two projects: com.dcx.iap and com.uc4.ra. The classes from the latter one are also in a bundle project contained in ra.jar.
>
> There are other bundle projects that are setup like the two above containing the class files in jar files in the bundle project. None of the classes from these bundles seem to cause the same effect.
>
> Do you have any explanation how this can happen? How can I find out more about why this is happening?
>
> I am attaching part of the IO trace. Please note the times in the first column. There is really much failing IO going on.
>
> Thanks!
>
>
> Regards,
>
> Thomas
>
>
>
>
>
> _______________________________________________
> 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
