Ok, I think I have a much better feel for what's happening here now.
I think that this particular error is triggered by the interface:
public class SearchAction<T>{
public List<? extends T> search(){
...
}
....
}
From the debugging that I did, that search method was where it was
blowing up. I'm not entirely sure of the whole sequence of events,
but I guess if it is the search() method on the aspect itself that
hibernate validator is trying to resolve it would expect to find T
referenced by the aspect class and quite possibly fail with an NPE
when it's not there. I'm not that familiar with how AspectJ does it's
delegation of method calls to the aspects providing their
implementation, but if the aspect instance is contained in a field
within the advised class, it would probably be checked, and I think
this would all make sense.
So if I'm following you, I would think that stripping the generic
signatures from the methods within the aspect class should be fine.
The interfaces generic signature will still be available, which is
what calls are made to from user code, and I don't think having that
typing information available from the aspect at runtime would be too
important... not to me anyway...
On Oct 28, 2008, at 2:11 PM, Andy Clement wrote:
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
_______________________________________________
aspectj-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users
