The idea to lookup beans by presence of methods seems weird to me
Yet that's essentially what happens in Jakarta REST. Leaving path combining out, you essentially get a request for path "/foo/bar", so you look up a bean declaring to handle "/foo/bar".
That would make for a very inefficient implementation though, especially considering path variables. If CDI had some kind of "executable methods", and I were to implement JAX-RS on top of it, I would want to collect all annotated methods beforehands and build an efficient lookup structure that would in the end give me the executable method. (Or an ordered sequence of matching methods, for content negotiation etc. Of course this is a simplification because of subresource locators and I don't know what, but I think you know what I mean. Subresource locators don't mesh very well with CDI anyway.)
I still think of "executable methods" as bound method references, so an instance of such method reference implicitly knows how to look up the correct bean instance, but it could be the other way around without too many changes. Passing parameters is an interesting challenge so I won't comment on that for now :-)
So I guess I'm thinking, we shouldn't mandate overhead unless there's a broad set of use cases. In that spirit, perhaps we don't even want all beans to know all their methods (know as in "be capable of providing a reference"), as that's probably also quite a bit of overhead. There should be a way for extensions to signal what methods may be "referenced", and that's all. That might be unrealistic due to certain aspects of the CDI SPI design (e.g. the Bean interface is used both in extensions and in the application, so if extensions access methods through that interface, then naturally applications can too), but I confess I didn't really think this through and there's certainly a variety of possible designs.
LT
Now declaring this can be done in two ways; in pseudo code:
1.
@Path("/foo/bar")
class Resource{
}
2.
class Resource{
@Path("/foo/bar")
void myMethod() {}
}
So working on a prototype implementation for this, I just wondered; why can we query beans based on qualifiers at the class-level only. Why don't we include qualifiers on methods as well?
Note that more powerful bean queries are also related to my other proposal for being able to provide a synthetic injection point for a bean lookup.
Kind regards,
Arjan
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
