Cannot inherit resource methods from a common base class

[kelihlodversson]

I have a situation where I want to collect a common implementation of the various CRUD metods in a common base class,

In my case the hierarchy consists of a base class and some classes extending it:

public class CommonCollectionResource<RT extends RecordTemplate>
        extends CollectionResourceTemplate<String, RT>
{ ... }

@ResLiCollection(...)
public class ACollectionResource extends CommonCollectionResource<ARecord>
{ ... }

@ResLiCollection(...)
public class BCollectionResource extends CommonCollectionResource<BRecord>
{ ... }

What I want to be able to do is to define get, create, update, delete etc. methods in the base class, but the only way to make rest.li recognize them is to implement them directly in the leaf classes, which leads to an ugly workaround like this:

public ARecord get(String id) {
    return super.get(id);
}

Looking at the rest.li source (in restli-server/src/main/java/com/linkedin/restli/internal/server/model/RestLiAnnotationReader.java, line 1209 in method addResourceMethods) this seems to be a deliberate design decision. How come and is there a way I can make it work without having to resort to redefining the methods in the concrete classes?

[jpbetz]

Hi kelihlodversson,

Unfortunately, rest.li was originally designed such that this is not possible. We do consider it a defect and plan to fix.

We have been thinking of this an a few other big changes to rest.li, which we plan to share with the community in full before we start tackling them. Here's a snippet from a draft of proposed rest.li improvements that is relevant here:

"When scanning resource classes for annotations and binding java methods for dispatch, base classes and interfaces will also be scanned. This will be used to allow for more expressive type hierarchy composition and reduce how aware of the type hierarchy the rest.li codebase needs to be. In particular, classes like CollectionResource will add the @RestMethod annotations to all the methods they define so that the resource processing code understands what operations they provide without the need for custom code to understand CollectionResource. Basically, rest.li should be able to function without CollectionResource or CollectionResourceTemplate being defined, they are purely a convenience and the rest of the rest.li codebase can be unaware of them."

Doing this should allow for very expressive type hierarchies, and would certainly cover the case you describe.

Timeline is likely early 2014.

The only workaround till then is the one you described.

-Joe

[kelihlodversson]

I really think this is something that should be fixed. Why was this closed?

[karanparikh]

Hi @kelihlodversson

I closed this with the understanding that the way you are handling this right now is correct, until we release the next major version of Rest.li (as @jpbetz mentioned in his response above). I could leave it open if you want.

[luney112]

I've run into this same issue recently. Is there still a plan in the works to fix this issue?

[karanparikh]

Hi @JeremySimpson and @kelihlodversson

We haven't fixed this yet. I will talk with the Rest.li team and update this issue with our plans. Re-opening this issue as well.