(a) binary compatibility and (b) compiler's responsibility
for exception-checking, both as
defined by the JLS and VM spec. So the programmer's
expectation is not determinative.
*smile*: It's an exercise for the reader to write an abstract aspect that
enables the client to
A step beyond the idea of "contracts" is "who's supposed to know about
X?" The total invariants
that hold for a given method could be a combination of local and remote
{attributes}, including
XML specifiers, annotations, access modifiers, package sealing, operative
container, and so on;
glomming all those into the idea of "contract" doesn't fly. The real
question is what do the folks
who write the XML specifiers or the source code or ... need or want to
know.
------------Original Message------------
From: Paulo Alexandre Corigo Zenida <Paulo.Zenida@xxxxxxxx>
To: aspectj-users@xxxxxxxxxxx
Date: Mon, Jun-26-2006 6:20 AM
Subject: Re: why you can't use AspectJ to throw or declare
checked exceptions from/in a method -- was Re:
[aspectj-users] Some questions/suggestions about
AspectJ
Hi Alex,
Hum, I see..
That leads us to an interesting issue, I think. Is access control a part of
the contract? If it is, maybe we should not use ITD to inject annotations
related to access control in methods or attributes. If it is not, then we can
use ITD for injecting the annotations but, once the annotation should
implicitly throw an exception that client code should handle, then we also
should be able to inject the declaration of checked exceptions in the methods
through ITD (yes, changing the method contract).
In the situation I am facing, we could have two different
implementations for the project and let the client code choose between which
one to use (is this desirable? If so, I would like to ask for your opinion
about which version you would be preferable):
1 - AccessControlledException as an unchecked exception, not forcing client
code to handle the exception that can be thrown by the method execution, when
the principal does not have access to it, which is a very important drawback -
clients should be able and forced to handle situations related to lack of
authorizations.
2 - AccessControlledException as a checked exception, forcing client code
to handle the exception, but not letting him centralize the concerns related
to authorization or the resources that require authorization in a single
point.
For the first implementation, we would also loose one feature we have
implemented for propagating through type members (methods) access control
requirements, based on the type (class or interface):
declare @method :
!@AccessControlled !private * (@AccessControlled *..*).*(..) :
@AccessControlled(inherited = true);
If we cannot inject checked exceptions based on a method
annotation, we could only "help" the programmer by issuing compile time errors
for all methods annotated as @AccessControlled, not throwing an
AccessControlledException. But we loose the capability to put in a single
point, if we desire, all the points in the code that should be access
controlled.
I would like to ask for your opinions as experts about this matter.
Regards,
Paulo
Em Domingo, 25 de Junho de 2006 20:21, o Alexandru Popescu escreveu:
> #: Paulo Alexandre Corigo Zenida changed the world a bit at a time
by
> saying (astral date: 6/25/2006 12:16 PM) :#
>
> > Hi Wes,
> >
> > Actually, what does happen when you do ITD of a method? Something
like:
> >
> > public void MyClass.foo() { ... }
> >
> > Classes that use this method will have a problem when you do not
put
> > the aspect (unwoven), right? Isn't the problem that you are
pointing
> > out similar?
>
> I think it is the other way around in fact. The classes that use the
ITD
> have been compiled against the weaved jar (a strong dependency). But
Wes is
> pointing out that in your scenario you are in fact changing the
> contract/API defined by these libraries and this may result in very
weird
> behavior.
>
> ./alex
> --
> .w( the_mindstorm )p.
> ---
> (http://themindstorms.blogspot.com)
>
> > Actually, I really would like that, at least in situations
similar to
> > the one I have referred, that my project would show me compile
time
> > errors if any class, using the methods annotated with
@AccessControlled
> > would not handle the checked exception I would like to insert. My
point
> > is that it would be a lot easier if I could do that. This way, I
could
> > concentrate in one single point in my code, the concerns related
to
> > authorization:
> >
> > public aspect MyAspect {
> >
> > declare @method : ... : @AccessControlled;
> > // then, I would like to be able to do something like this:
> > declare throws AuthorizationException : @AccessControlled
!private
> > *.*(..);
> >
> > }
> >
> > Notice that I am not trying to make aspect advise throw
checked
> > exceptions different than the ones declared in the method:
> >
> > class MyClass {
> > public void foo() { ... }
> > }
> >
> > aspect MyAspect {
> >
> > before() : call(public void MyClass.foo()) {
> > if(true)
> > throw new Exception();
> > }
> > }
> >
> > The alternative for my problem is to write directly in the
annotated
> > methods, the throws AuthorizationException. However, we would
have this
> > scattered all over the application and very hard to maintain
because we
> > can have annotations directly in methods or annotations through
ITD.
> >
> > Best regards,
> >
> > Paulo
> >
> > Citando Wes Isberg <wes@xxxxxxxxxxxxxx>:
> >> Hi -
> >>
> >> It's easier if you stick to the one-topic rule for
emails,
> >> with the subject being the topic.
> >>
> >>> why it isn't possible
> >>> to inject exceptions in methods.
> >>
> >> That would mean clients built against the original class
> >> won't have done the required exception checking.
> >> Generally, it's very important that classes affected by
> >> aspects are binary-compatible with the unwoven/original
> >> classes. While this is the responsibility of the compiler
> >> and not technically part of binary compatibility as
defined
> >> by the JLS, it certainly would be viewed as not
> >> Java-compliant for programs to start throwing (and not
> >> catching) unexpected checked exceptions.
> >>
> >> Wes
> >>
> >> On Thu, 15 Jun 2006 21:38:49 +0100
> >> Paulo Alexandre Corigo Zenida
<paulo.zenida@xxxxxxxx>
> >>
> >> wrote:
> >>> Hello there,
> >>>
> >>> I have a few questions and suggestions that I would
like
> >>> to share with the AspectJ community.
> >>>
> >>> First of all, I would like to know why it isn't
possible
> >>> to inject exceptions in methods. I know it is not
> >>> possible to make an advice throw an exception other
than
> >>> the ones in the contract of a method, which makes
sense.
> >>> However, why can't we make a method, annotated with a
> >>> certain annotation, for example, throw a checked
> >>> exception, through ITD? I am working on my master
degree
> >>> thesis project, about access control, and I am using
> >>> annotations to specify the points in the code that
> >>> require some kind of permission. This way, I am doing
> >>> something like this on methods:
> >>>
> >>> @AccessControlled(requires = "foo")
> >>> public void foo() {
> >>> ...
> >>> }
> >>>
> >>> In order for client code to be able to deal with the
lack
> >>> of permissions by the principals, I would like to make
it
> >>> possible to throw a checked exception (at the moment,
I
> >>> am just throwing an unchecked exception, which is not
> >>> what we want here!). Shouldn't this be possible?
> >>> Something like:
> >>>
> >>> declare throws mypackage.MyClass.foo() :
> >>> AccessControlException;
> >>>
> >>>
> >>> Second: I would also like to know why isn't possible
to
> >>> extend concrete aspects. I have one situation in which
I
> >>> would like to make the aspect application mandatory
(a
> >>> concrete aspect) but, at the same time, make it
possible
> >>> to "refine" the pointcuts definitions in it (an
abstract
> >>> aspect). More concretely, I have created an aspect
which
> >>> enforces some policies, which must always be applied.
> >>> However, I would like to make it possible to switch
from
> >>> warning to error messages, as wanted. Example:
> >>>
> >>> public aspect MyAspect {
> >>>
> >>> public final pointcut all() : !none();
> >>>
> >>> public final pointcut none();
> >>>
> >>> public pointcut declareWarningScope() : all();
> >>>
> >>> public final pointcut declareErrorScope() :
> >>> !declareWarningScope();
> >>>
> >>> declare warning : declareWarningScope() && ...
:
> >>> "Warning: Blabla";
> >>> declare error : declareErrorScope() && ... :
> >>> "Error: Blabla";
> >>>
> >>> }
> >>>
> >>> This aspect should always be applied but I would like
to
> >>> make it possible to redefine the
declareWarningScope()
> >>> pointcut. However, I cannot extend that aspect so I
have
> >>> a problem! To fix this, I have created a workaround,
> >>> together with my thesis advisor (Manuel Menezes de
> >>> Sequeira), which I would like to share and, maybe,
get
> >>> some feedback about it.
> >>>
> >>> The idea is that we put the pointcuts definitions
(the
> >>> declareWarningScope and declareErrorScope pointcuts) in
a
> >>> class, which the aspect extends (not an interface so
that
> >>> the declareErrorScope() can be final):
> >>>
> >>> public abstract class MyClass {
> >>> public pointcut declareWarningScope() :
> >>> mypackage.AnAspect.all();
> >>>
> >>> public final pointcut declareErrorScope() :
> >>> !declareWarningScope();
> >>>
> >>> }
> >>>
> >>> public aspect MyAspect extends MyClass {
> >>>
> >>> declare warning : declareWarningScope() && ...
:
> >>> "Warning: Blabla";
> >>> declare error : declareErrorScope() && ... :
> >>> "Error: Blabla";
> >>>
> >>> }
> >>>
> >>> Then, when we make the project available for others,
we
> >>> create two JAR files: one with everything, except the
> >>> class MyClass, jar-base.jar, and another one with
just
> >>> the class MyClass, jar-ext.jar.
> >>>
> >>> When we want to refine the pointcuts definition, we
don't
> >>> use the second JAR, which will cause a compile time
> >>> error, due to the unexistence of the class MyClass.
That
> >>> forces the user to create that class in the specified
> >>> package, where he may define the pointcut as wanted.
If
> >>> he does not want a redefinition of those pointcuts,
he
> >>> simply uses both JAR's. What do you think about this
> >>> solution? Is there one better for this problem?
> >>>
> >>>
> >>> Finally, I am using annotations in packages to
declare
> >>> the permissions for all members of that same package.
> >>> This way, I try to verify if the permission
requirements
> >>> for a certain method have been declared or not in a
> >>> certain class or package. However, when those are
> >>> declared in packages, I cannot guarantee that the
package
> >>> have been actually loaded: only if a class in that
> >>> package have been loaded, right? This way, I force a
> >>> class to be loaded in a certain package. The
convention
> >>> was that one aspect in my project, when instantiated,
is
> >>> passed a list of classes that should be instantiated,
so
> >>> that the packages and their annotations are loaded
and
> >>> stored in that aspect. However, if we have a class A
in
> >>> the package pt.iscte but no class in the package pt,
the
> >>> package pt will not be recognized. So, my question
is:
> >>> would it be possible to use AspectJ to declare classes
on
> >>> packages? If that would be possible, I would not have
to
> >>> create a class myself but I could use AspectJ to
create
> >>> it, and then pass it to that Aspect that loads the
> >>> classes.
> >>>
> >>> I hope I have made myself clear and sorry for the
mail
> >>> size...
> >>>
> >>> Thanks for your attention and interest.
> >>>
> >>> Cheers,
> >>>
> >>> Paulo Zenida
> >>
> >>
----------------------------------------------------------------
> >>
> >>> Mensagem enviada usando o IMP (Internet Messaging
> >>> Program).
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> >
> >
----------------------------------------------------------------
> > Mensagem enviada usando o IMP (Internet Messaging Program).
> >
> >
> > _______________________________________________
> > 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
_______________________________________________
aspectj-users
mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
