<
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