Re: [VOTE] CXF 3.2.10, CXF 3.3.3, and buildutils 3.4.3

Come on, lets get it out :-) +1 Sergey On Fri, Aug 9, 2019 at 12:46 PM Colm O hEigeartaigh wrote: > +1. > > Colm. > > On Fri, Aug 9, 2019 at 10:42 AM Alessio Soldano > wrote: > > > +1 > > > > Thanks > > > > On Thu, Aug 8, 2019 at 7:10 PM Daniel Kulp wrote: > > > > > This is vote to release

Re: [VOTE] CXF 3.2.5/3.1.16

+1 Sergey On Tue, Jun 19, 2018 at 8:56 AM, Romain Manni-Bucau wrote: > +1, tested on my apps and Apache Meecrowave > > Romain Manni-Bucau > @rmannibucau | Blog > | Old Blog > | Github

Re: Going offline soon

when difficult questions come up. I wish you all the best with your new job. Cheers, Christian 2018-02-09 12:23 GMT+01:00 Sergey Beryozkin <sberyoz...@gmail.com>: Hi Guys, Just a short note that I'll be going offline for a while pretty soon, at the end of next week, this is due to me st

Re: Going offline soon

with the sentiments already shared - you will definitely be missed. Best of luck in your new role, and please keep in touch, Andy On Fri, Feb 9, 2018 at 8:47 AM, Sergey Beryozkin <sberyoz...@gmail.com> wrote: Hi Dennis On 09/02/18 13:00, Dennis Kieselhorst wrote: Hi Sergey, when I saw the s

Re: Going offline soon

Hi Dennis On 09/02/18 13:00, Dennis Kieselhorst wrote: Hi Sergey, when I saw the subject, I thought you will just leave for a long holiday :-). Sad that you will get lost somehow :-(. Now that you've mentioned it, I start thinking going for a long holidays would be great :-). One of those

Re: Going offline soon

Thanks Carlos, hope CXF JAX-RS will have 0 bugs after I go offline :-) Sergey On 09/02/18 12:47, Carlos Sierra Andrés wrote: Best of lucks Sergey! we will miss you for sure! El 9/2/18 a las 13:24, Sergey Beryozkin escribió: Hi Francesco You are too kind, I'm just a fixer of the bugs, most

Re: Going offline soon

Hey Andriy Thanks very much, I'm humbled (knowing how truly limited I can be at times :-) ), but I'm def not the one who made CXF succeed :-). Many of us did... Speaking of which, all that time you've spent over the years, keeping tirelessly enhancing CXF JAXRS (but not only), this is what

Re: Going offline soon

On 09/02/18 12:14, Francesco Chicchiriccò wrote: Hi Sergey, sorry to hear you're leaving, I believe Apache CXF is about to loose one of its pillars - especially for JAX-RS. Wish the best for your new professional adventure, anyway! Cheers. On 09/02/2018 12:23, Sergey Beryozkin wrote: Hi Guys

Going offline soon

Hi Guys, Just a short note that I'll be going offline for a while pretty soon, at the end of next week, this is due to me starting a new job in a company with their own JAX-RS investment/interest, and joining the project which depends on that, with no CXF JAX-RS link. Please get in touch

Re: CXF with WLS 12.2.1

Hi Not that I'm aware of; perhaps you need to configure WLS 12.2.1 somehow to tell it not to use the default JAX-RS stack for your web app... Sergey On 08/02/18 09:13, Moshe Lavi (Raanana) wrote: Hi, I would like to know if there is any known limitation where both CXF 3.0.2 and WLS 12.2.1

Re: Remove obsolete RxJava code and keep RxJava2 only one

ing recently, it didn't make much sense to see both RxJava and JDA> RxJava2 in one module). JDA> On Wed, Nov 15, 2017 at 10:56 AM Sergey Beryozkin < sberyoz...@gmail.com> JDA> wrote: Hi cxf-rt-rs-extension-rx ships the code for both (old) RxJava and RxJava2 code. It supports

Re: Reactive Streams dependency in Project Reactor module

thoughts yet, since my use case is just taking an existing Flux/Mono and piping it to a AsyncResponse (nothing to do with client). Granted, by doing that, I'm relying on internal CXF code, but it works. John On Sun, Feb 4, 2018 at 2:04 PM Sergey Beryozkin <sberyoz...@gmail.com> wrote: Th

Re: Reactive Streams dependency in Project Reactor module

The same though applies to the client code - it makes no sense on the server side, so may be it is just simpler to make that dep non-optional for the consistency purpose, up to you guys... Sergey On 04/02/18 18:57, Sergey Beryozkin wrote: You've already concluded it is a bug... I recall now

Re: Reactive Streams dependency in Project Reactor module

; On Sun, Feb 4, 2018 at 12:49 PM Sergey Beryozkin <sberyoz...@gmail.com> JDA> wrote: Why should be optional ? Sergey On 04/02/18 14:00, John D. Ament wrote: Hi, As far as I can tell, the dependency on reactive streams isn't optional in the project reactor module. I'm wondering, was t

Re: [cxf] branch master updated: update swagger-core to latest version

Hi Dennis Np, sometimes I miss the failures as well :-). As I said earlier, it looks like 1.5.18 went to a pre 1.5.16 model. The Swagger 2 to Open Api conversion test does pass with 1.5.18 in 3.1.x but note the conversion filter is diff betweem 3.1.x and the master; in 3.1.x, in

Re: [cxf] branch master updated: update swagger-core to latest version

FYI, that jenkins job did not reach these tests: [INFO] Apache CXF JAX-RS System Tests . SKIPPED On 01/02/18 14:24, Sergey Beryozkin wrote: Hi Dennis All related tests in systests/jaxrs fail if I run then directly from systests/jaxrs: [ERROR] Errors: [ERROR

Re: [cxf] branch master updated: update swagger-core to latest version

nTest.doTestApiListingIsProperlyReturnedJSON:137->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:147 » InternalServerError [ERROR] SwaggerToOpenApiConversionTest.testOpenApiJSON:104 » InternalServerError HTTP ... Can you try the same please ? Thanks, Sergey On 01/02/18 14:10, Sergey Beryozkin wrote: Hi Denn

Re: [cxf] branch master updated: update swagger-core to latest version

Hi Dennis All Swagger 2 tests in systests/jaxrs... Let me rebuild everything and try again Thanks, Sergey On 01/02/18 14:04, Dennis Kieselhorst wrote: Hi Sergey, which tests are failing for you? I don't see any related test failures here:

Re: [cxf] branch master updated: update swagger-core to latest version

/18 09:33, Sergey Beryozkin wrote: Hi Dennis We were looking with Francesco at this version and saw some issues, do systest/jaxrs tests pass for you ? Thanks, Sergey On 01/02/18 09:30, d...@apache.org wrote: This is an automated email from the ASF dual-hosted git repository. deki pushed

Re: [cxf] branch master updated: update swagger-core to latest version

Hi Dennis We were looking with Francesco at this version and saw some issues, do systest/jaxrs tests pass for you ? Thanks, Sergey On 01/02/18 09:30, d...@apache.org wrote: This is an automated email from the ASF dual-hosted git repository. deki pushed a commit to branch master in

Re: New Logging interceptors

interceptors to the interceptor chain if I explicitly set the system property to "true". Otherwise nothing was logged. Colm. On Fri, Jan 19, 2018 at 11:15 AM, Sergey Beryozkin <sberyoz...@gmail.com> wrote: It can only be used to disable the logging if it is explicitly set and

Re: New Logging interceptors

"org.apache.cxf.logging.enabled" set anywhere in the systests or is it enabled a different way? Colm. On Fri, Jan 19, 2018 at 11:00 AM, Sergey Beryozkin <sberyoz...@gmail.com> wrote: These new interceptors are used in systests, no problems. That property is used to switch the logging on

Re: New Logging interceptors

These new interceptors are used in systests, no problems. That property is used to switch the logging on/off dynamically... Cheers, Sergey On 19/01/18 10:56, Colm O hEigeartaigh wrote: Hi all, With the old logging interceptors in CXF core (org.apache.cxf.interceptor) you just had to attach

Re: Failing tests with latest JDK

I mean, does it still work with the older Java 1.8.x after your PR is applied ? Sergey On 18/01/18 10:08, Sergey Beryozkin wrote: Hi Jim Will it work with the earlier JDK 1.8.x, say, 1.8.144 ? Cheers, Sergey On 18/01/18 05:09, Jim Ma wrote: Looks like this jaxb change goes into jdk8 now

Re: Failing tests with latest JDK

Hi Jim Will it work with the earlier JDK 1.8.x, say, 1.8.144 ? Cheers, Sergey On 18/01/18 05:09, Jim Ma wrote: Looks like this jaxb change goes into jdk8 now : https://github.com/javaee/jaxb-v2/commit/8cbd5e0ec41c94d743c6ae993289e7a18d00aed4 I already sent a

Re: [cxf] branch master updated: CXF-7525...

Hi Andriy Indeed, makes sense to keep it and consider extending CXF UserModel over time to be a bit richer so that it can accommodate Swagger/OpenApi/something else/ models... Cheers, Sergey On 29/12/17 17:13, Andriy Redko wrote: Hi Sergey, Got it, thanks a lot for explaining the context.

Re: [cxf] branch master updated: CXF-7525...

Hi Andriy The idea there was to support the dynamic creation of CXF JAX-RS endpoints from a given Swagger doc, i.e, support Swagger-first dev without the code-generation, by converting Swagger docs into CXF specific UserResource(s) which in turn can be used to initialize the endpoint... I've

Re: [cxf] branch master updated: CXF-7525...

Hi Andriy Just curious, why would this new module will need OpenApiParseUtils ? Thanks, Sergey

Re: How to automatically register OpenTracingFeature?

ect JDA>> There's not much happening with a CXF @Provider declaration in the extension. But at the end of the day, I'm only JDA>> dealing with a JAX-RS @Provider and that doesn't get registered since it's not a CDI bean. I don't see any issue JDA>> registe

Re: How to automatically register OpenTracingFeature?

t doesn't get registered since it's not a CDI bean. I don't see any issue JDA>> registering CXF @Provider this way as well, but its possible it's not a CDI bean still, but that's ultimately what the customizer was put in for. JDA>> John JDA>> On 2017-12-22 09:56

Re: How to automatically register OpenTracingFeature?

I'm only JDA>> dealing with a JAX-RS @Provider and that doesn't get registered since it's not a CDI bean. I don't see any issue JDA>> registering CXF @Provider this way as well, but its possible it's not a CDI bean still, but that's ultimately what the customizer was put in

Re: How to automatically register OpenTracingFeature?

g CXF @Provider this way as well, but its possible it's not a CDI bean still, but that's ultimately what the customizer was put in for. JDA>> John JDA>> On 2017-12-22 09:56, Sergey Beryozkin <sberyoz...@gmail.com> wrote: >>> Sure, I just don't understand what is

MonoReactorTest

Hi John I've started preparing the reactor invoker to be able to handle Flux which is expected to publish many items, without the service code itself having to do with tying it to AsyncResponse, as I noted earlier at CXF-7535. One thing I've noticed, if I run, in systests/jaxrs: mvn clean

Re: How to update cxf.apache.org?

Hi, On 22/12/17 15:21, John D. Ament wrote: I'd like to make some updates to the CXF website. For one, I want to add information about the MicroProfile Client API. I'm not sure if its a dedicated page or a part of http://cxf.apache.org/docs/jax-rs-client-api.html IMHO it would be easier for

Re: How to automatically register OpenTracingFeature?

JAXRSServer Customization into core and using service loader :-) Perhaps after the new year. On 2017-12-22 09:23, Sergey Beryozkin <sberyoz...@gmail.com> wrote: I was not referring the OpenTracing module offering a CDI extension, but to the work Andriy did in the CXF CDI integration where the pro

Re: How to automatically register OpenTracingFeature?

o make more JARs available, right? On 2017-12-22 08:15, Sergey Beryozkin <sberyoz...@gmail.com> wrote: It is annotated with CXF @Provider annotation - should be picked up by the CXF CDI extension Sergey On 22/12/17 13:07, John D. Ament wrote: I'm trying to finish up testing CDI inject

Re: MP client test failing

Local, Java 1.8.0_144 Sergey On 22/12/17 13:05, John D. Ament wrote: This is on your local or in jenkins? This was passing at one point, but I see it failing locally right now. Will take a look. John On 2017-12-22 05:52, Sergey Beryozkin <sberyoz...@gmail.com> wrote: Hi John Consis

Re: How to automatically register OpenTracingFeature?

It is annotated with CXF @Provider annotation - should be picked up by the CXF CDI extension Sergey On 22/12/17 13:07, John D. Ament wrote: I'm trying to finish up testing CDI injection of Context objects. The one area I'm struggling with is the automatic registration of this feature. I

MP client test failing

Hi John Consistently seeing: Method InvalidInterfaceTest.testExceptionThrownWhenInterfaceHasMethodWithPathParamAnnotationButNoURITemplate()[pri:0, instance:org.eclipse.microprofile.rest.client.tck.InvalidInterfaceTest@17579e0f] should have thrown an exception of type class

Re: OpenAPI: Swagger2 or Swagger3

Sure. I've just really asked for my own understanding in case I talk about it somewhere. Indeed, referring to OpenAPI v3 as Swagger 3 (as opposed to 2) is right, the lib versions is an impl detail... Romain, FYI, Andriy has already provided an initial impl of the OpenAPiFeature based on the

OpenAPI: Swagger2 or Swagger3

Hi How should CXF position its OpenAPI feature, as Swagger 2 or 3 ? Swagger 2 is a bit confusing, given that we have am Open Api version 3 and the existing Swagger2Feature. I know Swagger2Feature depends on swagger core/jaxrs 1.5.x, but it is still Swagger2 ? Sergey

Re: Default Priority for built in providers

, more specific type, and if it ever comes to it - the right priority value). Thanks, Sergey John On 2017-12-19 10:17, Sergey Beryozkin <sberyoz...@gmail.com> wrote: Hi John Thinking more about it, adding some protection in the form of the max priority to the built-in MBRs and MBWs w

Re: Default Priority for built in providers

specific type, and if it ever comes to it - the right priority value). Thanks, Sergey John On 2017-12-19 10:17, Sergey Beryozkin <sberyoz...@gmail.com> wrote: Hi John Thinking more about it, adding some protection in the form of the max priority to the built-in MBRs and MBWs will pr

Re: Default Priority for built in providers

priorities, it does not make much sense, the priority can help with ordering the filters/interceptors, but in case of MBR/MBW where the action affecting the streams is expected it is just to imagine... Thanks, Sergey On 19/12/17 12:08, Sergey Beryozkin wrote: I'd like to avoid starting

Re: Default Priority for built in providers

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

Re: Default Priority for built in providers

04:38, Sergey Beryozkin <sberyoz...@gmail.com> wrote: Which default providers are you referring to ? If it is MBR or MBW then their priority is implicit, based on the spec text re how to sort media types, etc. Sergey On 17/12/17 14:42, John D. Ament wrote: FWIW, I had assumed I was doing som

Re: Default Priority for built in providers

are mixed in, and the various spec conditions are applied, and only then, if a user-provided provider and a built-in provider are 2 equal candidates, then the user-provided one wins Sergey On 18/12/17 09:39, Sergey Beryozkin wrote: What exactly is falling down ? Sergey On 17/12/17 21:46, John

Re: Default Priority for built in providers

e them with USER + 1 to avoid the issue? John -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/

Re: Default Priority for built in providers

notate them with USER + 1 to avoid the issue? John -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/

Re: Push does not work

Thanks, yes I was getting ready to do what was printed in the error message, but it was resolved... Interesting, should some of CXF error messages advice to send a message to us...@cxf.apache.org :-) ? Sergey On 07/12/17 10:25, Colm O hEigeartaigh wrote: A similar error was reported to INFRA

Re: Push does not work

Hi Andriy Yes, thanks, the classical solution (reboot the computer or, in this case, try tomorrow :-)) always works Cheers, Sergey On 06/12/17 23:54, Andriy Redko wrote: Hi Sergey, Has it been resolved? Have nothing to push but could do just whitespace. Let me know if you want me to try.

Push does not work

Hi Seeing my push being repeatedly rejected remote: This repository is currently out of sync, please remote: contact us...@infra.apache.org! To https://gitbox.apache.org/repos/asf/cxf.git ! [remote rejected] master -> master (pre-receive hook declined) with 'git pull' showing all is up to

Re: Implementing MicroProfile's Rest Client here at CXF?

l as JDA> handle any response code. JDA> You can read more about the API and specification at JDA> https://github.com/eclipse/microprofile-rest-client JDA> You can also see the base impl I've started on at JDA> https://github.com/johnament/cxfmprestclient JDA> John -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/

Re: [VOTE] - Release Apache CXF Fediz 1.3.3

+1 Sergey On 23/11/17 17:04, Colm O hEigeartaigh wrote: This is a vote to release Apache CXF Fediz 1.3.3. This is the last planned release of Fediz 1.3.x. Issued fixed: https://issues.apache.org/jira/projects/FEDIZ/versions/12340453 Git tag:

Re: [VOTE] - Release Apache CXF Fediz 1.4.3

+1 Sergey On 23/11/17 15:59, Colm O hEigeartaigh wrote: This is a vote to release Apache CXF Fediz 1.4.3. Issues fixed: https://issues.apache.org/jira/projects/FEDIZ/versions/12341612 Git tag: https://github.com/apache/cxf-fediz/tree/fediz-1.4.3 Maven artifacts:

Re: [VOTE] - Release Apache CXF 3.0.16

+1 Sergey On 23/11/17 13:03, Colm O hEigeartaigh wrote: This is a vote to release Apache CXF 3.0.16. This will be the last planned release of CXF 3.0.x. Issues fixed: https://issues.apache.org/jira/projects/CXF/versions/12341568 Git tag: https://github.com/apache/cxf/tree/cxf-3.0.16 Maven

Re: New Java 9 master

/17 03:42, Jeff Genender wrote: On Nov 16, 2017, at 7:02 AM, Sergey Beryozkin <sberyoz...@gmail.com> wrote: Indeed it will take a long time for a team with the limited resources to have CXF embracing Java 9. Postponing the start of this long process for 2 years or so and wait for the

Re: New Java 9 master

then but honestly I personally have no intention to ever switch to java 9. I will probably wait if java 10 brings anything convincing. Christian 2017-11-16 16:57 GMT+01:00 Sergey Beryozkin <sberyoz...@gmail.com>: Sorry, looks like a pretty messy and non convincing plan to me. Simple for users and us ? Ser

Re: New Java 9 master

15:57, Sergey Beryozkin wrote: Sorry, looks like a pretty messy and non convincing plan to me. Simple for users and us ? Seriously ? This would be Java 9 only branch would be released probably once in at least a year time from now. Cheers, Sergey On 16/11/17 15:42, Christian Schneider wrote: So

Re: New Java 9 master

ase with Java 9 but make sure that most modules can run with java 8 and only the few java 9 modules require java 9. Not sure if that is possible but it would make our and the users life a lot simpler than a pure java 9 master. Christian 2017-11-16 15:02 GMT+01:00 Sergey Beryozkin <sberyoz...@gma

Re: New Java 9 master

I remember how reluctant we were when it came to adopting the previous CS> java versions like 7 and 8 as minimal requirement I think it makes sense to CS> do this rather slowly. CS> Christian CS> 2017-11-16 13:31 GMT+01:00 Sergey Beryozkin <sberyoz...@gmail.com>: Hi Andriy I'm only

Re: Remove obsolete RxJava code and keep RxJava2 only one

her module to support, for users - out of the box integration. With new module we could collect a bit more insights if people use it or not. No use - drop in next releases. Thanks. Best Regards, Andriy Redko On Nov 16, 2017 4:42 AM, "Sergey Beryozkin" <*sberyoz...@gmail.

Re: Remove obsolete RxJava code and keep RxJava2 only one

le we could collect a bit more insights if people use it or not. No use - drop in next releases. Thanks. Best Regards, Andriy Redko On Nov 16, 2017 4:42 AM, "Sergey Beryozkin" <*sberyoz...@gmail.com <mailto:sberyoz...@gmail.com>*> wrote: Hi Andriy As I said, introducing

Re: New Java 9 master

Obvious typo there, that yes in a Java 9 only master it won;t work with Java 8. To be honest I don't understand why would CXF dev would be effectively frozen which would be the case if no Java 9 master is not opened Sergey On 16/11/17 13:09, Sergey Beryozkin wrote: Yes, in a Java 9 only

Re: New Java 9 master

were when it came to adopting the previous java versions like 7 and 8 as minimal requirement I think it makes sense to do this rather slowly. Christian 2017-11-16 13:31 GMT+01:00 Sergey Beryozkin <sberyoz...@gmail.com>: Hi Andriy I'm only presuming that yes, a Java 9 only master woul

Re: New Java 9 master

On Nov 16, 2017, at 6:26 PM, Sergey Beryozkin <sberyoz...@gmail.com> wrote: Hi Freeman By the way, what is status of your Java 9 branch, I understand it was really about using Java 9 to compile and load CXF 3.2.x ? If so then may be it can be merged to 3.2.x ? Cheers, Sergey On 16/11

Re: New Java 9 master

Hi Andriy I'm only presuming that yes, a Java 9 only master would have to support the new Java 9 modules system, so I'd say a lot of exciting work would await for the CXF dev community :-) Cheers, Sergey On 16/11/17 12:19, Andriy Redko wrote: Hey Sergey, Do we have a goal to support Java 9

Re: Remove obsolete RxJava code and keep RxJava2 only one

for users - out of the box integration. With new module we could collect a bit more insights if people use it or not. No use - drop in next releases. Thanks. Best Regards,      Andriy Redko On Nov 16, 2017 4:42 AM, "Sergey Beryozkin" <*sberyoz...@gmail.com <mailto:s

Re: Remove obsolete RxJava code and keep RxJava2 only one

o ask. For us - yet another module to support, for users - out of the box integration. With new module we could collect a bit more insights if people use it or not. No use - drop in next releases. Thanks. Best Regards,      Andriy Redko On Nov 16, 2017 4:42 AM, "Sergey Beryozkin" <*s

Re: Introduction

Hi Andrei Thank you for the introduction and welcome :-) Please keep your review comments coming, very much appreciated Cheers, Sergey On 16/11/17 11:17, Andrei Ivanov wrote: Hi, As requested by Sergey Beryozkin, I'm sending this email to introduce myself :-) I'm a Java developer (though

Re: Remove obsolete RxJava code and keep RxJava2 only one

hom to ask. For us - yet another module to support, for users - out of the box integration. With new module we could collect a bit more insights if people use it or not. No use - drop in next releases. Thanks. Best Regards, Andriy Redko On Nov 16, 2017 4:42 AM, "Sergey Beryozkin" &

Re: New Java 9 master

master branch to work with 18.3 as well, then maybe consider a new master branch for 18.9 some time next year. What do you think? Thanks, Andy [1] http://www.oracle.com/technetwork/java/eol-135779.html On Wed, Nov 15, 2017 at 5:47 AM, Sergey Beryozkin <sberyoz...@gmail.com> wrote: Hi Should w

Re: New Java 9 master

It's pretty simple really. It's about having a new impetus for the CXF development. Without a Java 9 only master CXF will be about fixing the bugs only. JAX-WS is done long time ago, next version of JAX-RS will take N amount of time to materialize. Java 9 with its Flow class will let CXF do

Re: New Java 9 master

? Thanks, Andy [1] http://www.oracle.com/technetwork/java/eol-135779.html On Wed, Nov 15, 2017 at 5:47 AM, Sergey Beryozkin <sberyoz...@gmail.com> wrote: Hi Should we open a new Java 9 only master soon enough ? Thanks, Sergey

Re: Remove obsolete RxJava code and keep RxJava2 only one

a2 in one module). JDA> On Wed, Nov 15, 2017 at 10:56 AM Sergey Beryozkin <sberyoz...@gmail.com> JDA> wrote: Hi cxf-rt-rs-extension-rx ships the code for both (old) RxJava and RxJava2 code. It supports returning RxJava2 Flowable and Observable on the server and accepting it on the

Re: Remove obsolete RxJava code and keep RxJava2 only one

AM Sergey Beryozkin <sberyoz...@gmail.com> wrote: Hi cxf-rt-rs-extension-rx ships the code for both (old) RxJava and RxJava2 code. It supports returning RxJava2 Flowable and Observable on the server and accepting it on the client, and the same for the (old) RxJava Observable... Whil

Remove obsolete RxJava code and keep RxJava2 only one

Hi cxf-rt-rs-extension-rx ships the code for both (old) RxJava and RxJava2 code. It supports returning RxJava2 Flowable and Observable on the server and accepting it on the client, and the same for the (old) RxJava Observable... While even the (old) RxJava code is very new for CXF, the

New Java 9 master

Hi Should we open a new Java 9 only master soon enough ? Thanks, Sergey

Re: JIRA Karma?

, Andy On Wed, Nov 8, 2017 at 9:39 PM, John D. Ament <johndam...@apache.org> wrote: I believe this is resolved. I neglected to respond, but I can confirm I have the right permissions now. Thanks. On 2017-11-06 06:37, Sergey Beryozkin <sberyoz...@gmail.com> wrote: Hi John I s

Re: JIRA Karma?

Hi John I see you being in the Committers group and Issue Permissions such as Assign to Others is allowed to Committers Dan, what else should be done to let committers assign issues to themselves. May be more options are visible to JIRA admins... Thanks, Sergey On 29/10/17 18:36, John D.

Re: [cxf] branch master updated: Add doPrivs

Hi Andy Thanks, FYI, just in case, there could be some helper methods available in https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/common/util/ReflectionUtil.java Cheers. Sergey On 26/10/17 16:55, amccri...@apache.org wrote: This is an automated email from the ASF

Re: [cxf] branch master updated: [CXF-7532]REST on JMS transport can't handle the request message with text messageType

) Fang Red Hat, Inc. FuseSource is now part of Red Hat On Oct 20, 2017, at 5:59 AM, Sergey Beryozkin <sberyoz...@gmail.com <mailto:sberyoz...@gmail.com>> wrote: Some JAX-RS providers check Reader or XMLStreamReader if InputStream is null. But at the moment, Freeman, please do a bi

Re: [cxf] branch master updated: [CXF-7532]REST on JMS transport can't handle the request message with text messageType

ust clean up. － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat On Oct 19, 2017, at 5:16 PM, Sergey Beryozkin <sberyoz...@gmail.com> wrote: If we assume that checking Reader can be useful in the general sense, then may be lets keep things as is, with the

Re: [cxf] branch master updated: [CXF-7532]REST on JMS transport can't handle the request message with text messageType

If we assume that checking Reader can be useful in the general sense, then may be lets keep things as is, with the minor cleanup only... Sergey On 19/10/17 10:05, Sergey Beryozkin wrote: Hi Freeman Reader may likely need to be set too for SOAP, and I recall checking Reader somewhere else too

Re: [cxf] branch master updated: [CXF-7532]REST on JMS transport can't handle the request message with text messageType

, Sergey Beryozkin <sberyoz...@gmail.com <mailto:sberyoz...@gmail.com>> wrote: The other thing is, should JMS transport itself set ReaderInputStream as InputStream on the message, as opposed to patching the JAX-RS code in various places ? Sergey On 19/10/17 09:44, Sergey Beryozki

Re: [cxf] branch master updated: [CXF-7532]REST on JMS transport can't handle the request message with text messageType

The other thing is, should JMS transport itself set ReaderInputStream as InputStream on the message, as opposed to patching the JAX-RS code in various places ? Sergey On 19/10/17 09:44, Sergey Beryozkin wrote: Hi Freeman Can you move ReaderInputStream to the CXF core where CachedInputStream

Re: [cxf] branch master updated: [CXF-7532]REST on JMS transport can't handle the request message with text messageType

ressUrlEncoded = "jms:jndi:dynamicQueues/test.jmstransport.text" + + "?jndiInitialContextFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactory" + + "=dynamicQueues/test.jmstransport.response" + + "=tcp://localhost:&qu

Re: Swagger2Feature bug caused by removal of isScan() check

I've introduced the property but it is set to false in 3.2.x Sergey On 07/10/17 17:17, Sergey Beryozkin wrote: Hi Dennis Thanks very much, my fault really as I did not see a point in keeping this property in 3.2.x and indeed, as you imply, all tests were/are still passing, but I guess more

Re: [JAXRS][CLIENT] rx() executor

Hi Romain Was the idea it would be passed via one of rx() methods ? Though we can def start with 1. for sure, what property name do you suggest ? The look up (3.), would it require a non-SE dependency ? Cheers, Sergey On 07/10/17 17:18, Romain Manni-Bucau wrote: Hi guys, seems

Re: Swagger2Feature bug caused by removal of isScan() check

Hi Dennis Thanks very much, my fault really as I did not see a point in keeping this property in 3.2.x and indeed, as you imply, all tests were/are still passing, but I guess more preparation should've gone into it. Setting a scan to true did never work in OSGI as far as I know, may be in

Re: [VOTE] - Release Apache CXF DOSGi 2.3.0 .. take 2

me. Christian -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/

Re: [VOTE] - Release Apache CXF DOSGi 2.3.0

g: CS> https://gitbox.apache.org/repos/asf?p=cxf-dosgi.git;a=tag;h=refs/tags/cxf-dosgi-2.3.0 CS> Maven Artifacts: CS> https://repository.apache.org/content/repositories/orgapachecxf-1094/ CS> +1 from me. CS> Christian -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/

Re: 3.2 on web site...

Hi It's gone from 3.2.0, still in 3.1.x Thanks, Sergey On 15/09/17 09:52, Dennis Kieselhorst wrote: Hi, I just continued fixing broken links. http://cxf.apache.org/docs/atom-logging.html -> http://cxf.apache.org/javadoc/latest/org/apache/cxf/management/web/logging/atom/package-summary.html

Re: [VOTE] - Release Apache CXF Fediz 1.4.2

+1 Sergey On 12/09/17 16:57, Colm O hEigeartaigh wrote: This is a vote to release Apache CXF Fediz 1.4.2. It consists of an update to use the latest CXF 3.1.13 release, as well as some fixes relating to logout, and a serialization fix in the Fediz core. Artifacts:

Re: [VOTE] Apache CXF 3.2.0

. Christian On 11.09.2017 12:33, Sergey Beryozkin wrote: Christian Looks like it is only happening with the DOSGI, if you try to update it to 3.2.0 - but does the issue you see with updating DOSGi to 3.2.0 warrants -1 ? Can't you just wait till 3.2.1 ? Cheers, Sergey On 11/09/17 11:30, Christian

Re: [VOTE] Apache CXF 3.2.0

Christian Looks like it is only happening with the DOSGI, if you try to update it to 3.2.0 - but does the issue you see with updating DOSGi to 3.2.0 warrants -1 ? Can't you just wait till 3.2.1 ? Cheers, Sergey On 11/09/17 11:30, Christian Schneider wrote: Reverting my vote to -1 until we

Re: [DISCUSS] Status of 3.0.x...

Indeed, good plan... Sergey On 06/09/17 20:14, Andriy Redko wrote: I think that keeping 3.2.x on master would make sense, at least till 3.2.1. As Dennis pointed out, with Java 9 just a few weeks away we may branch off 3.2 later and work on 3.3 (master) to make it good Jigsaw citizen.

Re: [VOTE] Apache CXF 3.2.0

+1 Thanks, Sergey On 06/09/17 19:14, Daniel Kulp wrote: It’s been 2 years since the last major CXF release.We have well over 100 JIRA’s of new features and enhancements that are only targeted toward 3.2. Let’s get it out! Staging repo:

Re: cxf git commit: fixed NPE

Thanks Dennis, you were right when you were talking about simplifying the code and having the default licenses removed :-) Cheers, Sergey On 05/09/17 20:32, d...@apache.org wrote: Repository: cxf Updated Branches: refs/heads/master 70ac8edcc -> 3453c6cca fixed NPE Project:

Re: CXF 3.2?

Hey Andriy IMHO it might wait till 3.2.1 (may be we can do a camel cxf demo making sure the context can flow from Camel to CXF and vice versa) as a POC and tweak few things along the way ? If we doc it right now in a bit of a hurry then we will have less space for the changes ? Thanks,

  1   2   3   4   5   6   7   8   9   10   >