Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ajdt-dev] StreamCorruptedException

> Adrians messages to the lists about compatibility gave rise to
> bug 82134 ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=82134 ).  I
> implemented a first pass at this late last week so that a 1.5.0 weaver
> (post build date 7th January) will correctly load an Aspect built with
> either 1.5.0 or AspectJ 1.2.1.  This isn't available in an AJDT
> build yet.
>
> *However* - the changes to Resolved Type Munger aren't strictly
> related to this as when I added locations to the type munger I ensured
> the 'reading back in' code could cope with them being missing (i.e. if
> it  encountered an old aspect).
>
> Unfortunately, I left a line of debug code in !!
>
> Here it is:
>
>                 try {
>                    ... Skipping some code that reads in the location
>                 } catch (IOException ioe) {
>               //   this includes StreamCorruptedException
>                   ioe.printStackTrace();
>                   return null;
>                 }
>
> which means that although you are getting the stack trace out, the
> weave should still be executing successfully??

It seems that Eclipse's "rebuild project" is going down hard when it hits
the problem. My Maven builds succeed just fine but I'm much more
comfortable that they're using a consistent set of aspectj jars (version
1.2 actually).

>
> To get rid of the message, you can rebuild the utility jar from source
> so it includes a source location or wait for me to do a build
> which removes that line of debug ...

I'm content to wait :-)


In answer to your other email, yes I am doing binary weaving.

We have a utility jar in which I have an interface defined and a default
implementation via static aspect on there. That jar gets compiled and
installed locally with Maven using aspectj 1.2.

We then have an AspectJ project in Eclipse that depends upon the utility
jar. One of its classes implements said interface and relies on the
aspect-provided default implementation. Using Eclipse 3.0/3.1 with the
bleeding edge AJDT gives me the stacktrace in my original post.

I suspect this is due to the AJDT plugin using AspectJ 1.5.x versus the
jar compiled with 1.2.x. I tossed out my 1.2.x jars and replaced them with
1.5.x (from the AJDT plugin actually), recompiled and reinstalled the
utility jar but Eclipse still won't compile the project.

For sanity, I removed the default implementation aspect from the jar and
rebuilt it and all is well.

My best guess at this point is that although I thought I had Maven and
AJDT sync'd on AspectJ 1.5.x I probably did not. I did a double-check that
$MAVEN_REPO/aspectj/jars/... had only the 1.5.x jars but given the
"Monday" I've had today I can't guarantee anything at this point...

I've got to bail out early today but perhaps tomorrow I can follow a more
scientific method and try to get everything sync'd on 1.5.x and see if it
plays nice.

Thanks to all for the prompt help. Its nice to know there's a helping hand
when you're knee-deep in a pile of Java...

Later,
James


>
> cheers,
> Andy.
> ---
> Andy Clement
> AspectJ
> clemas@xxxxxxxxxx
>
>



Back to the top