[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] ITDs and generic types
|
If it is taking the class file apart to analyse the type parameters, it might well be tripping over the inconsistency in the signature attribute.
I think the solution is not to use the Signature attribute in this case to capture something that will trip up other tools - however that will mean the other tools will not know it is a generic declaration and who knows if they can cope with that. It all comes down to this kind of problem:
interface I<T> {}
aspect X {
public void I<Z>.foo(Z z) {}
}
The type parameter Z for the intertype declaration isn't anywhere to be found in type X. It is not a generic method and it is not a generic aspect and so resolving Z without being aware that it is a generic intertype declaration is tough (only AspectJ knows that it is a reference to the type variable in type I). If the fact that the method is parameterized is captured in a normal Java signature attribute against method foo() in the aspect then any tool (java compiler or something else) will look at that attribute and go 'I dont know what Z you are talking about' which manifests as an 'inconsistent class file' in the JDT compiler and possibly your NPE in seam. So to answer your questions:
> my question is... is that the same issue I'm seeing here as well? Is AspectJ writing a Type value that is unresolvable at runtime via reflection?
could well be. I don't know what the other tool wants to do with the type parameter. The full solution is a bunch of work - but a first pass could be to remove the signature attribute from these methods and see if the tool is happy. It will not know that the ITD is generic but it may not really care. Do you want to try this out? Do you know precisely which method it is tripping up over - is it the manifestation of the ITD in the target types (the mangled ajc$inter* methods) or is it the declaration of the ITD in the aspect type?
cheers,
Andy.
2008/10/28 Dave Whittaker
<dave@xxxxxxxxxx>
I'm seeing some new weirdness with ITDs that mixin generic methods and I wanted to see if anybody could give me a clearer understanding of what's going on. The issue is: I have a bunch of marker interfaces which I use to piece together the actions available on an object in a webapp (Create, Update, Delete, etc). Thanks to Andy's recent bug fixes, this is working pretty well and using JSF components that recognize these marker interfaces and generate a lot of the HTML / Action Invocations for me it might make my life a lot easier. The problem is I'm also using the JBoss Seam framework which has some strong ties to the Hibernate Validator framework. To make a long story short, when certain methods are invoked on my actions, Seam insists on using the Hibernate Validator to validate the entire class, the Hibernate Validator tries to do a runtime resolution of type parameters, and the whole thing dies with an NPE. Now, I know that there are still issue with how types are written out in woven class files which has caused the inconsistent class file error up until recently, so my question is... is that the same issue I'm seeing here as well? Is AspectJ writing a Type value that is unresolvable at runtime via reflection? Or am I looking in the wrong place?
Thanks.
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
