Thanks for the input Monzillo - as far as my limited knowlege allows me to see, it seems that you were correct about the problem being upstream in the annotation processor:
Investigation over the weekend indicates that the culprit seems to be the confusion caused by my bean implementing/extending a parameterized interface. My bean inheritance:
CategoryFacade -> CategoryFacadeRemote -> FacadeRemote
CategoryFacade -> CategoryFacadeLocal
FacadeRemote is an interface inherited by a several different Beans, and it allows large parts of the client architecture to use different beans without really knowing too much about them -- very useful.
It is parameterized because without this, most of the return values and method parameters were plain Objects (beans, bean ids), and it was easy to write code that compiled, but would actually crash (ie you pass in a bean as a param when you should have passed in a bean id and vice versa).
More detail:
The FacadeRemote declaration:
[b]public interface FacadeRemote<T,Id> {[/b]...
where 'T' is the Entity type and 'Id' is the type of the entity's id object.
CategoryFacadeRemote declaration
[b]public interface CategoryFacadeRemote extends FacadeRemote<Category, Integer> {[/b]...
and finally CategoryBean declaration:
[b]public class CategoryFacade implements CategoryFacadeLocal, CategoryFacadeRemote {[/b]...
An example method as seen in all three files:
FacadeRemote method declaration:
[b]Id save(T entity);[/b]
extended (masked, perhaps) in the CategoryFacadeRemote interface:
[b]Integer save(Category entity);[/b]
implemented in CatgoryFacade:
[b]Integer save(Category entity) { [/b] ...
I'm fairly certain the annotation processor is getting confused over the differing method signatures as seen in
a. the Parameterized FacadeRemote and
b. the CategoryFacadeRemote and CategoryFacade.
Anyways, I have so far found three ways of getting around this (none of which are very satisfying):
1. Remove the FacadeRemote from the inheritance hierarchy. I tested this and it works, but it's not really a option at this point as there is too much client code that relies on its existence.
2. De-parameterize FacadeRemote. Again, I've tested this and it works, but it eliminates the compile-time checks from which we are supposed to benefit with a strongly-typed language. It also makes the code less readable - more plain Objects, casts, etc.
3. Write out the method permissions by hand in the ejb-jar.xml. This works, and although its painful and probably more error-prone than annotations (as I would like them to work), I'm currently leaning towards it as my solution.
I guess at this point I'm wondering whether this is is a case of
1. glassfish having an insufficiently subtle annotation processor, or
2. me having abused the spec and having tried to make go in places to which it was never (or at least not yet) intended to go.
Any insights/corrections/suggestions most welcome.
Thanks,
Ross
[Message sent by forum member 'rycohen2000' (rycohen2000)]
http://forums.java.net/jive/thread.jspa?messageID=271891