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

[Sergey Beryozkin]

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 CXF 3.2.10 and CXF 3.3.3.   3.3.3 also required
> > > the release of cxf-build-utils 3.4.3 to pickup the new Checkstyle and
> PMD
> > > configs required by the new maven plugins.  This fixes over 30 JIRA
> > issues
> > > reported by users.
> > >
> > >
> > > Staging areas:
> > > buildutils:
> > > https://repository.apache.org/content/repositories/orgapachecxf-1142
> > > 3.2.10:
> > > https://repository.apache.org/content/repositories/orgapachecxf-1143
> > > 3.3.3:
> > > https://repository.apache.org/content/repositories/orgapachecxf-1144
> > >
> > > Tags:
> > > 3.2.10:
> > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=commit;h=abd1a3d98db6abe7736b3730c418984083a7add0
> > > <
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=commit;h=abd1a3d98db6abe7736b3730c418984083a7add0
> > > >
> > > 3.3.3:
> > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=commit;h=c7806cbcbba6005bd6f6af75cf71696d82c5ba4d
> > > <
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=commit;h=c7806cbcbba6005bd6f6af75cf71696d82c5ba4d
> > > >
> > > buildutils:
> > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cxf-build-utils.git;a=commit;h=dadf870a0c73aa906fc8de4a6f072319ad88ff85
> > > <
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cxf-build-utils.git;a=commit;h=dadf870a0c73aa906fc8de4a6f072319ad88ff85
> > > >
> > >
> > > Here is my +1
> > >
> > >
> > > --
> > > Daniel Kulp
> > > dk...@apache.org  - http://dankulp.com/blog <
> > > http://dankulp.com/blog>
> > > Talend Community Coder - http://talend.com 
> > >
> >
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>

Re: [VOTE] CXF 3.2.5/3.1.16

[Sergey Beryozkin]

+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  rmannibucau> |
> LinkedIn  | Book
>  ee-8-high-performance>
>
>
> Le mar. 19 juin 2018 à 09:24, Francesco Chicchiriccò 
> a écrit :
>
> > On 19/06/2018 01:35, Daniel Kulp wrote:
> > > This is a vote to release CXF 3.2.5 and 3.1.16.   The 3.2.5 staging
> area
> > also include releases of cxf-buildutils and cxf-xjc-utils as they were
> > needed for the release.
> > >
> > >
> > > Staging repos:
> > > 3.1.16:
> > > https://repository.apache.org/content/repositories/orgapachecxf-1116/
> <
> > https://repository.apache.org/content/repositories/orgapachecxf-1116/>
> > > 3.2.5:
> > > https://repository.apache.org/content/repositories/orgapachecxf-1117/
> <
> > https://repository.apache.org/content/repositories/orgapachecxf-1117/>
> > >
> > >
> > > Tags:
> > > 3.1.16:
> > >
> > https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=
> 31216129250266470a3076411a3390f79341c6fb
> > <
> > https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=
> 31216129250266470a3076411a3390f79341c6fb
> > >
> > > 3.2.5:
> > >
> > https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=
> 4bc4bcb1539150f8f1149073d90c65a60ed7d4e3
> > <
> > https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=
> 4bc4bcb1539150f8f1149073d90c65a60ed7d4e3
> > >
> > > Buildutils:
> > >
> > https://gitbox.apache.org/repos/asf?p=cxf-build-utils.git;a=tag;h=
> 33533c136d2a11becdf06f21ed5f3ecc58bfdeda
> > <
> > https://gitbox.apache.org/repos/asf?p=cxf-build-utils.git;a=tag;h=
> 33533c136d2a11becdf06f21ed5f3ecc58bfdeda
> > >
> > > Xjc-utils:
> > >
> > https://gitbox.apache.org/repos/asf?p=cxf-xjc-utils.git;a=tag;h=
> 940e30464842b68edfc7be79861508c39f7111e9
> > <
> > https://gitbox.apache.org/repos/asf?p=cxf-xjc-utils.git;a=tag;h=
> 940e30464842b68edfc7be79861508c39f7111e9
> > >
> >
> >
> > +1
> > Regards.
> >
> > --
> > Francesco Chicchiriccò
> >
> > Tirasa - Open Source Excellence
> > http://www.tirasa.net/
> >
> > Member at The Apache Software Foundation
> > Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
> > http://home.apache.org/~ilgrosso/
> >
> >
>

Re: Going offline soon

[Sergey Beryozkin]

Hi Christian

Thanks, I wish I had contributed something major to JAX-RS :-), but on 
reflection, I think my main contrib was about hanging at the spec list 
and arguing with the guys :-).
And yeah, the difficult questions, I've never hesitated to ask Dan or 
indeed yourself to look into them :-) lol


Thanks Christian, hope you are doing well

Sergey
On 11/02/18 10:31, Christian Schneider wrote:

Hi Sergey,

thanks for all your great contributions to CXF. JAX-RS would not be
anywhere the level it is without you.
We will all miss you here and I hope we can still ask you from time to time
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 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 privately if you reckon I might be of some help,

Thank you all and best of luck :-)

Sergey

Re: Going offline soon

[Sergey Beryozkin]

Hi Andy

Many thanks for supporting the project and also helping to improve the 
test coverage of the CXF JAX-RS code :-),


Thanks, Sergey
On 09/02/18 16:13, Andy McCright wrote:

Hi Sergey,

Sorry to see you go.  You have definitely been a great mentor for me on
this project, and I agree 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 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 dreams of mine yet to come true :-)


  From my own experience I know it's hard to contribute without dedicated
time at work. I hope you'll
find time to follow us and share some ideas you get in your new project.

Thanks for all the work you've done and all the best for the future.

Thanks and all the best, Sergey



Cheers

Dennis

Re: Going offline soon

[Sergey Beryozkin]

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 dreams of mine yet to come true :-)

 From my own experience I know it's hard to contribute without dedicated time 
at work. I hope you'll
find time to follow us and share some ideas you get in your new project.

Thanks for all the work you've done and all the best for the future.


Thanks and all the best, Sergey



Cheers
Dennis

Re: Going offline soon

[Sergey Beryozkin]

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 of them I created
myself, lol :-)
The good news is the dev team is large now and things will surely go
well...
I'll be around anyway and who knows may be get a chance to contribute
again to some parts of CXF...

Cheers, Sergey
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,
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 privately if you reckon I might be of some help,

Thank you all and best of luck :-)

Sergey

Re: Going offline soon

[Sergey Beryozkin]

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 did help CXF 
JAXRS get to the next level, I and we've all appreciated it and please 
keep contributing :-).


I'll be around most of the next week, and talk to you soon

Thanks, Sergey

On 09/02/18 14:24, Andriy Redko wrote:

Hey Sergey,

You are the one who made CXF to be what it is today. I won't be affraid to add 
that you are
the exceptional example of true leader, contributor and mentor (for many of 
us). I know how
hard it is to find the time to dedicate to the project besides working hours, 
but I really
hope you would be able to pull it off, even just a bit.

I wish you the best at the new place. You are the foundational part of CXF and 
you will
always be, that's a given. Thank you so much for all these years of dedication 
and hard work.
You are one of the brightest people I am honored to know!

Best Regards,
 Andriy Redko



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

SB> Please get in touch privately if you reckon I might be of some help,

SB> Thank you all and best of luck :-)

SB> Sergey

Re: Going offline soon

[Sergey Beryozkin]

Hi Francesco

You are too kind, I'm just a fixer of the bugs, most of them I created 
myself, lol :-)

The good news is the dev team is large now and things will surely go well...
I'll be around anyway and who knows may be get a chance to contribute 
again to some parts of CXF...


Cheers, Sergey
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,
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 privately if you reckon I might be of some help,

Thank you all and best of luck :-)

Sergey

Going offline soon

[Sergey Beryozkin]

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 privately if you reckon I might be of some help,

Thank you all and best of luck :-)

Sergey

Re: CXF with WLS 12.2.1

[Sergey Beryozkin]

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 can work together, as that was not an issue with WLS 12.1.3?

Issue - Resource Interface that contain the signature of @Multipart with 
Attachment type is failed in Jersey validation.



public abstract Response applyBulkDependencies(@PathParam("fwa-id") String paramString1, @Multipart("dependencies") InputStream 
paramInputStream, @Multipart("dependencies") Attachment paramAttachment, @QueryParam("fwa-version") String paramString2, 
@QueryParam("sitegroup-id") String paramString3, @QueryParam("sitegroup-name") String paramString4, 
@QueryParam("file-name") String paramString5);



Exception

[] from public void org.apache.cxf.jaxrs.provider.AbstractJAXBProvider.setExtraClass(java.lang.Class[]) is not resolvable to a concrete 
type.; source='public void org.apache.cxf.jaxrs.provider.AbstractJAXBProvider.setExtraClass(java.lang.Class[])', [WARNING] Parameter 1 of type java.lang.Class[] from public void 
org.apache.cxf.jaxrs.provider.AbstractJAXBProvider.setExtraClass(java.lang.Class[]) is not resolvable to a concrete type.; source='public void 
org.apache.cxf.jaxrs.provider.AbstractJAXBProvider.setExtraClass(java.lang.Class[])', [WARNING] Parameter 1 of type java.util.Map, java.lang.String> from 
public void org.apache.cxf.jaxrs.provider.RequestDispatcherProvider.setEnumResources(java.util.Map, java.lang.String>) is not resolvable to a concrete type.; 
source='public void org.apache.cxf.jaxrs.provider.RequestDispatcherProvider.setEnumResources(java.util.Map)', [WARNING] Parameter 1 of type T from public void 
org.apache.cxf.jaxrs.provider.AbstractCachingMessageProvider.setObject(T) is not resolvable to a concrete type.; source='public void 
org.apache.cxf.jaxrs.provider.AbstractCachingMessageProvider.setObject(java.lang.Object)', [WARNING] Parameter 1 of type javax.ws.rs.ext.MessageBodyWriter from public void 
org.apache.cxf.jaxrs.provider.CachingMessageBodyWriter.setDelegatingWriter(javax.ws.rs.ext.MessageBodyWriter) is not resolvable to a concrete type.; source='public void 
org.apache.cxf.jaxrs.provider.CachingMessageBodyWriter.setDelegatingWriter(javax.ws.rs.ext.MessageBodyWriter)', [WARNING] Parameter 1 of type 
java.util.List from public void 
org.apache.cxf.jaxrs.provider.CachingMessageBodyWriter.setDelegatingWriters(java.util.List) is not resolvable to a concrete type.; source='public 
void org.apache.cxf.jaxrs.provider.CachingMessageBodyWriter.setDelegatingWriters(java.util.List)', [WARNING] Parameter 1 of type T from public void 
org.apache.cxf.jaxrs.provider.AbstractCachingMessageProvider.setObject(T) is not resolvable to a concrete type.; source='public void 
org.apache.cxf.jaxrs.provider.AbstractCachingMessageProvider.setObject(java.lang.Object)', [WARNING] Parameter 1 of type javax.ws.rs.ext.MessageBodyReader from public void 
org.apache.cxf.jaxrs.provider.CachingMessageBodyReader.setDelegatingReader(javax.ws.rs.ext.MessageBodyReader) is not resolvable to a concrete type.; source='public void 
org.apache.cxf.jaxrs.provider.CachingMessageBodyReader.setDelegatingReader(javax.ws.rs.ext.MessageBodyReader)', [WARNING] Parameter 1 of type 
java.util.List from public void 
org.apache.cxf.jaxrs.provider.CachingMessageBodyReader.setDelegatingReaders(java.util.List) is not resolvable to a concrete type.; source='public 
void org.apache.cxf.jaxrs.provider.CachingMessageBodyReader.setDelegatingReaders(java.util.List)', [WARNING] Parameter 1 of type T from public void 
org.apache.cxf.jaxrs.provider.AbstractCachingMessageProvider.setObject(T) is not resolvable to a concrete type.; source='public void 
org.apache.cxf.jaxrs.provider.AbstractCachingMessageProvider.setObject(java.lang.Object)', [FATAL] No injection source found for a parameter of type public abstract javax.ws.rs.core.Response

com.amdocs.ms.frameworkagreementextractor.resources.interfaces.IExtractrequestResource.applyBulkDependencies(java.lang.String,java.io.InputStream,org.apache.cxf.jaxrs.ext.multipart.Attachment,java.lang.String,java.lang.String,java.lang.String,java.lang.String)
 at index 1.; source='ResourceMethod{httpMethod=POST, 
consumedTypes=[multipart/form-data], producedTypes=[application/json], 
suspended=false, suspendTimeout=0, suspendTimeoutUnit=MILLISECONDS, 
invocable=Invocable{handler=ClassBasedMethodHandler{handlerClass=interface 
com.amdocs.ms.frameworkagreementextractor.resources.interfaces.IExtractrequestResource,
 handlerConstructors=[]}, definitionMethod=public abstract 
javax.ws.rs.core.Response 

Re: Remove obsolete RxJava code and keep RxJava2 only one

[Sergey Beryozkin]

I'd still favour removing RxJava, if you would like to keep it then I 
guess the new module would indeed have to be introduced


Cheers, Sergey

On 06/02/18 03:49, John D. Ament wrote:

I was just about to remove the optional marking on reactive streams, and
noticed that rxjava was still around.  I guess it was decided to keep it?
I'll point out, this now makes the dependency chain even harder to follow
(since rxjava2 uses reactive streams, but rxjava does not).

John

On Wed, Nov 15, 2017 at 6:53 PM Andriy Redko <drr...@gmail.com> wrote:


Hey Sergey,

That would be ideal I think (move RxJava into separate module). RxJava2 and
RxJava are quite different frameworks, some people just stuck with RxJava
so
we could support them there. Thanks.

Best Regards,
 Andriy Redko

JDA> What about just leaving the old RxJava code in a module by itself
(when I
JDA> was looking 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 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 reality is
that RxJava has been around for a while now and with RxJava2 embracing
org.reactivestreams, it's hard to see CXF users preferring to start with
the (old) RxJava.



The other minor problem is that cxf-rt-rs-extension-rx has optional
RxJava and RxJava2 deps to be able to ship the relevant code in the same
module and splitting it into 2 modules will be too much at this point.



I suggest that unless some users confirm (I CC to the users) that they
need to use the (old) RxJava code, then we just remove it and make
things much simpler...



Thanks, Sergey

Re: Reactive Streams dependency in Project Reactor module

[Sergey Beryozkin]

Hi John

I think I indeed sent some confusing messages yesterday :-)

OK, what I meant was that the module had the original code to do with 
supporting the client only Rx invocations (such a client code can be 
server scoped as in your example), and the server only invocations (Json 
subcriber).


When I moved some of the server specific code into a shared base module 
I thought, after the 1st iteration, where only the JSON subscriber was 
shared, that it was OK to make that module optional - as it was of no 
use in the client-only scope and was not strictly needed for the server 
too, but during the 2nd/3rd iteration, when I pushed some more common 
code there affecting the JAXRSInvoker extensions, I should've removed 
the optional dep...


Perhaps making that dependency required is the simplest way forward

Sergey

On 04/02/18 19:22, John D. Ament wrote:

Well, now that I understand that it was meant specifically for client only
(its kind of odd, because JsonStreamingAsyncSubscriber is really for
subscribers, which is more on the server produced response).

What if we just had distinct modules for reactive-client and
reactive-server?

But either way, I'm not sure I follow your 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:


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, I made it optional because that code makes no sense on the
client side only, while the reactive streams api is also pulled from the
reactor dep...

Cheers, Sergey
On 04/02/18 18:12, Andriy Redko wrote:

Same conclusion, it shouldn't be optional/provided.
Thanks for spotting it.

Best Regards,
  Andriy Redko

JDA> That's what I'm asking basically.  If you look at
JDA>


https://github.com/apache/cxf/blob/master/rt/rs/extensions/reactor/pom.xml#L47-L49


JDA> I
JDA> don't believe it should be provided/optional.

JDA> 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 this just a typo,
or am I
missing something?

John

Re: Reactive Streams dependency in Project Reactor module

[Sergey Beryozkin]

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, I made it optional because that code makes no sense on the 
client side only, while the reactive streams api is also pulled from the 
reactor dep...


Cheers, Sergey
On 04/02/18 18:12, Andriy Redko wrote:

Same conclusion, it shouldn't be optional/provided.
Thanks for spotting it.

Best Regards,
 Andriy Redko

JDA> That's what I'm asking basically.  If you look at
JDA> 
https://github.com/apache/cxf/blob/master/rt/rs/extensions/reactor/pom.xml#L47-L49 


JDA> I
JDA> don't believe it should be provided/optional.

JDA> 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 this just a typo, 
or am I

missing something?

John

Re: Reactive Streams dependency in Project Reactor module

[Sergey Beryozkin]

You've already concluded it is a bug...

I recall now, I made it optional because that code makes no sense on the 
client side only, while the reactive streams api is also pulled from the 
reactor dep...


Cheers, Sergey
On 04/02/18 18:12, Andriy Redko wrote:

Same conclusion, it shouldn't be optional/provided.
Thanks for spotting it.

Best Regards,
 Andriy Redko

JDA> That's what I'm asking basically.  If you look at
JDA> 
https://github.com/apache/cxf/blob/master/rt/rs/extensions/reactor/pom.xml#L47-L49
JDA> I
JDA> don't believe it should be provided/optional.

JDA> 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 this just a typo, or am I
missing something?

John

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

[Sergey Beryozkin]

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 ContainerResponseFilter it sees Swagger instance as a response 
body, on the master it sees a String...


Thanks Sergey
On 01/02/18 14:43, Dennis Kieselhorst wrote:

Hi Sergey,

my bad I wasn't able to run all tests locally. The ServerLauncher class 
produces a long classpath resulting in CreateProcess error=206 on my current 
environment. In general it looked fine and I thought Jenkins will run the 
testcases as well.

So let's use 1.5.17 for 3.2.2 and I'll try to resolve the issues later on when 
I can reproduce then.

Cheers
Dennis

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

[Sergey Beryozkin]

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] 
Swagger2CustomPropertiesTest.testApiListingIsProperlyReturnedJSON:67->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:134->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:137->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:148 
» NullPointer
[ERROR] 
Swagger2FilterServiceDescriptionTest.testApiListingIsProperlyReturnedJSON:54->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:134->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:137->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:148 
» NullPointer
[ERROR] 
Swagger2NonAnnotatedServiceDescriptionTest.testApiListingIsProperlyReturnedJSON:76->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:134->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:137->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:148 
» NullPointer
[ERROR] 
Swagger2RegularServiceDescriptionTest.testApiListingIsProperlyReturnedJSON:54->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:134->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:137->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:148 
» NullPointer
[ERROR] 
Swagger2XForwardedDescriptionTest.testApiListingIsProperlyReturnedJSON:38->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:134->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:137->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:147 
» InternalServerError
[ERROR] 
Swagger2XForwardedDescriptionTest.testApiListingIsProperlyReturnedJSONXForwarded:43->AbstractSwagger2ServiceDescriptionTest.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 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: 
https://builds.apache.org/view/A-D/view/CXF/job/CXF-Trunk-JDK18/lastCompletedBuild/testReport/ 



They fixed pretty print 
(https://github.com/swagger-api/swagger-core/issues/2320) and read 
only properties 
(https://github.com/swagger-api/swagger-core/pull/2502). Moreover the 
Jackson version was aligned 
(https://github.com/swagger-api/swagger-core/pull/2576). That's why I 
thought it's a good idea to update.


Cheers
Dennis

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

[Sergey Beryozkin]

Hi Dennis

All related tests in systests/jaxrs fail if I run then directly from 
systests/jaxrs:


[ERROR] Errors:
[ERROR] 
Swagger2CustomPropertiesTest.testApiListingIsProperlyReturnedJSON:67->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:134->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:137->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:148 
» NullPointer
[ERROR] 
Swagger2FilterServiceDescriptionTest.testApiListingIsProperlyReturnedJSON:54->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:134->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:137->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:148 
» NullPointer
[ERROR] 
Swagger2NonAnnotatedServiceDescriptionTest.testApiListingIsProperlyReturnedJSON:76->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:134->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:137->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:148 
» NullPointer
[ERROR] 
Swagger2RegularServiceDescriptionTest.testApiListingIsProperlyReturnedJSON:54->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:134->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:137->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:148 
» NullPointer
[ERROR] 
Swagger2XForwardedDescriptionTest.testApiListingIsProperlyReturnedJSON:38->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:134->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:137->AbstractSwagger2ServiceDescriptionTest.doTestApiListingIsProperlyReturnedJSON:147 
» InternalServerError
[ERROR] 
Swagger2XForwardedDescriptionTest.testApiListingIsProperlyReturnedJSONXForwarded:43->AbstractSwagger2ServiceDescriptionTest.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 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: 
https://builds.apache.org/view/A-D/view/CXF/job/CXF-Trunk-JDK18/lastCompletedBuild/testReport/ 



They fixed pretty print 
(https://github.com/swagger-api/swagger-core/issues/2320) and read 
only properties 
(https://github.com/swagger-api/swagger-core/pull/2502). Moreover the 
Jackson version was aligned 
(https://github.com/swagger-api/swagger-core/pull/2576). That's why I 
thought it's a good idea to update.


Cheers
Dennis

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

[Sergey Beryozkin]

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: 
https://builds.apache.org/view/A-D/view/CXF/job/CXF-Trunk-JDK18/lastCompletedBuild/testReport/

They fixed pretty print 
(https://github.com/swagger-api/swagger-core/issues/2320) and read only 
properties (https://github.com/swagger-api/swagger-core/pull/2502). Moreover 
the Jackson version was aligned 
(https://github.com/swagger-api/swagger-core/pull/2576). That's why I thought 
it's a good idea to update.

Cheers
Dennis

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

[Sergey Beryozkin]

I've reverted back to 1.5.17 as I see systests failing with it.
FYI, tests pass OK with 1.5.18 in 3.1.x which stayed at 1.5.12.

In 3.1.x we retained the the same feature code but on the master, when 
upgrading to 1.5.16 (?) we had to change that as the same model did nnot 
work anymore. Now it appears 1.5.18 has changed internally to the older 
per 1.5.16 model.


IMHO, it only makes sense to move to newer 1.5.x versions when it can 
bring something new to the users, rewriting Swagger2Feature with every 
swagger-jaxrs/core 1.5.x iteration seems a bit too much :-)


Thanks, Sergey

On 01/02/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 a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cxf.git


The following commit(s) were added to refs/heads/master by this push:
  new 2cd77ba  update swagger-core to latest version
2cd77ba is described below

commit 2cd77bae06fc51ef2bc6d7679db1fdf6e9476af1
Author: Dennis Kieselhorst <m...@dekies.de>
AuthorDate: Thu Feb 1 10:30:00 2018 +0100

 update swagger-core to latest version
---
  parent/pom.xml | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/parent/pom.xml b/parent/pom.xml
index 9c80f55..ea4516d 100644
--- a/parent/pom.xml
+++ b/parent/pom.xml
@@ -159,7 +159,7 @@
  1.2.1
  
2.3.2.RELEASE

  spring-test
-    1.5.17
+    1.5.18
  2.0.0-rc4
  3.9.2
  2.0

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

[Sergey Beryozkin]

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 repository https://gitbox.apache.org/repos/asf/cxf.git


The following commit(s) were added to refs/heads/master by this push:
  new 2cd77ba  update swagger-core to latest version
2cd77ba is described below

commit 2cd77bae06fc51ef2bc6d7679db1fdf6e9476af1
Author: Dennis Kieselhorst 
AuthorDate: Thu Feb 1 10:30:00 2018 +0100

 update swagger-core to latest version
---
  parent/pom.xml | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/parent/pom.xml b/parent/pom.xml
index 9c80f55..ea4516d 100644
--- a/parent/pom.xml
+++ b/parent/pom.xml
@@ -159,7 +159,7 @@
  1.2.1
  2.3.2.RELEASE
  spring-test
-1.5.17
+1.5.18
  2.0.0-rc4
  3.9.2
  2.0

Re: New Logging interceptors

[Sergey Beryozkin]

May be that property was already set somewhere to false, hence reseting 
it to true made a diff, might be worth debugging what 
isLoggingDisabledNow returns...


Sergey
On 19/01/18 11:20, Colm O hEigeartaigh wrote:

In a test I was working with, message logging only worked when I added the
new 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 is
false:

https://github.com/apache/cxf/blob/master/rt/features/loggin
g/src/main/java/org/apache/cxf/ext/logging/AbstractLoggin
gInterceptor.java#L49

Sergey
On 19/01/18 11:09, Colm O hEigeartaigh wrote:


I don't see "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/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 them to the interceptor chain to see the
outbound/inbound requests. These interceptors are now deprecated.

However in the new interceptors (org.apache.cxf.ext.logging), attaching
them to the interceptor chain is not enough to see the requests. You
also
need to set the system property org.apache.cxf.logging.enabled to
"true".

Is this change in behaviour intended?

Colm.

Re: New Logging interceptors

[Sergey Beryozkin]

It can only be used to disable the logging if it is explicitly set and 
is false:


https://github.com/apache/cxf/blob/master/rt/features/logging/src/main/java/org/apache/cxf/ext/logging/AbstractLoggingInterceptor.java#L49

Sergey
On 19/01/18 11:09, Colm O hEigeartaigh wrote:

I don't see "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/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 them to the interceptor chain to see the
outbound/inbound requests. These interceptors are now deprecated.

However in the new interceptors (org.apache.cxf.ext.logging), attaching
them to the interceptor chain is not enough to see the requests. You also
need to set the system property org.apache.cxf.logging.enabled to "true".

Is this change in behaviour intended?

Colm.

Re: New Logging interceptors

[Sergey Beryozkin]

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 them to the interceptor chain to see the
outbound/inbound requests. These interceptors are now deprecated.

However in the new interceptors (org.apache.cxf.ext.logging), attaching
them to the interceptor chain is not enough to see the requests. You also
need to set the system property org.apache.cxf.logging.enabled to "true".

Is this change in behaviour intended?

Colm.

Re: Failing tests with latest JDK

[Sergey Beryozkin]

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 :
https://github.com/javaee/jaxb-v2/commit/8cbd5e0ec41c94d743c6ae993289e7a18d00aed4 


I already sent a PR(https://github.com/apache/cxf/pull/365/files) to fix
these test failures and it should work for jdk1.8.0_161, jdk 9.0.1 and 
jaxb

2.3.

Cheers,
Jim

On Thu, Jan 18, 2018 at 9:29 AM, Freeman Fang <freeman.f...@gmail.com>
wrote:


Yeah, this is an issue we found in JDK9 built-in jaxb firstly, than ran
into same problem in JAXB 2.3,  and now seems latest JDK8 built-in 
jaxb is

also affected.

Btw, it is tracked by CXF-7520
[1]https://issues.apache.org/jira/browse/CXF-7520
－
Freeman(Yue) Fang

Red Hat, Inc.
FuseSource is now part of Red Hat




On Jan 18, 2018, at 4:31 AM, Daniel Kulp <dk...@apache.org> wrote:

These are the same tests that fail on Java9 that Freeman and Jim are
trying to get fixed.   I’m willing to bet Oracle back ported the 
changes.


Dan



On Jan 17, 2018, at 3:03 PM, Colm O hEigeartaigh <cohei...@apache.org>

wrote:


Hi all,

With the latest JDK (8-161) some tests have started to fail (at least

for

me locally), e.g.:

[ERROR]
testWriteNullValueAsString(org.apache.cxf.jaxrs.provider.

json.JSONProviderTest)

Time elapsed: 0.006 s  <<< FAILURE!
java.lang.AssertionError
   at
org.apache.cxf.jaxrs.provider.json.JSONProviderTest.

doTestWriteNullValue(JSONProviderTest.java:354)

   at
org.apache.cxf.jaxrs.provider.json.JSONProviderTest.

testWriteNullValueAsString(JSONProviderTest.java:329)


[ERROR]
testWriteNullValueAsNull(org.apache.cxf.jaxrs.provider.

json.JSONProviderTest)

Time elapsed: 0.003 s  <<< FAILURE!
java.lang.AssertionError
   at
org.apache.cxf.jaxrs.provider.json.JSONProviderTest.

doTestWriteNullValue(JSONProviderTest.java:356)

   at
org.apache.cxf.jaxrs.provider.json.JSONProviderTest.

testWriteNullValueAsNull(JSONProviderTest.java:335)


Colm.


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com


--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Re: Failing tests with latest JDK

[Sergey Beryozkin]

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 PR(https://github.com/apache/cxf/pull/365/files) to fix
these test failures and it should work for jdk1.8.0_161, jdk 9.0.1 and jaxb
2.3.

Cheers,
Jim

On Thu, Jan 18, 2018 at 9:29 AM, Freeman Fang 
wrote:


Yeah, this is an issue we found in JDK9 built-in jaxb firstly, than ran
into same problem in JAXB 2.3,  and now seems latest JDK8 built-in jaxb is
also affected.

Btw, it is tracked by CXF-7520
[1]https://issues.apache.org/jira/browse/CXF-7520
－
Freeman(Yue) Fang

Red Hat, Inc.
FuseSource is now part of Red Hat




On Jan 18, 2018, at 4:31 AM, Daniel Kulp  wrote:

These are the same tests that fail on Java9 that Freeman and Jim are

trying to get fixed.   I’m willing to bet Oracle back ported the changes.


Dan



On Jan 17, 2018, at 3:03 PM, Colm O hEigeartaigh 

wrote:


Hi all,

With the latest JDK (8-161) some tests have started to fail (at least

for

me locally), e.g.:

[ERROR]
testWriteNullValueAsString(org.apache.cxf.jaxrs.provider.

json.JSONProviderTest)

Time elapsed: 0.006 s  <<< FAILURE!
java.lang.AssertionError
   at
org.apache.cxf.jaxrs.provider.json.JSONProviderTest.

doTestWriteNullValue(JSONProviderTest.java:354)

   at
org.apache.cxf.jaxrs.provider.json.JSONProviderTest.

testWriteNullValueAsString(JSONProviderTest.java:329)


[ERROR]
testWriteNullValueAsNull(org.apache.cxf.jaxrs.provider.

json.JSONProviderTest)

Time elapsed: 0.003 s  <<< FAILURE!
java.lang.AssertionError
   at
org.apache.cxf.jaxrs.provider.json.JSONProviderTest.

doTestWriteNullValue(JSONProviderTest.java:356)

   at
org.apache.cxf.jaxrs.provider.json.JSONProviderTest.

testWriteNullValueAsNull(JSONProviderTest.java:335)


Colm.


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com


--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

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

[Sergey Beryozkin]

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. So I guess, we could
keep it, right? There is a diff from older Swagger specs, but more or less,
the parser does the job. What do you think?

Best Regards,
 Andriy Redko

SB> Hi Andriy

SB> The idea there was to support the dynamic creation of CXF JAX-RS
SB> endpoints from a given Swagger doc, i.e, support Swagger-first dev
SB> without the code-generation, by converting Swagger docs into CXF
SB> specific UserResource(s) which in turn can be used to initialize the
SB> endpoint...
SB> I've found UserResource can not entirely match swagger model, the
SB> original idea behind UserResource/etc is doc-ed here:
SB> 
http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-RESTfulserviceswithoutannotations

SB> with the model/etc classes expected to be avail on the classpath

SB> Sergey



SB> On 29/12/17 16:35, Andriy Redko wrote:

Hi Sergey,



I am not sure actually it is needed, but I am trying to match our Swagger2 
implementation
where we have/are using Swagger2ParseUtils. We have test cases for that as well 
as it is being
used in system tests for parsing the spec and checking expectations. Does it 
make sense?
Thanks.



Best Regards,
  Andriy Redko



SB> Hi Andriy



SB> Just curious, why would this new module will need OpenApiParseUtils ?



SB> Thanks, Sergey

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

[Sergey Beryozkin]

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 found UserResource can not entirely match swagger model, the 
original idea behind UserResource/etc is doc-ed here:

http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-RESTfulserviceswithoutannotations

with the model/etc classes expected to be avail on the classpath

Sergey



On 29/12/17 16:35, Andriy Redko wrote:

Hi Sergey,

I am not sure actually it is needed, but I am trying to match our Swagger2 
implementation
where we have/are using Swagger2ParseUtils. We have test cases for that as well 
as it is being
used in system tests for parsing the spec and checking expectations. Does it 
make sense?
Thanks.

Best Regards,
 Andriy Redko

SB> Hi Andriy

SB> Just curious, why would this new module will need OpenApiParseUtils ?

SB> Thanks, Sergey

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

[Sergey Beryozkin]

Hi Andriy

Just curious, why would this new module will need OpenApiParseUtils ?

Thanks, Sergey

Re: How to automatically register OpenTracingFeature?

[Sergey Beryozkin]

xrs

package) is JAX-RS feature,

JDA>  which JAXRS CDI extension should recognize out of the box.

There

is also CXF feature (

JDA>  in org.apache.cxf.tracing.opentracing package) to be used for

JAX-WS services. The only explanation

JDA>  I have why it is not being picked up it the absense of

bean.xml

so we could fix that. I will

JDA>  take a look shorly (if you haven't figured this one out

already).

Thanks.



JDA>  Best Regards,
JDA>  Andriy Redko




JDA>> I'm not sure either, this is the behavior I see in the

code:



JDA>> - Register JAX-RS resources (with @ApplicationPath)
JDA>> - Register JAX-RS resources (with @Path)
JDA>> - Register JAX-RS providers (with JAX-RS @Provider)
JDA>> - Register JAX-RS features (with JAX-RS @Feature)
JDA>> - Register CXF features (doesn't care if it has a CXF

@Provider

annotation but I see the OpenTracing one does have it)

JDA>> - Otherwise we assume its the CXF Bus object



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>> 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, Sergey Beryozkin <

sberyoz...@gmail.com>

wrote:

>>> Sure, I just don't understand what is the difference between

a

JAX-RS

>>> feature and CXF feature, as far as the CXF CDI code is

concerned.

If it

>>> can load the JAX-RS features which have not been written

with CDI

in

>>> mind, why can't it load CXF features without some extra work

going into

>>> these features...



>>> Thanks, Sergey
>>> On 22/12/17 14:50, John D. Ament wrote:
>>> > That's not really the issue though.  The extension will

only

receive CDI managed beans.  Take a look at my pull to see what I had

to do

to get it to register automatically.  If nothing else, this is an

argument

for moving 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

providers

>>> >> and feature are picked up. Thought, when we were

discussing

the SSE

>>> >> feature I thought Andriy said it was looking at the CXF

@Provider as

>>> >> well, may be I misunderstood.
>>> >> Updating the CDI code to check CXF @Provider, if it is not

already

>>> >> checked, makes sense IMHO
>>> >>
>>> >> Sergey
>>> >> On 22/12/17 14:08, John D. Ament wrote:
>>> >>> Actually one more thing.  The CDI extension only looks

for

JAX-RS @Provider not CXF @Provider.

>>> >>>
>>> >>> On 2017-12-22 09:06, "John D. Ament"<

johndam...@apache.org>

wrote:

>>> >>>> I'm not sure what the CDI extension has to do with

this.  It

has no bean defining annotations, and there is no beans.xml in the

JAR that

it ships with so I'm not sure it would be picked up by the extension.

>>> >>>>
>>> >>>> There's nothing special done for TomcatwarTest to 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 injection of

Context

objects.  The one

>>> >>>>>> area I'm struggling with is the automatic

registration of

this feature.  I

>>> >>>>>> added a dependency on OpenTracing, just to confirm

that

injection via CDI

>>> >>>>>> works (and to be honest, this is one of my use cases,

working with

>>> >>>>>> tracing).  However, it seems that this feature isn't

automatically

>>> >>>>>> registered via CDI.  Is there something I have to do

to

make it work?

>>> >>>>>>
>>> >>>>>> John
>>> >>>>>>
>>> >>>>>
>>> >>>>
>>> >>

Re: How to automatically register OpenTracingFeature?

[Sergey Beryozkin]

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>> 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, Sergey Beryozkin <

sberyoz...@gmail.com>

wrote:

   >>> Sure, I just don't understand what is the difference between

a

JAX-RS

   >>> feature and CXF feature, as far as the CXF CDI code is

concerned.

If it

   >>> can load the JAX-RS features which have not been written

with CDI

in

   >>> mind, why can't it load CXF features without some extra work

going into

   >>> these features...



   >>> Thanks, Sergey
   >>> On 22/12/17 14:50, John D. Ament wrote:
   >>> > That's not really the issue though.  The extension will

only

receive CDI managed beans.  Take a look at my pull to see what I had

to do

to get it to register automatically.  If nothing else, this is an

argument

for moving 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

providers

   >>> >> and feature are picked up. Thought, when we were

discussing

the SSE

   >>> >> feature I thought Andriy said it was looking at the CXF

@Provider as

   >>> >> well, may be I misunderstood.
   >>> >> Updating the CDI code to check CXF @Provider, if it is not

already

   >>> >> checked, makes sense IMHO
   >>> >>
   >>> >> Sergey
   >>> >> On 22/12/17 14:08, John D. Ament wrote:
   >>> >>> Actually one more thing.  The CDI extension only looks

for

JAX-RS @Provider not CXF @Provider.

   >>> >>>
   >>> >>> On 2017-12-22 09:06, "John D. Ament"<

johndam...@apache.org>

wrote:

   >>> >>>> I'm not sure what the CDI extension has to do with

this.  It

has no bean defining annotations, and there is no beans.xml in the

JAR that

it ships with so I'm not sure it would be picked up by the extension.

   >>> >>>>
   >>> >>>> There's nothing special done for TomcatwarTest to 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 injection of

Context

objects.  The one

   >>> >>>>>> area I'm struggling with is the automatic

registration of

this feature.  I

   >>> >>>>>> added a dependency on OpenTracing, just to confirm

that

injection via CDI

   >>> >>>>>> works (and to be honest, this is one of my use cases,

working with

   >>> >>>>>> tracing).  However, it seems that this feature isn't

automatically

   >>> >>>>>> registered via CDI.  Is there something I have to do

to

make it work?

   >>> >>>>>>
   >>> >>>>>> John
   >>> >>>>>>
   >>> >>>>>
   >>> >>>>
   >>> >>

Re: How to automatically register OpenTracingFeature?

[Sergey Beryozkin]

In the spring boot demo the class-scanning is enabled first and then the 
packages to scan are checked, having the module on the classpath does 
not auto-load - so I reckon the CXF CDI code should follow the same 
pattern. The users will only need to set the properties in order to get 
some providers auto-discovered...


Sergey


On 22/12/17 22:27, John D. Ament wrote:

I would do nothing but document a strategy that users can implement.  The
biggest question I have is whether a provider like this should be
registered automatically?  Does that happen with spring based runtimes?
What about when there is no DI framework present?  Is it clear enough that
user would need to list it in their Application class as a singleton/class?

John

On Fri, Dec 22, 2017 at 5:08 PM Andriy Redko <drr...@gmail.com> wrote:


Sure, removed/reverted. So here are the general thoughts. Yes, most (if
not all) of the providers/features/... are not CDI
specific and as such, they are not bean archives (and it make sense). Now,
how could we make the CXF more CDIish? There
are a couple of option we could explore, but what would be the idiomatic
CDI way?

Best Regards,
 Andriy Redko

JDA> Personally, I would actually recommend removing the beans.xml from
open tracing (and really any module that isn't
JDA> a cdi specific module).  While it does allow for a bit more automatic
binding, my question was more around what is
JDA> missing.  I missed the fact that there is no build in automatic
discovery of providers in CDI if they're not CDI
JDA> managed - which is OK and the answer I was working through.

JDA> And realistically, this issue is not specific to the open tracing
integration, I can replicate it with other
JDA> providers.  Its just a matter of documenting and knowing what to
setup.

JDA> So if you don't mind, I'd like to revert that commit; and add some
docs around how to create an automatically registered provider.

JDA> John

JDA> On 2017-12-22 15:24, Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

How can i disable it now? Tink that cxf feature - even if in separate
modules - shouldnt be auto registered until it has a deactivable flag -
classpath properties + overridable through system prop.



Wdyt?



Le 22 déc. 2017 18:38, "Andriy Redko" <drr...@gmail.com> a écrit :



Hi Sergey,

It wasn't (for CDI only), but it could have been always included

manually.

Thanks.

Best Regards,
 Andriy Redko

SB> Hi Andriy

SB> So how was a JAX-RS (OpenTracing) Feature discovered without

beans.xml

?

SB> Cheers, Sergey
SB> On 22/12/17 17:24, Andriy Redko wrote:

The beans.xml was missed indeed, I added it and OpenTracingFeature

has

been discovered right away.

The commit is on its way. Thanks!



Best Regards,
  Andriy Redko



JDA> I'm holding off on doing anything to fix it.  For one, a user

may

not want to use the global tracer so making it

JDA> so that they register it makes more sense.  Ultimately to

solve

it, I think we should be moving server

JDA> customizations outside of CDI to ensure that it can be auto

registered.



JDA> John




JDA> On Fri, Dec 22, 2017 at 11:12 AM Andriy Redko <

drr...@gmail.com>

wrote:


JDA> Hey John,



JDA>  The OpenTracingFeature

(org.apache.cxf.tracing.opentracing.jaxrs

package) is JAX-RS feature,

JDA>  which JAXRS CDI extension should recognize out of the box.

There

is also CXF feature (

JDA>  in org.apache.cxf.tracing.opentracing package) to be used for

JAX-WS services. The only explanation

JDA>  I have why it is not being picked up it the absense of

bean.xml

so we could fix that. I will

JDA>  take a look shorly (if you haven't figured this one out

already).

Thanks.


JDA>  Best Regards,
JDA>  Andriy Redko




   JDA>> I'm not sure either, this is the behavior I see in the

code:



   JDA>> - Register JAX-RS resources (with @ApplicationPath)
   JDA>> - Register JAX-RS resources (with @Path)
   JDA>> - Register JAX-RS providers (with JAX-RS @Provider)
   JDA>> - Register JAX-RS features (with JAX-RS @Feature)
   JDA>> - Register CXF features (doesn't care if it has a CXF

@Provider

annotation but I see the OpenTracing one does have it)

   JDA>> - Otherwise we assume its the CXF Bus object



   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>> 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, Sergey Beryozkin <

sberyoz...@gmail.com>

wrote:

   >>> Sure, I just don't understand what is the difference betw

Re: How to automatically register OpenTracingFeature?

[Sergey Beryozkin]

Hi Andriy

So how was a JAX-RS (OpenTracing) Feature discovered without beans.xml ?

Cheers, Sergey
On 22/12/17 17:24, Andriy Redko wrote:

The beans.xml was missed indeed, I added it and OpenTracingFeature has been 
discovered right away.
The commit is on its way. Thanks!

Best Regards,
 Andriy Redko

JDA> I'm holding off on doing anything to fix it.  For one, a user may not want 
to use the global tracer so making it
JDA> so that they register it makes more sense.  Ultimately to solve it, I 
think we should be moving server
JDA> customizations outside of CDI to ensure that it can be auto registered.


JDA> John


JDA> On Fri, Dec 22, 2017 at 11:12 AM Andriy Redko <drr...@gmail.com> wrote:

JDA> Hey John,

JDA>  The OpenTracingFeature (org.apache.cxf.tracing.opentracing.jaxrs package) 
is JAX-RS feature,
JDA>  which JAXRS CDI extension should recognize out of the box. There is also 
CXF feature (
JDA>  in org.apache.cxf.tracing.opentracing package) to be used for JAX-WS 
services. The only explanation
JDA>  I have why it is not being picked up it the absense of bean.xml so we 
could fix that. I will
JDA>  take a look shorly (if you haven't figured this one out already). Thanks.

JDA>  Best Regards,
JDA>  Andriy Redko


  JDA>> I'm not sure either, this is the behavior I see in the code:

  JDA>> - Register JAX-RS resources (with @ApplicationPath)
  JDA>> - Register JAX-RS resources (with @Path)
  JDA>> - Register JAX-RS providers (with JAX-RS @Provider)
  JDA>> - Register JAX-RS features (with JAX-RS @Feature)
  JDA>> - Register CXF features (doesn't care if it has a CXF @Provider 
annotation but I see the OpenTracing one does have it)
  JDA>> - Otherwise we assume its the CXF Bus object

  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>> 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, Sergey Beryozkin <sberyoz...@gmail.com> wrote:
  >>> Sure, I just don't understand what is the difference between a JAX-RS
  >>> feature and CXF feature, as far as the CXF CDI code is concerned. If it
  >>> can load the JAX-RS features which have not been written with CDI in
  >>> mind, why can't it load CXF features without some extra work going into
  >>> these features...

  >>> Thanks, Sergey
  >>> On 22/12/17 14:50, John D. Ament wrote:
  >>> > That's not really the issue though.  The extension will only receive 
CDI managed beans.  Take a look at my pull to see what I had to do to get it to register 
automatically.  If nothing else, this is an argument for moving 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 providers
  >>> >> and feature are picked up. Thought, when we were discussing the SSE
  >>> >> feature I thought Andriy said it was looking at the CXF @Provider as
  >>> >> well, may be I misunderstood.
  >>> >> Updating the CDI code to check CXF @Provider, if it is not already
  >>> >> checked, makes sense IMHO
  >>> >>
  >>> >> Sergey
  >>> >> On 22/12/17 14:08, John D. Ament wrote:
  >>> >>> Actually one more thing.  The CDI extension only looks for JAX-RS 
@Provider not CXF @Provider.
  >>> >>>
  >>> >>> On 2017-12-22 09:06, "John D. Ament"<johndam...@apache.org> wrote:
  >>> >>>> I'm not sure what the CDI extension has to do with this.  It has no 
bean defining annotations, and there is no beans.xml in the JAR that it ships with so I'm not sure 
it would be picked up by the extension.
  >>> >>>>
  >>> >>>> There's nothing special done for TomcatwarTest to 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 injection of Context objects.  
The one
  >>> >>>>>> area I'm struggling with is the automatic registration of this 
feature.  I
  >>> >>>>>> added a dependency on OpenTracing, just to confirm that injection 
via CDI
  >>> >>>>>> works (and to be honest, this is one of my use cases, working with
  >>> >>>>>> tracing).  However, it seems that this feature isn't automatically
  >>> >>>>>> registered via CDI.  Is there something I have to do to make it 
work?
  >>> >>>>>>
  >>> >>>>>> John
  >>> >>>>>>
  >>> >>>>>
  >>> >>>>
  >>> >>

MonoReactorTest

[Sergey Beryozkin]

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 test -Dtest=MonoReactorTest

then it fails, while

mvn clean test -Dtest=FluxReactorTest

passes,

as well as both MonoReactorTest and FluxReactorTest pass when I do

mvn clean install

Minor issue, have a look please after New Year :-)

Sergey

Re: How to update cxf.apache.org?

[Sergey Beryozkin]

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 users to read if you create a new page a 
link to it from the jaxrs clients page and possibly from the top level 
JAX-Rs page as well.


The second, I think http://cxf.apache.org/docs/jax-rs-client-api.html isn't
actually linked incoming from anywhere.  It may make sense to add it to
http://cxf.apache.org/docs/index.html


See
http://cxf.apache.org/docs/jax-rs.html#JAX-RS-ClientAPI


I also want to update
http://cxf.apache.org/docs/using-cxf-and-cdi-11-jsr-346.html with
information about CDI based context injection, as well as the server
customization bits (JAXRSServerFactoryCustomizationExtension).

John

Re: How to automatically register OpenTracingFeature?

[Sergey Beryozkin]

Sure, I just don't understand what is the difference between a JAX-RS 
feature and CXF feature, as far as the CXF CDI code is concerned. If it 
can load the JAX-RS features which have not been written with CDI in 
mind, why can't it load CXF features without some extra work going into 
these features...


Thanks, Sergey
On 22/12/17 14:50, John D. Ament wrote:

That's not really the issue though.  The extension will only receive CDI 
managed beans.  Take a look at my pull to see what I had to do to get it to 
register automatically.  If nothing else, this is an argument for moving 
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 providers
and feature are picked up. Thought, when we were discussing the SSE
feature I thought Andriy said it was looking at the CXF @Provider as
well, may be I misunderstood.
Updating the CDI code to check CXF @Provider, if it is not already
checked, makes sense IMHO

Sergey
On 22/12/17 14:08, John D. Ament wrote:

Actually one more thing.  The CDI extension only looks for JAX-RS @Provider not 
CXF @Provider.

On 2017-12-22 09:06, "John D. Ament"<johndam...@apache.org> wrote:

I'm not sure what the CDI extension has to do with this.  It has no bean 
defining annotations, and there is no beans.xml in the JAR that it ships with 
so I'm not sure it would be picked up by the extension.

There's nothing special done for TomcatwarTest to 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 injection of Context objects.  The one
area I'm struggling with is the automatic registration of this feature.  I
added a dependency on OpenTracing, just to confirm that injection via CDI
works (and to be honest, this is one of my use cases, working with
tracing).  However, it seems that this feature isn't automatically
registered via CDI.  Is there something I have to do to make it work?

John

Re: How to automatically register OpenTracingFeature?

[Sergey Beryozkin]

I was not referring the OpenTracing module offering a CDI extension, but 
to the work Andriy did in the CXF CDI integration where the providers 
and feature are picked up. Thought, when we were discussing the SSE 
feature I thought Andriy said it was looking at the CXF @Provider as 
well, may be I misunderstood.
Updating the CDI code to check CXF @Provider, if it is not already 
checked, makes sense IMHO


Sergey
On 22/12/17 14:08, John D. Ament wrote:

Actually one more thing.  The CDI extension only looks for JAX-RS @Provider not 
CXF @Provider.

On 2017-12-22 09:06, "John D. Ament"<johndam...@apache.org> wrote:

I'm not sure what the CDI extension has to do with this.  It has no bean 
defining annotations, and there is no beans.xml in the JAR that it ships with 
so I'm not sure it would be picked up by the extension.

There's nothing special done for TomcatwarTest to 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 injection of Context objects.  The one
area I'm struggling with is the automatic registration of this feature.  I
added a dependency on OpenTracing, just to confirm that injection via CDI
works (and to be honest, this is one of my use cases, working with
tracing).  However, it seems that this feature isn't automatically
registered via CDI.  Is there something I have to do to make it work?

John

Re: MP client test failing

[Sergey Beryozkin]

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

Consistently seeing:

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

I thought it was passing yesterday though...
Cheers, Sergey

Re: How to automatically register OpenTracingFeature?

[Sergey Beryozkin]

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
added a dependency on OpenTracing, just to confirm that injection via CDI
works (and to be honest, this is one of my use cases, working with
tracing).  However, it seems that this feature isn't automatically
registered via CDI.  Is there something I have to do to make it work?

John

MP client test failing

[Sergey Beryozkin]

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 
org.eclipse.microprofile.rest.client.RestClientDefinitionException


I thought it was passing yesterday though...
Cheers, Sergey

Re: OpenAPI: Swagger2 or Swagger3

[Sergey Beryozkin]

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 v3 libs...


Cheers, Sergey
On 21/12/17 13:46, Andriy Redko wrote:

It is confusing indeed, for OpenApi v3 integration we decided to get rid of 
"Swagger"
and make the emphasize on OpenApi aspect of it. Swagger 2 is the spec version 
(2.0)
while the 1.5.x is the implementation of it (so we are really naming after the
specification). To make things cleaner, we would have migrated our old Swagger
integration into xxx-openapi-v2, but this is a bit risky since it is in use
these days.

Best Regards,
 Andriy Redko

SB> Hi

SB> How should CXF position its OpenAPI feature, as Swagger 2 or 3 ?

SB> Swagger 2 is a bit confusing, given that we have am Open Api version 3
SB> and the existing Swagger2Feature.

SB> I know Swagger2Feature depends on swagger core/jaxrs 1.5.x, but it is
SB> still Swagger2 ?

SB> Sergey

OpenAPI: Swagger2 or Swagger3

[Sergey Beryozkin]

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

[Sergey Beryozkin]

Hi John

Well, if we have the developers who are reading the spec then they will 
know the default priority is Priority.USER and can adjust accordingly.


I've just checked the spec, it has a new 4.1.3 section. That section 
first stresses that the pre-packaged provider should not be chosen over 
the equal application provider, and next it talks about how priorities 
can affect the (2) equal application providers.


Indeed, perhaps putting some large number on the built-in MBRs/MBWs 
won't harm. May be it just should be done. You are right we don't want 
the developers be unexpectedly 'surprised'.


IMHO though it would not be a bad idea to get at least a single case 
tested first where, without attaching these max values, we would see, 
yes, the user provider loses. As I implied earlier the selection 
algorithm should guarantee it never happens with respect to MBR/MBW, so 
if one gets such a test then the selection algorithm implementation will 
need to be reviewed...


I've just looked at the MBR and MBW comparators, the priority check is 
done after the custom flag is checked, so it does look very safe to me...


Sergey

On 20/12/17 23:33, John D. Ament wrote:

Sergey,

Agreed, yes that's the current confusing part.  The problem is that the 500x 
default behavior is what's surprising to some users (having implemented it in 
CXF and other JAX-RS runtimes and received internal user feedback on what is 
and isn't working).  Granted, most devs don't read the JAX-RS spec and just 
blindly do, as a result everything ends up with the default priority and simply 
win as custom vs built in.

Then you get the craft dev that did read the spec, realizes that you can 
specify priority and suddenly the provider they registered isn't taken into 
account.  You know why? They added @Priority(6000) (higher value) instead of 
@Priority(4000) (lower value) expecting theirs to be picked up first.

So really the argument makes it so that giving everything a consistent priority 
would work a bit better than centering everything around 5000.

John

On 2017-12-20 05:48, Sergey Beryozkin <sberyoz...@gmail.com> wrote:

Hi John
On 20/12/17 02:47, John D. Ament wrote:

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.

It is a bit more complex, unfortunately. The way the current
(spec-compliant) selection algorithm works in CXF is that the user
provided provider will win, but only if it is at least equal to the
competing built-in provider.

For example, CXF has a built-in provider typed by String for reading
writing strings, with the wildcard Consumes. A user registered provider
typed by String will always win, but a custom provider typed by Object
and which is meant to read/write String as well will lose to the
built-in provider on the basis that Object is less specific then String,
before the priorities or the fact it is a user provider will even be
considered. (The property mentioned by Romain can be used to change it)

Another case. CXF ships JSONProvider which is Jettison based. It's not
technically a built-in JAX-RS provider, it is optional, just happens,
historically, CXF will auto-load it if it is available on the classpath,
So, if it is loaded, and Jackson is also loaded, Jackson will lose, why
?, because CXF JSONProvider has more specific media types better
matching something like application/json. The priorities will not be
even taken into consideration.

Etc...


Take for instance the one that ships with Johnzon or Jackson.  There may be 
cases where those providers should be used over the ones shipped by the JAX-RS 
runtime.  In fact, I would argue that if a JSON-B/JSON-P impl ships a JAX-RS 
provider, we should use that provider over the one created by the JAX-RS 
runtime (but that's just my opinion).


Both CXF JSONProvider (see above - vs Jackson) and the one shipped in
the CXF JSONP module (vs Johnson) are optional, they are not 'built-in',
as far as ProviderFactory is concerned, only the providers it registers
at the init time, before checking the user providers, are built-in ones.

What happens if, for example, a user adds a CXF JSONP module and Johnson
at the same time, which MessageBodyReader/writer will be selected ? I
don't know, that will need to be tested, I'd assume both providers have
exactly the same default priority though and both will be treated as
custom providers.

I feel the built-in providers (namely MBRs and MBWs) should have the
default priority, and it is up to the custom providers to ensure they
are selected first (have more specific Consumes or Produces, 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

Thinkin

Re: Default Priority for built in providers

[Sergey Beryozkin]

Hi John
On 20/12/17 02:47, John D. Ament wrote:

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.
It is a bit more complex, unfortunately. The way the current 
(spec-compliant) selection algorithm works in CXF is that the user 
provided provider will win, but only if it is at least equal to the 
competing built-in provider.


For example, CXF has a built-in provider typed by String for reading 
writing strings, with the wildcard Consumes. A user registered provider 
typed by String will always win, but a custom provider typed by Object 
and which is meant to read/write String as well will lose to the 
built-in provider on the basis that Object is less specific then String, 
before the priorities or the fact it is a user provider will even be 
considered. (The property mentioned by Romain can be used to change it)


Another case. CXF ships JSONProvider which is Jettison based. It's not 
technically a built-in JAX-RS provider, it is optional, just happens, 
historically, CXF will auto-load it if it is available on the classpath,
So, if it is loaded, and Jackson is also loaded, Jackson will lose, why 
?, because CXF JSONProvider has more specific media types better 
matching something like application/json. The priorities will not be 
even taken into consideration.


Etc...


Take for instance the one that ships with Johnzon or Jackson.  There may be 
cases where those providers should be used over the ones shipped by the JAX-RS 
runtime.  In fact, I would argue that if a JSON-B/JSON-P impl ships a JAX-RS 
provider, we should use that provider over the one created by the JAX-RS 
runtime (but that's just my opinion).


Both CXF JSONProvider (see above - vs Jackson) and the one shipped in 
the CXF JSONP module (vs Johnson) are optional, they are not 'built-in', 
as far as ProviderFactory is concerned, only the providers it registers 
at the init time, before checking the user providers, are built-in ones.


What happens if, for example, a user adds a CXF JSONP module and Johnson 
at the same time, which MessageBodyReader/writer will be selected ? I 
don't know, that will need to be tested, I'd assume both providers have 
exactly the same default priority though and both will be treated as 
custom providers.


I feel the built-in providers (namely MBRs and MBWs) should have the 
default priority, and it is up to the custom providers to ensure they 
are selected first (have more specific Consumes or Produces, 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 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
absolutely equal user provider candidate prevails over the built in one.

There might be some cases I'm not aware of where the allocating of the
max priority values to the built-in ones can indeed help, but without
identifying such cases it can be also risky, hence I'd like us to come
up with such a case.

The extra sporting key in the form of the priority value can prob make
sense when 2 absolutely equal *user* providers are available, but to be
honest I can't even thing of the case where one would want to register
sat 2 MBRs with the same Consumes and the same Type but with different
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 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 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 some high priority will matter,
example, describe some case where a user provider (with some type) is
registered and the current implementation is not sufficient to get
this user provider selected.

I'd like to avoid starting introducing the fixes against the problems
which might be the actual problems, as far as the selection of MBRs
and MBWs in the spec compliant manner is concerned

Thanks, Sergey
On 19/12/17 11:59, John D. Ament wrote:

Re: Default Priority for built in providers

[Sergey Beryozkin]

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 
absolutely equal user provider candidate prevails over the built in one.


There might be some cases I'm not aware of where the allocating of the 
max priority values to the built-in ones can indeed help, but without 
identifying such cases it can be also risky, hence I'd like us to come 
up with such a case.


The extra sporting key in the form of the priority value can prob make 
sense when 2 absolutely equal *user* providers are available, but to be 
honest I can't even thing of the case where one would want to register 
sat 2 MBRs with the same Consumes and the same Type but with different 
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 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 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 some high priority will matter, 
example, describe some case where a user provider (with some type) is 
registered and the current implementation is not sufficient to get 
this user provider selected.


I'd like to avoid starting introducing the fixes against the problems 
which might be the actual problems, as far as the selection of MBRs 
and MBWs in the spec compliant manner is concerned


Thanks, Sergey
On 19/12/17 11:59, John D. Ament wrote:
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 between provider info and the 
contracts registered in JAX-RS.  To fix that in a typesafe client I 
added a new comparator that uses the contracts.  However I 
implemented it against the unbounded comparator you pass in.
- At one point, I was using this to directly sort the MicroProfile 
ResponseExceptionMapper impls as well, which have their own priority 
method.


So bottom line, I was able to get the sorting working properly, at 
least based on my understanding of the spec.  I do think it would be 
beneficial to set the built in providers with a very high priority 
and avoid configurations using the custom flag, since a user may want 
to register the built in providers with a different priority; 
presently that is blocked.


On 2017-12-18 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 something wrong.  However, I'm just 
delegating down to ClientProviderFactory.setProviders, which does 
pass in custom as false for the built in providers (look at 
ProviderFactory#L142).


I'm inclined to align with Romain's thinking, we should just set a 
high priority on the built in providers, to avoid any conflicts.  I 
already did this to register the Json P provider.  This would more 
easily allow consuming frameworks to add their own providers of 
slightly higher priorities.


John

On 2017-12-16 21:06, Andy McCright <j.andrew.mccri...@gmail.com> 
wrote:
True - we would also need to add default priority to the 
user-specified

providers (‘Priorities.USER’).

On Sat, Dec 16, 2017 at 2:08 PM Romain Manni-Bucau 
<rmannibu...@gmail.com>

wrote:

Le 16 déc. 2017 20:28, "Andy McCright" 
<j.andrew.mccri...@gmail.com> a

écrit :

I don’t have the code in front of me, but I remember that 
for JAX-RS
providers there was a check for a 
“user”/“custom” boolean - the built-in
providers are false, user providers (regardless of priority) are 
true.
That boolean is checked before the ‘@Priority’ 
annotation.


With the new emphasis on using ‘@Priority’ in the 
JAX-RS 2.1 spec, we could
probably simplify the code (and possibly speed up the sorting 
logic) if we
got rid of the special booleans and set 
‘@Priority(Integer.MAX_VALUE)’ for

all built-in 

Re: Default Priority for built in providers

[Sergey Beryozkin]

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 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 some high priority will matter, example, 
describe some case where a user provider (with some type) is registered 
and the current implementation is not sufficient to get this user 
provider selected.


I'd like to avoid starting introducing the fixes against the problems 
which might be the actual problems, as far as the selection of MBRs and 
MBWs in the spec compliant manner is concerned


Thanks, Sergey
On 19/12/17 11:59, John D. Ament wrote:
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 between provider info and the 
contracts registered in JAX-RS.  To fix that in a typesafe client I 
added a new comparator that uses the contracts.  However I implemented 
it against the unbounded comparator you pass in.
- At one point, I was using this to directly sort the MicroProfile 
ResponseExceptionMapper impls as well, which have their own priority 
method.


So bottom line, I was able to get the sorting working properly, at 
least based on my understanding of the spec.  I do think it would be 
beneficial to set the built in providers with a very high priority and 
avoid configurations using the custom flag, since a user may want to 
register the built in providers with a different priority; presently 
that is blocked.


On 2017-12-18 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 something wrong.  However, I'm just 
delegating down to ClientProviderFactory.setProviders, which does 
pass in custom as false for the built in providers (look at 
ProviderFactory#L142).


I'm inclined to align with Romain's thinking, we should just set a 
high priority on the built in providers, to avoid any conflicts.  I 
already did this to register the Json P provider.  This would more 
easily allow consuming frameworks to add their own providers of 
slightly higher priorities.


John

On 2017-12-16 21:06, Andy McCright <j.andrew.mccri...@gmail.com> wrote:
True - we would also need to add default priority to the 
user-specified

providers (‘Priorities.USER’).

On Sat, Dec 16, 2017 at 2:08 PM Romain Manni-Bucau 
<rmannibu...@gmail.com>

wrote:

Le 16 déc. 2017 20:28, "Andy McCright" 
<j.andrew.mccri...@gmail.com> a

écrit :

I don’t have the code in front of me, but I remember that 
for JAX-RS
providers there was a check for a 
“user”/“custom” boolean - the built-in
providers are false, user providers (regardless of priority) are 
true.
That boolean is checked before the ‘@Priority’ 
annotation.


With the new emphasis on using ‘@Priority’ in the 
JAX-RS 2.1 spec, we could
probably simplify the code (and possibly speed up the sorting 
logic) if we
got rid of the special booleans and set 
‘@Priority(Integer.MAX_VALUE)’ for

all built-in providers.


This is not forbidden by the spec so we still need a flag to let 
the user
overriding cxf defaults, no? (Unlikely doesnt mean never, libs 
will have

the same idea i guess, in particular for generic providers)


On Sat, Dec 16, 2017 at 12:55 PM John D. Ament 
<johndam...@apache.org>

wrote:

The JAX-RS spec mandates a certain number of providers by 
default.  I'm
noticing that when these providers are added, they're added 
without any

priority.  Andy mentioned to me that they should be added with the

priority

of USER + 1, but the actual resolved priority I'm seeing is USER.

Granted, this is within the proxy client code base.  Is this problem

going

to exist as well in the regular clients?  As well as server?

If so, should we annotate them with USER + 1 to avoid the issue?

John








--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/




--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Re: Default Priority for built in providers

[Sergey Beryozkin]

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 some high priority will matter, example, 
describe some case where a user provider (with some type) is registered 
and the current implementation is not sufficient to get this user 
provider selected.


I'd like to avoid starting introducing the fixes against the problems 
which might be the actual problems, as far as the selection of MBRs and 
MBWs in the spec compliant manner is concerned


Thanks, Sergey
On 19/12/17 11:59, John D. Ament wrote:

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 between provider info and the contracts 
registered in JAX-RS.  To fix that in a typesafe client I added a new 
comparator that uses the contracts.  However I implemented it against the 
unbounded comparator you pass in.
- At one point, I was using this to directly sort the MicroProfile 
ResponseExceptionMapper impls as well, which have their own priority method.

So bottom line, I was able to get the sorting working properly, at least based 
on my understanding of the spec.  I do think it would be beneficial to set the 
built in providers with a very high priority and avoid configurations using the 
custom flag, since a user may want to register the built in providers with a 
different priority; presently that is blocked.

On 2017-12-18 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 something wrong.  However, I'm just delegating 
down to ClientProviderFactory.setProviders, which does pass in custom as false 
for the built in providers (look at ProviderFactory#L142).

I'm inclined to align with Romain's thinking, we should just set a high 
priority on the built in providers, to avoid any conflicts.  I already did this 
to register the Json P provider.  This would more easily allow consuming 
frameworks to add their own providers of slightly higher priorities.

John

On 2017-12-16 21:06, Andy McCright <j.andrew.mccri...@gmail.com> wrote:

True - we would also need to add default priority to the user-specified
providers (‘Priorities.USER’).

On Sat, Dec 16, 2017 at 2:08 PM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:


Le 16 déc. 2017 20:28, "Andy McCright" <j.andrew.mccri...@gmail.com> a
écrit :

I don’t have the code in front of me, but I remember that for JAX-RS
providers there was a check for a “user”/“custom” 
boolean - the built-in
providers are false, user providers (regardless of priority) are true.
That boolean is checked before the ‘@Priority’ annotation.

With the new emphasis on using ‘@Priority’ in the JAX-RS 2.1 spec, 
we could
probably simplify the code (and possibly speed up the sorting logic) if we
got rid of the special booleans and set 
‘@Priority(Integer.MAX_VALUE)’ for
all built-in providers.


This is not forbidden by the spec so we still need a flag to let the user
overriding cxf defaults, no? (Unlikely doesnt mean never, libs will have
the same idea i guess, in particular for generic providers)


On Sat, Dec 16, 2017 at 12:55 PM John D. Ament <johndam...@apache.org>
wrote:


The JAX-RS spec mandates a certain number of providers by default.  I'm
noticing that when these providers are added, they're added without any
priority.  Andy mentioned to me that they should be added with the

priority

of USER + 1, but the actual resolved priority I'm seeing is USER.

Granted, this is within the proxy client code base.  Is this problem

going

to exist as well in the regular clients?  As well as server?

If so, should we annotate 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

[Sergey Beryozkin]

At some point, user-registered providers were always preferred over the 
equal built-in providers before even starting the selection,, but 
eventually, after the TCK failures and long discussions, it proved CXF 
was not compliant at a time. Thus, first, the built in and 
user-registered 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 D. Ament wrote:
I figured out where its falling down.  If you look at the class 
ProviderInfoClassComparator in ProviderFactory, it handles sort the 
provider infos with the custom attribute set.


The problem is that the actual provider sorting is done on the built 
lists.  They're not provider infos, just the instances of the 
providers.  I guess the provider infos can be passed around, but the 
way they're determined is out of sync.


John

On 2017-12-17 14:46, Andy McCright <j.andrew.mccri...@gmail.com> wrote:

John,

There is also a setUserProviders(...) method (possibly in the base
ProviderFactory class) - that method should set the custom boolean to 
true

in the ProviderInfo object and should sort them ahead of the built-in
providers.

Even so, I like the idea of setting a MAX_INT priority on the built-in
providers - that would definitely prevent them from being selected over
user-specified providers.

Thanks,

Andy

On Sun, Dec 17, 2017 at 8:42 AM John D. Ament <johndam...@apache.org> 
wrote:



FWIW, I had assumed I was doing something wrong.  However, I'm just
delegating down to ClientProviderFactory.setProviders, which does 
pass in
custom as false for the built in providers (look at 
ProviderFactory#L142).


I'm inclined to align with Romain's thinking, we should just set a high
priority on the built in providers, to avoid any conflicts.  I 
already did

this to register the Json P provider.  This would more easily allow
consuming frameworks to add their own providers of slightly higher
priorities.

John

On 2017-12-16 21:06, Andy McCright <j.andrew.mccri...@gmail.com> wrote:
True - we would also need to add default priority to the 
user-specified

providers (‘Priorities.USER’).

On Sat, Dec 16, 2017 at 2:08 PM Romain Manni-Bucau <

rmannibu...@gmail.com>

wrote:

Le 16 déc. 2017 20:28, "Andy McCright" 
<j.andrew.mccri...@gmail.com> a

écrit :

I don’t have the code in front of me, but I remember that for 
JAX-RS
providers there was a check for a “user”/“custom” boolean 
- the

built-in
providers are false, user providers (regardless of priority) are 
true.

That boolean is checked before the ‘@Priority’ annotation.

With the new emphasis on using ‘@Priority’ in the JAX-RS 2.1 
spec, we

could

probably simplify the code (and possibly speed up the sorting logic)

if we
got rid of the special booleans and set 
‘@Priority(Integer.MAX_VALUE)’

for

all built-in providers.


This is not forbidden by the spec so we still need a flag to let the

user

overriding cxf defaults, no? (Unlikely doesnt mean never, libs will

have

the same idea i guess, in particular for generic providers)


On Sat, Dec 16, 2017 at 12:55 PM John D. Ament 
<johndam...@apache.org>

wrote:


The JAX-RS spec mandates a certain number of providers by default.

I'm

noticing that when these providers are added, they're added without

any

priority.  Andy mentioned to me that they should be added with the

priority

of USER + 1, but the actual resolved priority I'm seeing is USER.

Granted, this is within the proxy client code base.  Is this problem

going

to exist as well in the regular clients?  As well as server?

If so, should we annotate them with USER + 1 to avoid the issue?

John

Re: Default Priority for built in providers

[Sergey Beryozkin]

What exactly is falling down ?

Sergey
On 17/12/17 21:46, John D. Ament wrote:

I figured out where its falling down.  If you look at the class 
ProviderInfoClassComparator in ProviderFactory, it handles sort the provider 
infos with the custom attribute set.

The problem is that the actual provider sorting is done on the built lists.  
They're not provider infos, just the instances of the providers.  I guess the 
provider infos can be passed around, but the way they're determined is out of 
sync.

John

On 2017-12-17 14:46, Andy McCright <j.andrew.mccri...@gmail.com> wrote:

John,

There is also a setUserProviders(...) method (possibly in the base
ProviderFactory class) - that method should set the custom boolean to true
in the ProviderInfo object and should sort them ahead of the built-in
providers.

Even so, I like the idea of setting a MAX_INT priority on the built-in
providers - that would definitely prevent them from being selected over
user-specified providers.

Thanks,

Andy

On Sun, Dec 17, 2017 at 8:42 AM John D. Ament <johndam...@apache.org> wrote:


FWIW, I had assumed I was doing something wrong.  However, I'm just
delegating down to ClientProviderFactory.setProviders, which does pass in
custom as false for the built in providers (look at ProviderFactory#L142).

I'm inclined to align with Romain's thinking, we should just set a high
priority on the built in providers, to avoid any conflicts.  I already did
this to register the Json P provider.  This would more easily allow
consuming frameworks to add their own providers of slightly higher
priorities.

John

On 2017-12-16 21:06, Andy McCright <j.andrew.mccri...@gmail.com> wrote:

True - we would also need to add default priority to the user-specified
providers (‘Priorities.USER’).

On Sat, Dec 16, 2017 at 2:08 PM Romain Manni-Bucau <

rmannibu...@gmail.com>

wrote:


Le 16 déc. 2017 20:28, "Andy McCright" <j.andrew.mccri...@gmail.com> a
écrit :

I don’t have the code in front of me, but I remember that for JAX-RS
providers there was a check for a “user”/“custom” boolean - the

built-in

providers are false, user providers (regardless of priority) are true.
That boolean is checked before the ‘@Priority’ annotation.

With the new emphasis on using ‘@Priority’ in the JAX-RS 2.1 spec, we

could

probably simplify the code (and possibly speed up the sorting logic)

if we

got rid of the special booleans and set ‘@Priority(Integer.MAX_VALUE)’

for

all built-in providers.


This is not forbidden by the spec so we still need a flag to let the

user

overriding cxf defaults, no? (Unlikely doesnt mean never, libs will

have

the same idea i guess, in particular for generic providers)


On Sat, Dec 16, 2017 at 12:55 PM John D. Ament <johndam...@apache.org>
wrote:


The JAX-RS spec mandates a certain number of providers by default.

I'm

noticing that when these providers are added, they're added without

any

priority.  Andy mentioned to me that they should be added with the

priority

of USER + 1, but the actual resolved priority I'm seeing is USER.

Granted, this is within the proxy client code base.  Is this problem

going

to exist as well in the regular clients?  As well as server?

If so, should we annotate 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

[Sergey Beryozkin]

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 something wrong.  However, I'm just delegating 
down to ClientProviderFactory.setProviders, which does pass in custom as false 
for the built in providers (look at ProviderFactory#L142).

I'm inclined to align with Romain's thinking, we should just set a high 
priority on the built in providers, to avoid any conflicts.  I already did this 
to register the Json P provider.  This would more easily allow consuming 
frameworks to add their own providers of slightly higher priorities.

John

On 2017-12-16 21:06, Andy McCright <j.andrew.mccri...@gmail.com> wrote:

True - we would also need to add default priority to the user-specified
providers (‘Priorities.USER’).

On Sat, Dec 16, 2017 at 2:08 PM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:


Le 16 déc. 2017 20:28, "Andy McCright" <j.andrew.mccri...@gmail.com> a
écrit :

I don’t have the code in front of me, but I remember that for JAX-RS
providers there was a check for a “user”/“custom” boolean - the built-in
providers are false, user providers (regardless of priority) are true.
That boolean is checked before the ‘@Priority’ annotation.

With the new emphasis on using ‘@Priority’ in the JAX-RS 2.1 spec, we could
probably simplify the code (and possibly speed up the sorting logic) if we
got rid of the special booleans and set ‘@Priority(Integer.MAX_VALUE)’ for
all built-in providers.


This is not forbidden by the spec so we still need a flag to let the user
overriding cxf defaults, no? (Unlikely doesnt mean never, libs will have
the same idea i guess, in particular for generic providers)


On Sat, Dec 16, 2017 at 12:55 PM John D. Ament <johndam...@apache.org>
wrote:


The JAX-RS spec mandates a certain number of providers by default.  I'm
noticing that when these providers are added, they're added without any
priority.  Andy mentioned to me that they should be added with the

priority

of USER + 1, but the actual resolved priority I'm seeing is USER.

Granted, this is within the proxy client code base.  Is this problem

going

to exist as well in the regular clients?  As well as server?

If so, should we annotate them with USER + 1 to avoid the issue?

John








--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Re: Push does not work

[Sergey Beryozkin]

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 from the Beam project. INFRA 
reported that it was fixed for Beam - not sure if that means it's fixed 
for CXF as well - if not I guess send a mail to INFRA.


Colm.

On Wed, Dec 6, 2017 at 11:54 PM, 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.

Best Regards,
     Andriy Redko

SB> Hi

SB> Seeing my push being repeatedly rejected

SB> remote: This repository is currently out of sync, please
SB> remote: contact us...@infra.apache.org
!
SB> To https://gitbox.apache.org/repos/asf/cxf.git

SB>   ! [remote rejected] master -> master (pre-receive hook declined)

SB> with 'git pull' showing all is up to date...

SB> Can someone try to do some basic update ? Curious is it only me
or not...

SB> Sergey





--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: Push does not work

[Sergey Beryozkin]

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.

Best Regards,
 Andriy Redko

SB> Hi

SB> Seeing my push being repeatedly rejected

SB> remote: This repository is currently out of sync, please
SB> remote: contact us...@infra.apache.org!
SB> To https://gitbox.apache.org/repos/asf/cxf.git
SB>   ! [remote rejected] master -> master (pre-receive hook declined)

SB> with 'git pull' showing all is up to date...

SB> Can someone try to do some basic update ? Curious is it only me or not...

SB> Sergey

Push does not work

[Sergey Beryozkin]

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 date...

Can someone try to do some basic update ? Curious is it only me or not...

Sergey

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

[Sergey Beryozkin]

Sounds like that should be a separate module which links the current 
impl with the profile, profile and JAX-RS may evolve independently.


Wiring the API lib into 3.2.x can be sensitive, not sure having a mix of 
various API flavors will work well...


Sergey
On 04/12/17 01:16, John D. Ament wrote:

The problem I see has to do with how the ResponseExceptionMapper works.
JAX-RS doesn't define this provider, however the MP Rest Client does, and
CXF also has this type of provider.  The handling of this provider is in
two places, ClientProxyImpl and ClientProviderFactory.  We'd have to create
sublcasses of these to handle the MicroProfile specific cases.

FWIW, the API JAR is only 12kb.  I'm not sure it could be optional, since I
was planning to make the CXF interface extend the MP interface
(ResponseExceptionMapper).

John

On Sun, Dec 3, 2017 at 5:40 PM Andriy Redko <drr...@gmail.com> wrote:


Hey John,

That would be an interesting feature, useful even beyond just Microprofile
actually (imho) :)
Should we have a dedicated module for it instead of using the client one?
We would
have the dependency to Microprofile REST Client SPI/API there, may be it
is better
not to introduce it into the existing client module (even as an optional)?

Best Regards,
 Andriy Redko

JDA> Hey all

JDA> Andy (McCright) and I (as well as some others who don't contribute to
CXF)
JDA> have been working on another project, specifically around
standardizing how
JDA> Type Safe rest clients can be built within MIcroProfile.  There's two
main
JDA> aspects to this, as well as some changes potentially required for a
JDA> presently CXF specific provider.

JDA> - Programmatic builder API for creating the clients from a JAX-RS
annotated
JDA> interface
JDA> - CDI injection support for interfaces

JDA> I have most of an implementation for this working, and would like to
start
JDA> to bring it into the CXF codebase.  My thought is to bring most of it
JDA> directly into the client module, and update some of the core logic
there to
JDA> work with MicroProfile's APIs.  There are some functional differences
JDA> though.  One of the things we felt was important was mapping Response
codes
JDA> into Exceptions, something that CXF already had support for.  The
behavior
JDA> is a little different in that we will evaluate multiple mappers as
well 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

[Sergey Beryozkin]

+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:

https://github.com/apache/cxf-fediz/tree/fediz-1.3.3

Maven artifacts:

https://repository.apache.org/content/repositories/orgapachecxf-/

Source distribution:

https://repository.apache.org/content/repositories/orgapachecxf-/org/apache/cxf/fediz/fediz/1.3.3/ 



+1 from me.

Colm.

Re: [VOTE] - Release Apache CXF Fediz 1.4.3

[Sergey Beryozkin]

+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:

https://repository.apache.org/content/repositories/orgapachecxf-1110/

In particular, the source release:

https://repository.apache.org/content/repositories/orgapachecxf-1110/org/apache/cxf/fediz/fediz/1.4.3/

+1 from me.

Colm.

Re: [VOTE] - Release Apache CXF 3.0.16

[Sergey Beryozkin]

+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 artifacts:

https://repository.apache.org/content/repositories/orgapachecxf-1109/

In particular, the source + binary distributions:

https://repository.apache.org/content/repositories/orgapachecxf-1109/org/apache/cxf/apache-cxf/3.0.16/

+1 from me.

Colm.

Re: New Java 9 master

[Sergey Beryozkin]

Hi Jeff

Good to hear from you, thanks for the feedback :-).

I suppose there's some consensus that in the next few months the team 
should probably spend more time with using Java 9 with CXF 3.2.x, and 
really get a better appreciation of what Java 9 is and which tools are 
available around (such as may be Maven Java 9 related as Dan indicated, 
etc) as it's fair enough to say that some of us (incl. myself) are not 
doing practical Java 9 at all at the moment...


Hopefully that will help, perhaps another round of discussions will 
follow afterwards, we'll see.


Thanks, Sergey


On 17/11/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 users to come in and say, when will CXF will do what 
SpringBoot with Java 9 can do, is not strategically right move IMHO.



+1000



Have the Java 9 branch, let people spend as much time as needed to play there, 
keep going with Java 8+9 in 3.2.1. I don't see where the conflict is


+1,000,000!!!

Jeff



Cheers. Sergey
On 16/11/17 13:53, Andriy Redko wrote:

Modules are really far away in the future (IMHO). As per my understanding, we
could think about real modules only when all our dependencies are modularized,
which would take quite a lot of time I suppose. The Reactive Streams part is
really appealing *BUT* even there we **could** keep the same master for 8 and 9
(http://openjdk.java.net/jeps/238).
Honestly, I am not 100% sure we have to branch off the new master and keep it
Java 9 only right now. May be the good moment will be when we discountinue
3.1.x so at least the code will be much easier to cherry-pick?
Best Regards,
Andriy Redko
CS> I am not sure sure about the need for Java 9 modules. Currently I see no
CS> user requesting this. It is also not yet fully clear how these modules
CS> behave in OSGi. As far as I understood as soon as we start with this we
CS> have code that is not working in Java 8. As we require every change to be
CS> done in master first this means we have a lot of back port work. A Java 9
CS> only master will also make it much harder for Java 8 users to supply pull
CS> requests as they have to develop and test on java 9 which is not their
CS> production system.
CS> So I think the current situation with a master that works on Java 9 and
CS> Java 8 is a pretty good situation that we should keep for as long as
CS> possible.
CS> I am not sure how attractive the other Java 9 features are. Personally I
CS> were really eager to adopt Java 8 because of the closures but I see no real
CS> need for myself to rush to java 9.
CS> When 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 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 modules (aka Jigsaw) for
the new master branch? Or we just looking to benefit from the
latest changes in stardand library (as you mentioned, Flow & Co,
collections are also a good example)? Is our current master JDK9
compatible actually (haven't seen successfull builds from
https://builds.apache.org/job/CXF-Master-JDK9) ?
Best Regards,
  Andriy Redko
SB> It's pretty simple really. It's about having a new impetus for the CXF
SB> development.
SB> Without a Java 9 only master CXF will be about fixing the bugs only.
SB> JAX-WS is done long time ago, next version of JAX-RS will take N
amount
SB> of time to materialize.
SB> Java 9 with its Flow class will let CXF do new work around Reactive
SB> support. It will have new features that only work with Java 9 and may
SB> give new ideas for the contributions.
SB> 3.2.x is at the start of its life-cycle and will have a couple of
years
SB> at least for it to retire, giving Java 8 support.
SB> 3.1.x has probably 6 months or so left in it, and after it's gone we
SB> will have 3.2.x and 4.0.x or whatever new version is preferred.
SB> Sergey
SB> On 16/11/17 08:15, Dennis Kieselhorst wrote:

On 2017-11-16 07:27, Christian Schneider <ch...@die-schneider.net>

wrote:

I dont think we can already predict when users move to Java 9.
So creating a Java 9 only branch at this time means we have to
maintain two
main branches over a long time.
What is the rationale behind a Java 9 only branch compared to being
Java 9
and Java 8 compatible on master?

I also don't see a good reas

Re: New Java 9 master

[Sergey Beryozkin]

Well, personally I'd like to see CXF being live rather than staying 
stale. CXF 3.2.x was open for more than a year and it has not gone off 
track.
Java 9 will have Flow, which despite your or mine preferences, will 
attract users who would rather work with standard Java 9 API as opposed 
to the popular but specific to the libs RxJava2 and/or Reactor, so it is 
a massive feature...
IMHO CXF dev community is large enough now for the Java 9+ only branch 
to succeed


Sergey
On 16/11/17 16:10, Christian Schneider wrote:

I mean simple in regard to everyday work on the code. The effort would be
mainly in setting up this build once.

I simply had bad experiences in the past with a master that is never
released for a long time. For example there was a camel 3 master for a long
time and it deteriorated more and more over time as people concentrated on
the code that was going into the releases they use on a daily basis. So no
one really cared about a master that everyone knew is not released anytime
(soon).

Personally I even prefer to simply stay on a java 8+9 master until a big
percentage of people switched to java 9. This will not allow us to use java
9 features until 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 ? 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 lets make this a little more concrete. What do we expect that people do
in the Java 9 master?

Java 9 modules -> As Andriy explained this only works when all our
dependencies are Java 9 modules. So this will not be near term.
Java 9 reactive streams. Could be interesting but there is already rxjava
and project reactor. So people have the reactive capabilities already. So
I
am not sure how many people are really interested in this. We can do kind
of a poll on the user list.
I do not think there are any other Java 9 features that are really an
incentive for a java 9 only branch.

So I think the Java 9 only code could be limited to only a few modules.
For
example we could have a REST client with java 9 Flow support.
So how about having a build that checks if the developer has a jdk8. If
yes
then we skip the java 9 modules in the build. If the developer has java 9
we build all modules. We could then do our release 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...@gmail.com>:

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 users to come in and say, when will CXF will
do what SpringBoot with Java 9 can do, is not strategically right move
IMHO.

Have the Java 9 branch, let people spend as much time as needed to play
there, keep going with Java 8+9 in 3.2.1. I don't see where the conflict
is.

Cheers. Sergey

On 16/11/17 13:53, Andriy Redko wrote:

Modules are really far away in the future (IMHO). As per my

understanding, we
could think about real modules only when all our dependencies are
modularized,
which would take quite a lot of time I suppose. The Reactive Streams
part
is
really appealing *BUT* even there we **could** keep the same master for
8
and 9
(http://openjdk.java.net/jeps/238).

Honestly, I am not 100% sure we have to branch off the new master and
keep it
Java 9 only right now. May be the good moment will be when we
discountinue
3.1.x so at least the code will be much easier to cherry-pick?

Best Regards,
  Andriy Redko

CS> I am not sure sure about the need for Java 9 modules. Currently I
see
no
CS> user requesting this. It is also not yet fully clear how these
modules
CS> behave in OSGi. As far as I understood as soon as we start with this
we
CS> have code that is not working in Java 8. As we require every change
to be
CS> done in master first this means we have a lot of back port work. A
Java 9
CS> only master will also make it much harder for Java 8 users to supply
pull
CS> requests as they have to develop and test on java 9 which is not
their
CS> production system.

CS> So I think the current situation with a master that works on Java 9
and
CS> Java 8 is a pretty good situation that we should keep for as long as
CS> possible.
CS> I am not sure how attractive the other Java 9 features are.
Personally I
CS> were really eager to adopt Java 8 because of the closures but I see
no real
CS> need for myself to rush to java 9.

CS> Wh

Re: New Java 9 master

[Sergey Beryozkin]

If we follow this line of reasoning then we should simply have a single 
branch only in CXF where we'd check Java9, Java 8 and Java 7 modules and 
then do Java 9 or Java 8 or Java 7 releases only from the same branch

and may be this will be simple for the users and for us...

Sergey
On 16/11/17 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 lets make this a little more concrete. What do we expect that 
people do

in the Java 9 master?

Java 9 modules -> As Andriy explained this only works when all our
dependencies are Java 9 modules. So this will not be near term.
Java 9 reactive streams. Could be interesting but there is already rxjava
and project reactor. So people have the reactive capabilities already. 
So I

am not sure how many people are really interested in this. We can do kind
of a poll on the user list.
I do not think there are any other Java 9 features that are really an
incentive for a java 9 only branch.

So I think the Java 9 only code could be limited to only a few 
modules. For

example we could have a REST client with java 9 Flow support.
So how about having a build that checks if the developer has a jdk8. 
If yes

then we skip the java 9 modules in the build. If the developer has java 9
we build all modules. We could then do our release 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...@gmail.com>:


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 users to come in and say, when will CXF 
will
do what SpringBoot with Java 9 can do, is not strategically right 
move IMHO.


Have the Java 9 branch, let people spend as much time as needed to play
there, keep going with Java 8+9 in 3.2.1. I don't see where the 
conflict is.


Cheers. Sergey

On 16/11/17 13:53, Andriy Redko wrote:


Modules are really far away in the future (IMHO). As per my
understanding, we
could think about real modules only when all our dependencies are
modularized,
which would take quite a lot of time I suppose. The Reactive Streams 
part

is
really appealing *BUT* even there we **could** keep the same master 
for 8

and 9
(http://openjdk.java.net/jeps/238).

Honestly, I am not 100% sure we have to branch off the new master and
keep it
Java 9 only right now. May be the good moment will be when we 
discountinue

3.1.x so at least the code will be much easier to cherry-pick?

Best Regards,
 Andriy Redko

CS> I am not sure sure about the need for Java 9 modules. Currently 
I see

no
CS> user requesting this. It is also not yet fully clear how these 
modules
CS> behave in OSGi. As far as I understood as soon as we start with 
this

we
CS> have code that is not working in Java 8. As we require every change
to be
CS> done in master first this means we have a lot of back port work. A
Java 9
CS> only master will also make it much harder for Java 8 users to 
supply

pull
CS> requests as they have to develop and test on java 9 which is not 
their

CS> production system.

CS> So I think the current situation with a master that works on Java 9
and
CS> Java 8 is a pretty good situation that we should keep for as 
long as

CS> possible.
CS> I am not sure how attractive the other Java 9 features are.
Personally I
CS> were really eager to adopt Java 8 because of the closures but I see
no real
CS> need for myself to rush to java 9.

CS> When 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 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 modules (aka Jigsaw) for

the new master branch? Or we just looking to benefit from the
latest changes in stardand library (as you mentioned, Flow & Co,
collections are also a good example)? Is our current master JDK9
compatible actually (haven't seen successfull builds from
https://builds.apache.org/job/CXF-Master-JDK9) ?




Best Regards,

   Andriy Redko



SB> It's pretty simple really. It's about having a new impetus for 

Re: New Java 9 master

[Sergey Beryozkin]

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 lets make this a little more concrete. What do we expect that people do
in the Java 9 master?

Java 9 modules -> As Andriy explained this only works when all our
dependencies are Java 9 modules. So this will not be near term.
Java 9 reactive streams. Could be interesting but there is already rxjava
and project reactor. So people have the reactive capabilities already. So I
am not sure how many people are really interested in this. We can do kind
of a poll on the user list.
I do not think there are any other Java 9 features that are really an
incentive for a java 9 only branch.

So I think the Java 9 only code could be limited to only a few modules. For
example we could have a REST client with java 9 Flow support.
So how about having a build that checks if the developer has a jdk8. If yes
then we skip the java 9 modules in the build. If the developer has java 9
we build all modules. We could then do our release 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...@gmail.com>:


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 users to come in and say, when will CXF will
do what SpringBoot with Java 9 can do, is not strategically right move IMHO.

Have the Java 9 branch, let people spend as much time as needed to play
there, keep going with Java 8+9 in 3.2.1. I don't see where the conflict is.

Cheers. Sergey

On 16/11/17 13:53, Andriy Redko wrote:


Modules are really far away in the future (IMHO). As per my
understanding, we
could think about real modules only when all our dependencies are
modularized,
which would take quite a lot of time I suppose. The Reactive Streams part
is
really appealing *BUT* even there we **could** keep the same master for 8
and 9
(http://openjdk.java.net/jeps/238).

Honestly, I am not 100% sure we have to branch off the new master and
keep it
Java 9 only right now. May be the good moment will be when we discountinue
3.1.x so at least the code will be much easier to cherry-pick?

Best Regards,
 Andriy Redko

CS> I am not sure sure about the need for Java 9 modules. Currently I see
no
CS> user requesting this. It is also not yet fully clear how these modules
CS> behave in OSGi. As far as I understood as soon as we start with this
we
CS> have code that is not working in Java 8. As we require every change
to be
CS> done in master first this means we have a lot of back port work. A
Java 9
CS> only master will also make it much harder for Java 8 users to supply
pull
CS> requests as they have to develop and test on java 9 which is not their
CS> production system.

CS> So I think the current situation with a master that works on Java 9
and
CS> Java 8 is a pretty good situation that we should keep for as long as
CS> possible.
CS> I am not sure how attractive the other Java 9 features are.
Personally I
CS> were really eager to adopt Java 8 because of the closures but I see
no real
CS> need for myself to rush to java 9.

CS> When 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 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 modules (aka Jigsaw) for

the new master branch? Or we just looking to benefit from the
latest changes in stardand library (as you mentioned, Flow & Co,
collections are also a good example)? Is our current master JDK9
compatible actually (haven't seen successfull builds from
https://builds.apache.org/job/CXF-Master-JDK9) ?




Best Regards,

   Andriy Redko




SB> It's pretty simple really. It's about having a new impetus for the CXF

SB> development.




SB> Without a Java 9 only master CXF will be about fixing the bugs only.

SB> JAX-WS is done long time ago, next version of JAX-RS will take N
amount
SB> of time to materialize.




SB> Java 9 with its Flow class will let CXF do new work around Reactive

SB> support. It will have new features that only work with J

Re: New Java 9 master

[Sergey Beryozkin]

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 users to come in and say, when will CXF 
will do what SpringBoot with Java 9 can do, is not strategically right 
move IMHO.


Have the Java 9 branch, let people spend as much time as needed to play 
there, keep going with Java 8+9 in 3.2.1. I don't see where the conflict is.


Cheers. Sergey
On 16/11/17 13:53, Andriy Redko wrote:

Modules are really far away in the future (IMHO). As per my understanding, we
could think about real modules only when all our dependencies are modularized,
which would take quite a lot of time I suppose. The Reactive Streams part is
really appealing *BUT* even there we **could** keep the same master for 8 and 9
(http://openjdk.java.net/jeps/238).

Honestly, I am not 100% sure we have to branch off the new master and keep it
Java 9 only right now. May be the good moment will be when we discountinue
3.1.x so at least the code will be much easier to cherry-pick?

Best Regards,
Andriy Redko

CS> I am not sure sure about the need for Java 9 modules. Currently I see no
CS> user requesting this. It is also not yet fully clear how these modules
CS> behave in OSGi. As far as I understood as soon as we start with this we
CS> have code that is not working in Java 8. As we require every change to be
CS> done in master first this means we have a lot of back port work. A Java 9
CS> only master will also make it much harder for Java 8 users to supply pull
CS> requests as they have to develop and test on java 9 which is not their
CS> production system.

CS> So I think the current situation with a master that works on Java 9 and
CS> Java 8 is a pretty good situation that we should keep for as long as
CS> possible.
CS> I am not sure how attractive the other Java 9 features are. Personally I
CS> were really eager to adopt Java 8 because of the closures but I see no real
CS> need for myself to rush to java 9.

CS> When 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 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 modules (aka Jigsaw) for
the new master branch? Or we just looking to benefit from the
latest changes in stardand library (as you mentioned, Flow & Co,
collections are also a good example)? Is our current master JDK9
compatible actually (haven't seen successfull builds from
https://builds.apache.org/job/CXF-Master-JDK9) ?



Best Regards,
  Andriy Redko



SB> It's pretty simple really. It's about having a new impetus for the CXF
SB> development.



SB> Without a Java 9 only master CXF will be about fixing the bugs only.
SB> JAX-WS is done long time ago, next version of JAX-RS will take N
amount
SB> of time to materialize.



SB> Java 9 with its Flow class will let CXF do new work around Reactive
SB> support. It will have new features that only work with Java 9 and may
SB> give new ideas for the contributions.



SB> 3.2.x is at the start of its life-cycle and will have a couple of
years
SB> at least for it to retire, giving Java 8 support.



SB> 3.1.x has probably 6 months or so left in it, and after it's gone we
SB> will have 3.2.x and 4.0.x or whatever new version is preferred.



SB> Sergey
SB> On 16/11/17 08:15, Dennis Kieselhorst wrote:



On 2017-11-16 07:27, Christian Schneider <ch...@die-schneider.net>

wrote:



I dont think we can already predict when users move to Java 9.
So creating a Java 9 only branch at this time means we have to
maintain two
main branches over a long time.



What is the rationale behind a Java 9 only branch compared to being
Java 9
and Java 8 compatible on master?




I also don't see a good reason to do that at the moment. Let's release
the XJC plugin and users should be able to use CXF with Java 9 or am I
missing something?



Cheers
Dennis






CS> --

Re: Remove obsolete RxJava code and keep RxJava2 only one

[Sergey Beryozkin]

In my defense I'd say neither Jersey nor Resteasy has as many many 
modules as CXF has, lol :-)


Sergey
On 16/11/17 13:55, Andriy Redko wrote:

+1 to that, also Jersey has RxJava and RxJava2 modules (at least for
the client side).

Thursday, November 16, 2017, 8:51:25 AM, you wrote:

SB> Hi Andriy

SB> Yeah, that is true. The only indirect reference to the fact CXF +
SB> RxJava1 might be combined somehow is that the initial RxJava1 code was
SB> added after a JIRA request was opened.
SB> By the way I've browsed around and found out ReastEasy friends have
SB> RxJava and RxJava2 modules :-).

SB> I guess the only prob with splitting it into tow modules in CXF is that
SB> CXF 3.2.1 is known to ship RxJava2 code in the cxf-rt-rs-extension-rx,
SB> so I guess it would have to be moved to cxf-rt-rs-extension-rx2, and I'd
SB> not be surprised if it would actually be noticed by CXF 3.2.2 users,
SB> given that users like trying newer things...

SB> So perhaps keeping things as is in 3.2.x is the best compromize

SB> Cheers. Sergey
SB> On 16/11/17 13:41, Andriy Redko wrote:

Let's do what is really the best for CXF in short term (long term is obviously
dropping RxJava 1.x). I saw and  still see RxJava 1.x in the field, BUT I 
haven't
seen the CXF + RxJava 1.x in use yet :) So my arguments are purely based on
assupmtions, not the real facts :-D



SB> It's obviously not only my decision what to do with this code, you are
SB> right it's only my opinion (which will stay non-binding) which is to
SB> keep where it is now just in case and drop it once the new master opens.



SB> To be honest, it does not matter much to me :-), so if few more PMCs say
SB> yes, def has to be a new module - then I'll give my +1 and move on, as I
SB> said purely from a tech point of view a dedicated module without
SB> optional deps is better.



SB> I'm simply hesitating, given how much effort went into dropping some old
SB> modules from 3.2.x, to start with another module with precisely 4 files
SB> (3 in .client subpackage, 1 in .server) with us (me definitely) unlikely
SB> contributing to it at this stage. I'd rather spend the limited amount of
SB> time I have now on growing the small (but with the prospect of growth)
SB> reactivestreams lib we've discussed with John which can be used by
SB> RxJava2 and Reactor code...




SB> Cheers, Sergey
SB> On 16/11/17 12:02, Andriy Redko wrote:

Fair enough, if we the new module is not a option (in your opinion),
I would vote to remove the RxJava 1.x integration and dependency.



SB> As I said, as far as CXF is concerned, there's no prospect of RxJava
SB> related code growing, and contributing to a CXF module noise to support
SB> a legacy library (I know I have to be careful now about the wording:-),
SB> I'm meaning here RxJava2 embracing org.ractivestreams) is not worth it IMHO.



SB> If you check my earlier reply, I suggested to keep it where it is now
SB> after all. So if we have some users somewhere deciding to stay with
SB> RxJava then they'd have the support they need.



SB> Cheers, SErgey
SB> On 16/11/17 11:45, Andriy Redko wrote:

Got it, so "legacy" part is questionable here. Check out the releases page,
https://github.com/ReactiveX/RxJava/releases, the 1.x is still being
actively
supported and maintained (and there are reasons for that, as I
mentioned). So
it is really up to us to decide, should we support it or not, but with
the new
module we could get the stats and make the decision not based on
"legacy" but
if it is used or not. I don't have particular attachments to RxJava 1.x so
if you are confident no one is relying on this integration, I would
agree with
you and we should better remove this code.



*SB> The problem is not about a new module, but about RxJava is a legacy
lib,
SB> and having a module with 2/3 files with no prospect of going beyond
this
SB> number is not worth it IMHO



SB> Sergey



SB> On 16/11/17 11:15, Andrey Redko wrote:

Hey Sergey,



I think the "ideal" in this case depends on whom 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" <*sberyoz...@gmail.com 
<mailto:sberyoz...@gmail.com>*> wrote:



Hi Andriy



As I said, introducing a dedicated support for a legacy library in the
form of a new module would not be ideal IMHO



Cheers, Sergey
On 15/11/17 23:53, Andriy Redko wrote:



Hey Sergey,



That would be ideal I think (move RxJava into separate module). RxJava2
and
RxJava are quite different frameworks, some people just stuck with RxJava
so
we could support them there. Thanks.



Best Regards,
 Andriy Redko



JDA> What a

Re: Remove obsolete RxJava code and keep RxJava2 only one

[Sergey Beryozkin]

Hi Andriy

Yeah, that is true. The only indirect reference to the fact CXF + 
RxJava1 might be combined somehow is that the initial RxJava1 code was 
added after a JIRA request was opened.
By the way I've browsed around and found out ReastEasy friends have 
RxJava and RxJava2 modules :-).


I guess the only prob with splitting it into tow modules in CXF is that 
CXF 3.2.1 is known to ship RxJava2 code in the cxf-rt-rs-extension-rx, 
so I guess it would have to be moved to cxf-rt-rs-extension-rx2, and I'd 
not be surprised if it would actually be noticed by CXF 3.2.2 users, 
given that users like trying newer things...


So perhaps keeping things as is in 3.2.x is the best compromize

Cheers. Sergey
On 16/11/17 13:41, Andriy Redko wrote:

Let's do what is really the best for CXF in short term (long term is obviously
dropping RxJava 1.x). I saw and  still see RxJava 1.x in the field, BUT I 
haven't
seen the CXF + RxJava 1.x in use yet :) So my arguments are purely based on
assupmtions, not the real facts :-D

SB> It's obviously not only my decision what to do with this code, you are
SB> right it's only my opinion (which will stay non-binding) which is to
SB> keep where it is now just in case and drop it once the new master opens.

SB> To be honest, it does not matter much to me :-), so if few more PMCs say
SB> yes, def has to be a new module - then I'll give my +1 and move on, as I
SB> said purely from a tech point of view a dedicated module without
SB> optional deps is better.

SB> I'm simply hesitating, given how much effort went into dropping some old
SB> modules from 3.2.x, to start with another module with precisely 4 files
SB> (3 in .client subpackage, 1 in .server) with us (me definitely) unlikely
SB> contributing to it at this stage. I'd rather spend the limited amount of
SB> time I have now on growing the small (but with the prospect of growth)
SB> reactivestreams lib we've discussed with John which can be used by
SB> RxJava2 and Reactor code...


SB> Cheers, Sergey
SB> On 16/11/17 12:02, Andriy Redko wrote:

Fair enough, if we the new module is not a option (in your opinion),
I would vote to remove the RxJava 1.x integration and dependency.



SB> As I said, as far as CXF is concerned, there's no prospect of RxJava
SB> related code growing, and contributing to a CXF module noise to support
SB> a legacy library (I know I have to be careful now about the wording:-),
SB> I'm meaning here RxJava2 embracing org.ractivestreams) is not worth it IMHO.



SB> If you check my earlier reply, I suggested to keep it where it is now
SB> after all. So if we have some users somewhere deciding to stay with
SB> RxJava then they'd have the support they need.



SB> Cheers, SErgey
SB> On 16/11/17 11:45, Andriy Redko wrote:

Got it, so "legacy" part is questionable here. Check out the releases page,
https://github.com/ReactiveX/RxJava/releases, the 1.x is still being
actively
supported and maintained (and there are reasons for that, as I
mentioned). So
it is really up to us to decide, should we support it or not, but with
the new
module we could get the stats and make the decision not based on
"legacy" but
if it is used or not. I don't have particular attachments to RxJava 1.x so
if you are confident no one is relying on this integration, I would
agree with
you and we should better remove this code.



*SB> The problem is not about a new module, but about RxJava is a legacy
lib,
SB> and having a module with 2/3 files with no prospect of going beyond
this
SB> number is not worth it IMHO



SB> Sergey



SB> On 16/11/17 11:15, Andrey Redko wrote:

Hey Sergey,



I think the "ideal" in this case depends on whom 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" <*sberyoz...@gmail.com 
<mailto:sberyoz...@gmail.com>*> wrote:



Hi Andriy



As I said, introducing a dedicated support for a legacy library in the
form of a new module would not be ideal IMHO



Cheers, Sergey
On 15/11/17 23:53, Andriy Redko wrote:



Hey Sergey,



That would be ideal I think (move RxJava into separate module). RxJava2
and
RxJava are quite different frameworks, some people just stuck with RxJava
so
we could support them there. Thanks.



Best Regards,
Andriy Redko



JDA> What about just leaving the old RxJava code in a module by itself
(when I
JDA> was looking 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 <mailto:sberyoz...@gmail.com>*>

JDA> wrote:



Hi




cxf-rt-rs-extension-rx ships th

Re: New Java 9 master

[Sergey Beryozkin]

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 master it will be expected that it won't work with 
Java 9. I guess it's also about trying to anticipate what the users will 
ask. If someone prefers to avoid Java 9 only then they'd just stay for a 
long time with 3.2.x


Sergey
On 16/11/17 13:02, Christian Schneider wrote:

I am not sure sure about the need for Java 9 modules. Currently I see no
user requesting this. It is also not yet fully clear how these modules
behave in OSGi. As far as I understood as soon as we start with this we
have code that is not working in Java 8. As we require every change to be
done in master first this means we have a lot of back port work. A Java 9
only master will also make it much harder for Java 8 users to supply pull
requests as they have to develop and test on java 9 which is not their
production system.

So I think the current situation with a master that works on Java 9 and
Java 8 is a pretty good situation that we should keep for as long as
possible.
I am not sure how attractive the other Java 9 features are. Personally I
were really eager to adopt Java 8 because of the closures but I see no 
real

need for myself to rush to java 9.

When I remember how reluctant we 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 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 modules (aka Jigsaw) for
the new master branch? Or we just looking to benefit from the
latest changes in stardand library (as you mentioned, Flow & Co,
collections are also a good example)? Is our current master JDK9
compatible actually (haven't seen successfull builds from
https://builds.apache.org/job/CXF-Master-JDK9) ?

Best Regards,
  Andriy Redko

SB> It's pretty simple really. It's about having a new impetus for 
the CXF

SB> development.

SB> Without a Java 9 only master CXF will be about fixing the bugs 
only.

SB> JAX-WS is done long time ago, next version of JAX-RS will take N
amount
SB> of time to materialize.

SB> Java 9 with its Flow class will let CXF do new work around Reactive
SB> support. It will have new features that only work with Java 9 
and may

SB> give new ideas for the contributions.

SB> 3.2.x is at the start of its life-cycle and will have a couple of
years
SB> at least for it to retire, giving Java 8 support.

SB> 3.1.x has probably 6 months or so left in it, and after it's 
gone we

SB> will have 3.2.x and 4.0.x or whatever new version is preferred.

SB> Sergey
SB> On 16/11/17 08:15, Dennis Kieselhorst wrote:


On 2017-11-16 07:27, Christian Schneider <ch...@die-schneider.net>

wrote:


I dont think we can already predict when users move to Java 9.
So creating a Java 9 only branch at this time means we have to
maintain two
main branches over a long time.

What is the rationale behind a Java 9 only branch compared to being
Java 9
and Java 8 compatible on master?



I also don't see a good reason to do that at the moment. Let's 
release
the XJC plugin and users should be able to use CXF with Java 9 or 
am I

missing something?

Cheers
Dennis










--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Re: New Java 9 master

[Sergey Beryozkin]

Yes, in a Java 9 only master it will be expected that it won't work with 
Java 9. I guess it's also about trying to anticipate what the users will 
ask. If someone prefers to avoid Java 9 only then they'd just stay for a 
long time with 3.2.x


Sergey
On 16/11/17 13:02, Christian Schneider wrote:

I am not sure sure about the need for Java 9 modules. Currently I see no
user requesting this. It is also not yet fully clear how these modules
behave in OSGi. As far as I understood as soon as we start with this we
have code that is not working in Java 8. As we require every change to be
done in master first this means we have a lot of back port work. A Java 9
only master will also make it much harder for Java 8 users to supply pull
requests as they have to develop and test on java 9 which is not their
production system.

So I think the current situation with a master that works on Java 9 and
Java 8 is a pretty good situation that we should keep for as long as
possible.
I am not sure how attractive the other Java 9 features are. Personally I
were really eager to adopt Java 8 because of the closures but I see no real
need for myself to rush to java 9.

When I remember how reluctant we 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 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 modules (aka Jigsaw) for
the new master branch? Or we just looking to benefit from the
latest changes in stardand library (as you mentioned, Flow & Co,
collections are also a good example)? Is our current master JDK9
compatible actually (haven't seen successfull builds from
https://builds.apache.org/job/CXF-Master-JDK9) ?

Best Regards,
  Andriy Redko

SB> It's pretty simple really. It's about having a new impetus for the CXF
SB> development.

SB> Without a Java 9 only master CXF will be about fixing the bugs only.
SB> JAX-WS is done long time ago, next version of JAX-RS will take N
amount
SB> of time to materialize.

SB> Java 9 with its Flow class will let CXF do new work around Reactive
SB> support. It will have new features that only work with Java 9 and may
SB> give new ideas for the contributions.

SB> 3.2.x is at the start of its life-cycle and will have a couple of
years
SB> at least for it to retire, giving Java 8 support.

SB> 3.1.x has probably 6 months or so left in it, and after it's gone we
SB> will have 3.2.x and 4.0.x or whatever new version is preferred.

SB> Sergey
SB> On 16/11/17 08:15, Dennis Kieselhorst wrote:


On 2017-11-16 07:27, Christian Schneider <ch...@die-schneider.net>

wrote:


I dont think we can already predict when users move to Java 9.
So creating a Java 9 only branch at this time means we have to
maintain two
main branches over a long time.

What is the rationale behind a Java 9 only branch compared to being
Java 9
and Java 8 compatible on master?



I also don't see a good reason to do that at the moment. Let's release
the XJC plugin and users should be able to use CXF with Java 9 or am I
missing something?

Cheers
Dennis

Re: New Java 9 master

[Sergey Beryozkin]

Hi Freeman

OK, thanks. So we already have 3.2.1 meeting a Java9 + Java8 
requirement, which is great. I haven't even tried to build CXF master 
with Java 9 :-), will try asap...


Cheers, Sergey
On 16/11/17 12:23, Freeman Fang wrote:

Hi Sergey,

Yep, it’s about to use Java9 to build and run CXF 3.2.x with classical java 
“classpath” way. To fully adapt the CXF to use jigsaw module, I think we need a 
JDK9 only branch to work with.

Btw, it’s already in current CXF master(3.2.x-SNAPSHOT). We can build and pass 
all tests with latest  JDK 9.0.1. So CXF 3.2.x have it already. I guess what we 
would do next is fork a 3.2.x-fixes branch based on current master, and change 
the master version to 4.0.0-SNAPSHOT, and this master branch could be the one 
we can experiment with pure JAVA9 new features.

Cheers.
－
Freeman(Yue) Fang

Red Hat, Inc.
FuseSource is now part of Red Hat




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/17 06:17, Freeman Fang wrote:

+1
If next CXF major release(3.3 or 4.0) are not going to support JDK8 anymore, 
it’s about the time to create master branch which is for Java9(and the 
successor JDK version which is not very far away). And this also would be easy 
for us to adjust CXF to use the jigsaw module eventually, like to add 
module-info.java  to see how is it going on there.
Best Regards
－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat

On Nov 16, 2017, at 1:03 PM, Andy McCright <j.andrew.mccri...@gmail.com> wrote:

Hi Sergey,

I'm in favor of the idea.  One thing worth noting is that Java 9 is a very
limited support release.  According to Oracle's support strategy [1], Java
9 will only be supported until March 2018, then they will be releasing Java
10 (aka 18.3) which also will have a short shelf-life.  The next long-term
support release is 18.9 which releases in September.  We'll probably want
the new Java 9 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 we open a new Java 9 only master soon enough ?

Thanks, Sergey

Re: New Java 9 master

[Sergey Beryozkin]

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 modules (aka Jigsaw) for
the new master branch? Or we just looking to benefit from the
latest changes in stardand library (as you mentioned, Flow & Co,
collections are also a good example)? Is our current master JDK9
compatible actually (haven't seen successfull builds from
https://builds.apache.org/job/CXF-Master-JDK9) ?

Best Regards,
 Andriy Redko

SB> It's pretty simple really. It's about having a new impetus for the CXF
SB> development.

SB> Without a Java 9 only master CXF will be about fixing the bugs only.
SB> JAX-WS is done long time ago, next version of JAX-RS will take N amount
SB> of time to materialize.

SB> Java 9 with its Flow class will let CXF do new work around Reactive
SB> support. It will have new features that only work with Java 9 and may
SB> give new ideas for the contributions.

SB> 3.2.x is at the start of its life-cycle and will have a couple of years
SB> at least for it to retire, giving Java 8 support.

SB> 3.1.x has probably 6 months or so left in it, and after it's gone we
SB> will have 3.2.x and 4.0.x or whatever new version is preferred.

SB> Sergey
SB> On 16/11/17 08:15, Dennis Kieselhorst wrote:

On 2017-11-16 07:27, Christian Schneider  wrote:

I dont think we can already predict when users move to Java 9.
So creating a Java 9 only branch at this time means we have to maintain two
main branches over a long time.

What is the rationale behind a Java 9 only branch compared to being Java 9
and Java 8 compatible on master?


I also don't see a good reason to do that at the moment. Let's release the XJC 
plugin and users should be able to use CXF with Java 9 or am I missing 
something?

Cheers
Dennis

Re: Remove obsolete RxJava code and keep RxJava2 only one

[Sergey Beryozkin]

It's obviously not only my decision what to do with this code, you are 
right it's only my opinion (which will stay non-binding) which is to 
keep where it is now just in case and drop it once the new master opens.


To be honest, it does not matter much to me :-), so if few more PMCs say 
yes, def has to be a new module - then I'll give my +1 and move on, as I 
said purely from a tech point of view a dedicated module without 
optional deps is better.


I'm simply hesitating, given how much effort went into dropping some old 
modules from 3.2.x, to start with another module with precisely 4 files 
(3 in .client subpackage, 1 in .server) with us (me definitely) unlikely 
contributing to it at this stage. I'd rather spend the limited amount of 
time I have now on growing the small (but with the prospect of growth) 
reactivestreams lib we've discussed with John which can be used by 
RxJava2 and Reactor code...



Cheers, Sergey
On 16/11/17 12:02, Andriy Redko wrote:

Fair enough, if we the new module is not a option (in your opinion),
I would vote to remove the RxJava 1.x integration and dependency.

SB> As I said, as far as CXF is concerned, there's no prospect of RxJava
SB> related code growing, and contributing to a CXF module noise to support
SB> a legacy library (I know I have to be careful now about the wording:-),
SB> I'm meaning here RxJava2 embracing org.ractivestreams) is not worth it IMHO.

SB> If you check my earlier reply, I suggested to keep it where it is now
SB> after all. So if we have some users somewhere deciding to stay with
SB> RxJava then they'd have the support they need.

SB> Cheers, SErgey
SB> On 16/11/17 11:45, Andriy Redko wrote:

Got it, so "legacy" part is questionable here. Check out the releases page,
https://github.com/ReactiveX/RxJava/releases, the 1.x is still being
actively
supported and maintained (and there are reasons for that, as I
mentioned). So
it is really up to us to decide, should we support it or not, but with
the new
module we could get the stats and make the decision not based on
"legacy" but
if it is used or not. I don't have particular attachments to RxJava 1.x so
if you are confident no one is relying on this integration, I would
agree with
you and we should better remove this code.

*SB> The problem is not about a new module, but about RxJava is a legacy
lib,
SB> and having a module with 2/3 files with no prospect of going beyond
this
SB> number is not worth it IMHO

SB> Sergey

SB> On 16/11/17 11:15, Andrey Redko wrote:

Hey Sergey,



I think the "ideal" in this case depends on whom 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" <*sberyoz...@gmail.com 
<mailto:sberyoz...@gmail.com>*> wrote:



Hi Andriy



As I said, introducing a dedicated support for a legacy library in the
form of a new module would not be ideal IMHO



Cheers, Sergey
On 15/11/17 23:53, Andriy Redko wrote:



Hey Sergey,



That would be ideal I think (move RxJava into separate module). RxJava2
and
RxJava are quite different frameworks, some people just stuck with RxJava
so
we could support them there. Thanks.



Best Regards,
       Andriy Redko



JDA> What about just leaving the old RxJava code in a module by itself
(when I
JDA> was looking 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 <mailto: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 client, and the same for the (old) RxJava
Observable...




While even the (old) RxJava code is very new for CXF, the reality is

that RxJava has been around for a while now and with RxJava2 embracing
org.reactivestreams, it's hard to see CXF users preferring to start with
the (old) RxJava.




The other minor problem is that cxf-rt-rs-extension-rx has optional

RxJava and RxJava2 deps to be able to ship the relevant code in the same
module and splitting it into 2 modules will be too much at this point.




I suggest that unless some users confirm (I CC to the users) that they

need to use the (old) RxJava code, then we just remove it and make
things much simpler...




Thanks, Sergey







*

Re: Remove obsolete RxJava code and keep RxJava2 only one

[Sergey Beryozkin]

As I said, as far as CXF is concerned, there's no prospect of RxJava 
related code growing, and contributing to a CXF module noise to support 
a legacy library (I know I have to be careful now about the wording:-), 
I'm meaning here RxJava2 embracing org.ractivestreams) is not worth it IMHO.


If you check my earlier reply, I suggested to keep it where it is now 
after all. So if we have some users somewhere deciding to stay with 
RxJava then they'd have the support they need.


Cheers, SErgey
On 16/11/17 11:45, Andriy Redko wrote:

Got it, so "legacy" part is questionable here. Check out the releases page,
https://github.com/ReactiveX/RxJava/releases, the 1.x is still being 
actively
supported and maintained (and there are reasons for that, as I 
mentioned). So
it is really up to us to decide, should we support it or not, but with 
the new
module we could get the stats and make the decision not based on 
"legacy" but

if it is used or not. I don't have particular attachments to RxJava 1.x so
if you are confident no one is relying on this integration, I would 
agree with

you and we should better remove this code.

*SB> The problem is not about a new module, but about RxJava is a legacy 
lib,
SB> and having a module with 2/3 files with no prospect of going beyond 
this

SB> number is not worth it IMHO

SB> Sergey

SB> On 16/11/17 11:15, Andrey Redko wrote:

Hey Sergey,



I think the "ideal" in this case depends on whom 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" <*sberyoz...@gmail.com 
<mailto:sberyoz...@gmail.com>*> wrote:



Hi Andriy



As I said, introducing a dedicated support for a legacy library in the
form of a new module would not be ideal IMHO



Cheers, Sergey
On 15/11/17 23:53, Andriy Redko wrote:



Hey Sergey,



That would be ideal I think (move RxJava into separate module). RxJava2
and
RxJava are quite different frameworks, some people just stuck with RxJava
so
we could support them there. Thanks.



Best Regards,
      Andriy Redko



JDA> What about just leaving the old RxJava code in a module by itself
(when I
JDA> was looking 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 <mailto: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 client, and the same for the (old) RxJava
Observable...




While even the (old) RxJava code is very new for CXF, the reality is

that RxJava has been around for a while now and with RxJava2 embracing
org.reactivestreams, it's hard to see CXF users preferring to start with
the (old) RxJava.




The other minor problem is that cxf-rt-rs-extension-rx has optional

RxJava and RxJava2 deps to be able to ship the relevant code in the same
module and splitting it into 2 modules will be too much at this point.




I suggest that unless some users confirm (I CC to the users) that they

need to use the (old) RxJava code, then we just remove it and make
things much simpler...




Thanks, Sergey







*

Re: Introduction

[Sergey Beryozkin]

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 in the last year I've been derailed to ext.js
and Python), from Romania, and CXF user and fan.

I also like to keep an eye on the development progress on some of the
frameworks I use (like CXF, Spring or Hibernate), as I find it valuable to
see if there are any bugs that could affect me and also to see how various
features are implemented by people smarter than me :-)
That implies looking at GIT changes and I like to comment if happen to
notice something weird, which triggered the attention of Sergey.

Unfortunately, I rarely have the time to contribute more to the frameworks
I use, in the form of code changes.

Regards,
Andrei

Re: Remove obsolete RxJava code and keep RxJava2 only one

[Sergey Beryozkin]

The problem is not about a new module, but about RxJava is a legacy lib, 
and having a module with 2/3 files with no prospect of going beyond this 
number is not worth it IMHO


Sergey

On 16/11/17 11:15, Andrey Redko wrote:

Hey Sergey,

I think the "ideal" in this case depends on whom 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" <sberyoz...@gmail.com> wrote:


Hi Andriy

As I said, introducing a dedicated support for a legacy library in the
form of a new module would not be ideal IMHO

Cheers, Sergey
On 15/11/17 23:53, Andriy Redko wrote:


Hey Sergey,

That would be ideal I think (move RxJava into separate module). RxJava2
and
RxJava are quite different frameworks, some people just stuck with RxJava
so
we could support them there. Thanks.

Best Regards,
  Andriy Redko

JDA> What about just leaving the old RxJava code in a module by itself
(when I
JDA> was looking 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 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 reality is

that RxJava has been around for a while now and with RxJava2 embracing
org.reactivestreams, it's hard to see CXF users preferring to start with
the (old) RxJava.




The other minor problem is that cxf-rt-rs-extension-rx has optional

RxJava and RxJava2 deps to be able to ship the relevant code in the same
module and splitting it into 2 modules will be too much at this point.




I suggest that unless some users confirm (I CC to the users) that they

need to use the (old) RxJava code, then we just remove it and make
things much simpler...




Thanks, Sergey

Re: New Java 9 master

[Sergey Beryozkin]

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/17 06:17, Freeman Fang wrote:

+1

If next CXF major release(3.3 or 4.0) are not going to support JDK8 anymore, 
it’s about the time to create master branch which is for Java9(and the 
successor JDK version which is not very far away). And this also would be easy 
for us to adjust CXF to use the jigsaw module eventually, like to add 
module-info.java  to see how is it going on there.

Best Regards
－
Freeman(Yue) Fang

Red Hat, Inc.
FuseSource is now part of Red Hat




On Nov 16, 2017, at 1:03 PM, Andy McCright <j.andrew.mccri...@gmail.com> wrote:

Hi Sergey,

I'm in favor of the idea.  One thing worth noting is that Java 9 is a very
limited support release.  According to Oracle's support strategy [1], Java
9 will only be supported until March 2018, then they will be releasing Java
10 (aka 18.3) which also will have a short shelf-life.  The next long-term
support release is 18.9 which releases in September.  We'll probably want
the new Java 9 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 we open a new Java 9 only master soon enough ?

Thanks, Sergey

Re: New Java 9 master

[Sergey Beryozkin]

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 new work around Reactive 
support. It will have new features that only work with Java 9 and may 
give new ideas for the contributions.


3.2.x is at the start of its life-cycle and will have a couple of years 
at least for it to retire, giving Java 8 support.


3.1.x has probably 6 months or so left in it, and after it's gone we 
will have 3.2.x and 4.0.x or whatever new version is preferred.


Sergey
On 16/11/17 08:15, Dennis Kieselhorst wrote:

On 2017-11-16 07:27, Christian Schneider  wrote:

I dont think we can already predict when users move to Java 9.
So creating a Java 9 only branch at this time means we have to maintain two
main branches over a long time.

What is the rationale behind a Java 9 only branch compared to being Java 9
and Java 8 compatible on master?


I also don't see a good reason to do that at the moment. Let's release the XJC 
plugin and users should be able to use CXF with Java 9 or am I missing 
something?

Cheers
Dennis

Re: New Java 9 master

[Sergey Beryozkin]

Hi Andy

Right, somewhere around March 2018 would be fine, though, I suppose, 
given this master would be open for a long time, it would be just a 
matter of updating to 18.3 and then to 18.9, I guess by the time a would 
be CXF 4.0.0 gets released at least 18.3  will have already been 
released as well :-)


Cheers, Sergey
On 16/11/17 05:03, Andy McCright wrote:

Hi Sergey,

I'm in favor of the idea.  One thing worth noting is that Java 9 is a very
limited support release.  According to Oracle's support strategy [1], Java
9 will only be supported until March 2018, then they will be releasing Java
10 (aka 18.3) which also will have a short shelf-life.  The next long-term
support release is 18.9 which releases in September.  We'll probably want
the new Java 9 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 we open a new Java 9 only master soon enough ?

Thanks, Sergey

Re: Remove obsolete RxJava code and keep RxJava2 only one

[Sergey Beryozkin]

Hi Andriy

As I said, introducing a dedicated support for a legacy library in the 
form of a new module would not be ideal IMHO


Cheers, Sergey
On 15/11/17 23:53, Andriy Redko wrote:

Hey Sergey,

That would be ideal I think (move RxJava into separate module). RxJava2 and
RxJava are quite different frameworks, some people just stuck with RxJava so
we could support them there. Thanks.

Best Regards,
 Andriy Redko

JDA> What about just leaving the old RxJava code in a module by itself (when I
JDA> was looking 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 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 reality is
that RxJava has been around for a while now and with RxJava2 embracing
org.reactivestreams, it's hard to see CXF users preferring to start with
the (old) RxJava.



The other minor problem is that cxf-rt-rs-extension-rx has optional
RxJava and RxJava2 deps to be able to ship the relevant code in the same
module and splitting it into 2 modules will be too much at this point.



I suggest that unless some users confirm (I CC to the users) that they
need to use the (old) RxJava code, then we just remove it and make
things much simpler...



Thanks, Sergey

Re: Remove obsolete RxJava code and keep RxJava2 only one

[Sergey Beryozkin]

Hi,

Indeed, creating a new module specifically for RxJava is technically 
clean, but creating it for a code which no one will probably use and 
also adding one module to the large number of CXF modules, with only 2/3 
Java files :-) is a bit problematic...


I guess I can keep it as is in 3.2.x but remove it once a new master 
opens...


Thanks, Sergey
On 15/11/17 16:04, John D. Ament wrote:

What about just leaving the old RxJava code in a module by itself (when I
was looking recently, it didn't make much sense to see both RxJava and
RxJava2 in one module).

On Wed, Nov 15, 2017 at 10:56 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...

While even the (old) RxJava code is very new for CXF, the reality is
that RxJava has been around for a while now and with RxJava2 embracing
org.reactivestreams, it's hard to see CXF users preferring to start with
the (old) RxJava.

The other minor problem is that cxf-rt-rs-extension-rx has optional
RxJava and RxJava2 deps to be able to ship the relevant code in the same
module and splitting it into 2 modules will be too much at this point.

I suggest that unless some users confirm (I CC to the users) that they
need to use the (old) RxJava code, then we just remove it and make
things much simpler...

Thanks, Sergey

Remove obsolete RxJava code and keep RxJava2 only one

[Sergey Beryozkin]

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 reality is 
that RxJava has been around for a while now and with RxJava2 embracing 
org.reactivestreams, it's hard to see CXF users preferring to start with 
the (old) RxJava.


The other minor problem is that cxf-rt-rs-extension-rx has optional 
RxJava and RxJava2 deps to be able to ship the relevant code in the same 
module and splitting it into 2 modules will be too much at this point.


I suggest that unless some users confirm (I CC to the users) that they 
need to use the (old) RxJava code, then we just remove it and make 
things much simpler...


Thanks, Sergey

New Java 9 master

[Sergey Beryozkin]

Hi

Should we open a new Java 9 only master soon enough ?

Thanks, Sergey

Re: JIRA Karma?

[Sergey Beryozkin]

Hi Andy

I've added you to the Committers group, hope that should be enough

Cheers, Sergey
On 09/11/17 04:08, Andy McCright wrote:

Hi Dan,

Could you grant me the same authority?  I think I'm in the same boat that
John was -  able to commit code changes, but unable to assign JIRAs.

Thanks,

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 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. Ament wrote:

Hi,

Could someone give me karma on JIRA to assign tickets to myself?

John

Re: JIRA Karma?

[Sergey Beryozkin]

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. Ament wrote:

Hi,

Could someone give me karma on JIRA to assign tickets to myself?

John

Re: [cxf] branch master updated: Add doPrivs

[Sergey Beryozkin]

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 dual-hosted git repository.

amccright pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cxf.git


The following commit(s) were added to refs/heads/master by this push:
  new 294e7aa  Add doPrivs
294e7aa is described below

commit 294e7aa05790c6a5925accac99841b0a0ceee1ea
Author: Andy McCright 
AuthorDate: Wed Oct 25 15:54:15 2017 -0500

 Add doPrivs
---
  .../apache/cxf/jaxrs/model/BeanResourceInfo.java   | 34 --
  1 file changed, 32 insertions(+), 2 deletions(-)

diff --git 
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/model/BeanResourceInfo.java
 
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/model/BeanResourceInfo.java
index 2f48fec..6134e9d 100644
--- 
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/model/BeanResourceInfo.java
+++ 
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/model/BeanResourceInfo.java
@@ -17,11 +17,32 @@
   * under the License.
   */
  
+/**

+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
  package org.apache.cxf.jaxrs.model;
  
  import java.lang.annotation.Annotation;

  import java.lang.reflect.Field;
  import java.lang.reflect.Method;
+import java.security.AccessController;
+import java.security.PrivilegedAction;
  import java.util.ArrayList;
  import java.util.Collections;
  import java.util.List;
@@ -59,7 +80,7 @@ public abstract class BeanResourceInfo extends 
AbstractResourceInfo {
  if (Object.class == cls || cls == null) {
  return;
  }
-for (Field f : cls.getDeclaredFields()) {
+for (Field f : getDeclaredFields(cls)) {
  for (Annotation a : f.getAnnotations()) {
  if 
(AnnotationUtils.isParamAnnotationClass(a.annotationType())) {
  if (paramFields == null) {
@@ -110,4 +131,13 @@ public abstract class BeanResourceInfo extends 
AbstractResourceInfo {
  return paramFields == null ? Collections.emptyList()
  : 
Collections.unmodifiableList(paramFields);
  }
-}
+
+private static Field[] getDeclaredFields(final Class cls) {
+return AccessController.doPrivileged(new PrivilegedAction() {
+
+@Override
+public Field[] run() {
+return cls.getDeclaredFields();
+} });
+}
+}
\ No newline at end of file

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

[Sergey Beryozkin]

Thanks Freeman, it looks fine, yes, it's a bit tricky to make sure it 
works across all of JAX-RS providers, especially with custom MBRs 
expecting InputStream to be not null...


Sergey

On 20/10/17 03:08, Freeman Fang wrote:

Hi Sergey,

Cleaned up accordingly.

Cheers
－
Freeman(Yue) 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 bit of cleanup as agreed, and 
then we can check if the use ReaderInputStream can be avoided at all.


Sergey

On 19/10/17 19:47, Daniel Kulp wrote:
If using the TEXT stuff for JMS, it should remain as a Reader on the 
message if at all possible.  Converting from Reader to InputStream is 
not a trivial operation and does enact a performance penalty.   All 
of the SOAP pathways for JMS should be OK for use of a Reader so that 
we can avoid the entire String->UTF-8 bytes->chars round tripping.

Dan
On Oct 19, 2017, at 5:21 AM, ffang <freeman.f...@gmail.com 
<mailto:freeman.f...@gmail.com>> wrote:


I modified the JMS transport part and set ReaderInputStream instead 
of Reader, running all tests now, will see what I can get.


If I run into any test failure, I will keep things as is, just 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 
<mailto: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 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 (will double check now), but I 
thought may be the transport can set both Reader and InputStream, 
hmm, that is an extra instance though, may be lets start with 
moving ReaderInputStream to the core first ?

Sergey
On 19/10/17 09:59, ffang wrote:
Yeah, set ReaderInputStream instead of Reader for the JMS 
transport is a better solution. If no objection I will go this way.

－
Freeman(Yue) Fang

Red Hat, Inc.
FuseSource is now part of Red Hat



On Oct 19, 2017, at 4:50 PM, Sergey Beryozkin 
<sberyoz...@gmail.com <mailto: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 Beryozkin wrote:

Hi Freeman
Can you move ReaderInputStream to the CXF core where 
CachedInputStream and other IO utility code is located ?
Please also update the code which gets Reader.class and check 
it for null first, and also drop a comment re the JMS 
transport, checking the reader can make sense in all the cases...

Thanks, Sergey
On 19/10/17 04:16, ff...@apache.org <mailto:ff...@apache.org> 
<mailto:ff...@apache.org> wrote:
This is an automated email from the ASF dual-hosted git 
repository.


ffang pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cxf.git


The following commit(s) were added to refs/heads/master by 
this push:
 new 1d66475  [CXF-7532]REST on JMS transport can't handle 
the request message with text messageType

1d66475 is described below

commit 1d66475b4dea2a0031dcb1765e8e9fd08430ec9b
Author: Freeman Fang <freeman.f...@gmail.com 
<mailto:freeman.f...@gmail.com> <mailto:freeman.f...@gmail.com>>

AuthorDate: Thu Oct 19 11:15:50 2017 +0800

[CXF-7532]REST on JMS transport can't handle the request 
message with text messageType

---
 .../org/apache/cxf/jaxrs/impl/ResponseImpl.java    |   5 +
 .../org/apache/cxf/jaxrs/utils/JAXRSUtils.java |   6 +-
 .../apache/cxf/jaxrs/utils/ReaderInputStream.java  | 296 
+

 .../apache/cxf/systest/jaxrs/jms/JAXRSJmsTest.java |  90 +++
 4 files changed, 396 insertions(+), 1 deletion(-)

diff --git 
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/ResponseImpl.java 
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/ResponseImpl.java

index e3a3acf..82f183a 100644
--- 
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/ResponseImpl.java
+++ 
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/ResponseImpl.java
@@ -58,6 +58,7 @@ import 
org.apache.cxf.jaxrs.provider.ProviderFactory;

 import org.apache.cxf.jaxrs.utils.HttpUtils;
 import org.apache.cxf.jaxrs.utils.InjectionUtils;
 import org.apache.cxf.jaxrs.utils.JAXRSUtils;
+import org.apache.cxf.jaxrs.utils.ReaderInputStream;
 import org.apache.cxf.message.Message;
 import org.apache.cxf.message.MessageUtils;
@@ -342,6 +343,10 @@ public final class ResponseImpl extends 
Respons

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

[Sergey Beryozkin]

Some JAX-RS providers check Reader or XMLStreamReader if InputStream is 
null.
But at the moment, Freeman, please do a bit of cleanup as agreed, and 
then we can check if the use ReaderInputStream can be avoided at all.


Sergey

On 19/10/17 19:47, Daniel Kulp wrote:

If using the TEXT stuff for JMS, it should remain as a Reader on the message if at 
all possible.  Converting from Reader to InputStream is not a trivial operation and 
does enact a performance penalty.   All of the SOAP pathways for JMS should be OK for 
use of a Reader so that we can avoid the entire String->UTF-8 bytes->chars 
round tripping.

Dan


On Oct 19, 2017, at 5:21 AM, ffang <freeman.f...@gmail.com> wrote:


I modified the JMS transport part and set ReaderInputStream instead of Reader, 
running all tests now, will see what I can get.

If I run into any test failure, I will keep things as is, just 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 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 (will double check now), but I thought may be the transport 
can set both Reader and InputStream, hmm, that is an extra instance though, may 
be lets start with moving ReaderInputStream to the core first ?
Sergey
On 19/10/17 09:59, ffang wrote:

Yeah, set ReaderInputStream instead of Reader for the JMS transport is a better 
solution. If no objection I will go this way.
－
Freeman(Yue) Fang

Red Hat, Inc.
FuseSource is now part of Red Hat




On Oct 19, 2017, at 4:50 PM, 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 Beryozkin wrote:

Hi Freeman
Can you move ReaderInputStream to the CXF core where CachedInputStream and 
other IO utility code is located ?
Please also update the code which gets Reader.class and check it for null 
first, and also drop a comment re the JMS transport, checking the reader can 
make sense in all the cases...
Thanks, Sergey
On 19/10/17 04:16, ff...@apache.org <mailto:ff...@apache.org> wrote:

This is an automated email from the ASF dual-hosted git repository.

ffang pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cxf.git


The following commit(s) were added to refs/heads/master by this push:
  new 1d66475  [CXF-7532]REST on JMS transport can't handle the request 
message with text messageType
1d66475 is described below

commit 1d66475b4dea2a0031dcb1765e8e9fd08430ec9b
Author: Freeman Fang <freeman.f...@gmail.com <mailto:freeman.f...@gmail.com>>
AuthorDate: Thu Oct 19 11:15:50 2017 +0800

 [CXF-7532]REST on JMS transport can't handle the request message with text 
messageType
---
  .../org/apache/cxf/jaxrs/impl/ResponseImpl.java|   5 +
  .../org/apache/cxf/jaxrs/utils/JAXRSUtils.java |   6 +-
  .../apache/cxf/jaxrs/utils/ReaderInputStream.java  | 296 +
  .../apache/cxf/systest/jaxrs/jms/JAXRSJmsTest.java |  90 +++
  4 files changed, 396 insertions(+), 1 deletion(-)

diff --git 
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/ResponseImpl.java 
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/ResponseImpl.java
index e3a3acf..82f183a 100644
--- 
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/ResponseImpl.java
+++ 
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/ResponseImpl.java
@@ -58,6 +58,7 @@ import org.apache.cxf.jaxrs.provider.ProviderFactory;
  import org.apache.cxf.jaxrs.utils.HttpUtils;
  import org.apache.cxf.jaxrs.utils.InjectionUtils;
  import org.apache.cxf.jaxrs.utils.JAXRSUtils;
+import org.apache.cxf.jaxrs.utils.ReaderInputStream;
  import org.apache.cxf.message.Message;
  import org.apache.cxf.message.MessageUtils;
@@ -342,6 +343,10 @@ public final class ResponseImpl extends Response {
  entityStreamAvailable = entityStream != null;
  } else if (entity instanceof InputStream) {
  entityStream = InputStream.class.cast(entity);
+} else {
+Message inMessage = getResponseMessage();
+Reader reader = inMessage.getContent(Reader.class);
+entityStream = InputStream.class.cast(new 
ReaderInputStream(reader));
  }
  // we need to check for readers even if no IS is set - the readers 
may still do it
diff --git 
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java 
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSU

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

[Sergey Beryozkin]

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 (will double check now), but I thought may be 
the transport can set both Reader and InputStream, hmm, that is an extra 
instance though, may be lets start with moving ReaderInputStream to the 
core first ?


Sergey
On 19/10/17 09:59, ffang wrote:
Yeah, set ReaderInputStream instead of Reader for the JMS transport is 
a better solution. If no objection I will go this way.

－
Freeman(Yue) Fang

Red Hat, Inc.
FuseSource is now part of Red Hat



On Oct 19, 2017, at 4:50 PM, 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 Beryozkin wrote:

Hi Freeman
Can you move ReaderInputStream to the CXF core where 
CachedInputStream and other IO utility code is located ?
Please also update the code which gets Reader.class and check it for 
null first, and also drop a comment re the JMS transport, checking 
the reader can make sense in all the cases...

Thanks, Sergey
On 19/10/17 04:16, ff...@apache.org <mailto:ff...@apache.org> wrote:

This is an automated email from the ASF dual-hosted git repository.

ffang pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cxf.git


The following commit(s) were added to refs/heads/master by this push:
  new 1d66475  [CXF-7532]REST on JMS transport can't handle the 
request message with text messageType

1d66475 is described below

commit 1d66475b4dea2a0031dcb1765e8e9fd08430ec9b
Author: Freeman Fang <freeman.f...@gmail.com 
<mailto:freeman.f...@gmail.com>>

AuthorDate: Thu Oct 19 11:15:50 2017 +0800

 [CXF-7532]REST on JMS transport can't handle the request 
message with text messageType

---
  .../org/apache/cxf/jaxrs/impl/ResponseImpl.java    |   5 +
  .../org/apache/cxf/jaxrs/utils/JAXRSUtils.java |   6 +-
  .../apache/cxf/jaxrs/utils/ReaderInputStream.java  | 296 
+

  .../apache/cxf/systest/jaxrs/jms/JAXRSJmsTest.java |  90 +++
  4 files changed, 396 insertions(+), 1 deletion(-)

diff --git 
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/ResponseImpl.java 
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/ResponseImpl.java 


index e3a3acf..82f183a 100644
--- 
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/ResponseImpl.java 

+++ 
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/ResponseImpl.java 

@@ -58,6 +58,7 @@ import 
org.apache.cxf.jaxrs.provider.ProviderFactory;

  import org.apache.cxf.jaxrs.utils.HttpUtils;
  import org.apache.cxf.jaxrs.utils.InjectionUtils;
  import org.apache.cxf.jaxrs.utils.JAXRSUtils;
+import org.apache.cxf.jaxrs.utils.ReaderInputStream;
  import org.apache.cxf.message.Message;
  import org.apache.cxf.message.MessageUtils;
@@ -342,6 +343,10 @@ public final class ResponseImpl extends 
Response {

  entityStreamAvailable = entityStream != null;
  } else if (entity instanceof InputStream) {
  entityStream = InputStream.class.cast(entity);
+    } else {
+    Message inMessage = getResponseMessage();
+    Reader reader = inMessage.getContent(Reader.class);
+    entityStream = InputStream.class.cast(new 
ReaderInputStream(reader));

  }
  // we need to check for readers even if no IS is set - 
the readers may still do it
diff --git 
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java 
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java 


index 0ef6565..509f76d 100644
--- 
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java 

+++ 
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java 


@@ -832,7 +832,11 @@ public final class JAXRSUtils {
 OperationResourceInfo 
ori)

  throws IOException, WebApplicationException {
  InputStream is = message.getContent(InputStream.class);
-
+    if (is == null) {
+    //may use the jms transport so check the Reader;
+    Reader reader = message.getContent(Reader.class);
+    is = new ReaderInputStream(reader);
+    }
  if (parameter.getType() == ParameterType.REQUEST_BODY) {
  if (parameterClass == AsyncResponse.class) {
diff --git 
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/ReaderInputStream.java 
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/ReaderInputStream.java 


new file mode 100644
index 000..c7b142e
--- /dev/null
+++ 
b/r

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

[Sergey Beryozkin]

Hi Freeman

Reader may likely need to be set too for SOAP, and I recall checking 
Reader somewhere else too (will double check now), but I thought may be 
the transport can set both Reader and InputStream, hmm, that is an extra 
instance though, may be lets start with moving ReaderInputStream to the 
core first ?


Sergey
On 19/10/17 09:59, ffang wrote:
Yeah, set ReaderInputStream instead of Reader for the JMS transport is a 
better solution. If no objection I will go this way.

－
Freeman(Yue) Fang

Red Hat, Inc.
FuseSource is now part of Red Hat



On Oct 19, 2017, at 4:50 PM, 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 Beryozkin wrote:

Hi Freeman
Can you move ReaderInputStream to the CXF core where 
CachedInputStream and other IO utility code is located ?
Please also update the code which gets Reader.class and check it for 
null first, and also drop a comment re the JMS transport, checking 
the reader can make sense in all the cases...

Thanks, Sergey
On 19/10/17 04:16, ff...@apache.org <mailto:ff...@apache.org> wrote:

This is an automated email from the ASF dual-hosted git repository.

ffang pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cxf.git


The following commit(s) were added to refs/heads/master by this push:
  new 1d66475  [CXF-7532]REST on JMS transport can't handle the 
request message with text messageType

1d66475 is described below

commit 1d66475b4dea2a0031dcb1765e8e9fd08430ec9b
Author: Freeman Fang <freeman.f...@gmail.com 
<mailto:freeman.f...@gmail.com>>

AuthorDate: Thu Oct 19 11:15:50 2017 +0800

 [CXF-7532]REST on JMS transport can't handle the request 
message with text messageType

---
  .../org/apache/cxf/jaxrs/impl/ResponseImpl.java    |   5 +
  .../org/apache/cxf/jaxrs/utils/JAXRSUtils.java |   6 +-
  .../apache/cxf/jaxrs/utils/ReaderInputStream.java  | 296 
+

  .../apache/cxf/systest/jaxrs/jms/JAXRSJmsTest.java |  90 +++
  4 files changed, 396 insertions(+), 1 deletion(-)

diff --git 
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/ResponseImpl.java 
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/ResponseImpl.java 


index e3a3acf..82f183a 100644
--- 
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/ResponseImpl.java 

+++ 
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/ResponseImpl.java 


@@ -58,6 +58,7 @@ import org.apache.cxf.jaxrs.provider.ProviderFactory;
  import org.apache.cxf.jaxrs.utils.HttpUtils;
  import org.apache.cxf.jaxrs.utils.InjectionUtils;
  import org.apache.cxf.jaxrs.utils.JAXRSUtils;
+import org.apache.cxf.jaxrs.utils.ReaderInputStream;
  import org.apache.cxf.message.Message;
  import org.apache.cxf.message.MessageUtils;
@@ -342,6 +343,10 @@ public final class ResponseImpl extends Response {
  entityStreamAvailable = entityStream != null;
  } else if (entity instanceof InputStream) {
  entityStream = InputStream.class.cast(entity);
+    } else {
+    Message inMessage = getResponseMessage();
+    Reader reader = inMessage.getContent(Reader.class);
+    entityStream = InputStream.class.cast(new 
ReaderInputStream(reader));

  }
  // we need to check for readers even if no IS is set - the 
readers may still do it
diff --git 
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java 
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java 


index 0ef6565..509f76d 100644
--- 
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java 

+++ 
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java 


@@ -832,7 +832,11 @@ public final class JAXRSUtils {
 OperationResourceInfo ori)
  throws IOException, WebApplicationException {
  InputStream is = message.getContent(InputStream.class);
-
+    if (is == null) {
+    //may use the jms transport so check the Reader;
+    Reader reader = message.getContent(Reader.class);
+    is = new ReaderInputStream(reader);
+    }
  if (parameter.getType() == ParameterType.REQUEST_BODY) {
  if (parameterClass == AsyncResponse.class) {
diff --git 
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/ReaderInputStream.java 
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/ReaderInputStream.java 


new file mode 100644
index 000..c7b142e
--- /dev/null
+++ 
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/ReaderInputStream.java 


@@ -0,0 +1,296 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor lice

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

[Sergey Beryozkin]

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 
and other IO utility code is located ?


Please also update the code which gets Reader.class and check it for 
null first, and also drop a comment re the JMS transport, checking the 
reader can make sense in all the cases...


Thanks, Sergey
On 19/10/17 04:16, ff...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

ffang pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cxf.git


The following commit(s) were added to refs/heads/master by this push:
  new 1d66475  [CXF-7532]REST on JMS transport can't handle the 
request message with text messageType

1d66475 is described below

commit 1d66475b4dea2a0031dcb1765e8e9fd08430ec9b
Author: Freeman Fang <freeman.f...@gmail.com>
AuthorDate: Thu Oct 19 11:15:50 2017 +0800

 [CXF-7532]REST on JMS transport can't handle the request message 
with text messageType

---
  .../org/apache/cxf/jaxrs/impl/ResponseImpl.java    |   5 +
  .../org/apache/cxf/jaxrs/utils/JAXRSUtils.java |   6 +-
  .../apache/cxf/jaxrs/utils/ReaderInputStream.java  | 296 
+

  .../apache/cxf/systest/jaxrs/jms/JAXRSJmsTest.java |  90 +++
  4 files changed, 396 insertions(+), 1 deletion(-)

diff --git 
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/ResponseImpl.java 
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/ResponseImpl.java 


index e3a3acf..82f183a 100644
--- 
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/ResponseImpl.java 

+++ 
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/ResponseImpl.java 


@@ -58,6 +58,7 @@ import org.apache.cxf.jaxrs.provider.ProviderFactory;
  import org.apache.cxf.jaxrs.utils.HttpUtils;
  import org.apache.cxf.jaxrs.utils.InjectionUtils;
  import org.apache.cxf.jaxrs.utils.JAXRSUtils;
+import org.apache.cxf.jaxrs.utils.ReaderInputStream;
  import org.apache.cxf.message.Message;
  import org.apache.cxf.message.MessageUtils;
@@ -342,6 +343,10 @@ public final class ResponseImpl extends Response {
  entityStreamAvailable = entityStream != null;
  } else if (entity instanceof InputStream) {
  entityStream = InputStream.class.cast(entity);
+    } else {
+    Message inMessage = getResponseMessage();
+    Reader reader = inMessage.getContent(Reader.class);
+    entityStream = InputStream.class.cast(new 
ReaderInputStream(reader));

  }
  // we need to check for readers even if no IS is set - the 
readers may still do it
diff --git 
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java 
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java 


index 0ef6565..509f76d 100644
--- 
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java 

+++ 
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java 


@@ -832,7 +832,11 @@ public final class JAXRSUtils {
 OperationResourceInfo ori)
  throws IOException, WebApplicationException {
  InputStream is = message.getContent(InputStream.class);
-
+    if (is == null) {
+    //may use the jms transport so check the Reader;
+    Reader reader = message.getContent(Reader.class);
+    is = new ReaderInputStream(reader);
+    }
  if (parameter.getType() == ParameterType.REQUEST_BODY) {
  if (parameterClass == AsyncResponse.class) {
diff --git 
a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/ReaderInputStream.java 
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/ReaderInputStream.java 


new file mode 100644
index 000..c7b142e
--- /dev/null
+++ 
b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/ReaderInputStream.java 


@@ -0,0 +1,296 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package 

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

[Sergey Beryozkin]

+assertEquals("Get a wrong book id.", 123, book.getId());
+}
  
  @Test

  public void testGetBookFromSubresourceProxyClient() throws Exception {
@@ -177,6 +232,23 @@ public class JAXRSJmsTest extends 
AbstractBusClientServerTestBase {
  assertEquals("Get a wrong response code.", 200, 
WebClient.client(bookProxy).getResponse().getStatus());
  assertEquals("Get a wrong book id.", 123, book.getId());
  }
+
+@Test
+public void testGetBookFromSubresourceProxyClientWithTextJMSMessage() 
throws Exception {
+// setup the the client
+String endpointAddressUrlEncoded = 
"jms:jndi:dynamicQueues/test.jmstransport.text"
+ + 
"?jndiInitialContextFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactory"
+ + "=dynamicQueues/test.jmstransport.response"
+ + "=tcp://localhost:" + JMS_PORT
+ + "=ConnectionFactory"
+ + "=text";
+
+JMSBookStore client = 
JAXRSClientFactory.create(endpointAddressUrlEncoded, JMSBookStore.class);
+Book bookProxy = client.getBookSubResource("123");
+Book book = bookProxy.retrieveState();
+assertEquals("Get a wrong response code.", 200, 
WebClient.client(bookProxy).getResponse().getStatus());
+assertEquals("Get a wrong book id.", 123, book.getId());
+}
  
  @Test

  public void testGetBookFromProxyClientWithQuery() throws Exception {
@@ -193,6 +265,24 @@ public class JAXRSJmsTest extends 
AbstractBusClientServerTestBase {
  assertEquals("Get a wrong book id.", 123, book.getId());
  }
  
+

+@Test
+public void testGetBookFromProxyClientWithQueryWithTextJMSMessage() throws 
Exception {
+// setup the the client
+String endpointAddressUrlEncoded = 
"jms:jndi:dynamicQueues/test.jmstransport.text"
+ + 
"?jndiInitialContextFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactory"
+ + "=dynamicQueues/test.jmstransport.response"
+     + "=tcp://localhost:" + JMS_PORT
+ + "=ConnectionFactory"
+ + "=text";
+
+JMSBookStore client = 
JAXRSClientFactory.create(endpointAddressUrlEncoded, JMSBookStore.class);
+Book book = client.getBookByURLQuery(new String[] {"1", "2", "3"});
+assertEquals("Get a wrong response code.", 200, 
WebClient.client(client).getResponse().getStatus());
+assertEquals("Get a wrong book id.", 123, book.getId());
+}
+
+
  @Test
  public void testGetBook() throws Exception {
  Context ctx = getContext();




--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

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

[Sergey Beryozkin]

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 preparation should've gone into it.


Setting a scan to true did never work in OSGI as far as I know, may be 
in some basic cases only, so in OSGI case, one nearly always has to set 
it to false anyway. I recall James Carman also suggesting to disable it 
by default. Then I also looked at


https://github.com/swagger-api/swagger-core/blob/master/modules/swagger-jaxrs/src/main/java/io/swagger/jaxrs/config/BeanConfig.java#L220 



and could not see (and still do not see) how this property, if set to 
false, can have any effect on disabling the scan, the only thing I found 
that the actual setScan call was still needed.


But the problem came from the other angle :-).

I guess the easiest way around it is to return a setScan setter to 
3.2.x, given that in some (I'd say - rare) cases uses depend on 
BeanConfig's implementation, but in 3.2.x keep this value by default to 
'false' so that in most other cases people do not have do setScan(false).


Cheers, Sergey


On 07/10/17 13:47, Dennis Kieselhorst wrote:

Hi Taylor!

This causes the subsequent code (line 196):

BeanConfig beanConfig = appInfo == null
 ? new BeanConfig()
 : new ApplicationBeanConfig(appInfo.getProvider());

…to always instantiate an ApplicationBeanConfig object. Our 
production code relied on the BeanConfig’s implementation of its 
classes() method to grab our ReaderListener classes annotated with 
@SwaggerDefinition. Because a BeanConfig will never be instantiated 
this way anymore, we would no longer be able to use our current 
implementations of the ReaderListener interface.


Is this a known bug, or is there a workaround that I’m missing?


Can you create a PR with a unittest for your scenario?

Unfortunately there are many ways of using Swagger2Feature and obviously
we missed that one.

Regards
Dennis




--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

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

[Sergey Beryozkin]

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 CompletionStageRxInvokerImpl doesn't support a user defined executor
nor a default EE managed executor. Would it be an option to default to
these impl instead of relying on the JVM implementation which makes it hard
to tune?

High level algorithm would be:

1. if user defined a custom executor in properties use it
2. if user defined a pool configuration (min/max/core/queue sizes) then
create a new pool
3. if default managed executor service (from EE) exists then use it -
simple lookup should be good
4. use forkjoin default pool like today

wdyt?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn 

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

[Sergey Beryozkin]

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 some basic cases only, so in OSGI case, one nearly always has to set 
it to false anyway. I recall James Carman also suggesting to disable it 
by default. Then I also looked at


https://github.com/swagger-api/swagger-core/blob/master/modules/swagger-jaxrs/src/main/java/io/swagger/jaxrs/config/BeanConfig.java#L220

and could not see (and still do not see) how this property, if set to 
false, can have any effect on disabling the scan, the only thing I found 
that the actual setScan call was still needed.


But the problem came from the other angle :-).

I guess the easiest way around it is to return a setScan setter to 
3.2.x, given that in some (I'd say - rare) cases uses depend on 
BeanConfig's implementation, but in 3.2.x keep this value by default to 
'false' so that in most other cases people do not have do setScan(false).


Cheers, Sergey


On 07/10/17 13:47, Dennis Kieselhorst wrote:

Hi Taylor!

This causes the subsequent code (line 196):

BeanConfig beanConfig = appInfo == null
 ? new BeanConfig()
 : new ApplicationBeanConfig(appInfo.getProvider());

…to always instantiate an ApplicationBeanConfig object. Our production code 
relied on the BeanConfig’s implementation of its classes() method to grab our 
ReaderListener classes annotated with @SwaggerDefinition. Because a BeanConfig 
will never be instantiated this way anymore, we would no longer be able to use 
our current implementations of the ReaderListener interface.

Is this a known bug, or is there a workaround that I’m missing?


Can you create a PR with a unittest for your scenario?

Unfortunately there are many ways of using Swagger2Feature and obviously
we missed that one.

Regards
Dennis

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

[Sergey Beryozkin]

+1

Sergey
On 23/09/17 11:46, Christian Schneider wrote:

This is a vote to release Apache CXF-DOSGi 2.3.0.

I cut a second release as the first one missed the LICENSE and NOTICE files
in the correct position. As another small improvement I upgraded to jline
3.5.1 which has better colors on windows.

Highlights:

* The multi bundle distro is now built using bnd-export-plugin and a bndrun
file instead of by exporting karaf features. The new approach makes sure
the bundles form a consistent and minimal deployment. In fact the distro in
now only 15MB instead of 22 MB.

* The multi bundle distro now includes apache felix and can be directly
started

* We do not list the bundles in the config anymore. Felix simply starts all
bundles in the directory bundle. There are also no more start level tweaks.

* The distro now uses the felix http service instead of pax web. This saves
us a lot of bundles

I found one issue which I can not fix before the release as requires a CXF
release:
https://issues.apache.org/jira/browse/DOSGI-276
Another issue is an exception thrown by gogo jline when starting the
distro. I will try to get that fixed too for 2.4.0.


Release Notes - CXF Distributed OSGi - Version 2.3.0

** Bug
 * [DOSGI-254] - ServiceInvocationHandler does not handle checked
super-interface exceptions correctly
 * [DOSGI-267] - ContainerRequestFilter intents do not get registered as
providers
 * [DOSGI-275] - Include felix and samples in multibundle distro

** Improvement
 * [DOSGI-273] - Use bnd resolver to create multibundle distro
 * [DOSGI-274] - Upgrade to CXF 3.2.0


Tag:
https://gitbox.apache.org/repos/asf?p=cxf-dosgi.git;a=tag;h=refs/tags/cxf-dosgi-2.3.0

Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecxf-1106


+1 from me.



Christian




--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Re: [VOTE] - Release Apache CXF DOSGi 2.3.0

[Sergey Beryozkin]

+1

Sergey
On 21/09/17 15:00, Andriy Redko wrote:

+1

Andriy

CS> This is a vote to release Apache CXF-DOSGi 2.3.0.

CS> Highlights:

CS> * The multi bundle distro is now built using bnd-export-plugin and a
CS> bndrun file instead of by exporting karaf features. The new approach
CS> makes sure the bundles form a consistent and minimal deployment. In fact
CS> the distro in now only 15MB instead of 22 MB.

CS> * The multi bundle distro now includes apache felix and can be directly
CS> started

CS> * We do not list the bundles in the config anymore. Felix simply starts
CS> all bundles in the directory bundle. There are also no more start level
CS> tweaks.

CS> * The distro now uses the felix http service instead of pax web. This
CS> saves us a lot of bundles

CS> I found one issue which I can not fix before the release as requires a
CS> CXF release:
CS> https://issues.apache.org/jira/browse/DOSGI-276


CS> Release Notes - CXF Distributed OSGi - Version 2.3.0

CS> ** Bug
CS>  * [DOSGI-254] - ServiceInvocationHandler does not handle checked
CS> super-interface exceptions correctly
CS>  * [DOSGI-267] - ContainerRequestFilter intents do not get
CS> registered as providers
CS>  * [DOSGI-275] - Include felix and samples in multibundle distro

CS> ** Improvement
CS>  * [DOSGI-273] - Use bnd resolver to create multibundle distro
CS>  * [DOSGI-274] - Upgrade to CXF 3.2.0


CS> Tag:
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...

[Sergey Beryozkin]

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

Does this Atom stuff still exist?

Regards
Dennis

Re: [VOTE] - Release Apache CXF Fediz 1.4.2

[Sergey Beryozkin]

+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:

https://repository.apache.org/content/repositories/orgapachecxf-1103/

Source artifacts:

https://repository.apache.org/content/repositories/orgapachecxf-1103/org/apache/cxf/fediz/fediz/1.4.2/

Git tag:

https://github.com/apache/cxf-fediz/tree/fediz-1.4.2

+1 from me.

Colm.

Re: [VOTE] Apache CXF 3.2.0

[Sergey Beryozkin]

3.2.0 has been open for 2 years so I doubt major OSGI integrators will 
start using it immediately, will try it, not all of them necessarily use 
karaf-maven-plugin. 3.2.1 will follow in a few weeks...


By the way, I see

[INFO] Verification of feature cxf-jaxrs-cdi/3.2.1.SNAPSHOT succeeded
(and it was fine with 3.2.0-SNAPSHOT)


from the Karaf Maven plugin:verify

Cheers, Sergey
On 11/09/17 11:38, Christian Schneider wrote:

Updating cxf-dosgi would of course not be a blocker.
The problem is that I think this might also block people from building 
custom distros that include 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 Schneider wrote:
Reverting my vote to -1 until we have a decision about the issues I 
found below.


I just tried to update cxf-dosgi to cxf 3.2.0. I get an error when 
building the multi bundle distro.


[ERROR] Failed to execute goal 
org.apache.karaf.tooling:karaf-maven-plugin:4.1.2:features-export-meta-data 
(features-add-to-repository) on project 
cxf-dosgi-multibundle-distribution: Error populating repository: 
Can't resolve artifact 
org.ops4j.pax.cdi:pax-cdi-features:xml:features:[1.0.0.RC1,2): 
Failure to find 
org.ops4j.pax.cdi:pax-cdi-features:xml:features:[1.0.0.RC1,2) in 
https://repo.maven.apache.org/maven2 was cached in the local 
repository, resolution will not be reattempted until the update 
interval of central has elapsed or updates are forced


So it seems like the karaf-maven-plugin does not work with a version 
range in the feature file. I think this is a bug and will report and 
fix it in karaf.
Even if this might be a problem in karaf I wonder if using a range in 
the CXF feature is a good idea at this time. It will probably affect 
all karaf users that build a custom distro.


I also tried to install the cxf-jaxrs-cdi feature from cxf 3.2.0 in 
karaf. The installation works but uses the 1.0.0-SNAPSHOT of the 
pax-cdi feature which is probably not what users expect.


Christian


On 06.09.2017 20: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:
https://repository.apache.org/content/repositories/orgapachecxf-1102/

Tag:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=79c1486ed9cf34d90a04d943ed72475500f83c48 



Here is my +1

Re: [VOTE] Apache CXF 3.2.0

[Sergey Beryozkin]

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 have a decision about the issues I 
found below.


I just tried to update cxf-dosgi to cxf 3.2.0. I get an error when 
building the multi bundle distro.


[ERROR] Failed to execute goal 
org.apache.karaf.tooling:karaf-maven-plugin:4.1.2:features-export-meta-data 
(features-add-to-repository) on project 
cxf-dosgi-multibundle-distribution: Error populating repository: Can't 
resolve artifact 
org.ops4j.pax.cdi:pax-cdi-features:xml:features:[1.0.0.RC1,2): Failure 
to find org.ops4j.pax.cdi:pax-cdi-features:xml:features:[1.0.0.RC1,2) in 
https://repo.maven.apache.org/maven2 was cached in the local repository, 
resolution will not be reattempted until the update interval of central 
has elapsed or updates are forced


So it seems like the karaf-maven-plugin does not work with a version 
range in the feature file. I think this is a bug and will report and fix 
it in karaf.
Even if this might be a problem in karaf I wonder if using a range in 
the CXF feature is a good idea at this time. It will probably affect all 
karaf users that build a custom distro.


I also tried to install the cxf-jaxrs-cdi feature from cxf 3.2.0 in 
karaf. The installation works but uses the 1.0.0-SNAPSHOT of the pax-cdi 
feature which is probably not what users expect.


Christian


On 06.09.2017 20: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:
https://repository.apache.org/content/repositories/orgapachecxf-1102/

Tag:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=79c1486ed9cf34d90a04d943ed72475500f83c48 



Here is my +1

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

[Sergey Beryozkin]

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. Supporting only 3.1.x and dropping 3.0.x sounds reasonable, +1 
to that.

DK> Just wanted to start a quick discussion about 3.0.x.   We’ve historically 
done work on the master and then
DK> supported two fixes branches.   With 3.2.0 being voted on now, I’m not sure 
if we would branch the 3.2.x-fixes
DK> branch immediately or wait a bit (we have historically waited a bit).   Are 
there major changes forthcoming that
DK> would warrant targeting 3.3 sooner?   If not, I think I’d like to stick on 
master for at least one round of fixes just to stabilize the 3.2.0 as users 
migrate.

DK> In any case, we’ve now supported the 3.0.x series for 2 years, 4 months.
  Would it make sense to announce that
DK> 3.0.15 will be the final scheduled release off that branch?   Maybe wait 
one more iteration?We haven’t been back
DK> porting much anyway.I grabbed the “central download stats” from Nexus 
for the cxf-core module (pretty much any
DK> usage of CXF requires that) just to get an idea of what is used.   The top 
10 are:

DK> 3.0.3   18%
DK> 3.1.11  11%
DK> 3.1.6   10%
DK> 3.1.10  7%
DK> 3.1.12  6%
DK> 3.1.7   5%
DK> 3.1.8   5%
DK> 3.1.5   4%
DK> 3.1.4   4%
DK> 3.0.1   4%


DK> As you can see, the only 3.0.x versions in the top 10 are 3.0.1 and 3.0.3.  
Since they are both ancient, I doubt
DK> anyone using them is planning on upgrading to new 3.0.x versions anyway.   
The good news is that the 3 latest 3.1.x
DK> versions are in the top 5.  Shows that the 3.1.x folks are keeping up to 
date.The last two 3.0.x releases (.13 and .14) are numbers 24 and 23 on the 
list.

DK> Anway, curious as to peoples thoughts….

Re: [VOTE] Apache CXF 3.2.0

[Sergey Beryozkin]

+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:
https://repository.apache.org/content/repositories/orgapachecxf-1102/

Tag:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=79c1486ed9cf34d90a04d943ed72475500f83c48

Here is my +1

Re: cxf git commit: fixed NPE

[Sergey Beryozkin]

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: http://git-wip-us.apache.org/repos/asf/cxf/repo
Commit: http://git-wip-us.apache.org/repos/asf/cxf/commit/3453c6cc
Tree: http://git-wip-us.apache.org/repos/asf/cxf/tree/3453c6cc
Diff: http://git-wip-us.apache.org/repos/asf/cxf/diff/3453c6cc

Branch: refs/heads/master
Commit: 3453c6ccac9bb829af8ecc65823e66b68db3e831
Parents: 70ac8ed
Author: Dennis Kieselhorst 
Authored: Tue Sep 5 21:32:27 2017 +0200
Committer: Dennis Kieselhorst 
Committed: Tue Sep 5 21:32:27 2017 +0200

--
  .../main/java/org/apache/cxf/jaxrs/swagger/Swagger2Feature.java| 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cxf/blob/3453c6cc/rt/rs/description-swagger/src/main/java/org/apache/cxf/jaxrs/swagger/Swagger2Feature.java
--
diff --git 
a/rt/rs/description-swagger/src/main/java/org/apache/cxf/jaxrs/swagger/Swagger2Feature.java
 
b/rt/rs/description-swagger/src/main/java/org/apache/cxf/jaxrs/swagger/Swagger2Feature.java
index 33ee47c..4679e6e 100644
--- 
a/rt/rs/description-swagger/src/main/java/org/apache/cxf/jaxrs/swagger/Swagger2Feature.java
+++ 
b/rt/rs/description-swagger/src/main/java/org/apache/cxf/jaxrs/swagger/Swagger2Feature.java
@@ -305,7 +305,7 @@ public class Swagger2Feature extends AbstractSwaggerFeature 
{
  if (theLicense == null && !licenseWasSet) {
  if (props != null) {
  theLicense = props.getProperty(LICENSE_PROPERTY);
-if (theLicense.isEmpty()) {
+if (theLicense != null && theLicense.isEmpty()) {
  theLicense = null;
  }
  } else {

Re: CXF 3.2?

[Sergey Beryozkin]

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, Sergey
On 04/09/17 21:22, Andriy Redko wrote:

Hey Dan,

Sorry for last minute thing (always pops up), do I have time to push this
guy https://issues.apache.org/jira/browse/CXF-7439? I am mostly done with the 
implementation,
need couple of more days to add a sample project and update the documentation. 
It is considerably
large chunk of the code, no urgency to have it in 3.2 really (could go to 
3.2.1). Just appreciate
the opinions, it is worth to delay a build for a couple of more days (Wed/Thu) 
or not.

Thanks!

Best Regards,
 Andriy Redko



DK> We just got the final releases of WSS4J and the JAX-RS api and I’ve also 
just managed to figure out how to get
DK> atmosphore and the latest Jetty releases to play nicely together.   Also 
considering it’s 4pm my time on a Friday
DK> before a long weekend, I’m not going to start the 3.2 build.   I think it’s 
best to delay until Tuesday to give the updates and such a chance to be tested.

DK> Dan





On Aug 10, 2017, at 12:22 PM, Daniel Kulp  wrote:




It’s been over two years since 3.1.0 was released which is a long time.I’d 
like to get 3.2.0 out shortly.   Looking through things, the major outstanding 
things are snapshots of a couple deps (xjc-utils,build-utils, wss4j) and 
updates to the JAX-RS stuff to use the released 2.1.   What else do folks have 
outstanding that would be “needed” to get into 3.2?Would Sept 1st be a good 
target for getting 3.2 built?   That would give use a few weeks to finish 
things up and get the releases out.



Thoughts?



--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com