Ok, I tried to set up a small test project so that I could try out
your type stripper, and of course I couldn't replicate the problem.
So I brought in more and more of the classes and aspects from the main
project until I noticed something odd. In the test project
SearchActionAspect where the search() ITD is defined caused no errors
in the original project, but in the test project it showed up as a
type mismatch. When I looked a bit closer I realized that the ITD was
defined as
public List<? extends T> SearchAction.search()
rather than,
public List<? extends T> SearchAction<T>.search()
And adding the type variable within the original project has stopped
the NPE from happening. So I think there is still a bug here, whether
it's due to no error marker showing up in the original project, or to
the different way the method is mixed in if the type variable is not
added to the marker interface, but I'm stumped again as to what really
happened.
Dave Whittaker
Iradix, LLC
(p) 212.513.0874 x100
(f) 212.504.8213
[EMAIL PROTECTED]
On Oct 28, 2008, at 3:15 PM, Andy Clement wrote:
Ok - I will do a build that has a flag to turn off the capturing of
that information in the signature attribute for the itd declaration
in the aspect. It should only be used for the final build of your
code that you are going to deploy - as incremental compilation will
break horribly (I imagine) if an incremental build is attempted
whilst this attribute is missing from the ITD. (that is where the
big bunch of work will be, sorting that out properly). But at least
this will tell us if the strategy will work before investing a lot
of time to go down this road.
cheers,
Andy.
2008/10/28 Dave Whittaker <[EMAIL PROTECTED]>
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
_______________________________________________
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
