Hi,
Currently, I have two issues with Jersey (other than URI dispatchement):
1- A super class for a resource which performs some operations on injectable resources can't use annotations to mark then resources used by it. With out modifying Jersey, a user has to declare abstract methods which return the resources that the super class needs and implement them in the sub classes (it causes a lot of duplicated code, not monetioning the separation of concerns).
I have the sources of Jersey and I solved the problem locally by modifying:
Class "com.sun.ws.rest.impl.application.WebApplicationImpl".
Method injectResources(Object resource).
By changing: resourceClass.getDeclaredFields() => resourceClass.getFields();
It works locally fine. It would be nice if this change would be applied to the source code in the trunk also.
2- I have a lot of resources which perfomrs CRUD operations on entities. All of these classes has a super class (lets say BaseEntityResource). The source could is similar to this:
abstract class BaseEntityResource<EntityType> {
@UriTemplate("{id}/")
@HttpMethod("PUT")
@ConsumeMime("application/xml")
public void Update(@UriParam("id") Integer id, EntityType entity) {
/// .....
}
}
The problem is that when Jersey looks for entity provider to deserialize the request for EntityType parameter, it ignores the fact that it's a generic type and passes it as it is. So the passed type id Object and as such then JAXB entity provider is not returned.
A solution without modifying Jersey, would be by overriding the method in each sub class, redeclaring all of the annotations, and calling the method of the super class. As it seems, duplicated code and inflexibility.
It would be very nice if this problem had a solution. Since in cases where the application has 10s of resource (as in mine), this has a huge effect.
Jersey is my favourite implementation of REST, anyway, I think the problem with inheritance causes some additional effort to be dedicated in order to use it, the kind of effort that makes programs less readable and flexible.
Thank you for efforts.
Best Regards,
Valery