| 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 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 <dave@xxxxxxxxxx> 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.
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
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
|
