[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Intertype Questions after porting to 1.1.1

My apologies...  I scanned bugzilla, but didn't see something that
pertained to either of what I was writing.  I guess perhaps I need new
glasses to help me read better.

Ron Bodkin wrote:
1.  It seems that I can no longer invoke intertype methods from
code that is not compiled by aspectj.  Is that true?

It's a known bug for 1.1.1 (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=43972) that is fixed in CVS HEAD.

There is also a work-around that Eric Jain devised (see
http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg01271.html).

This work around suggests using inner interfaces, which I tried but couldn't get to work. For the time being, I just moved the methods onto the classes, and can live with that. Once there is a later release, I may move them back to the aspects.

2. Introduced constructors seem to not invoke initializers on the

This is "considered the correct behavior"; see bugzilla bug 46282 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=46282) and/or start a discussion about why ITD constructors are important and this should be fixed. It seems like another important use case where preserving source information would help in the weaving phase... Note that this is a problem with all ITD constructors, whether called directly or by reflection.

That's odd. With the simple test case that I wrote, I only could reproduce it with reflection. Code that directly called the introduced constructor seemed to work.


Reading the bug in eclipse, I found this note:

  If you have an example of a real system where you need inter-type
  constructors and the current behavior is causing you problems please
  send it to aspectj-users for discussion

I'll at least mention why we were doing this (using introduced constructors): We use a 3rd party library (castor, http://www.castor.org) to serialize our objects. To do this, we write a mapping file that maps our objects to xml elements with attributes. The castor magic uses reflection, and requires public classes and public default constructors to create the objects.

However, in our state, many of our objects have fields that we'd like to establish as "final" variables. The way we use Castor, though, we can't do this - castor needs a default constructor.

So, we introduced a percflow aspect that traps when castor serialization is happening, and introduced default constructors and appropriate "setter" methods only on that aspect. That way, the default constructor can only be accessible while castor serialization is going on.

No other code is allowed to access the default constructor; they must use the "well-known" constructors that take required arguments. To make these introduced default constructors simple, we moved most of the "initialization" code out of the "normal" constructor for an object, and made it initializers.

So, long story short - our introduced constructors are sort of the reverse of your example: I need to introduce the default constructor, which I suppose could defer to the "real" constructor passing along null parameters.

But it sounds like I have 3 possible work arounds to this:
a) Move the default constructors to the class, as I did. I don't like this, though, as it leaves open the possibility of a client of our code creating an object in an inconsistent state.
b) Introduce the default constructor in an aspect, but explicitly call a well-defined constructor with default values.
c) I think Castor may have changed to allow us to specify non-default constructors as well.


Thanks for your quick response!

--
PC

Paul Christmann
Prior Artisans, LLC
mailto:paul@xxxxxxxxxxxxxxxxx
504-587-9072