Hi Valery,
Valery Abu-Eid wrote:
> 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).
>
Agreed.
> 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.
>
That will break things as injection is supported on private, package and
protected fields in addition to public fields.
I fixed things in the trunk to support injection on the declared fields
of the class and all the direct or indirect super classes of that class.
> 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.
>
>
Interesting case, i have added a (failing) unit test so we can track this.
I think this is possible to support, although working with reflection
*and* generics is never easy.
We need to determine the Java type from the type variable associated
with the method parameter. To do this the code that analyzes the method
signatures needs access to the concrete resource class. Then that type
variable needs to be matched against the parameterized types of the
super classes.
> 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.
>
Agreed.
Thanks for taking the time to provide feedback,
Paul.
> Thank you for efforts.
>
> Best Regards, Valery
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net For
> additional commands, e-mail: dev-help_at_jersey.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109