Re: [VOTE] Apache CXF 3.4.5 and 3.3.12

[Andy McCright]

+1  Thanks!

Andy

On Wed, Sep 29, 2021 at 8:41 PM Jim Ma  wrote:

> +1
>
>
> On Thu, Sep 30, 2021 at 7:46 AM Freeman Fang 
> wrote:
>
> > +1 (binding)
> > Thanks Dan!
> >
> > Freeman
> >
> > On Wed, Sep 29, 2021 at 5:00 PM Daniel Kulp  wrote:
> >
> > >
> > > This is a vote to release CXF 3.4.5 and 3.3.12.   We have fixed over 34
> > > issues and it’s been over 2 months since the last releases.
> > >
> > >
> > > Staging repositories:
> > > https://repository.apache.org/content/repositories/orgapachecxf-1168
> > > https://repository.apache.org/content/repositories/orgapachecxf-1169
> > >
> > > Tags:
> > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=c8acd048e093838732c553bb0a81e77dc91268d6
> > > <
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=c8acd048e093838732c553bb0a81e77dc91268d6
> > > >
> > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=dc79a1087374bdf1696599f6fa663b08e6fb5e47
> > > <
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=dc79a1087374bdf1696599f6fa663b08e6fb5e47
> > > >
> > >
> > >
> > >
> > > Here is my +1
> > >
> > >
> > > --
> > > Daniel Kulp
> > > dk...@apache.org  - http://dankulp.com/blog <
> > > http://dankulp.com/blog>
> > > Talend - http://talend.com 
> > >
> >
>

Re: [VOTE] Apache CXF 3.4.4 and 3.3.11

[Andy McCright]

+1 Thanks!

On Sat, Jun 5, 2021 at 4:51 AM Francesco Chicchiriccò 
wrote:

> On 04/06/21 21:41, Daniel Kulp wrote:
> > This is a vote to release CXF 3.4.4 and 3.3.11.   We have fixed over 26
> issues and it’s been over 2 months since the last releases.
> >
> >
> > Staging repositories:
> > https://repository.apache.org/content/repositories/orgapachecxf-1166 <
> https://repository.apache.org/content/repositories/orgapachecxf-1166>
> > https://repository.apache.org/content/repositories/orgapachecxf-1167 <
> https://repository.apache.org/content/repositories/orgapachecxf-1167>
> >
> > Tags:
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=e7f5899c3b158b50b68981ef5f6c20bd960375e4
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=7c90a225dd3f2ca73cf4673e12e8092e3378caff
>
> +1, thanks Dan.
> 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: CXF-7996 Jakarta EE TCKs and compatibility

[Andy McCright]

Hi Andriy,

Do you have a test case that shows the problem with the empty string
FormParam?  It does look like it might double-decode unless we also add a
check later in the method to avoid that case.

Thanks for pointing this out.

Andy

On Sun, Apr 18, 2021 at 9:19 PM Andriy Redko  wrote:

> Hey guys,
>
> I was lucky enough to have time during the weekend to fix a few TCK test
> cases caused by
> deployment issues. @David you may be interested in backporting [1] to your
> repository. So
> we are down to 61 failing test cases (+2 errors related to async
> processing if I am not
> mistaken). Regarding master builds, I am not sure we need yet another job,
> we usually
> very disciplined in backporting the fixes to 3.4.x / 3.3.x.
>
> @Andy I have run into the edge case with @Encoded, when parameter name is
> empty, fe @FormParam("").
> I believe this is not standard but CXF supports that. I came up with this
> quick fix [2] but I am
> not sure it won't lead to multiple decoding attempts, still looking for
> better solution.
>
> Thanks!
>
> [1]
> https://github.com/apache/cxf/commit/7b820e3f193dc6fd0d73272c646d9b9aae2a1377
> [2]
> https://github.com/apache/cxf/commit/3b1ddd7c5e7a450d0c768e40850e5a899a8720b3
>
>
> Best Regards,
> Andriy Redko
>
>
> > Do we want another job to build master?  Only mention that as I see
> Andy's PR was merged there.
>
> I just backported it to 3.4.x-fixes so that it will show up in 3.4.4.
>
> Thanks,
>
> Andy
>
> On Fri, Apr 16, 2021 at 2:04 PM David Blevins 
> wrote:
>
> > On Apr 16, 2021, at 4:46 AM, Andriy Redko  wrote:
>
> > Good idea to create a subtask for each failure, personally haven't found
> time to do that, my bad,
> > thank you.
>
> Happy to help!
>
> > I will go over them and point to the relevant pull requests, some of
> these issues
> > have been worked on already (but not integrated yet).
>
> Thank you so much.
>
>
> > FYI: Just a hint (if you haven't noticed) each CXF TCK run has reports
> and jtr files + binaries,
> > as build artifacts, for example [1].
>
> I totally did miss that :)  Thank you for that!  I downloaded the zip and
> it has it all right there.  Nice work.
>
> Do we want another job to build master?  Only mention that as I see Andy's
> PR was merged there.
>
>
> -David
>
>
>
> > [1]
> https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-TCK/lastSuccessfulBuild/artifact/
>
> > Best Regards,
> >Andriy Redko
>
> > DB> Hi All,
>
> > DB> Spinning a new thread as to not overload the original "@Encoded TCK
> issue" too much.
>
> > DB> Thanks, Andriy, for the Jenkins information and TCK setup scripts.
> Thanks also, Andy, for the link to the proper JIRA issue.
>
> > DB> Here's what I've done.  I converted the Jenkinsfile into a script
> and hammered on it so it is more developer friendly.  Specifically, you can
> run one test or a chunk of tests.  As well it won't redo any setup steps
> unless needed.  It calculates a sha on your cxf-core jar and if that hasn't
> changed, it just goes straight to running the requested test.  This should
> make it easier for us to debug and work locally.
>
> > DB>  - https://github.com/tckwork/cxf
>
> > DB> If we want this, tell me where it should go and I'll submit a PR.
> On the TomEE side, we keep a separate repo just for the TCK setup, which is
> kind of handy as it tends to grow over time and one setup can work for all
> our branches.  But anything works really.
>
> > DB> I then downloaded the consoleText from the latest CXF-JAXRS-TCK job,
> parsed out each failing test, ran it locally, saved all the output and
> wrote a script to create a subtask on CXF-7996 for each failing test:
>
> > DB>  - https://issues.apache.org/jira/browse/CXF-7996
>
> > DB> The description of each subtask is the test name, a chunk of the
> output, and instructions on how to run the test.  Attached to each subtask
> is the full TCK test output and jtr file so people can browse the failures
> without having to run them directly.  Also attached is a `test.txt` file
> containing the test name so there is an easy way for future automated tools
> to know what issue to update as status changes.
>
> > DB> If I've possibly overstepped creating all those subtasks, let me
> know and I can easily move them or delete them.  Totally fine.
>
>
> > DB> -David
>
>

Re: CXF-7996 Jakarta EE TCKs and compatibility

[Andy McCright]

> Do we want another job to build master?  Only mention that as I see
Andy's PR was merged there.

I just backported it to 3.4.x-fixes so that it will show up in 3.4.4.

Thanks,

Andy

On Fri, Apr 16, 2021 at 2:04 PM David Blevins 
wrote:

> > On Apr 16, 2021, at 4:46 AM, Andriy Redko  wrote:
> >
> > Good idea to create a subtask for each failure, personally haven't found
> time to do that, my bad,
> > thank you.
>
> Happy to help!
>
> > I will go over them and point to the relevant pull requests, some of
> these issues
> > have been worked on already (but not integrated yet).
>
> Thank you so much.
>
> >
> > FYI: Just a hint (if you haven't noticed) each CXF TCK run has reports
> and jtr files + binaries,
> > as build artifacts, for example [1].
>
> I totally did miss that :)  Thank you for that!  I downloaded the zip and
> it has it all right there.  Nice work.
>
> Do we want another job to build master?  Only mention that as I see Andy's
> PR was merged there.
>
>
> -David
>
>
> >
> > [1]
> https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-TCK/lastSuccessfulBuild/artifact/
> >
> > Best Regards,
> >Andriy Redko
> >
> > DB> Hi All,
> >
> > DB> Spinning a new thread as to not overload the original "@Encoded TCK
> issue" too much.
> >
> > DB> Thanks, Andriy, for the Jenkins information and TCK setup scripts.
> Thanks also, Andy, for the link to the proper JIRA issue.
> >
> > DB> Here's what I've done.  I converted the Jenkinsfile into a script
> and hammered on it so it is more developer friendly.  Specifically, you can
> run one test or a chunk of tests.  As well it won't redo any setup steps
> unless needed.  It calculates a sha on your cxf-core jar and if that hasn't
> changed, it just goes straight to running the requested test.  This should
> make it easier for us to debug and work locally.
> >
> > DB>  - https://github.com/tckwork/cxf
> >
> > DB> If we want this, tell me where it should go and I'll submit a PR.
> On the TomEE side, we keep a separate repo just for the TCK setup, which is
> kind of handy as it tends to grow over time and one setup can work for all
> our branches.  But anything works really.
> >
> > DB> I then downloaded the consoleText from the latest CXF-JAXRS-TCK job,
> parsed out each failing test, ran it locally, saved all the output and
> wrote a script to create a subtask on CXF-7996 for each failing test:
> >
> > DB>  - https://issues.apache.org/jira/browse/CXF-7996
> >
> > DB> The description of each subtask is the test name, a chunk of the
> output, and instructions on how to run the test.  Attached to each subtask
> is the full TCK test output and jtr file so people can browse the failures
> without having to run them directly.  Also attached is a `test.txt` file
> containing the test name so there is an easy way for future automated tools
> to know what issue to update as status changes.
> >
> > DB> If I've possibly overstepped creating all those subtasks, let me
> know and I can easily move them or delete them.  Totally fine.
> >
> >
> > DB> -David
> >
>
>

Re: @Encoded TCK issue

[Andy McCright]

Sounds good.  I'll try to have a PR tomorrow.  The fix is easy enough, but
I want to make sure that we have a good test case for it too.

Andriy and I (mostly Andriy) were looking at Jakarta TCK issues about a
year ago.  He has some results posted at
https://issues.apache.org/jira/browse/CXF-7996 - in the most recent report,
there were ~80 failures, but it's possible that some of them have already
been fixed since then. It might help if you post your failures in that
issue to keep better track of them.

Thanks,

Andy

On Tue, Apr 13, 2021 at 8:44 PM David Blevins 
wrote:

> > On Apr 13, 2021, at 9:10 AM, Andy McCright 
> wrote:
> >
> > Hi David,
> >
> > I had to do some digging - but yes, we addressed that issue in our Open
> Liberty fork of CXF and I must not have contributed that fix back to the
> main CXF fork (apologies for that).
> >
> > Here are the changes I made in the OL fork:
> https://github.com/OpenLiberty/open-liberty/pull/2504 - basically
> deferring the decoding until after the map has been populated.  If you
> want, I can try to push this change back to the main CXF fork.
>
> Thanks for the update, Andy!
>
> Your patch sounds much better than mine.  I was able to get the test to
> pass by effectively keeping two cached copies of the parsed form -- one
> decoded and one encoded.
>
>  -
> https://github.com/apache/tomee/commit/5c47f4482ea80601e17ead56e6f0a72e494a5b7e#diff-472b947a3abe2e03b6959ef6ad4e1137ff3012dee9de1a4c15acf57919ab525bL1027-L1035
>
> Works, but feels a little too hacky.  If you want to submit a PR for
> yours, that's great.  I'll post a list of the remaining 30-ish failures
> that we working through in a separate thread.
>
>
> -David
>
>

Re: @Encoded TCK issue

[Andy McCright]

Hi David,

I had to do some digging - but yes, we addressed that issue in our Open
Liberty fork of CXF and I must not have contributed that fix back to the
main CXF fork (apologies for that).

Here are the changes I made in the OL fork:
https://github.com/OpenLiberty/open-liberty/pull/2504 - basically deferring
the decoding until after the map has been populated.  If you want, I can
try to push this change back to the main CXF fork.

Thanks for pointing this out,

Andy

On Mon, Apr 12, 2021 at 9:12 PM David Blevins 
wrote:

> Did you run into this in Open Liberty?
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> Begin forwarded message:
>
> *From: *David Blevins 
> *Subject: **@Encoded TCK issue*
> *Date: *April 12, 2021 at 7:07:35 PM PDT
> *To: *dev@cxf.apache.org
>
> Hi All,
>
> I'm investigating a Jakarta EE TCK failure:
>
> -
> com/sun/ts/tests/jaxrs/ee/rs/beanparam/form/plain/JAXRSClient#formFieldParamEntityWithEncodedTest_from_standalone
>
> This test posts a form and is checking to ensure the @Encoded annotation
> is being respected.  The code to respect that annotation is definitely
> implemented, however before that code is called we've already parsed,
> decoded and cached the form into the Message so the test fails.
>
> -
> https://github.com/apache/cxf/blob/master/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java#L1033-L1054
>
> Essentially, due to this caching the "decode" boolean is ignored after the
> first field of the bean is processed.  When you have a bean like the
> following where there are two fields, one results in 'decode=true' and the
> second in 'decode=false', the second field's wishes will not happen as the
> first field caused the form to be decoded and cached.  The second field
> will then get a decoded value despite the @Encoded annotation.
>
>public class FormBeanParamEntity {
>  @DefaultValue(Constants.DEFAULT_VALUE)
>  @FormParam(Constants.PARAM_ENTITY_WITH_CONSTRUCTOR)
>  public ParamEntityWithConstructor paramEntityWithConstructor;
>
>  @Encoded
>  @DefaultValue(Constants.DEFAULT_VALUE)
>  @FormParam(Constants.PARAM_ENTITY_WITH_FROMSTRING)
>  public ParamEntityWithFromString paramEntityWithFromString;
>
>
> So essentially @Encoded will only work as the first parameter, field, etc.
>
> Investigating fixes at the moment and will submit a PR.  Open to thoughts
> and preferences.  This is one of about 33 failures I'm hunting down.
>
>
> -David
>
>
>

Re: [VOTE] Apache CXF 3.4.3 and 3.3.10

[Andy McCright]

+1

Thanks!

Andy

On Mon, Mar 15, 2021 at 5:17 PM Alexey Markevich  wrote:

> +1
>
> On 3/16/21, Freeman Fang  wrote:
> > +1 (binding)
> >
> > Thanks Dan!
> > Freeman
> >
> > On Mon, Mar 15, 2021 at 4:59 PM Daniel Kulp  wrote:
> >
> >>
> >> This is a vote to release CXF 3.4.3 and 3.3.10.   We have fixed over 20
> >> issues and it’s been almost 3 months since the last releases.
> >>
> >>
> >> Staging repositories:
> >> https://repository.apache.org/content/repositories/orgapachecxf-1164/
> >> https://repository.apache.org/content/repositories/orgapachecxf-1165/
> >>
> >> Tags:
> >>
> >>
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=9674eb2f8d0013ef1caa87358d6a9bfcdbc2245b
> >>
> >>
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=e85ef7e31d2709d481d3df9175edb5d5490f37fa
> >>
> >> Here is my +1
> >>
> >> --
> >> Daniel Kulp
> >> dk...@apache.org - http://dankulp.com/blog
> >> Talend - http://talend.com
> >>
> >>
> >
>

Re: CXF 3.4.2 soon

[Andy McCright]

Hi Andriy, Colm,

The MicroProfile Rest Client 2.0 GA release is currently in staging.  We
are working through a new process now that MP is formally an Eclipse
Working Group.  Part of that process is a two-week staging period where
steering committee members review and (hopefully) approve the staged
specification projects.  For Rest Client, we're about one week into that
process.  Given that many folks will be out next week due to the holidays,
I don't expect that Rest Client 2.0 will be officially released until early
January.  Once it is officially released, I plan to update the
parent/pom.xml file to point to the released API instead of the RC.  The
API is effectively the same as the RC - iirc, the only changes between the
last RC and the final (staged) release were changes to test cases in the
TCK.

If you want to release before the end of the year, I would not suggest
waiting for MP Rest Client 2.0 GA.  We can get it into the 3.4.3.

Hope this helps,

Andy

On Fri, Dec 18, 2020 at 12:25 PM Andriy Redko  wrote:

> Hey Colm,
>
> +1 in general, a few comments.
>
> The code for CXF-8340 is in, all builds are green, the only leftovers are
> to finalize the documentation and probably samples for JAX-RS / JAX-WS, I
> am on track to finish that over the weekend. Another good to have thing is
> to update to MP Rest Client API 2.0, it is already out [1] but I don't see
> it published to Maven repos yet. @Andy could you please clarify on the
> timelines?
>
> Thanks!
>
> [1] https://github.com/eclipse/microprofile-rest-client/releases/tag/2.0
>
> Friday, December 18, 2020, 2:02:25 AM, you wrote:
>
> COh> Hi all,
>
> COh> I'd like to get CXF 3.4.2 out before the end of the year if possible.
> It's
> COh> a bit shorter than our usual release cycle, but there have been some
> COh> regressions which we should get released.
>
> COh> WSS4J 2.3.1 is under vote and should be released by Monday. Apart from
> COh> that, the only outstanding issue is the Graal stuff (CXF-8340).
> @Andriy
> COh> Redko  is there much more to do on this? Anything
> else
> COh> anyone is going to imminently fix for 3.4.2?
>
> COh> Colm.
>
>

Re: [VOTE] Apache CXF 3.4.1 and 3.3.8

[Andy McCright]

+1 Thanks!

On Tue, Nov 3, 2020 at 4:00 PM Freeman Fang  wrote:

> +1(binding)
>
> Thanks Dan!
> Freeman
>
> On Tue, Nov 3, 2020 at 4:30 PM Daniel Kulp  wrote:
>
> >
> > This is a vote to release CXF 3.3.8 and 3.4.1.   We’ve fixed over 20 JIRA
> > issues and it’s been over 2 months since the last set of releases.
> >
> > Staging repos:
> > https://repository.apache.org/content/repositories/orgapachecxf-1159/ <
> > https://repository.apache.org/content/repositories/orgapachecxf-1159/>
> > https://repository.apache.org/content/repositories/orgapachecxf-1160/ <
> > https://repository.apache.org/content/repositories/orgapachecxf-1160/>
> >
> >
> > Tags:
> >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=57f618fdae294d5b068b3060aa403b5813c527a7
> > <
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=3de6388a8cc2bbd834a563750b66efb9ea45a4b1
> > >
> >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=18b39003a8a9e16ebd58b750da0c6b4db19b91da
> > <
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=f1d43967ee19387603db5c55de7ce95f54243c81
> > >
> >
> > Here is my +1
> >
> >
> > --
> > Daniel Kulp
> > dk...@apache.org  - http://dankulp.com/blog <
> > http://dankulp.com/blog>
> > Talend - http://talend.com 
> >
>

Re: [VOTE] Apache CXF 3.4.0

[Andy McCright]

+1 Thanks!

On Mon, Aug 24, 2020 at 2:05 AM Oliver Wulff  wrote:

> +1
> Thanks Oli
>
>
>
> Von meinem Samsung Galaxy Smartphone gesendet.
>
>
>
>  Ursprüngliche Nachricht 
> Von: Alessio Soldano 
> Datum: 22.08.20 18:27 (GMT+01:00)
> An: dev@cxf.apache.org
> Betreff: Re: [VOTE] Apache CXF 3.4.0
>
> +1, thanks!
>
> On Thursday, August 20, 2020, Daniel Kulp  wrote:
>
> > This is a vote to release Apache CXF 3.4.0.  There are several new
> > features, many dependency updates, bunches of fixes, etc….   See the
> > migration guide at:
> > http://cxf.apache.org/docs/34-migration-guide.html <
> > http://cxf.apache.org/docs/34-migration-guide.html>
> >
> > Staging area:
> > https://repository.apache.org/content/repositories/orgapachecxf-1158/ <
> > https://repository.apache.org/content/repositories/orgapachecxf-1158/>
> >
> > Tag:
> > https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=
> > e034b0b68e9604f4062ae1c4b719789ec51f77b6  > repos/asf?p=cxf.git;a=tag;h=e034b0b68e9604f4062ae1c4b719789ec51f77b6>
> >
> > Here is my +1!
> >
> > --
> > Daniel Kulp
> > dk...@apache.org  - http://dankulp.com/blog <
> > http://dankulp.com/blog>
> > Talend - http://talend.com 
> >
>

Re: [VOTE] CXF 3.3.7 and 3.2.14

[Andy McCright]

+1 - Thanks!

On Tue, Jun 23, 2020 at 5:10 PM Jeff Genender  wrote:

> +1
>
> Jeff
>
>
> > On Jun 23, 2020, at 3:02 PM, Daniel Kulp  wrote:
> >
> > This is a vote to release CXF 3.3.7 and 3.2.14.   We’ve fixed over 20
> JIRA issues and it’s been over 2 months since the last set of releases.
> >
> > Staging repos:
> > https://repository.apache.org/content/repositories/orgapachecxf-1154/ <
> https://repository.apache.org/content/repositories/orgapachecxf-1154/>
> > https://repository.apache.org/content/repositories/orgapachecxf-1155/ <
> https://repository.apache.org/content/repositories/orgapachecxf-1155/>
> >
> >
> > Tags:
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=3de6388a8cc2bbd834a563750b66efb9ea45a4b1
> <
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=3de6388a8cc2bbd834a563750b66efb9ea45a4b1
> >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=f1d43967ee19387603db5c55de7ce95f54243c81
> <
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=f1d43967ee19387603db5c55de7ce95f54243c81
> >
> >
> > Here is my +1
> >
> >
> > --
> > Daniel Kulp
> > dk...@apache.org  - http://dankulp.com/blog <
> http://dankulp.com/blog>
> >
> >
>
>

Re: Releases soon?

[Andy McCright]

+1 from me.  Thanks Colm!

On Thu, Jun 11, 2020 at 11:36 AM Jean-Baptiste Onofre 
wrote:

> It sounds good.
>
> Regards
> JB
>
> > Le 11 juin 2020 à 13:12, Colm O hEigeartaigh  a
> écrit :
> >
> > We should get 3.3.7 and 3.2.14 out soon. Is there anything else to go
> into
> > these releases? I propose that this should be the last 3.2.x release, as
> > 3.4.0 should be relatively imminent once we tidy up the last few issues.
> >
> > Colm.
>
>

Re: [VOTE] CXF 3.3.6 and 3.2.13

[Andy McCright]

+1 Thanks!

On Wed, Mar 25, 2020 at 2:53 PM Jean-Baptiste Onofre 
wrote:

> +1 (non binding)
>
> Regards
> JB
>
> > Le 25 mars 2020 à 20:53, Alexey Markevich  a écrit :
> >
> > +1
> >
> > On 3/25/20, Freeman Fang  wrote:
> >> +1(binding)
> >>
> >> Thanks!
> >> Freeman
> >>
> >> On Wed, Mar 25, 2020 at 2:38 PM Daniel Kulp  wrote:
> >>
> >>>
> >>> This is a vote to release CXF 3.3.6 and 3.2.13.   We’ve fixed over 30
> >>> JIRA
> >>> issues and it’s been over 2 months since the last set of releases.
> >>>
> >>> Staging repos:
> >>> https://repository.apache.org/content/repositories/orgapachecxf-1151/
> <
> >>> https://repository.apache.org/content/repositories/orgapachecxf-1151/>
> >>> https://repository.apache.org/content/repositories/orgapachecxf-1152/
> <
> >>> https://repository.apache.org/content/repositories/orgapachecxf-1152/>
> >>>
> >>>
> >>> Tags:
> >>>
> >>>
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=118421ee51886d47caf8b279e9b7e04dae067181
> >>> <
> >>>
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=118421ee51886d47caf8b279e9b7e04dae067181
> 
> >>>
> >>>
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=b38351b34549a851a2cf1aa95e94d29089d1c598
> >>> <
> >>>
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=b38351b34549a851a2cf1aa95e94d29089d1c598
> 
> >>>
> >>> Here is my +1
> >>>
> >>>
> >>>
> >>> --
> >>> Daniel Kulp
> >>> dk...@apache.org  - http://dankulp.com/blog <
> >>> http://dankulp.com/blog>
> >>> Talend Community Coder - http://talend.com 
> >>>
> >>
>
>

Re: [VOTE] Apache CXF 3.3.5 and 3.2.12

[Andy McCright]

+1 - Thanks!

On Mon, Jan 13, 2020 at 7:11 AM Colm O hEigeartaigh 
wrote:

> +1.
>
> Colm.
>
> On Mon, Jan 13, 2020 at 7:52 AM Francesco Chicchiriccò <
> ilgro...@apache.org>
> wrote:
>
> > On 10/01/20 23:29, Daniel Kulp wrote:
> > > After a couple of hiccups due to LDAP downtime, I was finally able to
> > get the builds staged. These releases are long overdue due to the
> > holidays.   Over 30 JIRA issues have been fixed.
> > >
> > >
> > > Tags:
> > > Buildutils-3.4.4:
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cxf-build-utils.git;a=tag;h=7c47996f32cf366b05223bd6e614db271158786a
> > <
> >
> https://gitbox.apache.org/repos/asf?p=cxf-build-utils.git;a=tag;h=7c47996f32cf366b05223bd6e614db271158786a
> > >
> > > xjc-utils 3.3.1:
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cxf-xjc-utils.git;a=tag;h=3b847753d5ffa01018f03edaa4dc3175808ca0a6
> > <
> >
> https://gitbox.apache.org/repos/asf?p=cxf-xjc-utils.git;a=tag;h=3b847753d5ffa01018f03edaa4dc3175808ca0a6
> > >
> > >
> > > 3.2.12
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=33895edbf4fd5baabba94ab336b1068a33321f36
> > <
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=33895edbf4fd5baabba94ab336b1068a33321f36
> > >
> > > 3.3.5:
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=33b4f4285601539cf4e5a5738b7a7823ccb82edc
> > <
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=33b4f4285601539cf4e5a5738b7a7823ccb82edc
> > >
> > >
> > > Staging areas:
> > > Buildutils and XJC:
> > > https://repository.apache.org/content/repositories/orgapachecxf-1148 <
> > https://repository.apache.org/content/repositories/orgapachecxf-1148>
> > > 3.2.12:
> > > https://repository.apache.org/content/repositories/orgapachecxf-1149 <
> > https://repository.apache.org/content/repositories/orgapachecxf-1149>
> > > 3.3.5:
> > > https://repository.apache.org/content/repositories/orgapachecxf-1150 <
> > https://repository.apache.org/content/repositories/orgapachecxf-1150>
> > +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: Votes by end of week?

[Andy McCright]

That sounds good. In that case, let's go ahead and plan to merge the TCK
formparam fix (following Colm's review).  If we get the other two reviewed
(and possibly changed) by the end of the week, let's take them too, but no
worries if not.

Thanks!

Andy

On Wed, Jan 8, 2020 at 11:57 AM Andrey Redko  wrote:

> Hey Andy,
>
> I would finish up with SSE today, I was reading through the callback
> discussion threads you mentioned, we may need to change a few things before
> merge. The TCK formparam fixes look good to me, but I haven't dug into the
> cause to be honest, Colm if you could take a look would be awesome, +1 from
> me to merge. For CDI one I would appreciate to have some time to finish the
> review, thanks!
>
> Best Regards,
> Andriy Redko
>
> On Wed, Jan 8, 2020, 12:35 PM Colm O hEigeartaigh 
> wrote:
>
>> No objections from me for including them, if Andriy is happy with them.
>> Otherwise we can leave them for 3.3.6.
>>
>> Colm.
>>
>> On Wed, Jan 8, 2020 at 5:19 PM Andy McCright 
>> wrote:
>>
>>> Andriy, Colm,
>>>
>>> I've three pull requests in progress that we could pull in - I'd like to
>>> get some more reviews on them, but otherwise I think they are ready to
>>> merge.  That said, I'm fine with waiting until the next release too.  The
>>> PRs in question are:
>>> https://github.com/apache/cxf/pull/619 - Adding injection into MP Rest
>>> Client's ClientHeadersFactory - this will be part of the next MP spec (not
>>> yet released), thus no urgency, but still a nice feature.
>>> https://github.com/apache/cxf/pull/621 - fixes some Jakarta EE JAX-RS
>>> TCK failures in the SSE bucket.
>>> https://github.com/apache/cxf/pull/620 - fixes some Jakarta EE JAX-RS
>>> TCK failures related to FormParam processing.
>>>
>>> Do you want to include them in the 3.3.5?
>>>
>>> Thanks, Andy
>>>
>>> On Wed, Jan 8, 2020 at 9:49 AM Colm O hEigeartaigh 
>>> wrote:
>>>
>>>> OK thanks Freeman. As of this point I'm all done with the release.
>>>> @Andriy
>>>> Redko  please reply when you're finished with any
>>>> changes
>>>> and we can start the votes.
>>>>
>>>> Colm.
>>>>
>>>> On Wed, Jan 8, 2020 at 3:00 PM ffang  wrote:
>>>>
>>>> >
>>>> >
>>>> > > On Jan 6, 2020, at 1:16 PM, Colm O hEigeartaigh <
>>>> cohei...@apache.org>
>>>> > wrote:
>>>> > >
>>>> > > Hi all,
>>>> > >
>>>> > > It would be good to get votes started on new 3.3 + 3.2 releases by
>>>> the
>>>> > end of this week, as we are already overdue. We already have 32 JIRAs
>>>> fixed
>>>> > for 3.3.5, so it's shaping up to be a pretty big release!
>>>> > >
>>>> > > There are 2 remaining JIRA issues targetted for 3.3.5, both
>>>> assigned to
>>>> > Freeman. @Freeman Fang <mailto:freeman.f...@gmail.com> do you think
>>>> you
>>>> > have time to look at them? Otherwise they can be moved to 3.3.6.
>>>> > Hi Colm,
>>>> >
>>>> > Both CXF-8173 and CXF-8183 are same issue, they are harmless in terms
>>>> of
>>>> > function at this stage and we can revisit in the future.
>>>> > Btw, I added comment here to explain it a bit
>>>> >
>>>> >
>>>> >
>>>> https://issues.apache.org/jira/browse/CXF-8173?focusedCommentId=17010739&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17010739
>>>> > <
>>>> >
>>>> https://issues.apache.org/jira/browse/CXF-8173?focusedCommentId=17010739&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17010739
>>>> > >
>>>> >
>>>> > Best Regards
>>>> > Freeman
>>>> > >
>>>> > > On my todo list is:
>>>> > >  - Merge https://github.com/apache/cxf/pull/615 <
>>>> > https://github.com/apache/cxf/pull/615>
>>>> > >  - Update XML Schema (currently under vote)
>>>> > >  - Merge a fix for the regression introduced by CXF-8088.
>>>> > >
>>>> > > Colm.
>>>> > >
>>>> >
>>>> >
>>>>
>>>

Re: Votes by end of week?

[Andy McCright]

Andriy, Colm,

I've three pull requests in progress that we could pull in - I'd like to
get some more reviews on them, but otherwise I think they are ready to
merge.  That said, I'm fine with waiting until the next release too.  The
PRs in question are:
https://github.com/apache/cxf/pull/619 - Adding injection into MP Rest
Client's ClientHeadersFactory - this will be part of the next MP spec (not
yet released), thus no urgency, but still a nice feature.
https://github.com/apache/cxf/pull/621 - fixes some Jakarta EE JAX-RS TCK
failures in the SSE bucket.
https://github.com/apache/cxf/pull/620 - fixes some Jakarta EE JAX-RS TCK
failures related to FormParam processing.

Do you want to include them in the 3.3.5?

Thanks, Andy

On Wed, Jan 8, 2020 at 9:49 AM Colm O hEigeartaigh 
wrote:

> OK thanks Freeman. As of this point I'm all done with the release. @Andriy
> Redko  please reply when you're finished with any
> changes
> and we can start the votes.
>
> Colm.
>
> On Wed, Jan 8, 2020 at 3:00 PM ffang  wrote:
>
> >
> >
> > > On Jan 6, 2020, at 1:16 PM, Colm O hEigeartaigh 
> > wrote:
> > >
> > > Hi all,
> > >
> > > It would be good to get votes started on new 3.3 + 3.2 releases by the
> > end of this week, as we are already overdue. We already have 32 JIRAs
> fixed
> > for 3.3.5, so it's shaping up to be a pretty big release!
> > >
> > > There are 2 remaining JIRA issues targetted for 3.3.5, both assigned to
> > Freeman. @Freeman Fang  do you think you
> > have time to look at them? Otherwise they can be moved to 3.3.6.
> > Hi Colm,
> >
> > Both CXF-8173 and CXF-8183 are same issue, they are harmless in terms of
> > function at this stage and we can revisit in the future.
> > Btw, I added comment here to explain it a bit
> >
> >
> >
> https://issues.apache.org/jira/browse/CXF-8173?focusedCommentId=17010739&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17010739
> > <
> >
> https://issues.apache.org/jira/browse/CXF-8173?focusedCommentId=17010739&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17010739
> > >
> >
> > Best Regards
> > Freeman
> > >
> > > On my todo list is:
> > >  - Merge https://github.com/apache/cxf/pull/615 <
> > https://github.com/apache/cxf/pull/615>
> > >  - Update XML Schema (currently under vote)
> > >  - Merge a fix for the regression introduced by CXF-8088.
> > >
> > > Colm.
> > >
> >
> >
>

Re: [VOTE] Apache CXF 3.2.11

[Andy McCright]

+1

Thanks!

On Thu, Oct 24, 2019 at 10:34 AM Daniel Kulp  wrote:

> Colm pointed out to me that we also need a 3.2.11 release.   Since that’s
> also been 2 months and we fixed 11 JIRA’s, it makes sense.
>
> It’s been over 2 months since 3.3.3 was released.   We fixed 20 JIRAS.
>
> Staging area:
> https://repository.apache.org/content/repositories/orgapachecxf-1146
>
> Tag:
>
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=commit;h=da2d27d97f9e9abd7d307e2224e5e0338b767ee2
> <
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=commit;h=da2d27d97f9e9abd7d307e2224e5e0338b767ee2
> >
>
>
> Here is my +1
>
> --
> Daniel Kulp
> dk...@apache.org  - http://dankulp.com/blog <
> http://dankulp.com/blog>
> Talend Community Coder - http://talend.com 
>

Re: [VOTE] Apache CXF 3.3.4

[Andy McCright]

+1

Thanks!

On Tue, Oct 22, 2019 at 8:32 AM Alexey Markevich  wrote:

> +1
>
> On Monday, October 21, 2019, Daniel Kulp  wrote:
>
> > It’s been over 2 months since 3.3.3 was released.   We fixed 20 JIRAS.
> >
> > Staging area:
> > https://repository.apache.org/content/repositories/orgapachecxf-1145/ <
> > https://repository.apache.org/content/repositories/orgapachecxf-1145/>
> >
> > Tag:
> > https://gitbox.apache.org/repos/asf?p=cxf.git;a=commit;h=
> > fbd2dbf5fecbac7343b9fe442a10e75cfb9f7471  > repos/asf?p=cxf.git;a=commit;h=fbd2dbf5fecbac7343b9fe442a10e75cfb9f7471>
> >
> >
> > Here is my +1
> >
> >
> > --
> > Daniel Kulp
> > dk...@apache.org  - http://dankulp.com/blog <
> > http://dankulp.com/blog>
> > Talend Community Coder - http://talend.com 
> >
>

Re: Flip master to 3.4, create 3.3.x-fixes

[Andy McCright]

Hi Dan,

No objections from me, but I have a question about the Jakarta
dependencies.

The Jakarta EE 8 release (due in September) is supposed to be binary
compatible with Java EE 8 - i.e. the javax.* packages will still be javax.*
(not jakarta.*).  Is the plan for 3.4.X to support Jakarta EE 8 (basically
just swapping the maven coordinates and optionally running the
now-open-sourced TCK), and then use 3.5.X or later to support Jakarta EE 9
with the new package names and new functionality?

Thanks,

Andy

On Thu, Aug 8, 2019 at 12:13 PM Daniel Kulp  wrote:

> Now that 3.3.3 is built, I’d like to flip master to 3.4 and open it up for
> the bigger changes (like Jakarta deps) and whatever else has to wait for
> 3.4.   Any objections?
>
>
> --
> Daniel Kulp
> dk...@apache.org  - http://dankulp.com/blog <
> http://dankulp.com/blog>
> Talend Community Coder - http://talend.com 
>

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

[Andy McCright]

+1 - Thanks!

On Thu, Aug 8, 2019 at 12:21 PM Freeman Fang  wrote:

> +1
>
> Thanks Dan!
> －
> Freeman(Yue) Fang
>
> Red Hat, Inc.
>
>
>
>
>
> > On Aug 8, 2019, at 1: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 
>
>

Re: Dropping JDK9 / JDK10 jobs from Jenkins

[Andy McCright]

+1 Thanks!

On Thu, May 23, 2019 at 8:13 AM Freeman Fang  wrote:

> +1
> Thanks!
> －
> Freeman(Yue) Fang
>
> Red Hat, Inc.
>
>
>
>
>
> > On May 22, 2019, at 9:48 PM, Andriy Redko  wrote:
> >
> > Hey guys,
> >
> > I think we could drop CXF's JDK9 [0] and JDK10 [1] jobs from Jenkins
> > since these JDKs are officially dead. Any objections?
> >
> > [0] https://builds.apache.org/job/CXF-Master-JDK9/
> > [1] https://builds.apache.org/job/CXF-Master-JDK10/
> >
> > Best Regards,
> >Andriy Redko
> >
>
>

Re: [VOTE] Apache CXF 3.2.9, CXF 3.3.2, and cxf-build-utils 3.4.2

[Andy McCright]

+1. Thanks!

On Fri, May 10, 2019 at 11:05 AM Romain Manni-Bucau 
wrote:

> +1, will just note that ClassUnwrapper got a new method with no default -
> not really trivial to impl - so implementations are broken. Don't think it
> is a blocker because it is mainly an integrator API and not an user API.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 10 mai 2019 à 17:58, Andrey Redko  a écrit :
>
> > +1, Andriy
> >
> > Best Regards,
> > Andriy Redko
> >
> > On Fri, May 10, 2019, 11:36 AM Daniel Kulp  wrote:
> >
> > >
> > > This is vote to release CXF 3.2.9 and CXF 3.3.2.   3.3.2 also required
> > the
> > > release of cxf-build-utils 3.4.2 to pickup the new PMD config required
> by
> > > the new PMD maven plugin.  This fixes over 30 JIRA issues reported by
> > > users.
> > >
> > >
> > > Staging areas:
> > > 3.2.9:
> > > https://repository.apache.org/content/repositories/orgapachecxf-1140
> > > 3.3.2 + buildutils:
> > > https://repository.apache.org/content/repositories/orgapachecxf-1141
> > >
> > > Tags:
> > > 3.2.9:
> > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=45bbf578434ed66e03a3488d4dedea77a1a3e855
> > > <
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=45bbf578434ed66e03a3488d4dedea77a1a3e855
> > > >
> > > 3.3.2:
> > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=ea9dc8805f5c4aca142c574bc9758b56d14460c6
> > > <
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=ea9dc8805f5c4aca142c574bc9758b56d14460c6
> > > >
> > > buildutils:
> > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cxf-build-utils.git;a=tag;h=4363ce17b167077b56543c3b7aa00b4c118782c3
> > > <
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cxf-build-utils.git;a=tag;h=4363ce17b167077b56543c3b7aa00b4c118782c3
> > > >
> > >
> > > Here is my +1
> > >
> > > --
> > > Daniel Kulp
> > > dk...@apache.org  - http://dankulp.com/blog <
> > > http://dankulp.com/blog>
> > > Talend Community Coder - http://talend.com 
> > >
> >
>

Re: Full Path Template from UriInfo?

[Andy McCright]

Hi James,

Any luck?  Worst case, you should be able to construct the path by
reflection (checking the @Path annotations from the resource class/method)
using @Context ResourceInfo's getResourceClass() and getResourceMethod()
methods.

Hope this helps,

Andy

On Sat, May 4, 2019 at 9:22 AM James Carman 
wrote:

> log.info("matchedUris: {}", uriInfo.getMatchedURIs());
>
> yields:
>
> matchedUris: [hello/Foo/1, hello]
>
> On Sat, May 4, 2019 at 10:19 AM Andy McCright
>  wrote:
> >
> > Hi James,
> >
> > I’m away from my computer now, so I cannot say for sure, but I think
> > UriInfo.getMatchedURIs() might get you the unresolved URI - assuming your
> > filter is not annotated with @PreMatch.
> >
> > Can you give that a try? If it doesn’t work I’ll take a closer look on
> > Monday.
> >
> > Thanks,
> >
> > Andy
> >
> > On Sat, May 4, 2019 at 8:41 AM James Carman 
> > wrote:
> >
> > > I am trying to use a JAX-RS ContainerRequestFilter to add the full
> > > path template to the MDC.  I am injecting the UriInfo via a @Context
> > > injection.  I have tried doing this:
> > >
> > > uriInfo.getAbsolutePathBuilder().toTemplate()
> > >
> > > But, that appears to already have the parameters resolved.  Is there a
> > > way to get the full string of the request URI template with the
> > > parameter names in it?
> > >
>

Re: Full Path Template from UriInfo?

[Andy McCright]

Hi James,

I’m away from my computer now, so I cannot say for sure, but I think
UriInfo.getMatchedURIs() might get you the unresolved URI - assuming your
filter is not annotated with @PreMatch.

Can you give that a try? If it doesn’t work I’ll take a closer look on
Monday.

Thanks,

Andy

On Sat, May 4, 2019 at 8:41 AM James Carman 
wrote:

> I am trying to use a JAX-RS ContainerRequestFilter to add the full
> path template to the MDC.  I am injecting the UriInfo via a @Context
> injection.  I have tried doing this:
>
> uriInfo.getAbsolutePathBuilder().toTemplate()
>
> But, that appears to already have the parameters resolved.  Is there a
> way to get the full string of the request URI template with the
> parameter names in it?
>

Re: Question about Apache cxf client compatibility with jersey client

[Andy McCright]

Hi Akshay,

I think it _can_ work, but it is a little risky. I believe it works because
Jersey's ClientConfig class is an implementation of
java.ws.rs.core.Configurable.  But in general, mixing implementations can
lead to problems - generally in the classloading space.

Do you need Jersey at all?  If not, then you could use CXF's equivalent (
org.apache.cxf.jaxrs.client.spec.ClientConfigurableImpl). Another
alternative would be to avoid any dependency on the implementation in your
application code - and just use the spec APIs - for example:

verifyingClient = ClientBuilder.newBuilder()
   .property(ApacheClientProperties.SSL_CONFIG,
sslConfigurator)
   .register(new ApacheConnectorProvider())
   .build();

Hope this helps,

Andy

On Sun, Apr 14, 2019 at 11:05 PM Akshay Hegade 
wrote:

> Hi Team,
>
>
>
> I have question related to cxf-rt-rs-client-3.3.1
>
>
>
> *Background* :
>
> I am working on legacy application which uses jersey-client-2.7 for http
> requests, since jersey-client-2.7 does not support *HTTP PATCH* method, we
> are using cxf-rt-rs-client-3.3.1.
>
> And HTTP PATCH started to work without any changes after *inclusion* of
> cxf-rt-rs-client-3.3.1.jar in our class path along with its dependencies.
>
>
>
> *Reason* :
>
> javax.ws.rs.client.FactoryFinder.java has following piece of code
>
>- String serviceId = "META-INF/services/“ + factoryId;
>
>
>
> javax.ws.rs.client.ClientBuilder.java has following piece of code
>
>- Object delegate =
>FactoryFinder.find("javax.ws.rs.client.ClientBuilder",
>"org.glassfish.jersey.client.JerseyClientBuilder");
>
>
>
> Since  cxf-rt-rs-client-3.3.1 in class path along with jersey-client-2.7,
> the precedence is given to cxf-rt-rs-client-3.3.1.
>
>
>
> And we are using passing org.glassfish.jersey.client.ClientConfig to
> javax.ws.rs.client.ClientBuilder
>
>
>
> *Code Snippet* :
>
> 
>
>   ClientConfig clientConfig = new ClientConfig();
>
>   clientConfig.property(ApacheClientProperties.SSL_CONFIG,
> sslConfigurator);
>
>   ConnectorProvider connectorProvider = new ApacheConnectorProvider();
>
>   clientConfig.connectorProvider(connectorProvider);
>
>
>
>   verifyingClient = ClientBuilder.newBuilder()
>
>   .withConfig(*clientConfig*).build();
>
> 
>
>
>
>
>
> *Question* :
>
> Whether jersey’s concrete class  org.glassfish.jersey.client.ClientConfig
> can be used along with javax.ws.rs.client.ClientBuilder ?
>
>
>
> Please revert back at your earliest convenience.
>
>
>
> Thanks,
>
> Akshay
>

Re: JDK13 build on Jenkins

[Andy McCright]

I should have a fix for the microprofile rest client failures shortly.

Thanks!

Andy

On Wed, Mar 13, 2019 at 10:11 PM Freeman Fang 
wrote:

> Thanks Andriy!
>
> The result isn’t bad, some failures are in OSGi, that’s kind of expected,
> since Karaf 4.2.x not support JDK13 yet.
>
> Cheers
> －
> Freeman(Yue) Fang
>
> Red Hat, Inc.
>
>
>
>
>
> > On Mar 14, 2019, at 10:18 AM, Andriy Redko  wrote:
> >
> > Hey guys,
> >
> > There is a new job configured on Jenkins [1] to build CXF using OpenJDK
> 13-ea.
> >
> > [1] https://builds.apache.org/job/CXF-Master-JDK13/
> >
> > Best Regards,
> >Andriy Redko
> >
> >
> >
>
>

Re: [VOTE] CXF 3.3.1

[Andy McCright]

+1

Thanks!

On Thu, Feb 28, 2019 at 2:39 PM Dennis Kieselhorst  wrote:

> +1
>
> Thanks!
>
> Am 28. Februar 2019 19:56:36 MEZ schrieb Daniel Kulp :
> >This is vote to release 3.3.1.   This doesn’t fix a ton of issues (only
> >12), but it does fix two relatively important regressions.
> >
> >Staging area:
> >https://repository.apache.org/content/repositories/orgapachecxf-1136/
> >
> >
> >Tag:
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=028131b027b3cfc56a18725bf6cd1f27e824a7e9
> ><
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=028131b027b3cfc56a18725bf6cd1f27e824a7e9
> >
> >
> >Here is my +1
> >
> >
> >--
> >Daniel Kulp
> >dk...@apache.org  - http://dankulp.com/blog
> >
> >Talend Community Coder - http://talend.com 
>

Re: 3.3.1 tomorrow?

[Andy McCright]

+1

There is also a minor issue where a warning is issued if using MP Rest
Client with CDI but without specifying any providers - pretty minor, but
would be nice to get that fix out.  The fix is part of commit:
https://github.com/apache/cxf/commit/d70589ed28942692f86753590fa23712850b3854

Thanks!

Andy

On Wed, Feb 27, 2019 at 9:29 AM Daniel Kulp  wrote:

>
>
> > On Feb 27, 2019, at 9:55 AM, David Karlsen 
> wrote:
> >
> > Do you have a jira ID for the performance issue?
>
> There was a brief discussion on the users list:
>
> https://lists.apache.org/thread.html/f9c6c5b504bcdfc280307ed8b7a630e9b5923ee1536bff51661b886c@%3Cusers.cxf.apache.org%3E
> <
> https://lists.apache.org/thread.html/f9c6c5b504bcdfc280307ed8b7a630e9b5923ee1536bff51661b886c@%3Cusers.cxf.apache.org%3E
> >
>
> Dan
>
>
> >
> > Den ons. 27. feb. 2019, 15:55 skrev Daniel Kulp :
> >
> >>
> >> I’d like to get 3.3.1 out real soon as it does fix a fairly severe
> >> performance issue and I’d like to get a “.1” out to appease folks that
> >> refuse to touch a .0.  :)
> >>
> >> Anyone have any objections if I do the build tomorrow?
> >>
> >> Thanks!
> >>
> >> --
> >> Daniel Kulp
> >> dk...@apache.org  - http://dankulp.com/blog <
> >> http://dankulp.com/blog>
> >> Talend Community Coder - http://talend.com 
> >>
>
> --
> Daniel Kulp
> dk...@apache.org  - http://dankulp.com/blog <
> http://dankulp.com/blog>
> Talend Community Coder - http://talend.com 
>

Re: [VOTE] CXF 3.2.8

[Andy McCright]

+1 - thanks!

On Thu, Jan 24, 2019 at 3:41 PM Andrey Redko  wrote:

> +1, thanks!
>
> Best Regards,
> Andriy Redko
>
> On Thu, Jan 24, 2019, 4:36 PM Daniel Kulp 
> > It’s been 3 months since 3.2.7 so we should do another release.  We’ve
> > fixed 18 JIRA issues
> >
> > Staging area:
> > https://repository.apache.org/content/repositories/orgapachecxf-1134 <
> > https://repository.apache.org/content/repositories/orgapachecxf-1134>
> >
> >
> > Tag:
> >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=a34bf55dea00c354bf3f49ad5b98fb18f01d9258
> > <
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=a34bf55dea00c354bf3f49ad5b98fb18f01d9258
> > >
> >
> >
> > Here is my +1
> >
> >
> > --
> > Daniel Kulp
> > dk...@apache.org  - http://dankulp.com/blog <
> > http://dankulp.com/blog>
> > Talend Community Coder - http://talend.com 
> >
>

Re: [VOTE] CXF 3.3.0 and CXF XJC Utils 3.3.0

[Andy McCright]

+1 - thanks!

On Thu, Jan 24, 2019 at 3:42 PM Andrey Redko  wrote:

> +1, this is a big one, thanks!
>
> Best Regards,
> Andriy Redko
>
> On Thu, Jan 24, 2019, 4:33 PM Daniel Kulp 
> > This is a vote to release Apache CXF 3.3.0 and the XJC Utils 3.3.0 it
> > needs.   The main new feature is support for Java 11, but there are a
> bunch
> > of other updates and enhancements such as the MP Rest Client 1.2, support
> > for signing HTTP messages via the HTTP signature draft spec, dependency
> > updates, etc…
> >
> > Staging are:
> > https://repository.apache.org/content/repositories/orgapachecxf-1133/ <
> > https://repository.apache.org/content/repositories/orgapachecxf-1133/>
> >
> > Tags:
> >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=a3207d3a979a73fbfb078153aff612d222f7109a
> > <
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=a3207d3a979a73fbfb078153aff612d222f7109a
> > >
> >
> >
> https://gitbox.apache.org/repos/asf?p=cxf-xjc-utils.git;a=tag;h=2ad0efed6e2a177b2edd4c35f3a1850c55bb9df9
> > <
> >
> https://gitbox.apache.org/repos/asf?p=cxf-xjc-utils.git;a=tag;h=2ad0efed6e2a177b2edd4c35f3a1850c55bb9df9
> > >
> >
> > Migration guide:
> > http://cxf.apache.org/docs/33-migration-guide.html
> >
> >
> > Here is my +1
> >
> > --
> > Daniel Kulp
> > dk...@apache.org  - http://dankulp.com/blog <
> > http://dankulp.com/blog>
> > Talend Community Coder - http://talend.com 
> >
>

Re: 3.3.0 soon?

[Andy McCright]

Thanks for the reminder Dennis - I just resolved it.

On Wed, Jan 23, 2019 at 11:40 AM Dennis Kieselhorst  wrote:

>
> > I was able to get the MP Rest Client 1.2 APIs and TCKs final release done
> > on time, so 3.3.0 will support the final release instead of a release
> > candidate!
>
> Great Andy, can we resolve https://issues.apache.org/jira/browse/CXF-7926?
>
> Cheers
>
> Dennis
>
>

Re: 3.3.0 soon?

[Andy McCright]

+1

I was able to get the MP Rest Client 1.2 APIs and TCKs final release done
on time, so 3.3.0 will support the final release instead of a release
candidate!

Thanks, Andy

On Wed, Jan 23, 2019 at 9:07 AM jean-frederic clere 
wrote:

> On 21/01/2019 14:06, Dennis Kieselhorst wrote:
> > Hi,
> >
> > in my view everything we discussed is finished. So we can cut a release
> and start a vote, can't we?
> >
> > Cheers
> > Dennis
> >
>
> +1 not binding :D
>
> --
> Cheers
>
> Jean-Frederic
>

Re: Builds failure

[Andy McCright]

Hi Colm,

Thanks for catching this.  It looks like a bug in the spec API.
The @ClientHeaderParam (singular) annotation has a target of TYPE,METHOD,
but the @ClientHeaderParams (plural/repeatable) only has a target of TYPE.
I can change this, but it will take a little while before it gets to the
Maven servers.

Unless anybody objects, I'll just comment out this test - then once the
spec API change is available in Maven, I'll update the dependency and
re-enable the test.

Thanks,

Andy

On Thu, Jan 17, 2019 at 10:18 AM Colm O hEigeartaigh 
wrote:

> Hi Andy,
>
> Looks like there is a build failure with JDK 11 with the last merge you
> made:
>
> https://builds.apache.org/job/CXF-Master-JDK11/239/consoleFull
>
> Colm.
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>

Re: GraphQL Project?

[Andy McCright]

Awesome!  Thanks for the feedback.

Regarding the API - the intent is be able to use a "code-first" approach -
i.e. write your object model in Java using annotations similar to
JAXB/JSON-B/etc. as necessary - write your business logic (CRUD operations)
similar to JAX-RS resource methods.  That would allow the user to generate
a schema file.  Most of the GraphQL Java implementations that I have seen
have a "schema-first" approach which leads to a lot of duplication of
effort.

Regarding the underlying implementation (whether to use graphql-java or
not), that question was asked in the last MP project meeting, and we
decided that it would be considered an implementation detail.  My opinion
would be to use graphql-java as a starting point, and only write something
from scratch if we find major limitations with it.

As far as timeline goes, I think it will be a while before we start work on
the implementation.  The MP project is just getting started, and I suspect
it will take a while to work out the spec work.

Thanks again,

Andy


On Thu, Jan 3, 2019 at 7:21 PM Andriy Redko  wrote:

> Hey Andy,
>
> Certainly +1, I think CXF would be a great place to host HTTP-based
> MP GraphQL implementation. I am wondering (probably related to Romain's
> 2nd point) if the intention is to implement the specification from scratch
> or pull in graphql-java? In any case, I think it would be great addition to
> CXF, count me in.
>
> Best Regards,
> Andriy Redko
>
> Thursday, January 3, 2019, 5:49:34 PM, you wrote:
>
> RMB> +1
>
> RMB> Two small side notes:
>
> RMB> 1. If cxf is not the right "home", geronimo would definitively be (
> RMB> http://geronimo.apache.org/microprofile/ to be concrete)
> RMB> 2. From my past experience having a graphql parser API (body reader
> for
> RMB> jaxrs/mp) is the most important feature, everything else is mainly
> the link
> RMB> to the backend and highly depends impl choices and the abstraction a
> RMB> framework gives is often  more an issue (N+1 queries to cite one
> obvious
> RMB> common problem) than a solution even if tempting
>
> RMB> Le jeu. 3 janv. 2019 23:29, Andy McCright <
> j.andrew.mccri...@gmail.com> a
> RMB> écrit :
>
> >> Hi All,
>
> >> I've been involved in an effort to create a MicroProfile GraphQL project
> >> that would provide a Java framework for building and deploying GraphQL
> >> apps.  The API would look similar to JAX-RS (i.e. @Query annotations
> >> instead of @GET, etc.).
>
> >> We have a draft project proposal available here:
>
> >>
> https://docs.google.com/document/d/1prwMGxgr0cI5yx4lrvMET5x6rD-CQ1y7XuS1PCegE4A/edit#
>
> >> Would this be something that we could implement in a new CXF module?
> And
> >> would anybody on this list be interested in participating in the MP spec
> >> project?
>
> >> Thanks in advance!
>
> >> Andy
>
> >> PS - we have a spec project meeting tomorrow at 10:30am US Eastern time.
> >> Meeting minutes (and a link to the webex) is available here:
>
> >>
> https://docs.google.com/document/d/1gb3jirFGrJwDZSbrtnFPVTNjPNe3Y0dUYfm-HkU1c3U/edit#
>
>
>

GraphQL Project?

[Andy McCright]

Hi All,

I've been involved in an effort to create a MicroProfile GraphQL project
that would provide a Java framework for building and deploying GraphQL
apps.  The API would look similar to JAX-RS (i.e. @Query annotations
instead of @GET, etc.).

We have a draft project proposal available here:
https://docs.google.com/document/d/1prwMGxgr0cI5yx4lrvMET5x6rD-CQ1y7XuS1PCegE4A/edit#

Would this be something that we could implement in a new CXF module?  And
would anybody on this list be interested in participating in the MP spec
project?

Thanks in advance!

Andy

PS - we have a spec project meeting tomorrow at 10:30am US Eastern time.
Meeting minutes (and a link to the webex) is available here:
https://docs.google.com/document/d/1gb3jirFGrJwDZSbrtnFPVTNjPNe3Y0dUYfm-HkU1c3U/edit#

Re: CxfTypeSafeClientBuilderTest failing on JDK9+

[Andy McCright]

Hi Dennis,

I most likely introduced this with my fix for CXF-7922 - in that fix, I
made some changes to internal JDK classes in ClientProxyImpl's
invokeDefaultMethod method.  The MP Rest Client (as well as the CXF proxy
client) should be able to invoke default methods, and there doesn't seem to
be a good way of doing that... Romain wrote a blog post on the subject
here:
https://rmannibucau.wordpress.com/2014/03/27/java-8-default-interface-methods-and-jdk-dynamic-proxies/
- this was the idea behind that change, but I would bet that it is not
allowed with JPMS enabled - and is most likely causing the failure.

It sounds like I need to find a better way to invoke default interface
methods without using JDK internals.  If anyone knows of a better way or
has any hints, please let me know.  In the meantime, I could add something
like "assume Java 8" to skip the test in Java 9+ environments.  What do you
think?

Thanks,

Andy

On Thu, Dec 20, 2018 at 2:33 PM Dennis Kieselhorst  wrote:

> Hi,
>
> only CxfTypeSafeClientBuilderTest is missing to have a stable build from
> JDK 9 - 11.
>
> java.lang.reflect.UndeclaredThrowableException
> at
> org.apache.cxf.microprofile.client.CxfTypeSafeClientBuilderTest.testCanInvokeDefaultInterfaceMethods(CxfTypeSafeClientBuilderTest.java:173)
> Caused by: java.lang.IllegalAccessException: access to public member
> failed:
> org.apache.cxf.microprofile.client.mock.MyClient.myDefaultMethod[Ljava.lang.Object;@10cf09e8/invokeSpecial,
> from org.apache.cxf.microprofile.client.mock.MyClient/2 (unnamed module
> @14dd9eb7)
> at
> org.apache.cxf.microprofile.client.CxfTypeSafeClientBuilderTest.testCanInvokeDefaultInterfaceMethods(CxfTypeSafeClientBuilderTest.java:173)
>
> Anyone seen something similar before?
>
> Cheers
> Dennis
>

Re: 3.3.0 soon?

[Andy McCright]

I'm working on an initial implementation of MicroProfile Rest Client 1.2
that I'd like to put in the 3.3.X stream.  The spec probably won't be
finalized until mid-January or later, but there is a 1.2 milestone (early
access) release in Maven central that we could use in a 3.3.0 release.

Does anybody have any thoughts about pushing the Rest Client 1.2
implementation into the 3.3.0 release (using the early access API) vs
waiting until January/February to use the official APIs?  I tend to prefer
the former, but I'd be fine either way.

Thanks,

Andy

On Fri, Dec 7, 2018 at 12:08 PM Romain Manni-Bucau 
wrote:

> Any hope javax.activation and jaxb becomes optional for the 3.3 and jaxrs?
> I can surely help in 10 days if not too late
>
> Le ven. 7 déc. 2018 10:39, Jean-Baptiste Onofré  a écrit
> :
>
> > Hi Colm,
> >
> > I'm working on a couple of new features for Karaf/OSGi (SCR support +
> > simple whiteboard). I will try to submit the PRs soon, but definitely
> > not a blocker for the 3.3.0 release.
> >
> > Regards
> > JB
> >
> > On 07/12/2018 10:27, Colm O hEigeartaigh wrote:
> > > Hi all,
> > >
> > > XML Schema 2.2.4 is under vote, and I believe a vote will also be
> called
> > on
> > > Karaf 4.2.2 shortly. We should be good to go then for CXF 3.3.0 either
> > next
> > > week or the week after, so if there is anything anyone needs to get in,
> > now
> > > is the time to do it.
> > >
> > > Colm.
> > >
> > >
> >
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>

Re: [VOTE] CXF 3.2.7 and xic-utils 3.2.3

[Andy McCright]

+1

Thanks!

Andy

On Wed, Oct 24, 2018 at 7:53 PM Jeff Genender  wrote:

> +1
>
> Jeff
>
> > On Oct 24, 2018, at 1:35 PM, Daniel Kulp  wrote:
> >
> > It’s been over two months since we last release a 3.2.x.  Thus, it’s
> time.   We’ve fixed a bunch of bugs, fixed some performance regressions,
> added a few new features, etc…
> >
> > Tags:
> > CXF:
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=7e83e9f7c5f448cbbc8ce5675f4814144270aef7
> <
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=7e83e9f7c5f448cbbc8ce5675f4814144270aef7
> >
> > XJC:
> https://gitbox.apache.org/repos/asf?p=cxf-xjc-utils.git;a=tag;h=0acc9ea783a88ff70711c1f1f1b925ce7ff75ef8
> <
> https://gitbox.apache.org/repos/asf?p=cxf-xjc-utils.git;a=tag;h=0acc9ea783a88ff70711c1f1f1b925ce7ff75ef8
> >
> >
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/orgapachecxf-1132/
> >
> >
> > Here is my +1.
> >
> > --
> > Daniel Kulp
> > dk...@apache.org  - http://dankulp.com/blog <
> http://dankulp.com/blog>
> > Talend Community Coder - http://talend.com 
>
>

Re: [VOTE] - Release Apache CXF 3.1.17

[Andy McCright]

+1

Thanks!

Andy

On Mon, Oct 1, 2018 at 9:13 AM Alessio Soldano  wrote:

> +1
> Thanks!
>
> On Sun, Sep 30, 2018 at 2:33 PM Colm O hEigeartaigh 
> wrote:
>
> > This is a vote to release Apache CXF 3.1.17.
> >
> > Issues fixed:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12343481
> >
> > Git tag: https://github.com/apache/cxf/tree/cxf-3.1.17
> >
> > Artifacts:
> > https://repository.apache.org/content/repositories/orgapachecxf-1125/
> >
> > +1 from me.
> >
> > Colm.
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
>

Re: [VOTE] Apache CXF 3.2.6

[Andy McCright]

+1

Thanks!

Andy

On Thu, Aug 9, 2018 at 3:23 AM Christian Schneider 
wrote:

> +1 (binding)
>
> Christian
>
> Am Do., 9. Aug. 2018 um 01:15 Uhr schrieb Daniel Kulp :
>
> > This is a vote to release CXF 3.2.6.
> >
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/orgapachecxf-1120/ <
> > https://repository.apache.org/content/repositories/orgapachecxf-1120/>
> >
> >
> > Tag:
> >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=f0b4f939f81894c9943c24ea6891c7fa08df00a6
> > <
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=f0b4f939f81894c9943c24ea6891c7fa08df00a6
> > >
> >
> >
> > Here is my +1
> >
> >
> > --
> > Daniel Kulp
> > dk...@apache.org  - http://dankulp.com/blog <
> > http://dankulp.com/blog>
> > Talend Community Coder - http://talend.com 
> >
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
>

Re: Change master to 3.3?

[Andy McCright]

+1

For Java levels, I'd recommend that we skip Java 10 and plan for Java 11.
Java 10 support ends in September, whereas Java 11 is a long term support
release.
http://www.oracle.com/technetwork/java/javase/eol-135779.html

Thanks!
Andy

On Tue, Jun 26, 2018 at 9:49 AM Dennis Kieselhorst  wrote:

> Definitely +1
>
> > And how about for the master we also have spring 5 + spring boot 2,
> basically merge the spring-5-boot-2 branch?
>
> Yes, I started the branch for testing and it looks good. Thank you for
> fixing some tests.
>
> Regards
> Dennis
>

Re: [VOTE] CXF 3.2.5/3.1.16

[Andy McCright]

+1 - Thanks!

On Mon, Jun 18, 2018 at 6:36 PM 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
> >
>
>
> Here is my +1
>
>
> --
> Daniel Kulp
> dk...@apache.org  - http://dankulp.com/blog <
> http://dankulp.com/blog>
> Talend Community Coder - http://coders.talend.com <
> http://coders.talend.com/>
>

Re: A few 'Feature' questions

[Andy McCright]

Hi Mark,

For #1 - I'll take a look - I've been meaning to ever since I saw the JIRA,
but I've been swamped lately.  My bad.

For #2 - I'd like others to weigh in, but I do think that this is the
intended behavior.  IIUC, org.apache.cxf.feature.Feature existed before the
JAX-RS spec and is used in a variety of non-JAX-RS scenarios (JAX-WS,
etc.).  The LoggingInterceptor is not actually a JAX-RS provider - rather
it is an interceptor used on the CXF chain.  JAX-RS Providers are typically
invoked from the JAXRSInInterceptor and JAXRSOutInterceptor on the chain.
It may be possible to add a LoggingInterceptor to the chain at that point,
but it doesn't seem advisable - I haven't done much with chain
manipulation, so would definitely recommend a second opinion here.

Thanks for the patch,

Andy

On Wed, Apr 25, 2018 at 3:26 PM, Mark Struberg 
wrote:

> hi folks!
>
> I have two questions:
>
> 1.) Could anybody plz take a quick look at CXF-7713 and review the patch?
>
> 2.) I've created a DynamicFeature @Provider and tried to register a CXF
> LoggingInterceptor.
> And this doesn't work since it seems to only pick up
> javax.ws.rs.core.Feature instances, but not
> org.apache.cxf.feature.Feature
>
> Is this observation correct?
> Is this behaviour intended?
>
> I know I can register it via Bus#setFeatures, but that is not as modular
> in comparison to the @Provider.
>
> txs and LieGrue,
> strub
>
>
>

Re: [VOTE] CXF 2.3.4

[Andy McCright]

+1. Thanks!

On Thu, Mar 22, 2018 at 6:08 PM John D. Ament  wrote:

> +1 plus this fixes an issue for Romain.
>
> On Thu, Mar 22, 2018 at 5:18 PM Daniel Kulp  wrote:
>
> >
> > This is a vote to release CXF 3.2.4.   We only fixed a few issues since
> > 3.2.3, but it fixes a severe regression for Syncope as well as fixes a
> > potential corruption issue with the JSONProvider.
> >
> > Staging area:
> > https://repository.apache.org/content/repositories/orgapachecxf-1115/
> >
> > Tag:
> >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=ad8b056676799c92d4d81e9c006c5711be35d62c
> >
> > Here is my +1.
> >
> >
> > --
> > Daniel Kulp
> > dk...@apache.org - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> >
> >
>

Re: [VOTE] Apache CXF 3.2.3

[Andy McCright]

+1

Thanks!

Andy

On Sat, Mar 17, 2018 at 10:02 AM François Papon <
francois.pa...@openobject.fr> wrote:

> +1 (non-binding)
>
> Thanks for the release !
>
> François
>
> Le 17 mars 2018 00:54, Daniel Kulp  a écrit :
> >
> >
> > This is a vote to release CXF 3.2.3.   We’ve fixed over 27 JIRA issues.
> >
> >
> > Staging area:
> > https://repository.apache.org/content/repositories/orgapachecxf-1114/
> >
> >
> > Tag:
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=commit;h=b82303bfb6802817d3ce3be1ce30df74fee50675
> >
> >
> > Here is my +1.
> >
> >
> > --
> > Daniel Kulp
> > dk...@apache.org - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> >
>

Re: [VOTE] - Release Apache CXF 3.1.15

[Andy McCright]

+1

Thanks!

Andy

On Thu, Mar 8, 2018 at 9:04 AM, Francesco Chicchiriccò 
wrote:

> On 08/03/2018 15:19, Colm O hEigeartaigh wrote:
>
>> This is a vote to release Apache CXF 3.1.15.
>>
>> Issued fixed: https://issues.apache.org/jira
>> /projects/CXF/versions/12342151
>>
>> Artifacts:
>> https://repository.apache.org/content/repositories/orgapachecxf-1113/
>>
>> Git tag: https://github.com/apache/cxf/tree/cxf-3.1.15
>>
>
>
> +1
> Thanks Colm.
> 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/
>
>

Web/wiki Access

[Andy McCright]

Hi All,

Can I get access to modify the cxf.apache.org website?  Through a question
on dwAnswers ,
I learned that a property listed on the page below is incorrect.  It is a
simple change to correct it - change "org.apache.cxf.jaxrs.service.scope"
to "org.apache.cxf.service.scope".

http://cxf.apache.org/docs/jaxrs-services-configuration.html#JAXRSServicesConfiguration-PostConstructandPreDestroy

Thanks in advance,

Andy

Re: Backport Microprofile Client to 3.1.x branch

[Andy McCright]

Hi Roberto,

I think it is a good idea.  The main drawback is that the 3.1.X stream
requires compatibility with Java 7.  The MicroProfile spec and Rest Client
specifically sets Java 8 as the minimum Java level - and the Rest Client
specifically makes use of Java 8 syntax and APIs, like lambdas and default
interface methods.  I don't think it will be possible to build in 3.1.X
without a Java 8 compiler.  That might be possible, but might not be a good
idea because then the MP Rest Client module will be out of sync with the
other modules in the 3.1.X stream.

One thing you might consider would be have your projects depend on the MP
Rest Client module from 3.2.X, but the rest of CXF be at the 3.1.X level.
You would need to run with Java 8 - and there are probably some other
changes in the 3.2.X stream that would need to be back ported for
compatibility.  I did something similar in OpenLiberty here [1] that might
help you.

Hope this helps,

Andy

[1] https://github.com/OpenLiberty/open-liberty/pull/1558

On Wed, Feb 28, 2018 at 4:40 AM, Roberto Cortez  wrote:

> Hi,
> I was wondering if it would be ok to backport the Microprofile Client
> module from the master branch in the 3.1.x branch.
> This is because the latest spec of Microprofile, version 1.3, targets
> JAX-RS 2.0 and requires the Rest Client 1.0, implemented in 3.2.x, which is
> JAX-RS 2.1.
> If this is ok, I wouldn't mind submitting a PR myself with the port.
> Cheers,Roberto

Re: [Dev] GSoC-2018 Project Ideas

[Andy McCright]

Hi Isuranga,

I've never done a GSoC project before, but I'd be interested in
participating/mentoring.  My expertise is more geared toward RESTful
services like JAX-RS and the MicroProfile Rest Client.  Would you be
interested in a project in that area?

Thanks,

Andy

On Tue, Feb 13, 2018 at 6:40 AM, Isuranga Perera 
wrote:

> Hi All,
>
> I'm a computer science undergraduate who participated GSoC 2017. I was
> involved in implementing WS-Trust implementation for WSO2 Identity server.
> In addition to that I worked on XACML, SCIM, SAML etc. related features of
> WSO2 Identity Server.
>
> I have previously worked with CXF for various projects so that I would like
> to know whether you're planning to include any project ideas to GSoC 2018
> project list this time.
>
> Best Regards
> Isuranga Perera
>

Re: Going offline soon

[Andy McCright]

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 
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: [VOTE] CXF 3.2.2

[Andy McCright]

+1

On Fri, Feb 2, 2018 at 2:15 PM, Andrey Redko  wrote:

> +1!
>
> Andriy
>
> On Fri, Feb 2, 2018 at 1:57 PM, Daniel Kulp  wrote:
>
> > This is a vote to release CXF 3.2.2.   We’ve fixed over 60 JIRA issues,
> > definitely time to release it.   This also includes releases of
> build-utils
> > (3.4.0) and xjc-utils (3.2.1) to allow it to build on Java 9 and with the
> > latest checkstyle plugins.
> >
> >
> > Staging area:
> > https://repository.apache.org/content/repositories/orgapachecxf-1112/
> >
> >
> > Tags:
> > https://gitbox.apache.org/repos/asf?p=cxf-build-utils.git;a=commit;h=
> > f362ab215acb17e744a8df4001b60e91dafb3a46
> > https://gitbox.apache.org/repos/asf?p=cxf-xjc-utils.git;a=commit;h=
> > 932ad93e601c19dab833b96a3649502334e90821
> > https://gitbox.apache.org/repos/asf?p=cxf.git;a=commit;h=
> > d579d7949d119dcf3d312059085bc200bcb3bbea
> >
> >
> > Here is my +1.
> >
> >
> > --
> > Daniel Kulp
> > dk...@apache.org - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> >
> >
>

Re: MP client test failing

[Andy McCright]

Hi John,

Sorry for the delay, but yes, that is an expected validation.  Thanks for
catching it!

Andy

On Fri, Dec 22, 2017 at 8:18 AM, John D. Ament 
wrote:

> I pushed up a fix.  Andy, whenever you get a chance can you take a look
> and confirm this validation is expected as well?
>
> On 2017-12-22 08:16, Sergey Beryozkin  wrote:
> > 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  wrote:
> > >> Hi John
> > >>
> > >> Consistently seeing:
> > >>
> > >> Method
> > >> InvalidInterfaceTest.testExceptionThrownWhenInterfa
> ceHasMethodWithPathParamAnnotationButNoURITemplate()[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: Default Priority for built in providers

[Andy McCright]

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  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  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"  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 
> > > 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

[Andy McCright]

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

> Le 16 déc. 2017 20:28, "Andy McCright"  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 
> 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

[Andy McCright]

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.

On Sat, Dec 16, 2017 at 12:55 PM John D. Ament 
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: New Java 9 master

[Andy McCright]

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

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

Re: JIRA Karma?

[Andy McCright]

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  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  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: [DISCUSS] Status of 3.0.x...

[Andy McCright]

+1 to keeping 3.2 on master until 3.2.1.  I also agree with declaring end
of support for 3.0.X (barring security vulnerabilities).

Good discussion!  Thanks!

Andy

On Wed, Sep 6, 2017 at 2:14 PM 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

[Andy McCright]

+1

On Wed, Sep 6, 2017 at 2:06 PM Andriy Redko  wrote:

> +1! CXF rocks!
>
> Andriy
>
> DK> It’s been 2 years since the last major CXF release.We have well
> over 100 JIRA’s of new features and
> DK> enhancements that are only targeted toward 3.2.   Let’s get it out!
>
>
> DK> Staging repo:
> DK> https://repository.apache.org/content/repositories/orgapachecxf-1102/
>
> DK> Tag:
> DK>
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=79c1486ed9cf34d90a04d943ed72475500f83c48
>
> DK> Here is my +1
>
>
>
>

Re: Gitbox

[Andy McCright]

+1 - agreed, low cost and it should make things a little easier.  Thanks!

On Mon, Jul 31, 2017 at 9:04 AM, Colm O hEigeartaigh 
wrote:

> +1 - makes sense to me.
>
> Colm.
>
> On Mon, Jul 31, 2017 at 2:47 PM, Daniel Kulp  wrote:
>
> >
> > To move this forward…..
> >
> >
> > From my reading/investigation, the only “change” that would be required
> > post migration would be for everyone to update the URL’s for their repos
> in
> > their clones. (Change git-wip.apache.org -> gitbox.apache.org).   That’s
> > it.   So the short term impact would be minimal.
> >
> > What we would gain includes:
> >
> > 1) writable GitHub repo -  instead of pushing to apache, you COULD push
> to
> > GitHub.  Not a big deal for anyone though.  Most of us just do “git push”
> > and where it goes doesn’t really matter.
> >
> > 2) However, (1) allows using the “merge” button on the pull requests.
> >  For simple pull requests, this can be easier.
> >
> > 3) This also allows use of the “Close” button on the pull requests for
> > requests that won’t be merged.   No more “bogus/empty” commits to close
> a PR
> >
> > 4) It also would allow assigning reviewers and labels and such the PR’s.
> >  We’ve never really used those (since they aren’t usable right now), but
> > they could be useful in the future.
> >
> >
> > Anyway, would anyone object if I filed a ticket to migrate?   I don’t see
> > any major downsides as it’s just a URL change.   Do you think we need a
> > formal vote or is a lazy-consensus ok?  That said, even if we agree
> to
> > file the ticket, it doesn’t mean INFRA will approve it.
> >
> >
> > Dan
> >
> >
> >
> > > On Jul 29, 2017, at 3:01 AM, Dennis Kieselhorst 
> wrote:
> > >
> > > I already replied yesterday, somehow Ponymail seems not to deliver
> > > anything at the moment, so I try again...
> > >
> > >> We'd obviously all have to update the URL's for our local repos, is
> > > that it?
> > >
> > > Basically yes, I don't see any disadvantages.
> > >
> > > See this thread for experiences in Accumulo project:
> > > https://lists.apache.org/thread.html/3b50ac9e449b3f0621478bba9ee1ad
> > 01340800982b0e7af17ecff792@%3Cdev.accumulo.apache.org%3E
> > >
> > > We should continue using JIRA and not switch to GitHub issues.
> > >
> > > Regards
> > > Dennis
> >
> > --
> > Daniel Kulp
> > dk...@apache.org - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> >
> >
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>

Re: SSE module missing from CXF 3.2.X snapshot?

[Andy McCright]

Thanks Andriy!

On Wed, Jul 19, 2017 at 9:35 PM Andriy Redko  wrote:

> Hi Andy,
>
> That would be my fault, my apologies. I will take care of this issue
> so SSE module would be included as part of the ZIP distribution. Thanks
> for spotting it.
>
> Best Regards,
> Andriy Redko
>
> AM> Hi All,
>
> AM> I'm starting to play with some of the SSE stuff as part of JAX-RS 2.1,
> and
> AM> I've noticed that the rt-rs-sse module is not in the CXF 3.2.X snapshot
> AM> ZIPs available here:
> AM>
> http://repository.apache.org/snapshots/org/apache/cxf/apache-cxf/3.2.0-SNAPSHOT/
>
> AM> I have been able to build the module locally, but I'm hoping to be
> able to
> AM> point customers to a single ZIP file that contains all of the modules
> in
> AM> use.
>
> AM> If there is some build/packaging steps that need to be performed to
> include
> AM> the SSE module, I'd be happy to do the work - but hopefully somebody
> can
> AM> point me in the right direction to get started.
>
> AM> Thanks,
>
> AM> Andy
>
>

SSE module missing from CXF 3.2.X snapshot?

[Andy McCright]

Hi All,

I'm starting to play with some of the SSE stuff as part of JAX-RS 2.1, and
I've noticed that the rt-rs-sse module is not in the CXF 3.2.X snapshot
ZIPs available here:
http://repository.apache.org/snapshots/org/apache/cxf/apache-cxf/3.2.0-SNAPSHOT/

I have been able to build the module locally, but I'm hoping to be able to
point customers to a single ZIP file that contains all of the modules in
use.

If there is some build/packaging steps that need to be performed to include
the SSE module, I'd be happy to do the work - but hopefully somebody can
point me in the right direction to get started.

Thanks,

Andy

Re: Enable reflective use of HttpURLConnection by default?

[Andy McCright]

Hi Sergey,

Thanks for the suggestion.  I'll definitely give cxf-rt-transports-http-hc
a try.

As for what will happen in Java 9 with using reflection, it will work by
default now that Oracle has decided to ship with the "kill-switch" enabled
(i.e. the JPMS module system will be disabled by default).  However, if a
user were to enable JPMS, then this reflection approach would also fail.
So wrt to this transport, PATCH and other "non-standard" HTTP methods will
not work with JPMS enabled.  Given that, your suggestion to use Apache HTTP
Client makes more sense.  Still, I'll plan to change the default for 3.2 to
use reflection unless anybody objects.

Thanks again,

Andy

On Sat, Jul 15, 2017 at 11:38 AM, Sergey Beryozkin 
wrote:

> Hi Andy
>
> Note that the other alternative is to use CXF Apache HTTP Client based
> conduit, cxf-rt-transports-http-hc, if it is on the classpath then CXF
> (Dan did it) will use HttpClient by default, and as far as I recall (I've
> no editor opened right now) CXF RS Client (in AbstractClient code)
> will instruct whatever HTTP conduit is loaded to run a non-async request
> synchronously.
>
> Have you tried cxf-rt-transports-http-hc ? My understanding CXF RS async
> requests (those part of 2.0 API for ex) can only be truly async when this
> conduit is loaded.
>
> Dan can provide more info but I believe when the async requests run over
> the HttpUrlConnection CXF may be blocking the thread (at the sync HTTP
> Conduit level) and using the internal pool, something like that...
>
> As far as enabling the reflective use of HttpUrlConnection by default: it
> is probably a good idea indeed.
> What will happen when CXF is run in a Java 9 VM though ?
>
>
> Thanks, Sergey
>
>
> On 14/07/17 18:36, Andy McCright wrote:
>
>> Hi All,
>>
>> With more and more people using different HTTP methods (verbs) with the
>> JAX-RS client - particularly PATCH, but really any method they want - is
>> there any objection to making the "use.httpurlconnection.method.
>> reflection"
>> true by default in CXF 3.2.X?
>>
>> Here is some background:
>> Java SE's HttpUrlConnection's setRequestMethod() implementation restricts
>> callers to the following HTTP methods: GET POST HEAD OPTIONS PUT DELETE
>> TRACE - if any other HTTP method is passed in, then the caller will get a
>> ProtocolException.
>>
>> This is very limiting and prevents users for invoking increasingly common
>> HTTP methods like PATCH, some of the WebDAV methods, etc. Ideally, the JDK
>> would alter the list of allows HTTP methods (or provide a mechanism for
>> users to specify a whitelist of allowed methods), but at best that won't
>> occur until Java 9.
>>
>> CXF worked around this problem by adding the
>> "use.httpurlconnection.method.reflection" property - this can be set as a
>> system property or as a property on the Message object.  When true, CXF
>> will reflectively modify the state of the HttpURLConnection object
>> (bypassing the setRequestMethod's parameter check) and set the user's
>> specified HTTP method.
>>
>> With JAX-RS 2.1 adding out-of-the-box @PATCH support, I suspect more and
>> more users will want to use HTTP methods not in the JDK's current
>> whitelist.  Rather than asking them to set this property, I think it might
>> make more sense to enable the property by default (they could always
>> disable if they feel it is a risk).
>>
>> Any thoughts?  If there are no objections, I can make the change.
>>
>> Thanks,
>> Andy
>>
>>

Enable reflective use of HttpURLConnection by default?

[Andy McCright]

Hi All,

With more and more people using different HTTP methods (verbs) with the
JAX-RS client - particularly PATCH, but really any method they want - is
there any objection to making the "use.httpurlconnection.method.reflection"
true by default in CXF 3.2.X?

Here is some background:
Java SE's HttpUrlConnection's setRequestMethod() implementation restricts
callers to the following HTTP methods: GET POST HEAD OPTIONS PUT DELETE
TRACE - if any other HTTP method is passed in, then the caller will get a
ProtocolException.

This is very limiting and prevents users for invoking increasingly common
HTTP methods like PATCH, some of the WebDAV methods, etc. Ideally, the JDK
would alter the list of allows HTTP methods (or provide a mechanism for
users to specify a whitelist of allowed methods), but at best that won't
occur until Java 9.

CXF worked around this problem by adding the
"use.httpurlconnection.method.reflection" property - this can be set as a
system property or as a property on the Message object.  When true, CXF
will reflectively modify the state of the HttpURLConnection object
(bypassing the setRequestMethod's parameter check) and set the user's
specified HTTP method.

With JAX-RS 2.1 adding out-of-the-box @PATCH support, I suspect more and
more users will want to use HTTP methods not in the JDK's current
whitelist.  Rather than asking them to set this property, I think it might
make more sense to enable the property by default (they could always
disable if they feel it is a risk).

Any thoughts?  If there are no objections, I can make the change.

Thanks,
Andy

Re: [VOTE] Apache CXF 3.1.12 and 3.0.14

[Andy McCright]

+1

Andy

On Tue, Jun 27, 2017 at 3:09 PM Andrei Shakirin 
wrote:

> +1
>
> Andrei.
>
> > -Original Message-
> > From: Daniel Kulp [mailto:dk...@apache.org]
> > Sent: Dienstag, 27. Juni 2017 00:23
> > To: dev@cxf.apache.org
> > Subject: [VOTE] Apache CXF 3.1.12 and 3.0.14
> >
> > It’s been over 2 months since the last release. We’ve fixed over 50
> JIRA’s for
> > 3.1.12.  Thus, let’s get it out.
> >
> > Staging repos:
> > 3.0.14:
> > https://repository.apache.org/content/repositories/orgapachecxf-1093/
> > 3.1.12:
> > https://repository.apache.org/content/repositories/orgapachecxf-1092/
> >
> > Tags:
> > 3.0.14:
> > https://git-wip-
> > us.apache.org/repos/asf?p=cxf.git;a=tag;h=a74c456018afc62d273cb8cb0a459f
> > ec5b12d265
> > 3.1.12:
> > https://git-wip-
> > us.apache.org/repos/asf?p=cxf.git;a=tag;h=6b41994254531a6ea6b2451277063
> > c71ecfac320
> >
> > Here is my +1.   Vote will be open for at least 72h.
> >
> >
> > --
> > Daniel Kulp
> > dk...@apache.org - http://dankulp.com/blog Talend Community Coder -
> > http://coders.talend.com
>
>

Re: [VOTE] Apache CXF 3.1.11 and 3.0.13

[Andy McCright]

+1

On Thu, Apr 6, 2017 at 7:06 AM Christian Schneider 
wrote:

> +1
>
> Christian
>
> On 06.04.2017 01:43, Daniel Kulp wrote:
> > It’s been about 2 months since the last release.  However, we’ve fixed
> over 100 JIRA’s for 3.1.11 which is a large number of fixes.  Thus, let’s
> get it out.
> >
> > Staging repos:
> > 3.0.13:
> > https://repository.apache.org/content/repositories/orgapachecxf-1087/
> > 3.1.11:
> > https://repository.apache.org/content/repositories/orgapachecxf-1088/
> >
> > Tags:
> > 3.0.13:
> >
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=444c58f6d36243e1a73efe3f0e748091cfbd499b
> > 3.1.11:
> >
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=2ae6483276825a93e7ebe40fbcfc11866d364530
> >
> > Here is my +1.   Vote will be open for at least 72h.
> >
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>

Re: Becoming a committer?

[Andy McCright]

Hi Sergey, John,

Thanks for the kind words.  I don't mind waiting -- I totally understand
the idea of wanting to make sure that a person is contributing on a
consistent basis before adding them as a committer -- or on the flip side,
that you don't want to have a bunch of committers who were active for a
short period of time, but then stopped.

I'll plan to keep contributing, and we can continue this conversation in a
few months (I'm not planning to go anywhere... :) ).

Thanks again for all of the support!

Andy

On Fri, Nov 18, 2016 at 9:41 AM, Sergey Beryozkin 
wrote:

> And it did not take everyone 1 year to become a committer anyway
>
> On 18/11/16 16:38, Sergey Beryozkin wrote:
>
>> I did not say it would take Andy 1 year to become a committer
>> On 18/11/16 16:30, John D. Ament wrote:
>>
>>> So, you're thinking its normal for a project to add a committer once per
>>> year?  Looking at the archives, last new committer was added almost 1
>>> year
>>> ago (just shy of two weeks).
>>>
>>> On Fri, Nov 18, 2016 at 10:05 AM Sergey Beryozkin 
>>> wrote:
>>>
>>> Hi Andi
>>>>
>>>> Please be assured your contributions have been noticed.
>>>>
>>>> FYI, it usually takes longer to become a CXF committer, as far as I'm
>>>> aware it has taken awhile for all the contributors who joined the team
>>>> in the last few years to become the committers, including some of your
>>>> colleagues. I think it took me a while to become the one too :-) and it
>>>> does not depend if the candidates for ex work for the same company as me
>>>> (or other PMC member) or not...
>>>>
>>>> Some contributors take on major projects, some do various fixes, but I
>>>> believe CXF PMC is always being recognizing contributors who have been
>>>> helping CXF.
>>>>
>>>> As far as JAX-RS 2.1 is concerned the initial draft has been mostly
>>>> implemented (SSE Server, Rx Client API - some improvements might need to
>>>> go there), and Andriy Redko is investigating the initial NIO
>>>> implementation. I guess we will see more requirements in 2017.
>>>>
>>>> Other than that - have a look please at other CXF JAX-RS or non JAX-RS
>>>> issues whenever you get a chance, if you have some opinion on whatever
>>>> issues the users are raising, consider contributing, etc.
>>>>
>>>> IMHO you are a quality contributor - so I'm looking forward to you
>>>> becoming a CXF committer.
>>>>
>>>> Thanks, Sergey
>>>>
>>>>
>>>>
>>>> On 18/11/16 00:31, Andy McCright wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> I would like to become a committer on CXF.  Hopefully over the past few
>>>>> months I've earned some karma with some of the performance and
>>>>>
>>>> CTS-related
>>>>
>>>>> fixes - and I'm hoping to contribute more - especially in the JAX-RS
>>>>> 2.1
>>>>> space.
>>>>>
>>>>> If I'm not quite there as far as contributions, is there anything
>>>>>
>>>> specific
>>>>
>>>>> that I could do to help get me to be a committer?
>>>>>
>>>>> Thanks in advance for your consideration,
>>>>>
>>>>> Andy
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>

Becoming a committer?

[Andy McCright]

Hi All,

I would like to become a committer on CXF.  Hopefully over the past few
months I've earned some karma with some of the performance and CTS-related
fixes - and I'm hoping to contribute more - especially in the JAX-RS 2.1
space.

If I'm not quite there as far as contributions, is there anything specific
that I could do to help get me to be a committer?

Thanks in advance for your consideration,

Andy

Re: Non-void return types for async methods

[Andy McCright]

Hi Sergey,

Sure, I can open both JIRAs.

As for use cases, the only one I can think of is a stretch, but what if a
user wanted to re-use an async method -- something like this:

@GET
public String getName(@QueryParam int id, @Suspended AsyncResponse ar) {
String result = getNameFromDatabase(id);
if (ar != null) {
ar.resume(result);
}
return result;
}

@PUT
String getAndUpdateName(int id, String newName) {
String result = getName(id, null);
if ( updateDatabaseWithNewName(id, newName) ) {
return "Was " + result + " but now is " + newName;
} else {
throw new DBException("failed to update name ...");
}
}

I'll start work on the first JIRA and patch (changing to warning) now.  If
this use case convinces you, we can always add to the patch to keep the
method in the list of candidates.

Thanks for feedback,

Andy

On Tue, Nov 1, 2016 at 4:45 PM, Sergey Beryozkin 
wrote:

> IMHO it is always worth looking critically at the spec API, not to be
> negative but to see what may not be quite right and can be improved going
> forward.
> As such, I can only imagine that the reason @Suspended docs say such
> method responses must be ignored but do not go further and recommend not
> adding them as the candidates is about supporting a "just in case" case or
> a case where a test has not been provided with a WARNING being the last
> resort warning.
>
> I believe at this stage it is safe and good to ignore such methods
> completely unless I'm missing something obvious.
>
> Andy, can you please start with a patch to move from FINE to WARNING and
> open another JIRA (minor Bug is probably OK) about such methods being
> removed from the list of candidates - we would link it to a JAX-RS 2.1
> issue where some extra justifications about the reason why such methods are
> still candidates can be sought - please open this JAX-RS 2.1 issue too or I
> can open it.
>
> Does this plan work for you ?
>
> Thanks, Sergey
>
>
> On 01/11/16 16:25, Sergey Beryozkin wrote:
>
>> Hi Andy
>> On 01/11/16 15:50, Andy McCright wrote:
>>
>>> Hi All,
>>>
>>> When we moved to 3.1.7 a few months ago, we started seeing a test failure
>>> in one of our system tests.  The tester had a JAX-RS resource with the
>>> following method signature:
>>>
>>>   @GET
>>>   @Produces(MediaType.APPLICATION_JSON)
>>>   public JSONObject getMessage(@QueryParam("id") int i, @Suspended
>>> AsyncResponse async)
>>>
>>> Prior to 3.1.7, this method could be invoked and would return a 200
>>> response with a JSON message.  After the upgrade, the same request
>>> results
>>> in a 405 response, and no warning message.
>>>
>>> When I read the javadoc text for the @Suspended annotation (
>>> http://docs.oracle.com/javaee/7/api/javax/ws/rs/container/Suspended.html
>>> ),
>>> it makes me think that the method should be available (and requests
>>> should
>>> still succeed), but that the return value of the method should be
>>> ignored.
>>> I also think we should be logging a warning rather than a fine message.
>>>
>>> Does that sound good?  If no objections, I'll plan to open a JIRA and
>>> provide a patch.
>>>
>> I agree it should be a warning instead of a fine message.
>>
>> However I'm not sure what we will achieve by keeping such method
>> candidates. The developer who writes this code will expect the value be
>> returned to the user but the test validating that some value is returned
>> will fail anyway.
>>
>> Thus such methods can only add to the cost of the selection process if
>> they are added to the list of the candidates and will confuse the users
>> (ex, suspended GET will be still supported but the GET user will
>> eventually get an empty page...).
>>
>> Can you see any practical scenarios where keeping such method candidates
>> can you actually make these methods work ?
>>
>> Thanks, Sergey
>>
>>>
>>> Thanks, Andy
>>>
>>>
>>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>

Non-void return types for async methods

[Andy McCright]

Hi All,

When we moved to 3.1.7 a few months ago, we started seeing a test failure
in one of our system tests.  The tester had a JAX-RS resource with the
following method signature:

  @GET
  @Produces(MediaType.APPLICATION_JSON)
  public JSONObject getMessage(@QueryParam("id") int i, @Suspended
AsyncResponse async)

Prior to 3.1.7, this method could be invoked and would return a 200
response with a JSON message.  After the upgrade, the same request results
in a 405 response, and no warning message.

When I read the javadoc text for the @Suspended annotation (
http://docs.oracle.com/javaee/7/api/javax/ws/rs/container/Suspended.html ),
it makes me think that the method should be available (and requests should
still succeed), but that the return value of the method should be ignored.
I also think we should be logging a warning rather than a fine message.

Does that sound good?  If no objections, I'll plan to open a JIRA and
provide a patch.

Thanks, Andy

CXF-7070 mixed in with CXF-7075

[Andy McCright]

Sergey, All,

While waiting on the performance benchmark results for 7075, I thought I
would take a look at 7070.  I ended up committing changes to that under the
same pull request that is still open for 7075 - different commit, but same
PR.

I'm still coming up to speed on Git, so there is probably an easy way to
separate the different commits into different PRs, but I don't know how
offhand.  Do you know how to do this?  Since they are different commits
does it matter if it is in the same PR or not?  Sorry for the rookie
questions.

Thanks,

Andy

Re: Introduction

[Andy McCright]

> Sure, please do. FYI, in CXF 3.1.7 we have JAX-RS
MessageBodyReader/Writer cache supported something that Neal Hu and myself
worked upon. MediaType cache has also been implemented earlier (with thanks
to Alessio).

Interesting - that is where we have found the most success as well.  In
3.0.3 and 3.0.9, we found a lot of time was spent determining the
appropriate MBR/MBW for a given request/response.  I'll take a look at
those changes to see if they could be ported back to the the 3.0.X stream.

Rookie question, but what is the major difference between the 3.0.X stream
and 3.1.X stream?  Does 3.1.X require Java 8 (or higher)?

Thanks,
Andy

On Wed, Aug 17, 2016 at 10:48 AM, Sergey Beryozkin 
wrote:

> Hi Andy
>
> Welcome, thanks for the introductions, some comments below
> On 17/08/16 15:56, Andy McCright wrote:
>
>> Hi All,
>>
>> I wanted to introduce myself.  My name is Andy McCright and I'll be taking
>> over Iris Deng's role as IBM's advocate for CXF and JAX-RS.
>>
>
> Please pass our thanks to Iris, who is still a CXF committer :-)
>
> I'm planning
>> to join the JSR 370 expert group as well.
>>
>> Will be good, the group does need new people joining, we already have
> Alessio Soldano representing our friends from RedHat (RestEasy) there
> joining recently too.
>
> My background has been mainly in WebSphere development.  I've worked on few
>> different areas including the kernel/bootstrap/OSGi implementation, the
>> classloading mechanism, trace and logging, the EJB container, etc.  I've
>> taken over the JAX-RS role due to some recent reorganizations.
>>
>> So far, my only involvement with CXF has been internal to IBM.  We've been
>> tweaking a few things in our WebSphere Liberty implementation.  Our main
>> concern lately has been in the area of performance.  We've seen about a
>> 20%
>> degradation of performance when taking a very simple JAX-RS 1.1-compliant
>> app (running with the Apache Wink implementation) and running it on CXF
>> 3.0.3 - using Liberty's jaxrs-2.0 feature.  I know this is not an
>> "apples-to-apples" comparison, and I suspect that much of the difference
>> is
>> time spent on function specific to JAX-RS 2.0.  That said, we have also
>> seen another ~10% drop in performance from 3.0.3 to 3.0.9.
>>
>> I am hoping to contribute some performance fixes to the community in the
>> near future.  I am still pretty new to this code base, so I'll be asking
>> for some help with code reviews and suggestions, etc.
>>
>> Sure, please do. FYI, in CXF 3.1.7 we have JAX-RS
> MessageBodyReader/Writer cache supported something that Neal Hu and myself
> worked upon. MediaType cache has also been implemented earlier (with thanks
> to Alessio).
> I believe one of your colleagues opened an issue earlier related to a CXF
> Bus synchronization issue and said they'd evaluate a fix.
>
>
> Looking forward to working with you,
>>
>
> Looking forward to working with you too
>
> Sergey
>
>
>> Andy
>>
>>
>

Introduction

[Andy McCright]

Hi All,

I wanted to introduce myself.  My name is Andy McCright and I'll be taking
over Iris Deng's role as IBM's advocate for CXF and JAX-RS.  I'm planning
to join the JSR 370 expert group as well.

My background has been mainly in WebSphere development.  I've worked on few
different areas including the kernel/bootstrap/OSGi implementation, the
classloading mechanism, trace and logging, the EJB container, etc.  I've
taken over the JAX-RS role due to some recent reorganizations.

So far, my only involvement with CXF has been internal to IBM.  We've been
tweaking a few things in our WebSphere Liberty implementation.  Our main
concern lately has been in the area of performance.  We've seen about a 20%
degradation of performance when taking a very simple JAX-RS 1.1-compliant
app (running with the Apache Wink implementation) and running it on CXF
3.0.3 - using Liberty's jaxrs-2.0 feature.  I know this is not an
"apples-to-apples" comparison, and I suspect that much of the difference is
time spent on function specific to JAX-RS 2.0.  That said, we have also
seen another ~10% drop in performance from 3.0.3 to 3.0.9.

I am hoping to contribute some performance fixes to the community in the
near future.  I am still pretty new to this code base, so I'll be asking
for some help with code reviews and suggestions, etc.

Looking forward to working with you,

Andy