Le 20 déc. 2017 03:47, "John D. Ament" a écrit :
The only concrete case I can think of is when someone registers a MBR/MBW
with annotation priority of 5002 and up. In this case, the CXF provider
will take precedence. But as I understand the spec, the user
defined provider should always take pre
The only concrete case I can think of is when someone registers a MBR/MBW with
annotation priority of 5002 and up. In this case, the CXF provider will take
precedence. But as I understand the spec, the user
defined provider should always take precedence over the container created one.
Take fo
johnament commented on a change in pull request #360: MP Rest Client interface
validation and tests
URL: https://github.com/apache/cxf/pull/360#discussion_r157912355
##
File path:
rt/rs/microprofile-client/src/main/java/org/apache/cxf/microprofile/client/CxfTypeSafeClientBuilder.ja
andymc12 opened a new pull request #360: MP Rest Client interface validation
and tests
URL: https://github.com/apache/cxf/pull/360
Checks:
- that the passed-in type is an interface
- that each method has, at most, one HTTP method annotation
- that URI template variables in @Path an
johnament commented on a change in pull request #351: [CXF-7571] Adding support
for CDI injection of @Context objects.
URL: https://github.com/apache/cxf/pull/351#discussion_r157872871
##
File path:
integration/cdi/src/main/java/org/apache/cxf/cdi/DelegateContextAnnotatedType.java
Hi John
Thinking more about it, adding some protection in the form of the max
priority to the built-in MBRs and MBWs will probably not harm, but it is
just difficult to see how it can practically help either, for now at least.
The existing selection algo should be sufficient to ensure the
ab
> since a user may want to register the built in providers with a different
priority; presently that is blocked.
this is not and you can and it will behave as expected if you register it
in your user providers but if you register it implicitly you have this
custom flag which allows to make it the
I'd like to avoid starting introducing the fixes against the problems
which might *not* be the actual problems, as far as the selection of
MBRs and
MBWs in the spec compliant manner is concerned
...
On 19/12/17 12:07, Sergey Beryozkin wrote:
Lets talk about some specific case. The only built in
Lets talk about some specific case. The only built in providers CXF has
are Message Body Reader and Writers. Well, there's a default excpetion
mapper there as well, but lets deal with it later.
So, giving these built-in MBRs and MBWs, lets have a look at a specific
case where you think having
So I figured out most of the issue. The problem was impacting all of the
providers.
Here's basically what happened:
- The type of comparator you pass into setProviderComparator is unbounded, it
takes any object. But its only meant to sort ProviderInfo impls.
- There's a missing relationship b
reta commented on a change in pull request #359: Adding an implementation of
the MicroProfile Rest Client v1.0
URL: https://github.com/apache/cxf/pull/359#discussion_r157732343
##
File path:
rt/rs/microprofile-client/src/main/java/org/apache/cxf/microprofile/client/MicroProfileClie
reta commented on a change in pull request #359: Adding an implementation of
the MicroProfile Rest Client v1.0
URL: https://github.com/apache/cxf/pull/359#discussion_r157732343
##
File path:
rt/rs/microprofile-client/src/main/java/org/apache/cxf/microprofile/client/MicroProfileClie
sberyozkin commented on issue #359: Adding an implementation of the
MicroProfile Rest Client v1.0
URL: https://github.com/apache/cxf/pull/359#issuecomment-352710029
Hi John, it looks good, as far as the initial implementation is concerned.
Indeed the ordering of the providers is a very sen
13 matches
Mail list logo
