Hi,
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
Just wondering here, why would a lookup for "/foo/bar" via CDI be inefficient, but via one's own structure efficient?
I know of course that the Jakarta REST example is contrived hence why I said "Leaving path combining out".
Well I didn't leave it out :-) But even if I did, what I meant is that in the usual CDI programmatic lookup, the container essentially has to run through all existing beans during programmatic lookup. Optimizations are possible, but based on cursory look, Weld (as well as Quarkus) only does one -- caching. Even if I leave out path variables etc. and only consider static paths, if you keep the naive caching that is perfectly fine today, you expose yourself to a very simple DOS attack (caching a negative result for 1_000_000_000 different HTTP request paths...). So in the end, you probably don't want to cache that part of the lookup.
On the other hand, if you start with the request path, you typically only have 1 class (or very few classes) that could possibly match, so that's the first thing you want to filter on. Again, only considering static paths, it's just one `Map.get` call. You can't get much cheaper than that. In reality, it will be more complex, but you will always want to start filtering on the HTTP request path (+ method, of course), as that prunes most of the useless stuff very quickly. Anything more complex needs to be after that.
LT
> that would in the end give me the executable method.
The idea was that the CDI lookup for a method could give you back just that as well.
Kind regards,
Arjan
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
