[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] NotSerializableException: org.aspectj.runtime.reflect.JoinPointImpl$StaticPartImpl

Ok, I just tried it and it worked for me, I was using a recent dev
build.  I then upgraded again just to make sure it still worked on the
latest and it does (3.7 dev stream).  I compiled this program and ran
it:

===
import java.lang.reflect.Field;
import java.lang.reflect.Modifier;


public class Foo {
	public static void main(String[] args) throws Exception {
		Foo foo = new Foo();
		foo.a();
		foo.b();
		foo.c();
		Field[] fs = Foo.class.getDeclaredFields();
		for (Field f: fs) {
			if (f.getName().startsWith("ajc$")) {
				System.out.println(f+" transient?"+Modifier.isTransient(f.getModifiers()));
			}
		}
	}
	
	public void a() {	}
	public void b() {	}
	public void c() {	}
}

aspect Advisor {
	before(): execution(* Foo.*(..)) {
		System.out.println(thisJoinPointStaticPart);
	}
}

With the option set it prints:

execution(void Foo.main(String[]))
execution(void Foo.a())
execution(void Foo.b())
execution(void Foo.c())
private static final transient org.aspectj.lang.JoinPoint$StaticPart
Foo.ajc$tjp_0 transient?true
private static final transient org.aspectj.lang.JoinPoint$StaticPart
Foo.ajc$tjp_1 transient?true
private static final transient org.aspectj.lang.JoinPoint$StaticPart
Foo.ajc$tjp_2 transient?true
private static final transient org.aspectj.lang.JoinPoint$StaticPart
Foo.ajc$tjp_3 transient?true


The option being -Xset:makeTjpFieldsTransient=true, and I set that in
the project properties "AspectJ Compiler" > Other > "Non-standard
compiler options"

How were you trying it? (taking jars from an AJ and dropping them into
an AJDT doesn't work very well as the packaging is different in AJDT)

cheers,
Andy

On 12 April 2012 06:39, Choudary Kothapalli
<choudary.kothapalli@xxxxxxxxx> wrote:
> Yes, I have tried, but it does not seem to work. I am using AJDT to compile.
> I replaced the original aspectjrt.jar and aspectjweaver.jar with the ones
> from your dev build.
>
> Is there a corresponding AJDT dev build that I can try with?
>
> Thanks,
> Choudary.
>
>
> On Wed, Apr 11, 2012 at 8:46 PM, Andy Clement <andrew.clement@xxxxxxxxx>
> wrote:
>>
>> Hi,
>>
>> As it was added as an -Xset option, it should just work for compile
>> time weaving too. Have you tried it?
>>
>> cheers
>> Andy
>>
>> On 11 April 2012 15:45, Choudary Kothapalli
>> <choudary.kothapalli@xxxxxxxxx> wrote:
>> > Andy,
>> >
>> > You added an option to make the synthetic JoinPointImpl$StaticPartImpl
>> > fields transient for load time weaved classes and it's working fine. Can
>> > the
>> > same thing be done for compile time weaved classes too? I mean, can you
>> > add
>> > an option to the compile time weaver so that the
>> > JoinPointImpl$StaticPartImpl fields are marked  transient?
>> >
>> > Thanks,
>> > Choudary Kothapalli.
>> >
>> >
>> > On Fri, Mar 2, 2012 at 2:02 PM, Andy Clement <andrew.clement@xxxxxxxxx>
>> > wrote:
>> >>
>> >> I checked the code and suid calculations ignore private static and
>> >> private transient fields.  So even right now the SUIDs will be the
>> >> same for a class with/without these (as they are private static)
>> >>
>> >> if you raise an issue about making them transient, I'll have a look at
>> >> doing it.
>> >>
>> >> cheers,
>> >> Andy
>> >>
>> >> On 2 March 2012 10:43, Choudary Kothapalli
>> >> <choudary.kothapalli@xxxxxxxxx> wrote:
>> >> > Yes, that seems to be the cleaner solution.
>> >> >
>> >> > 1. When the load time woven classes are involved in both serializing
>> >> > and
>> >> > deserializing: The transient fields are not serialized and when the
>> >> > during
>> >> > deserialization these fields are initialized in ajc$preClinit().
>> >> >
>> >> > 2. When serialized by a woven class and deserialized by a regular
>> >> > class:
>> >> > What will happen if SUID is not defined in the class? Wouldn't the
>> >> > generated
>> >> > SUID's be different?
>> >> >
>> >> > 3. When serialized by a regular class and deserialized by a woven
>> >> > class:
>> >> > Again, would the SUID's match if they are not already defined?
>> >> >
>> >> > My problem is more of scenario 1 and it should be solved by making
>> >> > the
>> >> > synthetic fields transient.
>> >> >
>> >> > Thanks,
>> >> > Choudary.
>> >> >
>> >> >
>> >> > On Fri, Mar 2, 2012 at 1:28 PM, Andy Clement
>> >> > <andrew.clement@xxxxxxxxx>
>> >> > wrote:
>> >> >>
>> >> >> Sorry, I was just saying that if you need to reinitialize those
>> >> >> fields
>> >> >> at any time then that is the method you need to call, but yes the
>> >> >> clinit for the class sets them up the first time.  Are we back to
>> >> >> just
>> >> >> considering transient as a suitable fix for your situation then?
>> >> >>
>> >> >> Andy
>> >> >>
>> >> >> On 2 March 2012 09:57, Choudary Kothapalli
>> >> >> <choudary.kothapalli@xxxxxxxxx> wrote:
>> >> >> > I am checking the decompiled version of a load time woven class
>> >> >> > and
>> >> >> > this
>> >> >> > is
>> >> >> > what I see.
>> >> >> >
>> >> >> > The ajc$preClinit() seems to the place where the 'ajc$tjp_x'
>> >> >> > fields
>> >> >> > are
>> >> >> > initialized. The ajc$preClinit() is called in a static block as
>> >> >> > below:
>> >> >> >
>> >> >> > static {
>> >> >> >         ajc$preClinit();
>> >> >> > }
>> >> >> >
>> >> >> > If this is the case, why do you say that it should be called just
>> >> >> > after
>> >> >> > deserialization? Wouldn't it be called as soon as the class is
>> >> >> > loaded
>> >> >> > anyway?
>> >> >> >
>> >> >> > Thanks,
>> >> >> > Choudary.
>> >> >> >
>> >> >> >
>> >> >> > On Fri, Mar 2, 2012 at 11:07 AM, Andy Clement
>> >> >> > <andrew.clement@xxxxxxxxx>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> I think all the fields mentioned that aren't basic strings are
>> >> >> >> populated 'on-demand' based on the string data  (or other factors
>> >> >> >> that
>> >> >> >> don't need serializing).  That includes method/class fields and
>> >> >> >> the
>> >> >> >> Cache field you mention - so making those transient is fine.
>> >> >> >>
>> >> >> >> As John points out you will have incompatibilities between
>> >> >> >> weaved/unweaved if the fields are included in the serialized
>> >> >> >> object.
>> >> >> >> Interestingly this is not a new problem, and I have no bugzillas
>> >> >> >> relating to it being an issue so I guess it really doesn't come
>> >> >> >> up
>> >> >> >> very often.
>> >> >> >>
>> >> >> >> If you want to rebuild the values for the fields, the target
>> >> >> >> types
>> >> >> >> containing them should all have a method in like this:
>> >> >> >>
>> >> >> >> private static void ajc$preClinit();
>> >> >> >>
>> >> >> >> which you could invoke to do so.  But you'd have to ensure it
>> >> >> >> gets
>> >> >> >> called just after deserialization.  I would need to check what
>> >> >> >> else
>> >> >> >> ajc$preClinit() might do but I'm pretty sure it is just those tjp
>> >> >> >> values.
>> >> >> >>
>> >> >> >> I can see arguments both ways: making tjp fields transient and
>> >> >> >> calling
>> >> >> >> ajc$preClinit or making them serializable if it is tricky to get
>> >> >> >> ajc$preClinit called at the right time.  If compile time weaving
>> >> >> >> it
>> >> >> >> doesn't seem as much of an issue for incompatibility between
>> >> >> >> weaved/unweaved form because the unweaved form is gone.  With ltw
>> >> >> >> maybe there is more chance of encountering the unwoven form again
>> >> >> >> sometime later.
>> >> >> >>
>> >> >> >> Andy
>> >> >> >>
>> >> >> >> On 2 March 2012 07:34, Choudary Kothapalli
>> >> >> >> <choudary.kothapalli@xxxxxxxxx> wrote:
>> >> >> >> >>>Would it be possible to have these fields set to transient but
>> >> >> >> >>> set
>> >> >> >> >>> them
>> >> >> >> >>> on-demand when deserialized (one time only) ?
>> >> >> >> >
>> >> >> >> > If you are talking about the following field, Andy may be the
>> >> >> >> > better
>> >> >> >> > person
>> >> >> >> > to answer. It looks possible to me and it  might be the
>> >> >> >> > cleanest
>> >> >> >> > solution to
>> >> >> >> > this problem.
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > private static final org.aspectj.lang.JoinPoint.StaticPart
>> >> >> >> > ajc$tjp_0;
>> >> >> >> > /*
>> >> >> >> > synthetic field */
>> >> >> >> >
>> >> >> >> >>>Choudary, does your product require transparency in
>> >> >> >> >>> deserializing
>> >> >> >> >>> the
>> >> >> >> >>> instrumented objects (from an uninstrumented instance of the
>> >> >> >> >>> application)?
>> >> >> >> >
>> >> >> >> > At least my current problem involves using the same
>> >> >> >> > instrumented
>> >> >> >> > classes
>> >> >> >> > while serializing and deserializing. I didn't really think of
>> >> >> >> > the
>> >> >> >> > scenario
>> >> >> >> > of needing to deserialize using the uninstrumented classes,
>> >> >> >> > which
>> >> >> >> > might
>> >> >> >> > occur.
>> >> >> >> >
>> >> >> >> > So I think it would be a better idea to make the
>> >> >> >> > 'JoinPoint.StaticPart
>> >> >> >> > ajc$tjp_0;' fields transient and to set them on demand, if it's
>> >> >> >> > possible
>> >> >> >> > to
>> >> >> >> > do so.
>> >> >> >> >
>> >> >> >> > Thanks,
>> >> >> >> > Choudary.
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Fri, Mar 2, 2012 at 9:58 AM, John Kew <jkew@xxxxxxxxxx>
>> >> >> >> > wrote:
>> >> >> >> >>
>> >> >> >> >> If I understand the use-case/problem correctly, there are not
>> >> >> >> >> many
>> >> >> >> >> great
>> >> >> >> >> solutions to this problem.
>> >> >> >> >>
>> >> >> >> >> Either we serialize StaticPart along with the object and make
>> >> >> >> >> the
>> >> >> >> >> serialized class incompatible with an unweaved application, or
>> >> >> >> >> we
>> >> >> >> >> make
>> >> >> >> >> it
>> >> >> >> >> transient and risk an inconsistent or unexpected state after
>> >> >> >> >> the
>> >> >> >> >> object
>> >> >> >> >> is
>> >> >> >> >> rehydrated.
>> >> >> >> >>
>> >> >> >> >> Would it be possible to have these fields set to transient but
>> >> >> >> >> set
>> >> >> >> >> them
>> >> >> >> >> on-demand when deserialized (one time only) ? Choudary, does
>> >> >> >> >> your
>> >> >> >> >> product
>> >> >> >> >> require transparency in deserializing the instrumented objects
>> >> >> >> >> (from
>> >> >> >> >> an
>> >> >> >> >> uninstrumented instance of the application)?
>> >> >> >> >>
>> >> >> >> >> -John
>> >> >> >> >>
>> >> >> >> >> ________________________________
>> >> >> >> >> From: "Choudary Kothapalli" <choudary.kothapalli@xxxxxxxxx>
>> >> >> >> >> To: "AspectJ developer discussions" <aspectj-dev@xxxxxxxxxxx>
>> >> >> >> >> Sent: Friday, March 2, 2012 6:22:38 AM
>> >> >> >> >> Subject: Re: [aspectj-dev]
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> NotSerializableException:        org.aspectj.runtime.reflect.JoinPointImpl$StaticPartImpl
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> Hi Andy,
>> >> >> >> >>
>> >> >> >> >> I will try to give you the patch, but here is what I notice
>> >> >> >> >> after
>> >> >> >> >> taking a
>> >> >> >> >> deeper look into the JoinPointImpl.StaticPartImpl class.
>> >> >> >> >>
>> >> >> >> >> Not all fields in this class are primitives and Serializable
>> >> >> >> >> classes.
>> >> >> >> >> For
>> >> >> >> >> example, the Signature implementation classes like
>> >> >> >> >> AdviceSignatureImpl
>> >> >> >> >> have
>> >> >> >> >> Method as a field, which is not Serializable. But I think we
>> >> >> >> >> can
>> >> >> >> >> safely
>> >> >> >> >> make
>> >> >> >> >> this a transient field.
>> >> >> >> >>
>> >> >> >> >> The same applies to Cache field in the SignatureImpl class. I
>> >> >> >> >> think
>> >> >> >> >> we
>> >> >> >> >> can
>> >> >> >> >> make it transient too.
>> >> >> >> >>
>> >> >> >> >> Shall I go ahead and do these changes or do you have any
>> >> >> >> >> reservations?
>> >> >> >> >>
>> >> >> >> >> Thanks,
>> >> >> >> >> Choudary.
>> >> >> >> >>
>> >> >> >> >> On Thu, Mar 1, 2012 at 11:05 AM, Andy Clement
>> >> >> >> >> <andrew.clement@xxxxxxxxx>
>> >> >> >> >> wrote:
>> >> >> >> >>>
>> >> >> >> >>> Sure, and if you want to give me a patch that does it, even
>> >> >> >> >>> better
>> >> >> >> >>> :)
>> >> >> >> >>>
>> >> >> >> >>> cheers,
>> >> >> >> >>> Andy
>> >> >> >> >>>
>> >> >> >> >>> On 29 February 2012 16:52, Choudary Kothapalli
>> >> >> >> >>> <choudary.kothapalli@xxxxxxxxx> wrote:
>> >> >> >> >>> > Shall I raise a request to make JoinPoint.StaticPart
>> >> >> >> >>> > serializable,
>> >> >> >> >>> > then? It
>> >> >> >> >>> > would solve the problem of serialization.
>> >> >> >> >>> >
>> >> >> >> >>> > Choudary.
>> >> >> >> >>> >
>> >> >> >> >>> >
>> >> >> >> >>> > On Wed, Feb 29, 2012 at 6:03 PM, Andy Clement
>> >> >> >> >>> > <andrew.clement@xxxxxxxxx>
>> >> >> >> >>> > wrote:
>> >> >> >> >>> >>
>> >> >> >> >>> >> Making them serializable is also reasonable.  There is
>> >> >> >> >>> >> nothing
>> >> >> >> >>> >> special
>> >> >> >> >>> >> in them - mostly strings/ints.
>> >> >> >> >>> >>
>> >> >> >> >>> >> There is no option to weave the classes with no synthetic
>> >> >> >> >>> >> fields.
>> >> >> >> >>> >>  It
>> >> >> >> >>> >> is feasible but they aren't necessarily cheap to construct
>> >> >> >> >>> >> and
>> >> >> >> >>> >> inlining their construction where they are used would
>> >> >> >> >>> >> damage
>> >> >> >> >>> >> performance to some degree.
>> >> >> >> >>> >>
>> >> >> >> >>> >> Andy
>> >> >> >> >>> >>
>> >> >> >> >>> >> On 29 February 2012 14:12, Choudary Kothapalli
>> >> >> >> >>> >> <choudary.kothapalli@xxxxxxxxx> wrote:
>> >> >> >> >>> >> > On second thoughts, making them transient may not be a
>> >> >> >> >>> >> > good
>> >> >> >> >>> >> > idea
>> >> >> >> >>> >> > because
>> >> >> >> >>> >> > the
>> >> >> >> >>> >> > deserialization may fail.
>> >> >> >> >>> >> >
>> >> >> >> >>> >> > Do you think you can make JoinPoint.StaticPart and its
>> >> >> >> >>> >> > contents
>> >> >> >> >>> >> > Serializable? I am not sure if that would be correct,
>> >> >> >> >>> >> > but
>> >> >> >> >>> >> > just
>> >> >> >> >>> >> > asking.
>> >> >> >> >>> >> >
>> >> >> >> >>> >> > Or, is there any option to weave the classes so that the
>> >> >> >> >>> >> > synthetic
>> >> >> >> >>> >> > fields do
>> >> >> >> >>> >> > not exist at all?
>> >> >> >> >>> >> >
>> >> >> >> >>> >> > I know that I'm asking for something that may not be a
>> >> >> >> >>> >> > requirement
>> >> >> >> >>> >> > for
>> >> >> >> >>> >> > most
>> >> >> >> >>> >> > usage scenarios or the actual intended usage of AspectJ.
>> >> >> >> >>> >> > But I
>> >> >> >> >>> >> > am
>> >> >> >> >>> >> > stuck
>> >> >> >> >>> >> > with
>> >> >> >> >>> >> > this problem and just checking if there is a way out.
>> >> >> >> >>> >> >
>> >> >> >> >>> >> > Thanks for your time.
>> >> >> >> >>> >> >
>> >> >> >> >>> >> > Choudary.
>> >> >> >> >>> >> >
>> >> >> >> >>> >> >
>> >> >> >> >>> >> > On Wed, Feb 29, 2012 at 4:39 PM, Andy Clement
>> >> >> >> >>> >> > <andrew.clement@xxxxxxxxx>
>> >> >> >> >>> >> > wrote:
>> >> >> >> >>> >> >>
>> >> >> >> >>> >> >> I can provide you an option to make them transient, but
>> >> >> >> >>> >> >> I'm
>> >> >> >> >>> >> >> hesitant
>> >> >> >> >>> >> >> to just change the default to transient.  If you want
>> >> >> >> >>> >> >> an
>> >> >> >> >>> >> >> option
>> >> >> >> >>> >> >> like
>> >> >> >> >>> >> >> that, please open a bugzilla:
>> >> >> >> >>> >> >>
>> >> >> >> >>> >> >>
>> >> >> >> >>> >> >> https://bugs.eclipse.org/bugs/enter_bug.cgi?product=AspectJ
>> >> >> >> >>> >> >>
>> >> >> >> >>> >> >> and I'll take a look.
>> >> >> >> >>> >> >>
>> >> >> >> >>> >> >> cheers,
>> >> >> >> >>> >> >> Andy
>> >> >> >> >>> >> >>
>> >> >> >> >>> >> >> On 28 February 2012 14:35, Choudary Kothapalli
>> >> >> >> >>> >> >> <choudary.kothapalli@xxxxxxxxx> wrote:
>> >> >> >> >>> >> >> > My product MaintainJ uses AspectJ load time weaving
>> >> >> >> >>> >> >> > to
>> >> >> >> >>> >> >> > capture
>> >> >> >> >>> >> >> > the
>> >> >> >> >>> >> >> > call
>> >> >> >> >>> >> >> > trace at runtime. When weaving an application, the
>> >> >> >> >>> >> >> > following
>> >> >> >> >>> >> >> > exception
>> >> >> >> >>> >> >> > is
>> >> >> >> >>> >> >> > seen.
>> >> >> >> >>> >> >> >
>> >> >> >> >>> >> >> > Caused by: java.io.NotSerializableException:
>> >> >> >> >>> >> >> >
>> >> >> >> >>> >> >> > org.aspectj.runtime.reflect.JoinPointImpl$StaticPartImpl
>> >> >> >> >>> >> >> >     at
>> >> >> >> >>> >> >> > java.io.ObjectOutputStream.writeObject0(Unknown
>> >> >> >> >>> >> >> > Source)
>> >> >> >> >>> >> >> >     at java.io.ObjectOutputStream.writeObject(Unknown
>> >> >> >> >>> >> >> > Source)
>> >> >> >> >>> >> >> >     at
>> >> >> >> >>> >> >> >
>> >> >> >> >>> >> >> >
>> >> >> >> >>> >> >> >
>> >> >> >> >>> >> >> > xxx.yyyyy.ZZZClass.writeExternal_aroundBody4(ZZZClass.java:70)
>> >> >> >> >>> >> >> >
>> >> >> >> >>> >> >> > AspectJ LTW seems to insert many fields as below in
>> >> >> >> >>> >> >> > the
>> >> >> >> >>> >> >> > class
>> >> >> >> >>> >> >> > files
>> >> >> >> >>> >> >> > and
>> >> >> >> >>> >> >> > serializing them seems to be failing.
>> >> >> >> >>> >> >> >
>> >> >> >> >>> >> >> > private static final
>> >> >> >> >>> >> >> > org.aspectj.lang.JoinPoint.StaticPart
>> >> >> >> >>> >> >> > ajc$tjp_0;
>> >> >> >> >>> >> >> > /*
>> >> >> >> >>> >> >> > synthetic field */
>> >> >> >> >>> >> >> >
>> >> >> >> >>> >> >> > Is there any quick fix for this? Can AspectJ make
>> >> >> >> >>> >> >> > these
>> >> >> >> >>> >> >> > fields
>> >> >> >> >>> >> >> > transient
>> >> >> >> >>> >> >> > without any other issues?
>> >> >> >> >>> >> >> >
>> >> >> >> >>> >> >> > Thanks,
>> >> >> >> >>> >> >> > Choudary Kothapalli
>> >> >> >> >>> >> >> > MaintainJ Inc.
>> >> >> >> >>> >> >> >
>> >> >> >> >>> >> >> > _______________________________________________
>> >> >> >> >>> >> >> > aspectj-dev mailing list
>> >> >> >> >>> >> >> > aspectj-dev@xxxxxxxxxxx
>> >> >> >> >>> >> >> > https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >> >> >> >>> >> >> >
>> >> >> >> >>> >> >> _______________________________________________
>> >> >> >> >>> >> >> aspectj-dev mailing list
>> >> >> >> >>> >> >> aspectj-dev@xxxxxxxxxxx
>> >> >> >> >>> >> >> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >> >> >> >>> >> >
>> >> >> >> >>> >> >
>> >> >> >> >>> >> >
>> >> >> >> >>> >> > _______________________________________________
>> >> >> >> >>> >> > aspectj-dev mailing list
>> >> >> >> >>> >> > aspectj-dev@xxxxxxxxxxx
>> >> >> >> >>> >> > https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >> >> >> >>> >> >
>> >> >> >> >>> >> _______________________________________________
>> >> >> >> >>> >> aspectj-dev mailing list
>> >> >> >> >>> >> aspectj-dev@xxxxxxxxxxx
>> >> >> >> >>> >> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >> >> >> >>> >
>> >> >> >> >>> >
>> >> >> >> >>> >
>> >> >> >> >>> > _______________________________________________
>> >> >> >> >>> > aspectj-dev mailing list
>> >> >> >> >>> > aspectj-dev@xxxxxxxxxxx
>> >> >> >> >>> > https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >> >> >> >>> >
>> >> >> >> >>> _______________________________________________
>> >> >> >> >>> aspectj-dev mailing list
>> >> >> >> >>> aspectj-dev@xxxxxxxxxxx
>> >> >> >> >>> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> _______________________________________________
>> >> >> >> >> aspectj-dev mailing list
>> >> >> >> >> aspectj-dev@xxxxxxxxxxx
>> >> >> >> >> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> _______________________________________________
>> >> >> >> >> aspectj-dev mailing list
>> >> >> >> >> aspectj-dev@xxxxxxxxxxx
>> >> >> >> >> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > _______________________________________________
>> >> >> >> > aspectj-dev mailing list
>> >> >> >> > aspectj-dev@xxxxxxxxxxx
>> >> >> >> > https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >> >> >> >
>> >> >> >> _______________________________________________
>> >> >> >> aspectj-dev mailing list
>> >> >> >> aspectj-dev@xxxxxxxxxxx
>> >> >> >> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > aspectj-dev mailing list
>> >> >> > aspectj-dev@xxxxxxxxxxx
>> >> >> > https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >> >> >
>> >> >> _______________________________________________
>> >> >> aspectj-dev mailing list
>> >> >> aspectj-dev@xxxxxxxxxxx
>> >> >> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > aspectj-dev mailing list
>> >> > aspectj-dev@xxxxxxxxxxx
>> >> > https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >> >
>> >> _______________________________________________
>> >> aspectj-dev mailing list
>> >> aspectj-dev@xxxxxxxxxxx
>> >> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > aspectj-dev mailing list
>> > aspectj-dev@xxxxxxxxxxx
>> > https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>> >
>> _______________________________________________
>> aspectj-dev mailing list
>> aspectj-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
>
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>