[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[aspectj-users] Re: Accessing a protected class...
|
You can target an inner class with an aspect regardless of its visibilty as
long as you can name it. Anonymous inner classes are a problem. See the
example below:
public class Outer {
public void test () {
new Inner().test();
new StaticInner().test();
}
public static void main(String[] args) {
new Outer().test();
}
protected class Inner {
public void test() {
System.out.println("? " + getClass().getName() +
".test()");
}
}
protected static class StaticInner {
public void test() {
System.out.println("? " + getClass().getName() +
".test()");
}
}
}
public aspect Logging {
pointcut test () :
execution(* test(..))
&& (within(Outer.Inner) || within(Outer.StaticInner));
before () : test () {
System.err.println(thisJoinPoint);
}
}
Running Outer gives the following console output:
? Outer$Inner.test()
execution(void Outer.Inner.test())
? Outer$StaticInner.test()
execution(void Outer.StaticInner.test())
Notice Java reflection gives the "external" class name with a "$" while
AspectJ uses the internal name with a ".".
Matthew Webster
AOSD Project
Java Technology Centre, MP146
IBM Hursley Park, Winchester, SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal)
Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
http://w3.hursley.ibm.com/~websterm/
aspectj-users-request@xxxxxxxxxxx@eclipse.org on 13/02/2004 17:00:01
Please respond to aspectj-users@xxxxxxxxxxx
Sent by: aspectj-users-admin@xxxxxxxxxxx
To: aspectj-users@xxxxxxxxxxx
cc:
Subject: aspectj-users digest, Vol 1 #465 - 9 msgs
Send aspectj-users mailing list submissions to
aspectj-users@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
http://dev.eclipse.org/mailman/listinfo/aspectj-users
or, via email, send a message with subject or body 'help' to
aspectj-users-request@xxxxxxxxxxx
You can reach the person managing the list at
aspectj-users-admin@xxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of aspectj-users digest..."
Today's Topics:
1. Re: AJDT Dev build available: 1.1.6 (Chad Woolley)
2. Re: Defining a pointcut selecting no joinpoints. (Wes Isberg)
3. Re: Defining a pointcut selecting no joinpoints. (Daniel
McAllansmith)
4. Accessing a protected class... (Alan Brown)
5. java.lang.VerifyError with weaved call to protected super-aspect
method (Daniel McAllansmith)
6. Re: Intertype Questions after porting to 1.1.1 (Ron Bodkin)
7. Re: java.lang.VerifyError with weaved call to protected
super-aspect method (Wes Isberg)
8. Re: java.lang.VerifyError with weaved call to protected super-aspect
method (Daniel McAllansmith)
--__--__--
Message: 1
Date: Thu, 12 Feb 2004 16:02:44 -0700
From: Chad Woolley <lists@xxxxxxxxxxxxxxxxx>
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] AJDT Dev build available: 1.1.6
Reply-To: aspectj-users@xxxxxxxxxxx
Andrew Clement wrote:
> Hi,
>
> With the recent interest in getting the latest AspectJ fixes available in
> AJDT- and the fact that the future version of AJDT (Codename: Lancaster)
> will only probably only run on Eclipse 3.0M6 and beyond, we have decided
> to build and package a new version of AJDT for Eclipse users working on
> any level of Eclipse up to 3.0M4. We would like to do more testing and
> tidying up before promoting this as a full production capable build - but
> hopefully some of you will find it useful.
I'm curious what the big change is between 3.0M4 and 3.0M5+. If it's a
long technical answer, then nevermind, that's fine.
>
> 2) Building behaves much better. There were numerous bugs in how we
> handled building of projects. Although we don't have fully correct
> incremental compilation in this version, the 'build on save' option works
> really nicely - *the build that is triggered on save will occur using the
> currently selected .lst file*. By default when you save any aspect or
> class in your AJDT project, we will perform a build, the structure view
> will be updated correctly and crosscutting annotations will immediately
> appear (if the file you have saved is covered by your currently active
> build configuration). If you want to deactivate this option, open the
> Window->Preferences->Workbench page and deselect 'perform build
> automatically on resource modification'.
Thanks a lot for getting this in. I was the one who originally
complained enough for you to add it :)
-- Chad
--__--__--
Message: 2
Date: Thu, 12 Feb 2004 15:26:15 -0800
From: Wes Isberg <wes@xxxxxxxxxxxxxx>
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] Defining a pointcut selecting no joinpoints.
Reply-To: aspectj-users@xxxxxxxxxxx
Sorry, just to be clear: the idiom is to declare a pointcut and
not define it (not to use a pointcut called "empty"):
pointcut p();
There was a aspectj-dev thread on ~ undefined concrete pointcuts~
a while back, and it's in the sample code (and not the docs,
perhaps because there's not consensus that it's the right thing).
I personally object to it because it's so close to an abstract
pointcut that someone could easily leave out "abstract" and not
realize it. It has the advantage that if this (imho) bug is
ever fixed, you'll get a compile-time error.
Wes
Daniel McAllansmith wrote:
> On Fri, 13 Feb 2004 10:49, Wes Isberg wrote:
>
>>>is there a special pointcut syntax which is defined to select no
>>>joinpoints at all?
>
>
>>try
>>
>> pointcut empty();
>
>
> Heh, should probably have tried that... thanks.
>
> That might be a good thing to get added to the section on pointcuts in
the
> language semantics doc.
>
> Cheers
> Daniel
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
>
--__--__--
Message: 3
From: Daniel McAllansmith <daniel@xxxxxxxxxxxxxxxxxx>
Organization: Spinsoftware (NZ) Ltd.
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] Defining a pointcut selecting no joinpoints.
Date: Fri, 13 Feb 2004 13:03:32 +1300
Reply-To: aspectj-users@xxxxxxxxxxx
On Fri, 13 Feb 2004 12:26, Wes Isberg wrote:
> Sorry, just to be clear: the idiom is to declare a pointcut and
> not define it (not to use a pointcut called "empty"):
>
> pointcut p();
>
> There was a aspectj-dev thread on ~ undefined concrete pointcuts~
> a while back, and it's in the sample code (and not the docs,
> perhaps because there's not consensus that it's the right thing).
>
> I personally object to it because it's so close to an abstract
> pointcut that someone could easily leave out "abstract" and not
> realize it. It has the advantage that if this (imho) bug is
> ever fixed, you'll get a compile-time error.
No worries, I followed.
I guess I didn't think of trying to use a pointcut with no definition
because
it didn't seem like something that would work.
Personally I expected to find a primitive, there doesn't seem to be a
logical
reason why an undefined pointcut should be interpreted as selecting no
joinpoints.
Defining utility pointcuts as Rod Bodkin showed seems like a good way to
go...
perhaps until the issue is decided permanently.
Daniel
--__--__--
Message: 4
Date: Thu, 12 Feb 2004 16:21:08 -0800
From: "Alan Brown" <abrown@xxxxxxxxxxxxxxxxx>
To: <aspectj-users@xxxxxxxxxxx>
Subject: [aspectj-users] Accessing a protected class...
Reply-To: aspectj-users@xxxxxxxxxxx
There is a class that I need to access but it isn't public. It's a
protected inner static class that's declared at the bottom of another
class. =20
How do I Import this class into my aspect in order to use it?
--__--__--
Message: 5
From: Daniel McAllansmith <daniel@xxxxxxxxxxxxxxxxxx>
Organization: Spinsoftware (NZ) Ltd.
To: aspectj-users@xxxxxxxxxxx
Date: Fri, 13 Feb 2004 13:37:54 +1300
Subject: [aspectj-users] java.lang.VerifyError with weaved call to
protected super-aspect method
Reply-To: aspectj-users@xxxxxxxxxxx
--Boundary-00=_ixBLAQOpUtqMWm9
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
I get a java.lang.VerifyError at runtime complaining about 'Bad access to
protected data' when advice on a sub-aspect that calls a protected method
on
the super-aspect is woven into a class.
However another call to the same method woven into the same class but due
to
advice declared in the super-aspect works fine.
It seems to me that both should work.
I've had a quick look in the bug tracker but can't find anything.
I am using version 1.1.1 of the compiler.
The aspects were woven into precompiled (by javac) classes.
The verify error occurs under both sun's 1.4 and blackdowns 1.3 VMs.
Following is a stack trace and some test files are attached.
Thanks
Daniel
Exception in thread "main" java.lang.VerifyError: (class:
com/spinsoftware/test/p1/ConcreteTest, method:
ajc$inlineAccessMethod$com_spinsoftware_test_p1_ConcreteTest$com_spinsoftware_test_p2_AbstractTest$getField
signature: (Lcom/spinsoftware/test/p2/AbstractTest;)I) Bad access to
protected data
at com.spinsoftware.test.Driver.doStuff(Driver.java)
at com.spinsoftware.test.Driver.main(Driver.java:18)
--Boundary-00=_ixBLAQOpUtqMWm9
Content-Type: text/x-java;
charset="us-ascii";
name="Driver.java"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Driver.java"
package com.spinsoftware.test;
public class Driver{
public static void main(String[] args) {
Driver d = new Driver();
d.doStuff();
d.doOtherStuff();
}
private void doOtherStuff() {
System.out.println("doing other stuff");
}
private void doStuff() {
System.out.println("doing stuff");
}
}
--Boundary-00=_ixBLAQOpUtqMWm9
Content-Type: text/plain;
charset="us-ascii";
name="ConcreteTest.aj"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="ConcreteTest.aj"
package com.spinsoftware.test.p1;
import com.spinsoftware.test.p2.AbstractTest;
import com.spinsoftware.test.Driver;
final aspect ConcreteTest extends AbstractTest {
protected pointcut pc(): execution(* Driver.doStuff());
protected pointcut pc2(): execution(* Driver.doOtherStuff());
Object around(): pc2() {
System.out.println("adding to the other stuff");
/*If we comment out the next line we don't get a
verify error.*/
System.out.println("The value of the field when
replacing is " + getField());
return proceed();
}
protected void hook() {
/*This doesn't cause a verify error seemably
because the advice calling it is in AbstractTest*/
System.out.println("The value of the field is " +
getField());
}
}
--Boundary-00=_ixBLAQOpUtqMWm9
Content-Type: text/x-c++src;
charset="us-ascii";
name="AbstractTest.aj"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="AbstractTest.aj"
package com.spinsoftware.test.p2;
public abstract aspect AbstractTest {
private int field;
protected abstract pointcut pc();
Object around(): pc() {
this.field++;
hook();
return proceed();
}
protected final int getField() {
return this.field;
}
protected abstract void hook();
}
--Boundary-00=_ixBLAQOpUtqMWm9--
--__--__--
Message: 6
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] Intertype Questions after porting to 1.1.1
From: "Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>
Organization: New Aspects of Security
Date: Thu, 12 Feb 2004 17:18:32 -0800
Reply-To: aspectj-users@xxxxxxxxxxx
Paul,
One small note. There is a reasonable work-around (maybe Eric's phrasing
di=
dn't give the most complete explanation) available. As I recall, you could
=
define a normal Java interface, Reservation, then define an interface
Reser=
vationHelper that extends Reservation, then use an ITD on
ReservationHelper=
(not Reservation) and use declare parents: ReservationImpl implements
Rese=
rvationHelper.
Re: your use case for inappropriate use of default constructors, you might
=
advice in your aspect that throws an exception if you're calling the
advice=
from outside the cflow of initialization. You might also make the
construc=
tor private (if Castor is able to invoke private constructors using
Accessi=
bleObject).
Ron Bodkin
Chief Technology Officer
New Aspects of Software
m: (415) 509-2895
> ------------Original Message------------
> From: Paul Christmann <paul@xxxxxxxxxxxxxxxxx>
> To: aspectj-users@xxxxxxxxxxx
> Date: Tue, Feb-10-2004 9:45 AM
> Subject: Re: [aspectj-users] Intertype Questions after porting to 1.1.1
> =
> Wes Isberg wrote:
> > Hi Paul -
> > =
> > Thanks for upgrading!
> =
> Glad to. Sorry it took us so long! :)
> =
> > In reverse order:
> > =
> > - Use the iajc task, not Ajc10, if you can.
> > (though results *should* be the same)
> =
> Definitely. I only used Ajc10 while trying to verify whether the =
> behavior I was seeing existed in earlier releases or not.
> =
> > - Please do submit a bug for the reflective-invocation of
> > the constructor defined by the aspect (presumably publicly);
> > it will at least result in a doc clarification. Try it
> > first with the latest compiler.
> =
> Will do.
> =
> > - Is Reservation an interface? =
> =
> I've tried it with Reservation as an interface, and found that the only =
> way I could get my test code to work was:
> a) Reservation interface included the method, and
> b) My Object in the TestCase was a Reservation object:
> =
> Reservation res =3D new ReservationImpl(argsGoHere);
> =
> If I wrote:
> =
> ReservationImpl res =3D new ReservationImpl(argsGoHere);
> =
> I still got the same behavior - I couldn't access the introduced method,
=
> even though it was declared on the interface that ReservationImpl =
> implemented. As I read the rest of your email, I think you say that I =
> should expect what I did encounter - at least with 1.1.1 as released.
> =
> But I'm not going to look any further than this given that:
> a) both you and Ron indicated that there was a known bug that has been =
> fixed in CVS Head, which I'm (unfortunately) not going to get to look at
=
> soon, and
> b) I've found a perfectly reasonable work around - I actually didn't =
> need the intertype declarations, and could just move the methods onto =
> the affected class.
> =
> > Hope this helps!
> > Wes
> =
> Definitely did, and thank you as well for the prompt response!
> =
> -- =
> PC
> =
> Paul Christmann
> Prior Artisans, LLC
> mailto:paul@xxxxxxxxxxxxxxxxx
> 504-587-9072
> =
> =
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
> =
> =
--__--__--
Message: 7
Date: Thu, 12 Feb 2004 17:21:15 -0800
From: Wes Isberg <wes@xxxxxxxxxxxxxx>
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] java.lang.VerifyError with weaved call to
protected
super-aspect method
Reply-To: aspectj-users@xxxxxxxxxxx
Ack!
Thank you very much for bringing this to our attention with a
most succinct test case. I've gone ahead and added it to CVS:
tests/bugs/protectedvf/...
tests/ajcTestFailing.xml
(I hope you don't mind.)
Would you like to submit a bug, or shall I? If you do,
please refer to the test case in bugs/protectedvf.
Wes
Daniel McAllansmith wrote:
> I get a java.lang.VerifyError at runtime complaining about 'Bad access to
> protected data' when advice on a sub-aspect that calls a protected method
on
> the super-aspect is woven into a class.
> However another call to the same method woven into the same class but due
to
> advice declared in the super-aspect works fine.
>
> It seems to me that both should work.
>
> I've had a quick look in the bug tracker but can't find anything.
>
> I am using version 1.1.1 of the compiler.
> The aspects were woven into precompiled (by javac) classes.
> The verify error occurs under both sun's 1.4 and blackdowns 1.3 VMs.
>
> Following is a stack trace and some test files are attached.
>
> Thanks
> Daniel
>
>
>
>
> Exception in thread "main" java.lang.VerifyError: (class:
> com/spinsoftware/test/p1/ConcreteTest, method:
>
ajc$inlineAccessMethod$com_spinsoftware_test_p1_ConcreteTest$com_spinsoftware_test_p2_AbstractTest$getField
> signature: (Lcom/spinsoftware/test/p2/AbstractTest;)I) Bad access to
> protected data
> at com.spinsoftware.test.Driver.doStuff(Driver.java)
> at com.spinsoftware.test.Driver.main(Driver.java:18)
>
>
> ------------------------------------------------------------------------
>
> package com.spinsoftware.test;
>
> public class Driver{
>
> public static void main(String[] args) {
> Driver d = new Driver();
> d.doStuff();
> d.doOtherStuff();
> }
>
> private void doOtherStuff() {
> System.out.println("doing other stuff");
> }
>
> private void doStuff() {
> System.out.println("doing stuff");
> }
> }
>
>
> ------------------------------------------------------------------------
>
> package com.spinsoftware.test.p1;
>
> import com.spinsoftware.test.p2.AbstractTest;
> import com.spinsoftware.test.Driver;
>
> final aspect ConcreteTest extends AbstractTest {
>
> protected pointcut pc(): execution(* Driver.doStuff());
>
> protected pointcut pc2(): execution(* Driver.doOtherStuff());
>
> Object around(): pc2() {
> System.out.println("adding to the other stuff");
> /*If we comment out the next line we don't get a
verify error.*/
> System.out.println("The value of the field when
replacing is " + getField());
> return proceed();
> }
>
> protected void hook() {
> /*This doesn't cause a verify error seemably
because the advice calling it is in AbstractTest*/
> System.out.println("The value of the field is " +
getField());
> }
> }
>
>
> ------------------------------------------------------------------------
>
> package com.spinsoftware.test.p2;
>
> public abstract aspect AbstractTest {
>
> private int field;
>
> protected abstract pointcut pc();
>
> Object around(): pc() {
> this.field++;
> hook();
> return proceed();
> }
>
> protected final int getField() {
> return this.field;
> }
>
> protected abstract void hook();
> }
--__--__--
Message: 8
From: Daniel McAllansmith <daniel@xxxxxxxxxxxxxxxxxx>
Organization: Spinsoftware (NZ) Ltd.
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] java.lang.VerifyError with weaved call to
protected super-aspect method
Date: Fri, 13 Feb 2004 15:06:01 +1300
Reply-To: aspectj-users@xxxxxxxxxxx
On Fri, 13 Feb 2004 14:21, Wes Isberg wrote:
> Ack!
>
> Thank you very much for bringing this to our attention with a
> most succinct test case. =A0I've gone ahead and added it to CVS:
>
> =A0 =A0 tests/bugs/protectedvf/...
> =A0 =A0 tests/ajcTestFailing.xml
>
> (I hope you don't mind.)
That's fine.
>
> Would you like to submit a bug, or shall I? =A0If you do,
> please refer to the test case in bugs/protectedvf.
Bug is 51929.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D51929
Daniel
--__--__--
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users
End of aspectj-users Digest
