Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re :Re: Re [aspectj-users] :Re: Protecting the joinpoints from being woven?

Hi Pavel,

I read the abstract of the ‘open modules’ and seems like this is what I was looking for. However I need to do some research on its implementation to assure if it’s doing what I want. I will get back to you in case I have any questions on “open module”. 

Thanks for giving the direction.

~Kunal.


On Sun, 24 Feb 2008 19:04:02 +0000 aspectj-users@xxxxxxxxxxx wrote
Dear Eric,

As you quite aptly point out, such an annotation is only useful when you
process your code with tools that respect it. In that, it is much like
the 'final' annotation in Java, which doesn't provide complete security
for the reasons you list. My understanding was that Kunal was after a
tool that would respect some (form of) 'do-not-weave' annotations.

Kunal,

Despite Eric's discouraging remarks, there *is* an abc extension aimed
at addressing the problem you describe in greater generality. It is
described in Neil Ongkingco's work, particularly the AOSD'06 paper
available at http://abc.comlab.ox.ac.uk/papers#aosd2006 . The extension
introduces the concept of 'open modules', with which you can restrict
the applicability of aspects to code.

The extension has seen some work since the paper, so please don't
hesitate to get in touch with us if you run into problems (the abc
mailing lists would probably be more suited for such discussions).

HTH,
- Pavel

Eric Bodden wrote:
> No, it doesn't. In fact I don't think there can be any program that
> provides what you want.
>
> It's easy to generate arbitrary attributes in the bytecode of some
> class. It's also easy to modify a compiler like ajc or abc to read
> such an attribute and, if a certain attribute is present in a class,
> omit weaving of this class.
>
> *However* this does not at all make your code more secure, as anybody
> could easily (a) remove the attribute or (b) just use another AspectJ
> compiler (or a modified version of one) that ignores the attribute.
>
> I have seen some people using some kind of checksum approach where a
> class, before performing some functionality computes a checksum of
> itself and compares that to some constant value. This seems much more
> secure already. (Although I want to encourage such methods by no
> means.)
>
> Eric
>
> On 24/02/2008, kunalrock wrote:
>
>> Thanks Dehua. I read some papers about abc, but was not sure if it provide
>> this facility as well. Anyway, I will look into it and will post the
>> question, if I have any.
>>
>> ~Kunal.
>>
>>
>>
>> Dehua Zhang wrote:
>> >
>> >
>> > Have a look at abc, http://aspectbench.org .
>> >
>> > --
>> > Dehua Zhang
>> > Sable Research Group, McGill University
>> > Montréal, Québec, Canada
>> > http://www.cs.mcgill.ca/~dzhang25
>> >
>> >
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: aspectj-users-bounces@xxxxxxxxxxx on behalf of Kunal Pathak
>> > Sent: Sat 2/23/2008 16:37
>> > To: aspectj-users@xxxxxxxxxxx
>> > Subject: Re :Re: [aspectj-users] Protecting the joinpoints from being
>> > woven?
>> >
>> >
>> >
>> > Thanks for the reply Dean. But looking at the aspect code, I
>> > think I haven't made my question clear.
>> >
>> >
>> > The brief explanation of what I am expecting is:
>> >
>> >
>> > Every time I declare my methods as final, I make sure
>> > that they will never be overridden. Likewise, I want some utility/
>> > functionality/ code/ annotation that will ensure that my method, class (or
>> > any
>> > joinpoint) is never woven by anyone in future. A nice way could be to
>> > write a
>> > patch in ajc that will skip the weaving process if it encounters some
>> > marker in the target code. Marker just tells the ajc "You can't enter in
>> > my personal area and
>> > spit the code (before, after, around) me".
>> >
>> >
>> > I know the question is silly, but the functionality will at
>> > least guarantee that no one in future will ruin my "secured" code area
>> > (especially
>> > by writing an around advice). Also the "secured" code can be thought of
>> > never
>> > undergoing change, whatsoever.
>> >
>> >
>> > Sorry for the confusion.
>> >
>> >
>> >
>> > Thanks,Kunal.
>> > On Sat, 23 Feb 2008 11:30:46 -0600 aspectj-users@xxxxxxxxxxx wrote Here's
>> > a runtime aspect that will raise an exception if a method annotated with
>> > @Critical (made up annotation) calls any other methods that are
>> > advised.public aspect PreventAdvice { public pointcut disallowed():
>> > adviceexecution() && cflow(execution (@Critical * *.*(..)))
>> > && !within(PreventAdvice);  // prevent an infinite
>> > recursion... before(): disallowed() { throw new
>> > RuntimeException("Disallowed! "+thisJoinPoint); }} Your automated testing
>> > regime will have to catch any violations before deploying to production
>> > ;) I don't know of a robust way to accomplish the same thing with a
>> > "declare error" statement, but that would be ideal.It's really useful to
>> > think through what a "critical section" means in terms of AspectJ's join
>> > point model. In this example, I'm specifically saying I don't want any
>> > advice executed while inside @Critical methods. Note that this wouldn't
>> > prevent before or
>> > after advise for calls to @Critical methods. I'm assuming that's okay.
>> > For example, it might be fine to have advice that logs that the program is
>> > about to enter a @Critical method and log after it returns. You don't
>> > have to use a method (or class) annotation of course, but doing so keeps
>> > this aspect generic and robust as the underlying code gets refactored.dean
>> > On Feb 23, 2008, at 8:43 AM, Kunal Pathak wrote:Hello All,I am just
>> > curious to know that is there any way (may be specifying some kind of
>> > annotation) to protect the joinpoint from being woven? The reason behind
>> > my question is "security". Thanks, Kunal.
>> > _______________________________________________ aspectj-users mailing
>> > list aspectj-users@xxxxxxxxxxx
>> > https://dev.eclipse.org/mailman/listinfo/aspectj-users Dean Wampler,
>> > Ph.D.dean at objectmentor.comhttp://www.objectmentor.comSee
>> > also:http://www.aspectprogramming.com  AOP advocacy
>> > sitehttp://aquarium.rubyforge.org     AOP for Rubyhttp
>> > ://www.contract4j.org         Design by
>> > Contract for Java5
>> >
>> > _______________________________________________
>> > aspectj-users mailing list
>> > aspectj-users@xxxxxxxxxxx
>> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
>> >
>> >
>>
>>
>> --
>> View this message in context: http://www.nabble.com/Re-%3ARe%3A-Protecting-the-joinpoints-from-being-woven--tp15657619p15666017.html
>> Sent from the AspectJ - users mailing list archive at Nabble.com.
>>
>> _______________________________________________
>>
>> 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


Back to the top