[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [aspectj-users] Why is toString matched?
|
Thanks for the help, Ron. I'm
quite new to aspectj, and I suspected it was because in java "everything
extends Object" that was causing me to get bit. I was quite
suprised by this behavior. Lots of gotchas for the aspectj noob!
Thanks,
Brian Yoffe
"Ron Bodkin"
<rbodkin@xxxxxxxxxxxxxx>
Sent by: aspectj-users-bounces@xxxxxxxxxxx
08/21/2006 02:51 PM
Please respond to
aspectj-users@xxxxxxxxxxx |
|
To
| <aspectj-users@xxxxxxxxxxx>
|
cc
|
|
Subject
| RE: [aspectj-users] Why is toString
matched? |
|
Hi Brian,
AspectJ appears to be considering
these methods as matching because they are defined on Object. In some sense
AspectJ considers that MyInterface extends Object, just as in Java you
can invoke methods on Object when you have an instance of an interface,
without downcasting. You can work around this behavior by excluding methods
defined on Object, e.g.,
protected pointcut
nonVoidMethod() :
execution(public !void (@ServiceCallback *).*(..)) && !execution(*
Object.*(..));
However, I think it would be
better if AspectJ didn’t consider methods defined on Object as being defined
on an interface unless the interface explicitly declares them. So I think
this should be a bug, although maybe there’s a use case for why it should
match?
Here’s a similar program that
shows the core issue without annotations (all the methods on MyInterfaceImpl):
public interface MyInterface
{
void doWork();
int getValue();
}
class MyInterfaceImpl implements
MyInterface {
public void doWork()
{}
public int getValue()
{ return 0; }
public String
toString() { return "x"; }
}
aspect MatchMyInterface {
declare warning:
execution(* MyInterface.*(..)): "method on my interface";
}
From: aspectj-users-bounces@xxxxxxxxxxx
[mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of brian.a.yoffe@xxxxxxxxxxxx
Sent: Monday, August 21, 2006 7:42 AM
To: aspectj-users@xxxxxxxxxxx
Subject: [aspectj-users] Why is toString matched?
I'm trying to create a policy that enforces the following:
Any interface that is marked with the @Callback annotation cannot have
methods that are non-void.
That is:
@Callback
public interface MyInterface {
void doWork();
int getValue();
}
public class MyInterfaceImpl implements MyInterface {
void doWork() {...}
// <---- just fine, as pectected
int getValue() {...}
// <---- expect error here, and it is
public String toString() {...}
// <---- should be just fine, but it's included in the joinpoint
and thus an error
}
I've tried to accomplish this using the following joinpoint/error:
protected pointcut nonVoidMethod() :
execution(public !void (@ServiceCallback *).*(..));
declare error : nonVoidMethod() :
"Non void method.";
However, the results I get indicate that public String toString() matches
this joinpoint.
In further experimentation, I redefined the interface:
@Callback
public interface MyInterface {
void doWork();
// int getValue(); note, I commented this out of the interface
}
and here's the results
public class MyInterfaceImpl implements MyInterface {
void doWork() {...}
// <---- just fine, as expected
int getValue() {...}
// <---- would expect the same behavior as toString
exhibits. However, this is not an error anymore
public String toString() {...}
// <---- still an error
}
I am a bit lost - why is the toString joinpoint included by my pointcut?
How do I prevent it?
Thanks,
Brian Yoffe
This communication is for informational purposes only. It is not intended
as an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy
and are subject to change without notice. Any comments or statements made
herein do not necessarily reflect those of JPMorgan Chase & Co., its
subsidiaries and affiliates.
This transmission may contain information that is privileged, confidential,
legally privileged, and/or exempt from disclosure under applicable law.
If you are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution, or use of the information contained
herein (including any reliance thereon) is STRICTLY PROHIBITED. Although
this transmission and any attachments are believed to be free of any virus
or other defect that might affect any computer system into which it is
received and opened, it is the responsibility of the recipient to ensure
that it is virus free and no responsibility is accepted by JPMorgan Chase
& Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this transmission
in error, please immediately contact the sender and destroy the material
in its entirety, whether in electronic or hard copy format. Thank you._______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.
This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.