Hi Pavel
Thanks, sorry, your note re having a working implementation was
not of the most major concern :-), I was only trying to imply that
well, sometimes we have to be ready to adjust our code, though I
know RI has a good code :-).
Either way, as far as I'm concerned, I reckon we can probably
won't have a better alternative to using @Priority
Thanks, Sergey
toggle quoted messageShow quoted text
On 25/05/17 16:19, Pavel Bucek wrote:
Hi Sergey,
please see inline.
On 25/05/2017 17:04, Sergey Beryozkin
wrote:
Hi Pavel
On 25/05/17 15:54, Pavel Bucek wrote:
Hi Sergey, others,
you suggest that the exception mapper would be part of MVC
spec (not the implementation, so not in javax.* package but
more like org.impl.something.*?). I think that checking
package name is fragile concept and should be avoided if
possible, not to mention that this setup would be not ideal
for MVC implementations.
I thought that the MVC spec was shipping its own default mapper,
that is way I was suggesting checking javax.*.
if it is not the case then I agree it would not work well...
I believe we shouldn't introduce new annotations whenever
there is a need for a marker (which, in this case, can be
easily defined without it); we already do have plenty of
them..
Also, note that @Priority is not use to control what is
excluded. It is used accordingly to what it is supposed to be
used - to sort providers. JAX-RS implementation then needs to
pick single one in most occasions and it will naturally pick
more important one.
Leading to the exclusion in the end. With Filters it is
obviously not the case, all of them are run.
yes, exactly.
I was trying to offer another point of view on that issue, seemed
like you are suggesting that the proposal uses @Priority in a way
that contradicts its purpose.
Since I believe we have working proposal (backed up by the
implementation),
IMHO that should not be used to affect the discussion given that
the proposal is still under the discussion ?
I'm sorry if that statement felt like something too offensive.
All I wanted to say there was "hey, this proposal does work, we
know it, since we do have backing implementation. with tests. :)"
I could use the argument that says "we need to have RI
implementation for anything we do propose here, because if we
don't, the feature cannot be part of the spec", since we have to
have everything ready for PFD, but .. it is not the case here.
let's stick to
following:
- clarify what is built-in and user-defined provider using
Santiagos definition:
if it is registered using the JAX-RS API or discovered via class
scanning (i.e. annotated with @Provider), then it is
user-defined regardless of their physical location (library,
container, etc.). Built-in ones should not
be made available using those mechanisms.
- define that user-defined providers will be sorted by the
@Priority with respect to existing, already defined
algorithms. That means it will influence which Provider is
defined only when other conditions are already applied and
more than one provider is equal in terms of the defined
algorithm (i.e. exception type distance for ExceptionMappers).
Described change fits well in Java EE environment, since using
@Provider is quite common among other specifications thus is
already natural for majority of users.
Please let us know whether you have any strong objections or
suggestions how to improve proposed rules.
Looks like we have no other option but to use @Priority even
though it will mean @Priority is used differently when applied
to exception mappers (or param converters ?). It feels wrong but
I guess we don't have other options (the new annotation will do
well but it is just too late for it to be introduced)
I do see it as "contextual" priority and the context is defined by
the provider definition. I don't have any examples from Java EE in
mind right now, but sorting something (by the priority) and then
picking "the best" provider seems to be natural. Also, if a
provider is a filter and filter contract defines that all filters
have to be executed, then using @Priority for sorting them doesn't
feel wrong. I do agree that there is a difference, but the
difference is in providers declaration, not in the semantics of
@Priority.
Of course, I can be wrong ;) Please let me know what do you think.
Best regards,
Pavel
Sergey
Thanks and regards,
Pavel
On 25/05/2017 11:30, Sergey
Beryozkin wrote:
I guess that what I also suggested when we
talked with Christian about @DefaultProvider - the only
problem from what I understood MVC will've been already
released by the time JAX-RS 2.1 gets out.
To be honest, I'm still thinking, checking the origin
(package) of the mapper can work. If for ex MVC ships its
ExceptionMapper it is still a built-in mapper in context of
MVC, and it can be identified to be a built-in one because
it will be in a javax. namespace. Such providers should get
a lower priority OOB (compared to the otherwise equal
competing mappers), without having to depend on @Priority.
@Priority is there to sort the providers, making sure they
execute in the right order. Using it as a mechanism to
exclude does not seem quite right...Though it can work...
Cheers, Sergey
|