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.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=244619
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 <[EMAIL PROTECTED]>
> 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
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
_______________________________________________
aspectj-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users
