Re: [VOTE] Release CXF 4.0.5, 3.6.4 and 3.5.9

[Alessio Soldano]

+1
Thanks!

On Fri, Jul 12, 2024 at 10:23 PM Freeman Fang 
wrote:

> Hi,
>
> It’s been a while since the last releases and many issues have been
> addressed, so here is the VOTE for CXF 4.0.5, 3.6.4 and 3.5.9
>
> Staging areas:
> https://repository.apache.org/content/repositories/orgapachecxf-1203
> https://repository.apache.org/content/repositories/orgapachecxf-1204
> https://repository.apache.org/content/repositories/orgapachecxf-1205
>
> Tags:
>
> https://github.com/apache/cxf/commit/630d7368e073d379227d48ff4797c23377dc5ebf
>
> https://github.com/apache/cxf/commit/6b27aec74e5329b60e84ff2478c854bf2acf3db5
>
> https://github.com/apache/cxf/commit/8c68c138ce0b7f5c1945e744f7cf5067a8298374
>
> I will keep the vote open for at least 72 hours(weekends not included).
>
> Cheers
> Freeman
>

Re: [VOTE] Release CXF 4.0.4

[Alessio Soldano]

+1
Thanks!

On Tue, Mar 5, 2024 at 11:06 PM Freeman Fang  wrote:

> It’s been a while since the last release and many issues have been
> addressed, so here is the VOTE for CXF 4.0.4.
>
> Staging area:
> https://repository.apache.org/content/repositories/orgapachecxf-1196
>
>
> Tag:
>
> https://github.com/apache/cxf/commit/f88b9bf2bc5121a8b8ed0629ff7685c2b1b447a1
>
>
> Here is my +1.
>
> Best Regards
> Freeman
>

Re: Wildfly 31 and OpenAPI

[Alessio Soldano]

Hi Francesco,
I wonder if the problem could be related to the implementation of OpenAPI
available on the container (I see there was a minor update in between
WildFly 30 and 31). You might consider posting to
https://groups.google.com/g/wildfly or asking in
https://wildfly.zulipchat.com/

Cheers

On Wed, Mar 6, 2024 at 8:27 AM Francesco Chicchiriccò 
wrote:

> Hi there,
> I am lately finding a strange behavior with CXF 4.0 (tried all versions
> including the upcoming 4.0.4), OpenAPI and Wildfly 31.
>
> Essentially, it fails with NPE at [1], meaning that the call from [2] is
> returning with null paths property.
>
> Everything is instead working as expected with other containers as Tomcat
> 10 and Payara 6, but also Wildfly 30.
>
> Does this ring any bell?
>
> Regards.
>
> [1]
> https://github.com/apache/cxf/blob/main/rt/rs/description-openapi-v3/src/main/java/org/apache/cxf/jaxrs/openapi/OpenApiCustomizer.java#L120
> [2]
> https://github.com/apache/cxf/blob/main/rt/rs/description-openapi-v3/src/main/java/org/apache/cxf/jaxrs/openapi/OpenApiCustomizedResource.java#L77
>
> --
> 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/
>
>

-- 

Alessio Soldano

Manager, Software Engineering

Red Hat
<https://www.redhat.com>

Re: [VOTE] CXF 4.0.3/3.6.2/3.5.7

[Alessio Soldano]

+1, thanks!

On Wed, Sep 13, 2023 at 7:55 PM Daniel Kulp  wrote:

> It’s been three months since the last releases so definitely time to get
> more fixes out there.
>
> Staging areas:
> https://repository.apache.org/content/repositories/orgapachecxf-1192/
> https://repository.apache.org/content/repositories/orgapachecxf-1193/
> https://repository.apache.org/content/repositories/orgapachecxf-1194/
>
>
> Tags:
>
> https://github.com/apache/cxf/commit/4b3f0ec20cc77ff8b3c04fee44f1cb8ca525f331
>
> https://github.com/apache/cxf/commit/752fbd67181d7ae2bf68a632857e5c2f7c6dec6f
>
> https://github.com/apache/cxf/commit/4adb1dc8bbd08f0910c5daef628182fea436523d
>
>
> Here is my +1.
>
>
> --
> Daniel Kulp
> dk...@apache.org 
> Qlik - https://qlik.com 
>

Re: [VOTE] Apache CXF 3.6.1 and 4.0.2

[Alessio Soldano]

+1

Thanks

On Tue, Jun 6, 2023 at 8:17 PM Daniel Kulp  wrote:

>
> This is a vote to release Apache CXF 3.6.1 and 4.0.2.   Not a lot has
> changed in these versions, but they do contain critical bug fixes needed in
> order to upgrade Camel to the latest releases.
>
> Tags:
> https://github.com/apache/cxf/releases/tag/cxf-4.0.2
> https://github.com/apache/cxf/releases/tag/cxf-3.6.1
>
>
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachecxf-1191
> https://repository.apache.org/content/repositories/orgapachecxf-1190
>
>
> Here is my +1
>
> --
> Daniel Kulp
> dk...@apache.org 
> Talend - https://talend.com 
>
>

Re: [VOTE] CXF 3.5.6, 3.6.0, 4.0.1

[Alessio Soldano]

+1

Thanks

On Tue, May 2, 2023 at 11:12 PM Daniel Kulp  wrote:

>
> It’s been quite a while since the last round of releases and a bunch of
> work has been done, lots of bug fixes, a couple of new features, etc…
>
>
> Tags:
> https://github.com/apache/cxf/releases/tag/cxf-4.0.1 (
> https://github.com/apache/cxf/commit/ce00f5b861c4dd87b225ee761d4919aa49244b5f
> )
> https://github.com/apache/cxf/releases/tag/cxf-3.6.0 (
> https://github.com/apache/cxf/commit/4cf375c5436f3e806293a73a5bb6a8510f7ac961
> )
> https://github.com/apache/cxf/releases/tag/cxf-3.5.6 (
> https://github.com/apache/cxf/commit/eb7a2133a5974efc128a58ad4ed239385da3f5fc
> )
>
> Staging repos:
> https://repository.apache.org/content/repositories/orgapachecxf-1187
> https://repository.apache.org/content/repositories/orgapachecxf-1188
> https://repository.apache.org/content/repositories/orgapachecxf-1189
>
>
> Here is my +1
>
> --
> Daniel Kulp
> dk...@apache.org
> Talend - https://talend.com
>
>

Re: [RESULT] [VOTE] Apache CXF 4.0.0

[Alessio Soldano]

Thanks!!

On Wed, Feb 1, 2023 at 2:31 AM Andriy Redko  wrote:

> Hey guys,
>
> Sorry about that, I have updated the following pages [1], [2], [3], the
> website
> should be updated shortly. Please let me know if I've missed something.
>
> [1]
> https://cwiki.apache.org/confluence/display/CXF/CXF+4.0.0+Release+Notes
> [2] https://cwiki.apache.org/confluence/display/CXF/Index
> [3] https://cwiki.apache.org/confluence/display/CXF/Download
>
> Thanks for bringing it up!
>
> Best Regards,
> Andriy Redko
>
> AS> Folks,
> AS> it looks weird to see CXF 4 artifacts on Maven Central since Dec 22nd
> but
> AS> no announcement on the website. Am I missing anything here? Who is
> going to
> AS> work on the remaining steps? Jim or me can likely help if it's just a
> AS> matter of not having time for this ;-)
>
> AS> Cheers
>
> AS> On Fri, Jan 13, 2023 at 4:05 AM Andrey Redko  wrote:
>
> >> Hey Jim,
> >>
> >> Happy New Year! I think Dan mentioned he was going on vacation for a few
> >> weeks. I am not sure he is back, @Colm do you know by any chance?
> >>
> >> Thank you!
> >>
> >> Best Regards,
> >> Andriy Redko
> >>
> >> On Thu, Jan 12, 2023, 9:52 PM Jim Ma  wrote:
> >>
> >> > Happy new year, everyone !
> >> >
> >> > I see the CXF 4.0.0 release note isn't finalized :
> >> >  https://issues.apache.org/jira/projects/CXF/versions/12351115
> >> > ,
> >> > and we didn't announce this release in https://cxf.apache.org/
> >> > . Is anyone working on this ?
> >> >
> >> > Thanks,
> >> > Jim
> >> >
> >> > On Thu, Dec 22, 2022 at 9:20 PM Daniel Kulp  wrote:
> >> >
> >> > > With 9  +1 votes, this vote passes.
> >> > >
> >> > > Thanks!
> >> > > Dan
> >> > >
> >> > >
> >> > > > On Dec 18, 2022, at 10:26 AM, Daniel Kulp 
> wrote:
> >> > > >
> >> > > > This is a vote to release CXF 4.0.0.This is a major release
> that
> >> > > completely changes the API from using the older javax.* packages to
> >> using
> >> > > the jakarta.* versions.   It also updates everything to more modern
> >> > > dependencies (Jetty 11, Spring 6, etc…).   This also raises the
> minimum
> >> > JDK
> >> > > level to Java 11, but in some cases Java 17  is required (example:
> >> Spring
> >> > > 6/SpringBoot 3).
> >> > > >
> >> > > > Staging repo:
> >> > > >
> >> https://repository.apache.org/content/repositories/orgapachecxf-1185/
> >> > > >
> >> > > > Tag:
> >> > > >
> >> > >
> >> >
> >>
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=9914621a3d875d8d5371544b0e92b11a10cd2fd9
> >> > > >
> >> > > >
> >> > > >
> >> > > > This vote will be open for 72 hours.   Here is my +1.
> >> > > >
> >> > > > --
> >> > > > Daniel Kulp
> >> > > > dk...@apache.org
> >> > > > Talend - https://talend.com
> >> > > >
> >> > >
> >> > > --
> >> > > Daniel Kulp
> >> > > dk...@apache.org 
> >> > > Talend - https://talend.com 
> >> > >
> >> > >
> >> >
> >>
>
>

Re: [RESULT] [VOTE] Apache CXF 4.0.0

[Alessio Soldano]

Folks,
it looks weird to see CXF 4 artifacts on Maven Central since Dec 22nd but
no announcement on the website. Am I missing anything here? Who is going to
work on the remaining steps? Jim or me can likely help if it's just a
matter of not having time for this ;-)

Cheers

On Fri, Jan 13, 2023 at 4:05 AM Andrey Redko  wrote:

> Hey Jim,
>
> Happy New Year! I think Dan mentioned he was going on vacation for a few
> weeks. I am not sure he is back, @Colm do you know by any chance?
>
> Thank you!
>
> Best Regards,
> Andriy Redko
>
> On Thu, Jan 12, 2023, 9:52 PM Jim Ma  wrote:
>
> > Happy new year, everyone !
> >
> > I see the CXF 4.0.0 release note isn't finalized :
> >  https://issues.apache.org/jira/projects/CXF/versions/12351115
> > ,
> > and we didn't announce this release in https://cxf.apache.org/
> > . Is anyone working on this ?
> >
> > Thanks,
> > Jim
> >
> > On Thu, Dec 22, 2022 at 9:20 PM Daniel Kulp  wrote:
> >
> > > With 9  +1 votes, this vote passes.
> > >
> > > Thanks!
> > > Dan
> > >
> > >
> > > > On Dec 18, 2022, at 10:26 AM, Daniel Kulp  wrote:
> > > >
> > > > This is a vote to release CXF 4.0.0.This is a major release that
> > > completely changes the API from using the older javax.* packages to
> using
> > > the jakarta.* versions.   It also updates everything to more modern
> > > dependencies (Jetty 11, Spring 6, etc…).   This also raises the minimum
> > JDK
> > > level to Java 11, but in some cases Java 17  is required (example:
> Spring
> > > 6/SpringBoot 3).
> > > >
> > > > Staging repo:
> > > >
> https://repository.apache.org/content/repositories/orgapachecxf-1185/
> > > >
> > > > Tag:
> > > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=9914621a3d875d8d5371544b0e92b11a10cd2fd9
> > > >
> > > >
> > > >
> > > > This vote will be open for 72 hours.   Here is my +1.
> > > >
> > > > --
> > > > Daniel Kulp
> > > > dk...@apache.org
> > > > Talend - https://talend.com
> > > >
> > >
> > > --
> > > Daniel Kulp
> > > dk...@apache.org 
> > > Talend - https://talend.com 
> > >
> > >
> >
>

Re: [VOTE] Apache CXF 4.0.0

[Alessio Soldano]

+1

Thanks!

On Sun, Dec 18, 2022 at 4:35 PM Daniel Kulp  wrote:

> This is a vote to release CXF 4.0.0.This is a major release that
> completely changes the API from using the older javax.* packages to using
> the jakarta.* versions.   It also updates everything to more modern
> dependencies (Jetty 11, Spring 6, etc…).   This also raises the minimum JDK
> level to Java 11, but in some cases Java 17  is required (example: Spring
> 6/SpringBoot 3).
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapachecxf-1185/
>
> Tag:
>
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=9914621a3d875d8d5371544b0e92b11a10cd2fd9
>
>
>
> This vote will be open for 72 hours.   Here is my +1.
>
> --
> Daniel Kulp
> dk...@apache.org
> Talend - https://talend.com
>
>

Re: [VOTE] CXF 3.5.5 and 3.4.10

[Alessio Soldano]

+1
thanks

On Wed, Dec 7, 2022 at 10:30 PM Daniel Kulp  wrote:

>
> I was only able to get the 3.4 and 3.5 patch releases built today, but I’d
> like to go ahead and get the vote started for them.
>
>
> This is a vote to release the latest set of patched for CXF.
>
>
> Staging repositories:
> 3.5.5
> https://repository.apache.org/content/repositories/orgapachecxf-1183/
> 3.4.10
> https://repository.apache.org/content/repositories/orgapachecxf-1184/
>
>
> Tags:
> 3.5.5
>
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=cad47a4176229e22404f4c6ebdadfa561b33a021
> 3.4.10
>
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=d091e556d1a28580a7089bbb142700be015c89f4
>
>
> Here is my +1
>
> --
> Daniel Kulp
> dk...@apache.org 
> Talend - https://talend.com 
>
>

Re: CXF 4.0.0 jakarta release

[Alessio Soldano]

; > > > > catch up later like other dropped integrations and core should be
> > > > exploded
> > > > > anyway, it is way too fat for what it does so moving spring out of
> it
> > > is
> > > > > quite a good direction IMHO.
> > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > https://github.com/rmannibucau> |
> > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > > Le lun. 7 nov. 2022 à 18:06, Freeman Fang 
> a
> > > > écrit :
> > > >
> > > > >> +1 to release CXF 4.0.0. And +1 to release using JDK17 as baseline
> > > > since we
> > > > >> upgraded to Spring 6 and Spring Boot 3.
> > > >
> > > > >> Thanks to all guys involved in this long process!
> > > > >> Freeman
> > > > >> On Mon, Nov 7, 2022 at 11:10 AM Andriy Redko 
> > > wrote:
> > > > >>> +1 to move forward with release (or milestone), but before that,
> > > there
> > > > is
> > > > >>> one issue which
> > > > >>> I would like to bring up and agree us upon. The initial
> discussion
> > > for
> > > > >>> Jakarta / 4.0.0 [1] concluded
> > > > >>> on having JDK-11 as a baseline. At the same time, there is a
> > > > misalignment
> > > > >>> with Spring 6 / Spring Boot 3
> > > > >>> requirements which bumped the baseline to JDK-17. Now, the way we
> > > build
> > > > >>> Jakarta / 4.0.0 branch (main) is
> > > > >>> like this: use JDK-17+ but set target/source to JDK-11.
> > > >
> > > > >>> With that being said, the not so good part. Technically, Jakarta
> /
> > > > 4.0.0
> > > > >>> bits could be used in the
> > > > >>> projects which are still using JDK-11. But because mostly every
> > > single
> > > > >>> piece (starting from cxf-core) depends
> > > > >>> on Spring, the application fail to start with
> > > > >>> "java.lang.UnsupportedClassVersionError" (very easy to confirm
> > > > >>> on any CXF provided sample). Effectively, the baseline is JDK-17,
> > not
> > > > >>> JDK-11 (we have hoped to isolate Spring
> > > > >>> related implementation but it hasn't happened yet and not sure it
> > > will
> > > > in
> > > > >>> the future). The question: does
> > > > >>> anyone have a compelling usecase for keeping CXF baseline at
> JDK-11
> > > > level
> > > > >>> despite being able to run only
> > > > >>> on JDK-17 or above? If yes, I think we have to make all Spring
> > > related
> > > > >>> dependencies optional and document
> > > > >>> clearly that JDK-17 is needed in case Spring / Spring Boot are
> > used,
> > > we
> > > > >>> surely cannot leave things
> > > > >>> as-is (in my opinion). If not, I would suggest to set JDK-17 as a
> > > > >>> baseline.
> > > > >>> What do you guys think?
> > > > >>> Thank you.
> > > > >>> [1]
> https://www.mail-archive.com/dev@cxf.apache.org/msg17031.html
> > > > >>> Best Regards,
> > > > >>> Andriy Redko
> > > > >>> Monday, November 7, 2022, 8:50:02 AM, you wrote:
> > > > RMB>>>> +1 to release, there are too much forks out there already so
> > > better
> > > > >> to
> > > > RMB>>>> release partially than not release at all IMHO
> > > > RMB>>>> Romain Manni-Bucau
> > > > RMB>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > RMB>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> > > > RMB>>>> <http://rmannibucau.wordpress.com> | Github <
> > > > >>> https://github.com/rmannibucau> |
> > > > RMB>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > RMB>>>> <
> > > > >>
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > RMB>>>> Le lun. 7 nov. 2022 à 14:25, Misagh <
> misagh.moay...@gmail.com>
> > a
> > > > >>> écrit :
> > > > >>>>> Hello all,
> > > >
> > > > >>>>> If possible, I'd like to ask that you allow v4 to ship with a
> new
> > > > >>>>> release of wss4j that would contain this change:
> > > > >>>>> https://github.com/apache/ws-wss4j/pull/62
> > > > >>>>> At the moment, OpenSAML v5 is not released yet, but it is
> > > anticipated
> > > > >>>>> to be GA before end of this year, hopefully.
> > > > >>>>> On Mon, Nov 7, 2022 at 12:19 PM Jim Ma 
> > > wrote:
> > > > >>>>>> Hi all,
> > > > >>>>>> After 9 months of work, we finally fixed/worked around all
> > issues
> > > > >> for
> > > > >>>>>> Jakarta support. Now all the cxf tests are passed:
> > > > >>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and
> we
> > > can
> > > > >>> say
> > > > >>>>> that
> > > > >>>>>> CXF successfully migrated to Jakarta namespace(and support
> > Jakarta
> > > >
> > > > >>>>> EE9.1).
> > > > >>>>>> To get cxf jakarta artifacts/binary available for the CXF
> > > community
> > > > >>>>>> especially the user who asked for this jakarta artifacts like
> > [1]
> > > > >> and
> > > > >>>>> get
> > > > >>>>>> more feedback from our community, do you think it's time to
> > > release
> > > > >>> the
> > > > >>>>> CXF
> > > > >>>>>> 4.0.0 and what else do you think we should have in this new
> > > jakarta
> > > >
> > > > >>>>> release
> > > > >>>>>> ?
> > > > >>>>>> [1]
> > > https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
> > > > >>>>>> Thanks,
> > > > >>>>>> Jim
> > > >
> > > >
> > >
> >
>


-- 

Alessio Soldano

Manager, Software Engineering

Red Hat <https://www.redhat.com>
<https://www.redhat.com>

Re: [VOTE] - Move Apache CXF DOSGi to the attic

[Alessio Soldano]

+1

Thanks

On Tue, Nov 8, 2022 at 3:59 PM Colm O hEigeartaigh 
wrote:

> This is a vote to move Apache CXF DOSGi to the attic. There is very
> little activity for many years now (last commit 2.5 years ago -
> https://github.com/apache/cxf-dosgi/commits/main).
>
> Previous discussion thread:
> https://lists.apache.org/thread/tjq9058n161p7fk8137nonwlfqvm9gys
>
> +1 from me.
>
> Colm.
>
>

Re: [DISCUSS] - Retire CXF DOSGI?

[Alessio Soldano]

I agree, especially considering the Jakarta aspect.

Thanks

On Wed, Oct 19, 2022 at 2:29 AM Andriy Redko  wrote:

> Hi Colm,
>
> I have never seen it used in the wild (at least, the projects I was/am
> involved with), I think it would make sense to retire it, especially taking
> into account the OSGi vague plans to support Jakarta. +1 from my side to
> move it to the attic. Thank you.
>
> Best Regards,
> Andriy Redko
>
>
> COh> Hi all,
>
> COh> What do you think about moving CXF DOSGI to the attic? There is very
> COh> little activity for many years now (last commit 2.5 years ago -
> COh> https://github.com/apache/cxf-dosgi/commits/main). It's just a
> COh> maintenance burden unless someone steps up to maintain it properly.
>
> COh> Colm.
>
>

Re: [VOTE] Apache CXF 3.4.9 and 3.5.4

[Alessio Soldano]

+1, thanks

On Mon, Oct 3, 2022 at 8:14 PM Daniel Kulp  wrote:

>
>
> This is a vote to release the latest set of patched for CXF.
>
>
> Staging repository: (I forgot to close the repo between builds so only a
> single staging repository that has both versions)
> https://repository.apache.org/content/repositories/orgapachecxf-1182/
>
>
> Tags:
>
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=0f3e02bf6a402c76c2fb66469df53b583e0fc9a4
>
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=1a49835461a0b4f56d53ad513a7665a72025c736
>
>
> Here is my +1
>
>
> --
> Daniel Kulp
> dk...@apache.org
> Talend - https://talend.com
>
>

Re: [VOTE] Apache CXF 3.5.3 and 3.4.8

[Alessio Soldano]

+1
Thanks

On Monday, June 27, 2022, Jim Ma  wrote:
> +1
>
> On Sat, Jun 25, 2022 at 12:18 AM Daniel Kulp  wrote:
>
>>
>>
>> This is a vote to release the latest set of patches for CXF.
>>
>>
>> Staging repositories:
>> https://repository.apache.org/content/repositories/orgapachecxf-1180/ <
>> https://repository.apache.org/content/repositories/orgapachecxf-1180/>
>> https://repository.apache.org/content/repositories/orgapachecxf-1181/ <
>> https://repository.apache.org/content/repositories/orgapachecxf-1181/>
>>
>> Tags:
>>
>>
https://gitbox.apache.org/repos/asf?p=cxf.git;a=commit;h=92217a0227bf6b7ef49ba4b68562232ec233d6fa
>>
>>
https://gitbox.apache.org/repos/asf?p=cxf.git;a=commit;h=6eb860c25b5728b64dc70f522d69ee34190be882
>>
>> Here is my +1
>>
>>
>> --
>> Daniel Kulp
>> dk...@apache.org 
>> Talend - https://talend.com 
>>
>>
>

Re: [VOTE] - Release Apache CXF XJC 4.0.0

[Alessio Soldano]

+1

On Friday, May 27, 2022, Colm O hEigeartaigh  wrote:
> This is a vote to release Apache CXF XJC 4.0.0. This is a major new
> release with support for the jakarta namespace.
>
> Issues fixed:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315520&version=12351197
> Git tag: https://github.com/apache/cxf-xjc-utils/tree/xjc-utils-4.0.0
> Artifacts:
https://repository.apache.org/content/repositories/orgapachecxf-1179/
>
> +1 from me.
>
> Colm.
>
>

-- 

Alessio Soldano

Manager, Software Engineering

Red Hat <https://www.redhat.com>
<https://www.redhat.com>

Re: [VOTE] - Release Apache CXF Build Utils 4.0.0

[Alessio Soldano]

+1, thanks!

On Mon, May 23, 2022 at 9:59 AM Colm O hEigeartaigh 
wrote:

> This is a vote to release Apache CXF Build Utils 4.0.0. It contains a
> security fix to disable DocTypes during XML parsing and an update to
> Java 11, with some other minor fixes.
>
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecxf-1178/
> Git tag:
> https://github.com/apache/cxf-build-utils/commits/cxf-build-utils-4.0.0
>
> +1 from me.
>
> Colm.
>
>

Re: [VOTE] Apache CXF 3.5.0

[Alessio Soldano]

+1

Thanks

On Thu, Dec 16, 2021 at 9:11 PM Daniel Kulp  wrote:

>
> This is a vote to release Apache CXF 3.5.0. 3.5.0 is a major release
> with a bunch of updates that could potentially have user impacts.   See the
> migration guide at:
>
> https://cxf.apache.org/docs/35-migration-guide.html
>
>
> Tag:
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=refs/tags/cxf-3.5.0
>  >
>
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapachecxf-1170/
>
>
> 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.3 and 3.3.10

[Alessio Soldano]

+1
Thanks!

On Mon, Mar 15, 2021 at 10:06 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: [VOTE] Apache CXF 3.4.1 and 3.3.8

[Alessio Soldano]

+1, thanks!

On Tue, Nov 3, 2020 at 10:35 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

[Alessio Soldano]

+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] Apache CXF 3.2.11

[Alessio Soldano]

+1
Thanks

On Thu, Oct 24, 2019 at 5:34 PM 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 <mailto:dk...@apache.org> - http://dankulp.com/blog <
> http://dankulp.com/blog>
> Talend Community Coder - http://talend.com <http://coders.talend.com/>
>


-- 

Alessio Soldano

Associate Manager, Software Engineering

Red Hat <https://www.redhat.com>
<https://www.redhat.com>

Re: [VOTE] Apache CXF 3.3.4

[Alessio Soldano]

+1, thanks!

On Wed, Oct 23, 2019 at 11:28 AM Jim Ma  wrote:

> +1
>
>
>
> On Tue, Oct 22, 2019 at 10:57 PM Jeff Genender 
> wrote:
>
> > +1
> >
> > Jeff
> >
> > > On Oct 21, 2019, at 1:19 PM, 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
> > <
> >
> https://gitbox.apache.org/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: [VOTE] CXF 3.2.10, CXF 3.3.3, and buildutils 3.4.3

[Alessio Soldano]

+1

Thanks

On Thu, Aug 8, 2019 at 7:10 PM Daniel Kulp  wrote:

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

Re: [VOTE] CXF 3.3.1

[Alessio Soldano]

+1

Thanks

On Thursday, February 28, 2019, Daniel Kulp  wrote:

> 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/ <
> 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 <mailto:dk...@apache.org> - http://dankulp.com/blog <
> http://dankulp.com/blog>
> Talend Community Coder - http://talend.com <http://coders.talend.com/>
>


-- 

Alessio Soldano

Associate Manager, Software Engineering

Red Hat

<https://www.redhat.com>
<https://red.ht/sig>

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

[Alessio Soldano]

Late +1 to the release, just for the records (sorry about it).

Cheers

On Thu, Jan 24, 2019 at 10:33 PM Daniel Kulp  wrote:

> 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: [VOTE] CXF 3.2.7 and xic-utils 3.2.3

[Alessio Soldano]

+1
Thanks!

On Wed, Oct 24, 2018 at 9: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

[Alessio Soldano]

+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

[Alessio Soldano]

+1

On Thu, Aug 9, 2018 at 2:39 PM, Andy McCright 
wrote:

> +1
>
> Thanks!
>
> Andy
>
> On Thu, Aug 9, 2018 at 3:23 AM Christian Schneider <
> ch...@die-schneider.net>
> 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 <mailto:dk...@apache.org> - http://dankulp.com/blog <
> > > http://dankulp.com/blog>
> > > Talend Community Coder - http://talend.com <http://coders.talend.com/>
> > >
> >
> >
> > --
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Computer Scientist
> > http://www.adobe.com
> >
>



-- 

Alessio Soldano

Associate Manager

Red Hat

<https://www.redhat.com>
<https://red.ht/sig>

Re: [VOTE] CXF 3.2.5/3.1.16

[Alessio Soldano]

+1
Thanks!

On Tue, Jun 19, 2018 at 1:35 AM, 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  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  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  repos/asf?p=cxf-build-utils.git;a=tag;h=33533c136d2a11becdf06f21ed5f3e
> cc58bfdeda>
> Xjc-utils:
> https://gitbox.apache.org/repos/asf?p=cxf-xjc-utils.git;a=tag;h=
> 940e30464842b68edfc7be79861508c39f7111e9  repos/asf?p=cxf-xjc-utils.git;a=tag;h=940e30464842b68edfc7be79861508
> c39f7111e9>
>
>
> 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: Plans for next 3.1.x/3.2.y release?

[Alessio Soldano]

Yep, I'm aware of the need for releasing both Santuario and WSS4J, I was
not expecting much less than that ;-)

Thanks
Alessio

On Mon, May 14, 2018 at 5:43 PM, Colm O hEigeartaigh 
wrote:

> Would 2+ weeks time work? I have a few issues to finish off in Santuario,
> and then I need to release that and then WSS4J (before we release CXF
> 3.2.x).
>
> Colm.
>
> On Mon, May 14, 2018 at 4:13 PM, Alessio Soldano 
> wrote:
>
> > Hi,
> > is there any plan regarding next 3.1.x/3.2.y releases? I'd like to see
> some
> > the issues fixed in them available in a release ;-)
> > Current status on jira:
> > * 3.2.5 https://issues.apache.org/jira/projects/CXF/versions/12342985
> > * 3.1.16 https://issues.apache.org/jira/projects/CXF/versions/12342902
> >
> > Cheers
> > Alessio
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>

Plans for next 3.1.x/3.2.y release?

[Alessio Soldano]

Hi,
is there any plan regarding next 3.1.x/3.2.y releases? I'd like to see some
the issues fixed in them available in a release ;-)
Current status on jira:
* 3.2.5 https://issues.apache.org/jira/projects/CXF/versions/12342985
* 3.1.16 https://issues.apache.org/jira/projects/CXF/versions/12342902

Cheers
Alessio

Re: 10 years of CXF - Happy Birthday!

[Alessio Soldano]

Good words Dan, I agree CXF has been and still is a very successful
project, proud of being one of its contributor!
Thanks for your leadership and commitment to it btw.
Cheers
Alessio

On Tue, Apr 17, 2018 at 3:03 AM, Daniel Kulp  wrote:

> Happy Birthday!
>
> While working on the board report, I noticed the 10 year thing and started
> looking back at the last 10 years.   I put some thoughts on my blog:
> http://www.dankulp.com/blog/2018/04/10-years-of-apache-cxf/
>
> Some additional thoughts:
>
> * The original board resolution had a PMC of 20 folks.   Of those 20, 6
> are still actively participating in the project either by code changes or
> release reviews or similar.   For an open source project where people are
> expected to come and go, that’s awesome.   We’ve obviously picked up a lot
> of new folks along the way, so there is both an element of “new” and bit of
> the “old”.   (I admit, I’m one of the “old”)
>
> * According to the reporter tool, we have done 210 releases.   8 were done
> prior to graduation.  Thus we have done over 200 releases over 10 years.
>  That includes the Fediz and DOSGi releases, but it’s still an incredible
> number.   20 releases a year.   That’s a great job in pushing new features
> out AND supporting our users.
>
> * According to GitHub, we have had contributions from 90 people.  That
> doesn’t include the patches attached to JIRA’s that were applied by
> committers.   Still, a very good number.
>
> * Speaking of JIRA, we have closed/resolved over 95% of the 7900 issues
> filed.   That’s impressive and once again shows how well we support our
> users.
>
> Anyway, it’s been an exciting 10 years.   I look forward to what the
> future brings for CXF!
>
> Dan
>
>
>
> > On Apr 16, 2018, at 2:15 PM, Dennis Kieselhorst  wrote:
> >
> > Hi,
> >
> > it's time to celebrate: 10 years ago, on April 16th in the year 2008,
> > CXF graduated from the Apache incubator as a merge of the Objectweb
> > Celtix project and the Codehaus XFire project (see
> > http://incubator.apache.org/projects/cxf.html for more details).
> >
> > Today we have lots of more features, support for additional
> > specifications and a large user base.
> >
> > Thanks to anyone who made this possible and looking forward to another
> > 10 years :-)
> >
> > Cheers
> > Dennis
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

Re: [VOTE] CXF 2.3.4

[Alessio Soldano]

+1

Thanks

On Fri, Mar 23, 2018 at 1:31 PM, Colm O hEigeartaigh 
wrote:

> +1.
>
> Colm.
>
> On Fri, Mar 23, 2018 at 7:35 AM, Romain Manni-Bucau  >
> wrote:
>
> > +1, thanks Dan (and I confirm the cdi fix is in and works)
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github  > rmannibucau> |
> > LinkedIn  | Book
> >  > ee-8-high-performance>
> >
> > 2018-03-23 8:24 GMT+01:00 Francesco Chicchiriccò :
> >
> > > On 22/03/2018 22:18, 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=ad8b05
> > >> 6676799c92d4d81e9c006c5711be35d62c
> > >>
> > >
> > > +1
> > > Thanks
> > >
> > > --
> > > 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/
> > >
> > >
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>

Re: [VOTE] Apache CXF 3.2.3

[Alessio Soldano]

+1

Thanks

On Mon, Mar 19, 2018 at 8:47 AM, Francesco Chicchiriccò  wrote:

> On 16/03/2018 21:54, Daniel Kulp wrote:
>
>> 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=b82
>> 303bfb6802817d3ce3be1ce30df74fee50675
>>
>
>
> +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: [VOTE] - Release Apache CXF 3.1.15

[Alessio Soldano]

+1

Thanks

On Fri, Mar 9, 2018 at 3:05 AM, François Papon  wrote:

> +1 (non-binding)
>
> Thanks !
>
> François
>
> Le 8 mars 2018 6:19 PM, Colm O hEigeartaigh  a écrit
> :
> >
> > 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 from me.
> >
> > Colm.
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
>

Re: [VOTE] CXF 3.2.2

[Alessio Soldano]

+1

Thanks
Alessio

On Fri, Feb 2, 2018 at 8: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: [VOTE] - Release Apache CXF 3.0.16

[Alessio Soldano]

+1

On Thu, Nov 23, 2017 at 8:59 PM, Dennis Kieselhorst  wrote:

> +1
>

Re: [VOTE] Apache CXF 3.2.1 and 3.1.14 patch releases...

[Alessio Soldano]

+1

Alessio

On Fri, Nov 3, 2017 at 2:10 AM, Daniel Kulp  wrote:

> It’s been almost 2 months since the last release.   We’ve fixed over 30
> JIRA’s for 3.2.
>
> Staging repos:
> 3.1.14:
> https://repository.apache.org/content/repositories/orgapachecxf-1107
> 3.2.1:
> https://repository.apache.org/content/repositories/orgapachecxf-1107
>
> Tags:
> 3.1.14:
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=
> 624a5af44fb14787f6f4b241258d01ebb8da8e49
> 3.2.1:
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=
> fdc5c55d054753f429d77e742390bcda895225f7
>
>
>
> 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] CXF build utils 3.3.0 and xjc-utils 3.2.0

[Alessio Soldano]

+1

Cheers
Alessio

On Thu, Aug 17, 2017 at 9:48 PM, Christian Schneider <
ch...@die-schneider.net> wrote:

> +1
>
> Christian
>
> 2017-08-17 19:45 GMT+02:00 Daniel Kulp :
>
> >
> > This is a vote to release new versions of CXF’s builtutils and xjc-utils
> > sub-projects in preparation for the upcoming 3.2 release.
> >
> > The buildutils project was updated with new PMD and check style rules to
> > match the new versions of check style and pmd that are used for 3.2 and
> are
> > part of the latest eclipse plugins.   Also, the supplements file has been
> > updated with the latest stuff it needs.
> >
> > xjc-utils has been update for Java8.  It also fixes a bunch of bugs in
> the
> > DV plugin that were found while updating CXF 3.2.
> >
> >
> > Tags:
> > https://git-wip-us.apache.org/repos/asf?p=cxf-build-utils.git;a=tag;h=
> > d40d8e27589dad1489dd4c01266735b7656c964a
> > https://git-wip-us.apache.org/repos/asf?p=cxf-xjc-utils.git;a=tag;h=
> > cbec5eeb17a5d3a712a8a8387c5f434326a6d4ec
> >
> > Staging areas:
> > https://repository.apache.org/content/repositories/orgapachecxf-1098/
> > https://repository.apache.org/content/repositories/orgapachecxf-1099/
> >
> >
> > Here is my +1.
> >
> > --
> > Daniel Kulp
> > dk...@apache.org - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> >
> >
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>  46&URL=http%3a%2f%2fwww.liquid-reality.de>
>
> Open Source Architect
> http://www.talend.com
>  46&URL=http%3a%2f%2fwww.talend.com>
>

Re: CXF 3.2?

[Alessio Soldano]

Fine with me, thanks :-)

On Thu, Aug 10, 2017 at 6:22 PM, Daniel Kulp  wrote:

>
> It’s been over two years since 3.1.0 was released which is a long time.
> I’d like to get 3.2.0 out shortly.   Looking through things, the major
> outstanding things are snapshots of a couple deps (xjc-utils,build-utils,
> wss4j) and updates to the JAX-RS stuff to use the released 2.1.   What else
> do folks have outstanding that would be “needed” to get into 3.2?Would
> Sept 1st be a good target for getting 3.2 built?   That would give use a
> few weeks to finish things up and get the releases out.
>
> Thoughts?
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

Re: commons-lang3

[Alessio Soldano]

I've actually just merged the PR, the only 2 failures I got on Jenkins did
not look related.
Cheers
Alessio

On Fri, Aug 4, 2017 at 11:42 PM, Alessio Soldano 
wrote:

> Yes, afaics velocity is only used in tooling.
> Anyway, now 2.0 is released, so I've rebased the PR so that it can be
> possibly merged. If there's any comment / feedback... just tell.
> Cheers
> Alessio
>
> On Wed, Jun 14, 2017 at 6:39 PM, Daniel Kulp  wrote:
>
>>
>> I believe the only use of velocity is in the tooling, right?
>>
>> In any case, I don’t think velocity 2.0 is actually released.   I’ve
>> checked their dev list and there have been some votes for various “RC”’s,
>> but no final vote for 2.0 or anything (and no announcements or anything).
>>  Thus, it’s definitely not something I’d rely on for us at this point.
>> Maybe file a JIRA with them to get them to finish the release and get the
>> artifacts to central.
>>
>> Dan
>>
>>
>>
>> > On Jun 13, 2017, at 7:30 AM, Alessio Soldano 
>> wrote:
>> >
>> > Il 26/05/2017 20:33, Dennis Kieselhorst ha scritto:
>> >> Hi Alessio!
>> >>
>> >>> What do you think about us trying to upgrade to recently released
>> >>> velocity 2.0 in master, before releasing 3.2.0, so that we can have
>> only
>> >>> commons-lang3 dependency ?
>> >> +1 but it's not published to central yet, is it?
>> > It's not, I've built it from the 2.0 tag locally.
>> >
>> > I've created a jira for this [1] and provided an initial PR [2].
>> > Anybody, please review if you have some time :-)
>> > Thanks
>> > Alessio
>> >
>> > [1] https://issues.apache.org/jira/browse/CXF-7405
>> > [2] https://github.com/apache/cxf/pull/282
>>
>> --
>> Daniel Kulp
>> dk...@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>
>

Re: commons-lang3

[Alessio Soldano]

Yes, afaics velocity is only used in tooling.
Anyway, now 2.0 is released, so I've rebased the PR so that it can be
possibly merged. If there's any comment / feedback... just tell.
Cheers
Alessio

On Wed, Jun 14, 2017 at 6:39 PM, Daniel Kulp  wrote:

>
> I believe the only use of velocity is in the tooling, right?
>
> In any case, I don’t think velocity 2.0 is actually released.   I’ve
> checked their dev list and there have been some votes for various “RC”’s,
> but no final vote for 2.0 or anything (and no announcements or anything).
>  Thus, it’s definitely not something I’d rely on for us at this point.
> Maybe file a JIRA with them to get them to finish the release and get the
> artifacts to central.
>
> Dan
>
>
>
> > On Jun 13, 2017, at 7:30 AM, Alessio Soldano 
> wrote:
> >
> > Il 26/05/2017 20:33, Dennis Kieselhorst ha scritto:
> >> Hi Alessio!
> >>
> >>> What do you think about us trying to upgrade to recently released
> >>> velocity 2.0 in master, before releasing 3.2.0, so that we can have
> only
> >>> commons-lang3 dependency ?
> >> +1 but it's not published to central yet, is it?
> > It's not, I've built it from the 2.0 tag locally.
> >
> > I've created a jira for this [1] and provided an initial PR [2].
> > Anybody, please review if you have some time :-)
> > Thanks
> > Alessio
> >
> > [1] https://issues.apache.org/jira/browse/CXF-7405
> > [2] https://github.com/apache/cxf/pull/282
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

Re: [VOTE] Apache CXF 3.1.12 and 3.0.14

[Alessio Soldano]

+1

Cheers
Alessio

Il 27/06/2017 00:23, Daniel Kulp ha scritto:

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=a74c456018afc62d273cb8cb0a459fec5b12d265
3.1.12:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=6b41994254531a6ea6b2451277063c71ecfac320

Here is my +1.   Vote will be open for at least 72h.

Re: commons-lang3

[Alessio Soldano]

Il 26/05/2017 20:33, Dennis Kieselhorst ha scritto:

Hi Alessio!


What do you think about us trying to upgrade to recently released
velocity 2.0 in master, before releasing 3.2.0, so that we can have only
commons-lang3 dependency ?

+1 but it's not published to central yet, is it?

It's not, I've built it from the 2.0 tag locally.

I've created a jira for this [1] and provided an initial PR [2].
Anybody, please review if you have some time :-)
Thanks
Alessio

[1] https://issues.apache.org/jira/browse/CXF-7405
[2] https://github.com/apache/cxf/pull/282

commons-lang3

[Alessio Soldano]

Hi,

I've noticed that on master we don't explicitly set a dependency to 
common-lang, we just have commons-lang3 there: 
https://github.com/apache/cxf/blob/master/parent/pom.xml#L83


That goes with cxf xjc 3.1.0 actually requiring commons-lang3. Now, 
unfortunately, it seems that old commons-lang is still transitively 
pulled through velocity 1.7.


What do you think about us trying to upgrade to recently released 
velocity 2.0 in master, before releasing 3.2.0, so that we can have only 
commons-lang3 dependency ?


Cheers

Alessio

Re: [VOTE] Apache CXF 3.1.11 and 3.0.13

[Alessio Soldano]

+1

Cheers
Alessio

Il 06/04/2017 01:43, Daniel Kulp ha scritto:

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.

Re: [VOTE] Apache CXF 3.1.10

[Alessio Soldano]

+1

Thanks

Il 27/01/2017 20:28, Daniel Kulp ha scritto:

This is a vote for Apache CXF 3.1.10.   We’ve fixed a bunch of issues and I’d 
like to get it out so we can start trying to concentrate on getting 3.2 out.

Staging area:
https://repository.apache.org/content/repositories/orgapachecxf-1085/

Tag:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=59f79f3cfca1beb6e8f3a3a3f60f7d1d62eb8422

Vote will be open for 72h.

Here is my +1.

Re: [DISCUSS] Add promotion for Apache events on website

[Alessio Soldano]

Fine with me :)

Il 26/01/2017 09:58, Christian Schneider ha scritto:
On the apache member list there is the request to help promoting the 
next Apachecon.


The proposal is to add the snippet below our web site. This allows the 
foundation to promote the current event.

I would like to help with this effort. Any opinions?

Christian

---

http://www.apache.org/events/current-event.html";>
http://www.apache.org/events/current-event-{size}.png"/>


where {size} = 125x125 or 234x60

Maintenance of current-event* files:
- update text in content/events/current-event.mdtext
- replace content/events/current-event-*.png files with the new 
versions from content/ads/ApacheCon


See also content/ads/README.txt

Re: Removing some old modules in 3.2.0-SNAPSHOT

[Alessio Soldano]

Il 23/12/2016 17:03, Sergey Beryozkin ha scritto:
OK, these 5 modules (jibx, xmlbeans, sdo, binding/object, 
rt-management-web - the best but never used logging system for the 
endpoints :-),  +2 systest jibx modules) have gone, -7 in total.


Not too many but it is a start.

I was hesitating for few mins about removing a databindins-xmlbeans, 
but then I reminded myself we can put it back if needed. I removed a 
JAX-RS Xmlbeans provider extension awhile back, and with JAXB and 
Aegis providing probably a 100% coverage for SOAP XML with no Xmlbeans 
queries at all we are likely safe here.


Dan, others, ping me please if you'd like some of these removed 
modules return to the 3.2.0 starting line, happy enough for the moment 
we have decreased a total number of modules by -7 :-)

Thanks :-)

Cheers
Alessio

Re: [VOTE] CXF 3.1.9 and 3.0.12

[Alessio Soldano]

+1

Thanks

Il 09/12/2016 21:47, Daniel Kulp ha scritto:

Since there are several folks waiting for this release and it would be good to 
get it out before the holidays, I’d like to call a vote for CXF 3.1.9 and 
3.0.12.

Staging areas:
3.1.9:
https://repository.apache.org/content/repositories/orgapachecxf-1083/
3.0.12:
https://repository.apache.org/content/repositories/orgapachecxf-1082/

Tags:
3.0.12:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=commit;h=c98cb3181ae1153c37240a851aefe8e4f3a40ae9
3.1.9:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=commit;h=7cd4d49a7fe7d24a715192112a2170bdd708e6c7


Vote will be open for 72h.

Here is my +1.

Re: [VOTE] CXF 3.0.11/3.1.8

[Alessio Soldano]

+1

Thanks!
Alessio

Il 14/10/2016 20:59, Daniel Kulp ha scritto:

This is a vote to release 3.0.11/3.1.8.   We’ve resolved over 55 issues for 
3.1.8.

Staging areas:
3.1.8:
https://repository.apache.org/content/repositories/orgapachecxf-1081/
3.0.11:
https://repository.apache.org/content/repositories/orgapachecxf-1080/


Tags:
3.1.8:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=80473c6a929cd797d5b0b0134f31818a716011e8
3.0.11:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=209f5f9d04b2b49e05c4894034a719eea40bd0e4

Here is my +1

Re: Concurrency issue with EHCacheTokenStore

[Alessio Soldano]

ok, no failures during the weekend testsuite runs.
Ive created https://issues.apache.org/jira/browse/WSS-587 and here is 
the patch I've tried 
https://github.com/asoldano/wss4j/commit/5a7897f7440940a11c0c853fbb8fb26c644fa898.diff 
.

Colm, if that's fine with you I can go ahead and commit and/or send a PR.

Cheers
Alessio

Il 16/09/2016 22:41, Alessio Soldano ha scritto:
OK, I have a patched wss4j 2.1.8-asoldano-SNAPSHOT on the snapshot 
repository and I'm letting the CI server here run with it for few 
days. Let's see if the failures pop up or not...


Cheers
Alessio

Il 15/09/2016 11:20, Alessio Soldano ha scritto:
mmh... I need to build a patched wss4j snapshot and have it consumed 
by the remote machine that is reproducing the issue a bit more 
frequently (locally it's very rare). Will let you know :-)


Il 15/09/2016 10:35, Colm O hEigeartaigh ha scritto:

Hi Alessio,

Yes, that makes sense to me. If you perform the fix locally, do the
intermittent failures go away?

Colm.

On Wed, Sep 14, 2016 at 9:55 PM, Alessio Soldano 
wrote:


Hi,

I'm currently seeing an intermittent issue in the JBossWS-CXF 
testsuite

(stacktrace at https://paste.fedoraproject.org/428145/14738847/raw/ ),
with the EHCacheTokenStore creation failing due to the CacheManager 
having
been shutdown. The testsuite includes multiple tests, almost all of 
them
create jaxws clients and in most of them the current thread bus is 
used
(few of them do create a new bus, set it as default thread bus, run 
and
eventually shutdown the bus). What I suspect is some kind of 
concurrency

issue in the CacheManager lifecycle management.

I've looked a bit at the code and noticed that there's basically a 1-1
relationship between Bus instances and CacheManager instances. 
Given I have
some tests that do not explicitly shutdown the bus (or the client) 
after
execution, it can happen that a client is closed because the JDK 
eventually
finalize ClientProxy, which in the end causes the 
CacheCleanupListener to
close the token store and hence to release/shutdown the cache 
manager (see

the invocation flow at https://paste.fedoraproject.or
g/428150/47388530/raw/ ). Unfortunately that exact cache manager could
possibly be in use to serve another client running in the same bus. 
AFAICS,

there's an attempt to avoid problems like this in WSS4J's
EHCacheManagerHolder (which deals with CXF requests of 
creating/releasing

cache managers), as it has a ConcurrentHashMap
attribute to keep track of how many consumers of a given cache 
manager are
there and avoid shutting down a manager if it's still in use. 
Looking at
its getCacheManager and releaseCacheManager methods I can see a 
possible

concurrency flaw which could be the root of my failure. The
releaseCacheManager method could be called with cacheManager X as 
parameter
while a different thread is running getCacheManager and is just 
before line
106 (that is just before the AtomicInteger is got from the map) 
with local
cacheManager variable already resolved to X. That should later deal 
to an
attempt to use an already shutdown cache manager. I would be 
tempted to
suggest making those two methods syncronized (the map could then 
probably

be a plain hash map).

WDYT? I might be missing something, so posting here before opening 
up a

jira. Any idea?

Cheers

Alessio


--
Alessio Soldano
Web Service Lead, JBoss













--
Alessio Soldano
Web Service Lead, JBoss

Re: Concurrency issue with EHCacheTokenStore

[Alessio Soldano]

OK, I have a patched wss4j 2.1.8-asoldano-SNAPSHOT on the snapshot 
repository and I'm letting the CI server here run with it for few days. 
Let's see if the failures pop up or not...


Cheers
Alessio

Il 15/09/2016 11:20, Alessio Soldano ha scritto:
mmh... I need to build a patched wss4j snapshot and have it consumed 
by the remote machine that is reproducing the issue a bit more 
frequently (locally it's very rare). Will let you know :-)


Il 15/09/2016 10:35, Colm O hEigeartaigh ha scritto:

Hi Alessio,

Yes, that makes sense to me. If you perform the fix locally, do the
intermittent failures go away?

Colm.

On Wed, Sep 14, 2016 at 9:55 PM, Alessio Soldano 
wrote:


Hi,

I'm currently seeing an intermittent issue in the JBossWS-CXF testsuite
(stacktrace at https://paste.fedoraproject.org/428145/14738847/raw/ ),
with the EHCacheTokenStore creation failing due to the CacheManager 
having
been shutdown. The testsuite includes multiple tests, almost all of 
them

create jaxws clients and in most of them the current thread bus is used
(few of them do create a new bus, set it as default thread bus, run and
eventually shutdown the bus). What I suspect is some kind of 
concurrency

issue in the CacheManager lifecycle management.

I've looked a bit at the code and noticed that there's basically a 1-1
relationship between Bus instances and CacheManager instances. Given 
I have
some tests that do not explicitly shutdown the bus (or the client) 
after
execution, it can happen that a client is closed because the JDK 
eventually
finalize ClientProxy, which in the end causes the 
CacheCleanupListener to
close the token store and hence to release/shutdown the cache 
manager (see

the invocation flow at https://paste.fedoraproject.or
g/428150/47388530/raw/ ). Unfortunately that exact cache manager could
possibly be in use to serve another client running in the same bus. 
AFAICS,

there's an attempt to avoid problems like this in WSS4J's
EHCacheManagerHolder (which deals with CXF requests of 
creating/releasing

cache managers), as it has a ConcurrentHashMap
attribute to keep track of how many consumers of a given cache 
manager are
there and avoid shutting down a manager if it's still in use. 
Looking at
its getCacheManager and releaseCacheManager methods I can see a 
possible

concurrency flaw which could be the root of my failure. The
releaseCacheManager method could be called with cacheManager X as 
parameter
while a different thread is running getCacheManager and is just 
before line
106 (that is just before the AtomicInteger is got from the map) with 
local
cacheManager variable already resolved to X. That should later deal 
to an

attempt to use an already shutdown cache manager. I would be tempted to
suggest making those two methods syncronized (the map could then 
probably

be a plain hash map).

WDYT? I might be missing something, so posting here before opening up a
jira. Any idea?

Cheers

Alessio


--
Alessio Soldano
Web Service Lead, JBoss










--
Alessio Soldano
Web Service Lead, JBoss

Re: Concurrency issue with EHCacheTokenStore

[Alessio Soldano]

mmh... I need to build a patched wss4j snapshot and have it consumed by 
the remote machine that is reproducing the issue a bit more frequently 
(locally it's very rare). Will let you know :-)


Il 15/09/2016 10:35, Colm O hEigeartaigh ha scritto:

Hi Alessio,

Yes, that makes sense to me. If you perform the fix locally, do the
intermittent failures go away?

Colm.

On Wed, Sep 14, 2016 at 9:55 PM, Alessio Soldano 
wrote:


Hi,

I'm currently seeing an intermittent issue in the JBossWS-CXF testsuite
(stacktrace at https://paste.fedoraproject.org/428145/14738847/raw/ ),
with the EHCacheTokenStore creation failing due to the CacheManager having
been shutdown. The testsuite includes multiple tests, almost all of them
create jaxws clients and in most of them the current thread bus is used
(few of them do create a new bus, set it as default thread bus, run and
eventually shutdown the bus). What I suspect is some kind of concurrency
issue in the CacheManager lifecycle management.

I've looked a bit at the code and noticed that there's basically a 1-1
relationship between Bus instances and CacheManager instances. Given I have
some tests that do not explicitly shutdown the bus (or the client) after
execution, it can happen that a client is closed because the JDK eventually
finalize ClientProxy, which in the end causes the CacheCleanupListener to
close the token store and hence to release/shutdown the cache manager (see
the invocation flow at https://paste.fedoraproject.or
g/428150/47388530/raw/ ). Unfortunately that exact cache manager could
possibly be in use to serve another client running in the same bus. AFAICS,
there's an attempt to avoid problems like this in WSS4J's
EHCacheManagerHolder (which deals with CXF requests of creating/releasing
cache managers), as it has a ConcurrentHashMap
attribute to keep track of how many consumers of a given cache manager are
there and avoid shutting down a manager if it's still in use. Looking at
its getCacheManager and releaseCacheManager methods I can see a possible
concurrency flaw which could be the root of my failure. The
releaseCacheManager method could be called with cacheManager X as parameter
while a different thread is running getCacheManager and is just before line
106 (that is just before the AtomicInteger is got from the map) with local
cacheManager variable already resolved to X. That should later deal to an
attempt to use an already shutdown cache manager. I would be tempted to
suggest making those two methods syncronized (the map could then probably
be a plain hash map).

WDYT? I might be missing something, so posting here before opening up a
jira. Any idea?

Cheers

Alessio


--
Alessio Soldano
Web Service Lead, JBoss







--
Alessio Soldano
Web Service Lead, JBoss

Re: Concurrency issue with EHCacheTokenStore

[Alessio Soldano]

Il 14/09/2016 22:55, Alessio Soldano ha scritto:
That should later deal to an attempt to use an already shutdown cache 
manager.

s/deal/lead/


--
Alessio Soldano
Web Service Lead, JBoss

Concurrency issue with EHCacheTokenStore

[Alessio Soldano]

Hi,

I'm currently seeing an intermittent issue in the JBossWS-CXF testsuite 
(stacktrace at https://paste.fedoraproject.org/428145/14738847/raw/ ), 
with the EHCacheTokenStore creation failing due to the CacheManager 
having been shutdown. The testsuite includes multiple tests, almost all 
of them create jaxws clients and in most of them the current thread bus 
is used (few of them do create a new bus, set it as default thread bus, 
run and eventually shutdown the bus). What I suspect is some kind of 
concurrency issue in the CacheManager lifecycle management.


I've looked a bit at the code and noticed that there's basically a 1-1 
relationship between Bus instances and CacheManager instances. Given I 
have some tests that do not explicitly shutdown the bus (or the client) 
after execution, it can happen that a client is closed because the JDK 
eventually finalize ClientProxy, which in the end causes the 
CacheCleanupListener to close the token store and hence to 
release/shutdown the cache manager (see the invocation flow at 
https://paste.fedoraproject.org/428150/47388530/raw/ ). Unfortunately 
that exact cache manager could possibly be in use to serve another 
client running in the same bus. AFAICS, there's an attempt to avoid 
problems like this in WSS4J's EHCacheManagerHolder (which deals with CXF 
requests of creating/releasing cache managers), as it has a 
ConcurrentHashMap attribute to keep track of how 
many consumers of a given cache manager are there and avoid shutting 
down a manager if it's still in use. Looking at its getCacheManager and 
releaseCacheManager methods I can see a possible concurrency flaw which 
could be the root of my failure. The releaseCacheManager method could be 
called with cacheManager X as parameter while a different thread is 
running getCacheManager and is just before line 106 (that is just before 
the AtomicInteger is got from the map) with local cacheManager variable 
already resolved to X. That should later deal to an attempt to use an 
already shutdown cache manager. I would be tempted to suggest making 
those two methods syncronized (the map could then probably be a plain 
hash map).


WDYT? I might be missing something, so posting here before opening up a 
jira. Any idea?


Cheers

Alessio


--
Alessio Soldano
Web Service Lead, JBoss

Re: Removing some old modules in 3.2.0-SNAPSHOT

[Alessio Soldano]

Hi Sergey,
I like the idea of cleaning up the code base a bit. I would however cast 
my -1 on the removal of rt/ws/eventing and rt/ws/mex, which are ws-* 
spec we kind of declare support for / implementation.


Cheers
Alessio

Il 02/09/2016 18:07, Sergey Beryozkin ha scritto:

Hi

CXF module base continues to grow - a lot of modules is available, 
with some of these modules being obsolete and never used.


I'd like to propose to drop some of these modules in 3.2.0-SNAPSHOT to 
make the builds faster, the workspaces smaller and new users less 
overwhelmed :-). Once we agree on the final list I can remove them but 
as soon as we have at least a single user requesting the module back 
we'll put it back in 3.2.1. But in meantime we should give this 
clean-up a try :-).


The proposed list is below. Dan, others, please add -1 under any item 
you feel like worth keeping (but note we will put any removed module 
back in 3.2.1 or later whenever it is needed again):


1. rt/management-web

I was the one who added it, it was based on a GSOC project and I do 
think it is a unique project (users can see logging events in Atom 
readers), Aki did some good work around it a couple of years back, but 
I haven't seen any user actually asking questions or trying to use it.
Thus it should go. I'll be the 1st one who will put it back if someone 
will want to push it further.


2. rt/rs/security/oauth-parent/oauth

This module supports Oauth1 and is also based on the GSOC project.
Removing it might be a bit sensitive as some users did use it few 
years back. But OAuth1 is technically deprecated and Oauth2 is now 
widely deployed which is where we put a lot of effort into in CXF. I 
haven;t heard any queries about it for the last few years.


3. maven-plugin/archetypes: Maven JAXWS and JAXRS prototypes. Can they 
be really useful to anyone ? May be we can drop them and put back if 
needed.


4. integration/jca - I don't even remember what JCA means :-). I 
vaguely recall it was some old container spec ?



5. rt/bindings/object

I think I recall Dan explaining awhile back it is a more advanced 
version of coloc but I don't think it has ever been used by CXF users ?


6. rt/databindings/jibx
   I believe JIBX has not been maintained for many years now, if yes 
then lets let it go


7. systests/jibx

8. rt/databindings/sdo

   I know it was added on request from one of our previous employers, 
which was awhile back. Not sure if we need to keep it though


9. rt/databindings/xmlbeans

   Not sure if it is still needed. Looks like SOAP users do JAXB, 
occasionally - Aegis


10. services/wsn ?

11. rt/ws/eventing ?

12. rt/ws/mex ?


This is it for now. Please provide the feedback, we can keep this 
thread open for few weeks for sure


Thanks, Sergey

10.





--
Alessio Soldano
Web Service Lead, JBoss

Re: [VOTE] Apache CXF 3.0.10 and 3.1.7

[Alessio Soldano]

+1
Thanks

Il 26/07/2016 20:25, Daniel Kulp ha scritto:

It’s been a long time coming, but we’re finally ready to release 3.0.10/3.1.7.  
 We’ve resolved over 75 issues for 3.1.7 which is a LOT for a “.7” release.

Staging areas:
3.1.7:
https://repository.apache.org/content/repositories/orgapachecxf-1074/ 
<https://repository.apache.org/content/repositories/orgapachecxf-1074/>
3.0.10:
https://repository.apache.org/content/repositories/orgapachecxf-1073 
<https://repository.apache.org/content/repositories/orgapachecxf-1073>/


Tags:
3.1.7:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=687d104d55d88449778dce8582bc549857460ded
 
<https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=687d104d55d88449778dce8582bc549857460ded>
3.0.10:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=a8745ba730bd7081b0f51dc1ff3edb3329fbc854
 
<https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=a8745ba730bd7081b0f51dc1ff3edb3329fbc854>


Here is my +1





--
Alessio Soldano
Web Service Lead, JBoss

Re: [VOTE] - Release Apache CXF Build Utils 3.2.1 take2

[Alessio Soldano]

+1

Il 05/07/2016 10:57, Christian Schneider ha scritto:

This is a vote to release Apache CXF Build Utils 3.2.1.

It contains changes for checkstyle config to make it compatible to 
Eclipse Neon. In version 3.2.0 Neon shows a lot of false checkstyle 
errors.


After my first change seemed to be incompatible with older checkstyle 
versions I removed the return count check now to make sure it works in

all scenarios.

See
https://issues.apache.org/jira/browse/CXF-6961

Git tag is:
https://git-wip-us.apache.org/repos/asf?p=cxf-build-utils.git;a=tag;h=4dbfa24b3cd27da45b4dd219e1aadd89ac5d3cba 



Maven artifacts:

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

+1 from me.

Christian




--
Alessio Soldano
Web Service Lead, JBoss

Re: [VOTE] CXF 3.1.6/3.0.9

[Alessio Soldano]

Sorry, I was late in testing this; anyway, just done and it would have 
been an additional +1 from me.

Thanks
Alessio

Il 26/03/2016 22:30, Daniel Kulp ha scritto:

We have 10 +1 votes, I’ll promote the artifacts!

Dan



On Mar 23, 2016, at 4:48 PM, Daniel Kulp  wrote:


It’s been awhile since the last set of releases and we’ve fixed over 45 JIRA’s 
(some of which may be needed for the Fediz release) so I’d like to get this out.

Staging areas:
3.0.9:
https://repository.apache.org/content/repositories/orgapachecxf-1066/
3.1.6:
https://repository.apache.org/content/repositories/orgapachecxf-1065/

Tags:
3.0.9:
https://git1-us-west.apache.org/repos/asf?p=cxf.git;a=tag;h=26f17fad2f123d655ccf2d3a7bd2f4d7f8c81862
3.1.6:
https://git1-us-west.apache.org/repos/asf?p=cxf.git;a=tag;h=ff9419a6292393159d44f134c15570f0c7c80bdb


Vote will be open for 72h.

Here is my +1.

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




--
Alessio Soldano
Web Service Lead, JBoss

Re: MessageBodyReader/Writer cache

[Alessio Soldano]

I've added a comment to CXF-6837, wondering how much of the time that 
would be saved here is actually already addressed by the CXF-6826 patch 
(which I believe should be helping here).


Cheers
Alessio

Il 22/03/2016 10:14, Sergey Beryozkin ha scritto:

Hi Neal

I think it can be risky in its own way, and if it is to be done 
properly than the strategies for dealing with the in memory cache 
should be pluggable.


I'm also assuming that a composite key has to be involved, everything 
that is passed to isWriteable/isReadable. Because this is where the 
final solution is often made, even after the runtime has statically 
determined the best candidate.


But having the option to optimize it can be useful in some cases for 
sure,


Can you please attach an initial patch to CXF-6837 for us to look at ?

Cheers, Sergey

On 22/03/16 06:11, neal hu wrote:

Hi,

CXF selects the msgBodyReader/writer in the reader/writer list for every
request, which has big impact to the performance. Jersey also has the 
cache

in
org.glassfish.jersey.message.internal.MessageBodyFactory._getMessageBodyReader(...). 

I have tried add the cache for CXF in ProviderFactory and been proved 
that

it has improved 7-8% for json requests in JMeter. Please let me know if
you'd like me to add the enhancement for CXF. Thanks.
Neal



--
View this message in context: 
http://cxf.547215.n5.nabble.com/MessageBodyReader-Writer-cache-tp5767091.html

Sent from the cxf-dev mailing list archive at Nabble.com.







--
Alessio Soldano
Web Service Lead, JBoss

Re: [VOTE] CXF 3.1.5/3.0.8

[Alessio Soldano]

+1

Thanks

Il 02/02/2016 22:28, Daniel Kulp ha scritto:

It’s been 3 months since the last patch releases so we really need to get these 
out.

Staging areas:
3.1.5
https://repository.apache.org/content/repositories/orgapachecxf-1059/
3.0.8
https://repository.apache.org/content/repositories/orgapachecxf-1060/

Tags:
3.1.5:
https://git1-us-west.apache.org/repos/asf?p=cxf.git;a=tag;h=9a864cf721b510621f73f36e0ffabc17fd13c53c
3.0.8:
https://git1-us-west.apache.org/repos/asf?p=cxf.git;a=tag;h=257a6d23948cb120b1e24e3668e128d8b6672829

Vote will be open for at least 72 hours.


Here is my +1




--
Alessio Soldano
Web Service Lead, JBoss

Re: [VOTE]Apache CXF 3.1.3

[Alessio Soldano]

+1

Alessio


On 17/09/15 15:53, Daniel Kulp wrote:

It’s been about 6 weeks since the 3.1.2 release and we’ve fixed a bunch of 
things that some users have been asking for:

Tag:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=commit;h=f3185100ec7caea0ac4b52108210ed7e68e85271

Staging repo:
https://repository.apache.org/content/repositories/orgapachecxf-1055/

Vote will be open for at least 72 hours.   Here is my +1.




--
Alessio Soldano
Web Service Lead, JBoss

Re: [VOTE] - Release Apache CXF XJC Utils 3.0.5

[Alessio Soldano]

+1

On 01/09/15 18:10, Colm O hEigeartaigh wrote:

This is a vote to release Apache CXF XJC Utils 3.0.5. This release just
fixes a couple of bugs I ran in to when porting Fediz to use the XJC DV
plugin instead of the generic jaxb plugin.

Issues fixed:

https://issues.apache.org/jira/browse/CXFXJC/fixforversion/1244

Artifacts:

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

Git tag:

https://git-wip-us.apache.org/repos/asf?p=cxf-xjc-utils.git;a=commit;h=5a6511320a3e78f762e42e22edfe8e42eb864411

+1 from me.

Colm.





--
Alessio Soldano
Web Service Lead, JBoss

[RESULT][VOTE] CXF 2.7.17

[Alessio Soldano]

We have 8 binding +1 votes (Jeff Genender, Andriy Redko , Sergey 
Beryozkin, Christian Schneider, Colm O hEigeartaigh, Daniel Kulp, Aki 
Yoshida, Alessio Soldano), 1 non-binding +1 vote (Jason Pell) and no 
other votes, hence the vote passes.

I'll get the artifacts promoted.

Thanks
Alessio

On 27/07/15 21:26, Alessio Soldano wrote:
This is a vote to release 2.7.17.  It’s been over 2 months since the 
last release and we’ve fixed more than 18 issues.


Staging area:
2.7.17:
https://repository.apache.org/content/repositories/orgapachecxf-1048/

Tag:
2.7.17:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=d8e7b4fd8eb69da6b3a95f8de1a6a671ac4aaa19 



The vote will be open for at least 72 hours.




--
Alessio Soldano
Web Service Lead, JBoss

Re: [VOTE] CXF 2.7.17

[Alessio Soldano]

Here is my +1

On 27/07/15 21:26, Alessio Soldano wrote:
This is a vote to release 2.7.17.  It’s been over 2 months since the 
last release and we’ve fixed more than 18 issues.


Staging area:
2.7.17:
https://repository.apache.org/content/repositories/orgapachecxf-1048/

Tag:
2.7.17:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=d8e7b4fd8eb69da6b3a95f8de1a6a671ac4aaa19 



The vote will be open for at least 72 hours.




--
Alessio Soldano
Web Service Lead, JBoss

Re: [VOTE] CXF 3.0.6 and 3.1.2

[Alessio Soldano]

+1

Thanks
Alessio

On 28/07/15 20:13, Daniel Kulp wrote:

This is a vote to release 3.0.6 and 3.1.2.   We’ve fixed over 40 issues for 
3.1.2.

Staging areas:
https://repository.apache.org/content/repositories/orgapachecxf-1049/
https://repository.apache.org/content/repositories/orgapachecxf-1051/

Tags:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=28edab19c30da3171a78319156b5364682da5232
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=bea9ca61265711ed843750c6ee1ef4686e3b78b1

The vote will be open for at least 72 hours.





--
Alessio Soldano
Web Service Lead, JBoss

[VOTE] CXF 2.7.17

[Alessio Soldano]

This is a vote to release 2.7.17.  It’s been over 2 months since the 
last release and we’ve fixed more than 18 issues.


Staging area:
2.7.17:
https://repository.apache.org/content/repositories/orgapachecxf-1048/

Tag:
2.7.17:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=d8e7b4fd8eb69da6b3a95f8de1a6a671ac4aaa19

The vote will be open for at least 72 hours.

--
Alessio Soldano
Web Service Lead, JBoss

Re: 3.0.6 release?

[Alessio Soldano]

Thanks a lot :-)

On 08/07/15 12:44, Colm O hEigeartaigh wrote:

Ok will do!

Colm.

On Wed, Jul 8, 2015 at 10:07 AM, Alessio Soldano 
wrote:


On 08/07/15 11:03, Colm O hEigeartaigh wrote:


Hi Alessio,

I need to release a new version of WSS4J for CXF 3.0.6. I can call a vote
early next week so it will be released by the end of the week.


That would be great :-)

Btw, how about having a release of Santuario too? We have the issue [1]
which has been fixed ~2months ago and is important when running with JDK8.

Thanks
Alessio


[1] https://issues.apache.org/jira/browse/SANTUARIO-420




Colm.

On Mon, Jul 6, 2015 at 8:44 PM, Alessio Soldano 
wrote:

  Hi,

I was wondering, are there plans for releasing 3.0.6 / 2.7.17 any time
soon? I just need plan few dependent releases here :-)
Thanks
Alessio

--
Alessio Soldano
Web Service Lead, JBoss




--
Alessio Soldano
Web Service Lead, JBoss







--
Alessio Soldano
Web Service Lead, JBoss

Re: 3.0.6 release?

[Alessio Soldano]

On 08/07/15 11:03, Colm O hEigeartaigh wrote:

Hi Alessio,

I need to release a new version of WSS4J for CXF 3.0.6. I can call a vote
early next week so it will be released by the end of the week.

That would be great :-)

Btw, how about having a release of Santuario too? We have the issue [1] 
which has been fixed ~2months ago and is important when running with JDK8.


Thanks
Alessio


[1] https://issues.apache.org/jira/browse/SANTUARIO-420




Colm.

On Mon, Jul 6, 2015 at 8:44 PM, Alessio Soldano  wrote:


Hi,
I was wondering, are there plans for releasing 3.0.6 / 2.7.17 any time
soon? I just need plan few dependent releases here :-)
Thanks
Alessio

--
Alessio Soldano
Web Service Lead, JBoss







--
Alessio Soldano
Web Service Lead, JBoss

3.0.6 release?

[Alessio Soldano]

Hi,
I was wondering, are there plans for releasing 3.0.6 / 2.7.17 any time 
soon? I just need plan few dependent releases here :-)

Thanks
Alessio

--
Alessio Soldano
Web Service Lead, JBoss

Re: [VOTE] CXF 3.1.1

[Alessio Soldano]

+1

On 05/06/15 22:49, Daniel Kulp wrote:

3.1.1 fixes a bunch of issues in 3.1.0 that would prevent it from working 
properly in several normal use cases, particularly in OSGi.

Staging area:
https://repository.apache.org/content/repositories/orgapachecxf-1044/

Tag:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=f0d82d6f37105d1e2c97a459fb7fe41d98e1e401

Here is my +1.

Vote will be open for 72 hours






--
Alessio Soldano
Web Service Lead, JBoss

Fwd: [5/6] cxf git commit: Use modifiable maps during JAXB context initialization

[Alessio Soldano]

How about cherry-picking 
https://github.com/apache/cxf/commit/e47e394114d6a3bf06401960618e6bd556a904d7 
into 3.0.x-fixes then?
With the maps being modifiable ones, it looks like we don't really need 
to create a new map for the unmarshallerProperties each time the 
JAXBDataBinding is initialized.


Cheers
Alessio

 Original Message 
Subject: 	[5/6] cxf git commit: Use modifiable maps during JAXB context 
initialization

Date:   Thu, 14 May 2015 19:33:08 -
From:   dk...@apache.org
Reply-To:   dev@cxf.apache.org
To: comm...@cxf.apache.org



Use modifiable maps during JAXB context initialization


Project: http://git-wip-us.apache.org/repos/asf/cxf/repo
Commit: http://git-wip-us.apache.org/repos/asf/cxf/commit/6db98b2e
Tree: http://git-wip-us.apache.org/repos/asf/cxf/tree/6db98b2e
Diff: http://git-wip-us.apache.org/repos/asf/cxf/diff/6db98b2e

Branch: refs/heads/3.0.x-fixes
Commit: 6db98b2e3801390562b81e345cb2aab3700bed4e
Parents: 0806c75
Author: Daniel Kulp 
Authored: Thu May 14 12:29:07 2015 -0400
Committer: Daniel Kulp 
Committed: Thu May 14 15:15:22 2015 -0400

--
 .../src/main/java/org/apache/cxf/jaxb/JAXBDataBinding.java   | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cxf/blob/6db98b2e/rt/databinding/jaxb/src/main/java/org/apache/cxf/jaxb/JAXBDataBinding.java
--
diff --git 
a/rt/databinding/jaxb/src/main/java/org/apache/cxf/jaxb/JAXBDataBinding.java 
b/rt/databinding/jaxb/src/main/java/org/apache/cxf/jaxb/JAXBDataBinding.java
index b624d8a..a034def 100644
--- a/rt/databinding/jaxb/src/main/java/org/apache/cxf/jaxb/JAXBDataBinding.java
+++ b/rt/databinding/jaxb/src/main/java/org/apache/cxf/jaxb/JAXBDataBinding.java
@@ -195,10 +195,10 @@ public class JAXBDataBinding extends 
AbstractInterceptorProvidingDataBinding
 
 Class cls;
 
-private Map contextProperties = Collections.emptyMap();

-private List> adapters = Collections.emptyList();
-private Map marshallerProperties = Collections.emptyMap();
-private Map unmarshallerProperties = 
Collections.emptyMap();
+private Map contextProperties = new HashMap();
+private List> adapters = new ArrayList>();
+private Map marshallerProperties = new HashMap();
+private Map unmarshallerProperties = new HashMap();
 private Unmarshaller.Listener unmarshallerListener;
 private Marshaller.Listener marshallerListener;
 private ValidationEventHandler validationEventHandler;

Re: [VOTE] CXF 3.1.0

[Alessio Soldano]

+1

Alessio

On 01/05/15 19:30, Daniel Kulp wrote:

It’s been a year since the 3.0.0 release and we’ve made a bunch of significant 
improvements. We really need to get this out.  :-)

This also include the latest cxf-build-utils which allows CXF to import into 
the latest Eclipse plugins

Staging areas:
build-utils:
https://repository.apache.org/content/repositories/orgapachecxf-1041/org/apache/cxf/apache-cxf/
3.1.0
https://repository.apache.org/content/repositories/orgapachecxf-1042/org/apache/cxf/apache-cxf/

Tags:
build-utils:
https://git-wip-us.apache.org/repos/asf?p=cxf-build-utils.git;a=tag;h=744814506a23406a77fa53e75b3f0036efda3f9d
3.1.0:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=ecacd89321435a5e64deb0f8e850dc8b094c934e


This vote will be open for at least 72 hours.



--
Alessio Soldano
Web Service Lead, JBoss

Different approach for saving context properties

[Alessio Soldano]

Hi,
few months ago I was profiling a JAX-WS client applications and 
mentioned few performance issues on this list, see [1].
Recently, I've had a chance to get back to that topic and think about a 
possible alternative to the way context properties are retrieved from 
and stored in the Message; as I previously noticed, the context cache 
computation is quite expensive as 7 maps are merged into one, at least 
twice for each request-response processing. I asked for the reason such 
cache is there (in the past, getContextualProperty used to go and look 
for the prop key into the Bus, Service, Endpoint etc.) and Dan explained 
that in some scenarios (for instance when using WS-Security) a lot of 
props are checked and that resulted in a lot of time spent creating hash 
codes for all those lookups, etc. So the need for a unified view of the 
props.
Now, I admit I've been looking around for inspiration, especially in the 
JAX-WS RI implementation... and found what I think could be an 
interesting idea ;-)
Basically, I think we could revisit this contextual property stuff as 
follows:

- we keep a list of the known property names
- for all known properties, instead of saving key-value entries in one 
of those 7 maps for each message if the prop is specified, we compute a 
static index that tells us where/how to get the value for a given 
property; so for instance the index would tell us if prop X is a 
Message, Bus, Service or Endpoint stored properties, so that we don't 
have to go and try each of them till we find the value.

- any other property is dealt with as we currently do

This way by default and in most of the cases, the context cache merged 
map (as well as the 7 maps) would be empty, meaning no need for actually 
allocating memory and doing any copy. At the same time, we'd not be 
slowing down the gets that much, as we'd only be doing an additional get 
in the index.
Moreover, perhaps afterwards in a second optimization effort, we could 
make this even more optimized by keeping the (most relevant) known 
property values in strong typed members of the Message, Bus, Endpoint, 
etc. instead of putting them in maps. For such properties, the index 
would return an accessor to the actual field/method providing the 
property value. The JAX-WS RI does this by parsing classes during 
initialization, looking for @Property custom annotations telling a 
field/method provides the value for a given property and creating the 
proper accessor for it. The accessor uses reflection to read/write the 
data using the field/method.


When adding a new known property, we'd have to add it to the list of the 
known properties and have it registered in the index (btw, for 
documentation sake, it would still be good to have a centralized 
collection of supported contextual properties, regardless of this issue).


Any thought / idea?
I could possibly try implementing this in the next future and have it 
included on master if it turns out to actually be an effective solution...

Cheers
Alessio

[1] 
http://cxf.547215.n5.nabble.com/JAX-WS-client-performances-td5753625.html


--
Alessio Soldano
Web Service Lead, JBoss

Re: 3.1 by end of month?

[Alessio Soldano]

Fine with me

Alessio

On 02/04/15 17:32, Daniel Kulp wrote:

It’s been almost a year since 3.0 and I really thing we need to get 3.1 out.   
We’ve done a ton of work getting some new features added in, updates to WSS4J 
(and OpenSAML), bunch of JAX-RS enhancements around security, etc…

Thoughts?   Other than getting a WSS4J release, any other major blockers?




--
Alessio Soldano
Web Service Lead, JBoss

Re: cxf git commit: Minor change

[Alessio Soldano]

Cool, thanks.

On 03/03/15 16:30, Colm O hEigeartaigh wrote:

Hi Alessio,

I switched to LinkedList here simply because we always prepend to the list,
so in theory it has a O(1) insertion cost instead of O(n). In practise the
list will be so small that it won't really matter much either way.

Colm.

On Tue, Mar 3, 2015 at 3:15 PM, Alessio Soldano  wrote:


Hi Colm,
I assume you've been doing some kind of memory analysis that led to these
changes of ArrayList into LinkedList instances, did you? If that's the
case, do you have any number to share and/or are planning to blog on this?
Or are these simply spot changes for lists that are know to contain one or
two elements in most of the cases, etc ?
Cheers
Alessio

On 03/03/15 15:31, cohei...@apache.org wrote:


Repository: cxf
Updated Branches:
refs/heads/opensaml-3.0-port 773722540 -> 9ae69b3b3


Minor change


Project: http://git-wip-us.apache.org/repos/asf/cxf/repo
Commit: http://git-wip-us.apache.org/repos/asf/cxf/commit/9ae69b3b
Tree: http://git-wip-us.apache.org/repos/asf/cxf/tree/9ae69b3b
Diff: http://git-wip-us.apache.org/repos/asf/cxf/diff/9ae69b3b

Branch: refs/heads/opensaml-3.0-port
Commit: 9ae69b3b323f48de033f62be9fc2780f11b0c761
Parents: 7737225
Author: Colm O hEigeartaigh 
Authored: Tue Mar 3 14:31:39 2015 +
Committer: Colm O hEigeartaigh 
Committed: Tue Mar 3 14:31:39 2015 +

--
   .../java/org/apache/cxf/ws/security/wss4j/WSS4JInInterceptor.java | 3
++-
   1 file changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cxf/blob/9ae69b3b/
rt/ws/security/src/main/java/org/apache/cxf/ws/security/
wss4j/WSS4JInInterceptor.java
--
diff --git a/rt/ws/security/src/main/java/org/apache/cxf/ws/
security/wss4j/WSS4JInInterceptor.java b/rt/ws/security/src/main/
java/org/apache/cxf/ws/security/wss4j/WSS4JInInterceptor.java
index 4e20831..79cb6da 100644
--- a/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/
WSS4JInInterceptor.java
+++ b/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/
WSS4JInInterceptor.java
@@ -26,6 +26,7 @@ import java.security.cert.Certificate;
   import java.security.cert.X509Certificate;
   import java.util.ArrayList;
   import java.util.HashMap;
+import java.util.LinkedList;
   import java.util.List;
   import java.util.Map;
   import java.util.Set;
@@ -541,7 +542,7 @@ public class WSS4JInInterceptor extends
AbstractWSS4JInterceptor {
*/
   List results = CastUtils.cast((List)msg.
get(WSHandlerConstants.RECV_RESULTS));
   if (results == null) {
-results = new ArrayList();
+results = new LinkedList();
   msg.put(WSHandlerConstants.RECV_RESULTS, results);
   }
   WSHandlerResult rResult = new WSHandlerResult(actor, wsResult);



--
Alessio Soldano
Web Service Lead, JBoss







--
Alessio Soldano
Web Service Lead, JBoss

Re: cxf git commit: Minor change

[Alessio Soldano]

Hi Colm,
I assume you've been doing some kind of memory analysis that led to 
these changes of ArrayList into LinkedList instances, did you? If that's 
the case, do you have any number to share and/or are planning to blog on 
this?
Or are these simply spot changes for lists that are know to contain one 
or two elements in most of the cases, etc ?

Cheers
Alessio

On 03/03/15 15:31, cohei...@apache.org wrote:

Repository: cxf
Updated Branches:
   refs/heads/opensaml-3.0-port 773722540 -> 9ae69b3b3


Minor change


Project: http://git-wip-us.apache.org/repos/asf/cxf/repo
Commit: http://git-wip-us.apache.org/repos/asf/cxf/commit/9ae69b3b
Tree: http://git-wip-us.apache.org/repos/asf/cxf/tree/9ae69b3b
Diff: http://git-wip-us.apache.org/repos/asf/cxf/diff/9ae69b3b

Branch: refs/heads/opensaml-3.0-port
Commit: 9ae69b3b323f48de033f62be9fc2780f11b0c761
Parents: 7737225
Author: Colm O hEigeartaigh 
Authored: Tue Mar 3 14:31:39 2015 +
Committer: Colm O hEigeartaigh 
Committed: Tue Mar 3 14:31:39 2015 +

--
  .../java/org/apache/cxf/ws/security/wss4j/WSS4JInInterceptor.java | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cxf/blob/9ae69b3b/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/WSS4JInInterceptor.java
--
diff --git 
a/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/WSS4JInInterceptor.java
 
b/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/WSS4JInInterceptor.java
index 4e20831..79cb6da 100644
--- 
a/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/WSS4JInInterceptor.java
+++ 
b/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/WSS4JInInterceptor.java
@@ -26,6 +26,7 @@ import java.security.cert.Certificate;
  import java.security.cert.X509Certificate;
  import java.util.ArrayList;
  import java.util.HashMap;
+import java.util.LinkedList;
  import java.util.List;
  import java.util.Map;
  import java.util.Set;
@@ -541,7 +542,7 @@ public class WSS4JInInterceptor extends 
AbstractWSS4JInterceptor {
   */
  List results = 
CastUtils.cast((List)msg.get(WSHandlerConstants.RECV_RESULTS));
  if (results == null) {
-results = new ArrayList();
+results = new LinkedList();
  msg.put(WSHandlerConstants.RECV_RESULTS, results);
  }
  WSHandlerResult rResult = new WSHandlerResult(actor, wsResult);




--
Alessio Soldano
Web Service Lead, JBoss

R: Re: [VOTE] CXF 3.0.4/2.7.15

[Alessio Soldano]

+1

Alessio
- Messaggio originale -
Da: Jim Ma 
A: dev@cxf.apache.org
Inviato: Sat, 14 Feb 2015 10:54:22 -0500 (EST)
Oggetto: Re: [VOTE] CXF 3.0.4/2.7.15

+1


On Thu, Feb 12, 2015 at 11:22 PM, Aki Yoshida  wrote:

> +1
>
> Aki
>
> 2015-02-12 2:53 GMT+01:00 Daniel Kulp :
> > This is a vote to release 3.0.4 and 2.7.15.  It’s been about 2 months
> since the last release and we’ve fixed more than 70 issues.
> >
> > Staging areas:
> > 2.7.15:
> > https://repository.apache.org/content/repositories/orgapachecxf-1036/
> > 3.0.4:
> > https://repository.apache.org/content/repositories/orgapachecxf-1037/
> >
> >
> > Tags:
> > 2.7.15:
> >
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=ad0e985de4d14603398765e96723a4d2efe9da64
> > 3.0.4:
> >
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=3bbc187f31e42cd4cb2e82b6604a87029823331c
> >
> >
> > The vote will be open for at least 72 hours.
> >
> > --
> > Daniel Kulp
> > dk...@apache.org - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> >
>

Re: JAX-WS client performances

[Alessio Soldano]

Hi Dan,
thanks for the feedback.

On 05/02/15 23:01, Daniel Kulp wrote:

1) Can you save/print a list of everything that is a “get” from the non-message 
contexts?   I’m mostly concerned about Bus/BindingOperation/Endpoint objects.   
A long long time ago (2.0/2.1 timeframe), those objects were stored as 
contextual properties and the only way to retrieve them was via the 
“getContextualProperty” things.   Since we use those all over the place, I 
added direct accessors to the Exchange, but for compatibility still stored them 
as properties.   However, I don’t remember if I went and found all the places 
that used to look those up via the “get” methods and replaced them.   We 
probably could remove those from being stored as contextual properties and 
document that. (should have been done long ago)  Would reduce the number of 
properties to deal with.
I've added few simple System.out in the get method of "array" version 
and run the jbossws testsuite. No get of Bus/BindingOperation/Endpoint 
objects afaics; so I've tried grepping getContextualProperty in the 
whole cxf sources and the only thing I could find is 
org/apache/cxf/rs/security/saml/sso/AbstractRequestAssertionConsumerHandler 
getting the Bus from the context.

I'm sending you the zip with the logs.



2) In the “array” version, you could loop through once and just do an == 
compare and then only do the .equals if that ends up null.   I’m willing to bet 
most of the strings we use as keys are interned.
Tried that, but it's not improving performances. To be honest, though, 
my bench app is likely not stressing the 'get' that much, as it doesn't 
use WS-Security, etc.
Anyway, my gut feeling is that's also because the cache misses are by 
far much more then the cache hits (for instance, on client side in the 
jbossws testsuite I see ~5700 props found in the message context, ~350 
props found in non-message contexts and ~72000 props not found.


Cheers
Alessio

--
Alessio Soldano
Web Service Lead, JBoss

Re: JAX-WS client performances

[Alessio Soldano]

I've posted two comments, each with a patch file, on 
https://issues.apache.org/jira/browse/CXF-6227 .

Any feedback, please let me know :-)

Cheers
Alessio

On 04/02/15 11:13, Alessio Soldano wrote:

On 03/02/15 23:52, Alessio Soldano wrote:
so we'd have a get method computing the requested key's hash once and 
not for each sub-map, etc. I don't really know yet if this is doable,
it isn't... as each map has its own hash seed. Will go on thinking 
about alternatives though.


Alessio



--
Alessio Soldano
Web Service Lead, JBoss

Re: JAX-WS client performances

[Alessio Soldano]

On 03/02/15 23:52, Alessio Soldano wrote:
so we'd have a get method computing the requested key's hash once and 
not for each sub-map, etc. I don't really know yet if this is doable,
it isn't... as each map has its own hash seed. Will go on thinking about 
alternatives though.


Alessio

Re: JAX-WS client performances

[Alessio Soldano]

Hi Dan,

On 03/02/15 21:02, Daniel Kulp wrote:

On Feb 3, 2015, at 8:11 AM, Alessio Soldano  wrote:

A brief update: I've committed the workaround for http connection issue (thanks 
Dan for the help on that!) as well as some other straightforward optimizations 
on stuff that popped up while profiling.

Now, next "big" topic I found is the way we get and set properties in the 
message context. We spend a relevant amount of time in creating HashMap instances and 
especially in MessageImpl#calcContextCache, which copies (putAll) all the Bus, Service, 
Endpoint, etc. properties into the context cache. You can see [1] the cpu hotspot view I 
get currently with the previously mentioned test app. AFAICS in the source history, there 
used to be a different way for dealing with message properties in the past [2], then the 
cache mechanism was added. So I'm wondering if some kind of profiling / perf testing have 
been performed in the past and led to the changes. I might simply be testing an edge 
scenario, with very few properties being looked up and hence not justifying the caching 
mechanism.
Any comment / idea / suggestion?

At one point, every “get” of a property would end up checking 4 or 5 hash maps 
which resulted in the keys being hashCoded many times, lots of checks, etc…
When you get into the WS-Security cases and some of the HTTP configuration 
cases where there are a bunch of keys being looked up, there was a LOT of time 
being spent on the lookups.
OK, I see, thanks; perhaps calls to "get" became a problem when you had 
a wide range of properties that could be there in the context, but 
actually were not, so you went through all the maps to eventually figure 
out the prop was not there... I wonder if a different cache approach 
(save the cache hit and cache miss entries in 2 maps as they're 
requested) could make sense or not.



For the most part, at the time, the maps were relatively small and the cost 
to build a single “context” map was small in comparison which is why this was 
done.

That said, the size of the cache map is likely fairly small as well.   Maybe a 
dozen keys?  (and I'm willing to bet most of the keys are interned where a == 
would catch it)  Might be simpler to just use an Object[] or something.
I've tried printing the cache size while running the jbossws testsuite 
and on average I get values around 40~50 (with most of the stuff being 
in the exchange and message maps). So I'm not sure a plain array would 
be a better solution in terms of performances.
What I've been thinking about (but didn't actually try, at least not 
yet) is a custom HashMap extension that would work as a composition of 
multiple HashMap instances; so we'd have a get method computing the 
requested key's hash once and not for each sub-map, etc. I don't really 
know yet if this is doable, perhaps I can try providing something 
working that avoids all the maps copies (btw, I bet we have basically no 
key overlaps among the various maps for the same context).


Thanks for now
Alessio

--
Alessio Soldano
Web Service Lead, JBoss

Re: JAX-WS client performances

[Alessio Soldano]

A brief update: I've committed the workaround for http connection issue 
(thanks Dan for the help on that!) as well as some other straightforward 
optimizations on stuff that popped up while profiling.


Now, next "big" topic I found is the way we get and set properties in 
the message context. We spend a relevant amount of time in creating 
HashMap instances and especially in MessageImpl#calcContextCache, which 
copies (putAll) all the Bus, Service, Endpoint, etc. properties into the 
context cache. You can see [1] the cpu hotspot view I get currently with 
the previously mentioned test app. AFAICS in the source history, there 
used to be a different way for dealing with message properties in the 
past [2], then the cache mechanism was added. So I'm wondering if some 
kind of profiling / perf testing have been performed in the past and led 
to the changes. I might simply be testing an edge scenario, with very 
few properties being looked up and hence not justifying the caching 
mechanism.

Any comment / idea / suggestion?

Cheers
Alessio

[1] http://pasteboard.co/QgiD4Af.png
[2]

On 27/01/15 18:14, Alessio Soldano wrote:

Hi,
my attention has been recently brought to a scenario in which an 
Apache CXF client invokes an endpoint operation in a loop and the 
number of invocations performed in a given amount of time (say, 2 
minutes) is used as benchmark for measuring WS stack performances. 
It's actually a very simplistic scenario, with a plain JAX-WS single 
thread client sending and receiving small RPC/Lit SOAP messages [1]. 
The reason why I've been asked to have a look is that with default 
settings the Apache CXF JAX-WS impl seems to perform *shamefully* bad 
compared to the Metro (JAX-WS RI) implementation. I've been blaming 
the user log configuration, etc but when I eventually tried on my own 
I could actually reproduce the bad results. I've been profiling a bit 
and found few hot spot area where CXF could possibly be optimized, but 
the big issue really seems to be at the HTTPCounduit / 
HTTPURLConnection level.
I found that almost all the invocations end up into 
sun.net.www.http.HttpClient.New(..) calling available() method [2] as 
part of the process for re-using cached connections [3]; that goes to 
the wire to try reading and takes a lot of time.
When the RI does the equivalent operation, the available() method is 
not called [4], resulting in much better performances.
By looking at the JDK code, it looks to me that the problem boils down 
to sun.net.www.protocol.http.HttpURLConnection#streaming() [5] 
returning different values, as a consequence of the fixedContentLenght 
attribute being set to a value different from -1 when running on CXF 
only. As a matter of fact, that is set when 
HTTPConduit.WrappedOutputStream#thresholdNotReached() is called, 
whenever a message is completely written to the outpustream buffer 
before the chunking threshold is reached (at least AFAIU). I've 
searched through the JAX-WS RI and could not find any place where 
setFixedLengthStreamingMode is called on the connection instead.
So, I've performed two quick and dirty tries: the first time I forced 
allowChunking = false on the client policy, the second time I 
commented out the code in 
HTTPConduit.WrappedOutputStream#thresholdNotReached(). In both cases I 
managed to get performances comparable to what I can get with the 
JAX-WS RI.

Now, few questions:
- are we really required to call setFixedLengthStreamingMode as we 
currently do? what's the drawback of not calling it?
- should we actually do something for getting decent performances by 
default in this scenario? (not sure expecting the user to disable 
chunking is that an option...)
As a side note, the relevant part of the JDK HttpClient code changed 
between JDK6 and JDK7, so things have not always been as explained 
above...


Cheers
Alessio


[1] http://www.fpaste.org/176166/14223765/
[2] http://pasteboard.co/FR5QVrP.png
[3] 
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7u40-b43/sun/net/www/http/HttpClient.java#276

[4] http://pasteboard.co/FR8okYM.png
[5] 
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7u40-b43/sun/net/www/protocol/http/HttpURLConnection.java#HttpURLConnection.streaming%28%29





--
Alessio Soldano
Web Service Lead, JBoss

Re: [1/5] cxf git commit: Update plugins to use annotations instead of the javadoc things

[Alessio Soldano]

apache.org/repos/asf/cxf/blob/96ed8050/pom.xml
--
diff --git a/pom.xml b/pom.xml
index 0873d69..31debe6 100644
--- a/pom.xml
+++ b/pom.xml
@@ -615,6 +615,37 @@
  
  
  
+
+
+   org.eclipse.m2e
+   lifecycle-mapping
+   1.0.0
+   
+   
+           
+   

JAX-WS client performances

[Alessio Soldano]

Hi,
my attention has been recently brought to a scenario in which an Apache 
CXF client invokes an endpoint operation in a loop and the number of 
invocations performed in a given amount of time (say, 2 minutes) is used 
as benchmark for measuring WS stack performances. It's actually a very 
simplistic scenario, with a plain JAX-WS single thread client sending 
and receiving small RPC/Lit SOAP messages [1]. The reason why I've been 
asked to have a look is that with default settings the Apache CXF JAX-WS 
impl seems to perform *shamefully* bad compared to the Metro (JAX-WS RI) 
implementation. I've been blaming the user log configuration, etc but 
when I eventually tried on my own I could actually reproduce the bad 
results. I've been profiling a bit and found few hot spot area where CXF 
could possibly be optimized, but the big issue really seems to be at the 
HTTPCounduit / HTTPURLConnection level.
I found that almost all the invocations end up into 
sun.net.www.http.HttpClient.New(..) calling available() method [2] as 
part of the process for re-using cached connections [3]; that goes to 
the wire to try reading and takes a lot of time.
When the RI does the equivalent operation, the available() method is not 
called [4], resulting in much better performances.
By looking at the JDK code, it looks to me that the problem boils down 
to sun.net.www.protocol.http.HttpURLConnection#streaming() [5] returning 
different values, as a consequence of the fixedContentLenght attribute 
being set to a value different from -1 when running on CXF only. As a 
matter of fact, that is set when 
HTTPConduit.WrappedOutputStream#thresholdNotReached() is called, 
whenever a message is completely written to the outpustream buffer 
before the chunking threshold is reached (at least AFAIU). I've searched 
through the JAX-WS RI and could not find any place where 
setFixedLengthStreamingMode is called on the connection instead.
So, I've performed two quick and dirty tries: the first time I forced 
allowChunking = false on the client policy, the second time I commented 
out the code in HTTPConduit.WrappedOutputStream#thresholdNotReached(). 
In both cases I managed to get performances comparable to what I can get 
with the JAX-WS RI.

Now, few questions:
- are we really required to call setFixedLengthStreamingMode as we 
currently do? what's the drawback of not calling it?
- should we actually do something for getting decent performances by 
default in this scenario? (not sure expecting the user to disable 
chunking is that an option...)
As a side note, the relevant part of the JDK HttpClient code changed 
between JDK6 and JDK7, so things have not always been as explained above...


Cheers
Alessio


[1] http://www.fpaste.org/176166/14223765/
[2] http://pasteboard.co/FR5QVrP.png
[3] 
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7u40-b43/sun/net/www/http/HttpClient.java#276

[4] http://pasteboard.co/FR8okYM.png
[5] 
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7u40-b43/sun/net/www/protocol/http/HttpURLConnection.java#HttpURLConnection.streaming%28%29


--
Alessio Soldano
Web Service Lead, JBoss

Re: [VOTE] CXF 2.7.14/3.0.3

[Alessio Soldano]

+1

Alessio

On 03/12/14 17:20, Daniel Kulp wrote:

This is a vote to release CXF 2.7.14 and 3.0.3.   These versions fix a bunch of 
bugs users have encountered.  They also provide some additional functionality 
to make it easier to configure various SSL/TLS things to mitigate various 
attacks.

Staging areas:
2.7.14:
https://repository.apache.org/content/repositories/orgapachecxf-1033/
3.0.3:
https://repository.apache.org/content/repositories/orgapachecxf-1034/

Tags:
3.0.3:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=e157ea4fd4848983a7044614246d04093b8a6936
2.7.14:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=b1867aec7a6be2e20f75570f4e99aac628ec73ea

The vote will be open for at least 72h.




--
Alessio Soldano
Web Service Lead, JBoss

Re: [VOTE] CXF 2.7.14/3.0.3

[Alessio Soldano]

+1

Alessio

On 03/12/14 17:20, Daniel Kulp wrote:

This is a vote to release CXF 2.7.14 and 3.0.3.   These versions fix a bunch of 
bugs users have encountered.  They also provide some additional functionality 
to make it easier to configure various SSL/TLS things to mitigate various 
attacks.

Staging areas:
2.7.14:
https://repository.apache.org/content/repositories/orgapachecxf-1033/
3.0.3:
https://repository.apache.org/content/repositories/orgapachecxf-1034/

Tags:
3.0.3:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=e157ea4fd4848983a7044614246d04093b8a6936
2.7.14:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=b1867aec7a6be2e20f75570f4e99aac628ec73ea

The vote will be open for at least 72h.




--
Alessio Soldano
Web Service Lead, JBoss

Re: [VOTE] CXF 2.7.13/3.0.2

[Alessio Soldano]

+1

Alessio

- Original Message -
From: "Daniel Kulp" 
To: dev@cxf.apache.org
Sent: Wednesday, October 8, 2014 7:30:52 PM
Subject: [VOTE] CXF 2.7.13/3.0.2


This is a vote to release CXF 2.7.13 and 3.0.2.There are over 90 JIRA 
issues resolved for 3.0.2 which is a lot.

Tags:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=3ec631c97e9eccf62490b176aab61044b3b9ab9f
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=44fff0be11438e91e236bc204e5975bd744613c1

Staging areas:
https://repository.apache.org/content/repositories/orgapachecxf-1029/
https://repository.apache.org/content/repositories/orgapachecxf-1030/


Here is my +1

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

Re: [VOTE] CXF 2.6.16

[Alessio Soldano]

+1

On 07/10/14 21:59, Daniel Kulp wrote:

This is a vote to release CXF 2.6.16.   This release is JUST to fix the 
problems running 2.6.15 with Java5.  All the changes between 2.6.15 and 2.6.16 
are directly related to getting it to build, run, and test with Java5.   This 
does include downgrading a couple of dependencies back to the 2.6.14 level.

Tag:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=03ee4401807edee68cfa590a400e8b35a0caac6b

Staging area:
https://repository.apache.org/content/repositories/orgapachecxf-1028/

Here is my +1.




--
Alessio Soldano
Web Service Lead, JBoss

On finalize() potential issues

[Alessio Soldano]

Hi,
some of you might already be aware that the finalize mechanism in the 
JVM is basically flawed and there could be issues even when it's used 
for commonly accepted reasons (like cleaning up stuff that the user 
forgot about). A very interesting presentation has been recently made 
available on this topic, I suggest having a look at 
https://www.youtube.com/watch?v=UrGP6pfb0H8 .
This said, it's many months (possibly years) since I started seeing 
infrequent transient failures in the JBossWS <-> Apache CXF integration 
testsuite, usually caused by "Socket closed" java.net.SocketException 
exceptions (here is an example, 
http://www.fpaste.org/139814/41267248/raw/). To be honest, I have no 
proof this is actually related to the finalize() topic above, but I'm 
wondering if anybody here ever seriously considered the potential issue.
We do have a finalize() method in the ClientProxy, which calls the 
close() method which in turn calls ClientImpl's destroy() method. That 
goes through multiple cleanup things, including shutting down the 
Conduit, which is always based on URLConnection in my case. To give an 
idea of the kind of issues, before you have a look at the presentation, 
especially on highly optimized JDK, the finalize method might end up 
being called when the resources it's meant to cleanup are still being used.

Any thoughts?
Cheers
Alessio

--
Alessio Soldano
Web Service Lead, JBoss

Re: [VOTE] CXF XJC Utils 3.0.2

[Alessio Soldano]

On 19/09/14 15:42, Daniel Kulp wrote:

This is a vote to release the 3.0.2 version of the XJC Utils.There are two 
major changes:

1) Update the plugin to use all the repositories in the pom to find the 
extensions so it can locate extensions that aren’t found in central

2) Add the new bug986 plugin to work around the XJC bug found in the latest 
versions of JAXB XJC (and Java8).

#2 is needed to be able to use Java7 and Java8 to build CXF in a way that the 
WS-Discovery stuff works.


Staging repo:
https://repository.apache.org/content/repositories/orgapachecxf-1027/

Tag:
https://git-wip-us.apache.org/repos/asf?p=cxf-xjc-utils.git;a=tag;h=758e8639d0bac8c8173fbb353d0110c240b9a804


Here is my +1.



+1

--
Alessio Soldano
Web Service Lead, JBoss

Re: On BouncyCastle installed as a global security provider

[Alessio Soldano]

Cool, thanks for the feedback.
I can deal with CXF-5905, but need you to deal with WSS-507, as I don't 
have commit rights on WSS4J ;-)


Thanks
Alessio

On 25/07/14 14:33, Colm O hEigeartaigh wrote:


It looks fine to me.

Colm.


On Fri, Jul 25, 2014 at 11:48 AM, Alessio Soldano <mailto:asold...@redhat.com>> wrote:


Hi Colm,
I've came up with a proposal, please see
https://issues.apache.org/jira/browse/WSS-507 and
https://issues.apache.org/jira/browse/CXF-5905 .
The CXF side of the proposal patch is still to be finished, but it
should give an idea of the approach.
Please let me know what you think.
Thanks
Alessio

On 23/07/14 12:49, Colm O hEigeartaigh wrote:

Hi Alessio,

I'm open to the idea of passing the BouncyCastle Provider
Object to the
various classes in WSS4J etc rather than installing it as a global
provider, IF it can be done without large code changes.
Ultimately, CXF
does not ship with BouncyCastle installed by default, and you
can use GCM
algorithms by upgrading to Java 8 as Sergey said, and so most
users will
not have to install/use BouncyCastle.

Colm.


On Wed, Jul 23, 2014 at 10:44 AM, Alessio Soldano
mailto:asold...@redhat.com>>
wrote:

Hi,
I've been asked whether it's possible to avoid having BC
installed as a
global security provider when using Apache CXF. I'm of
course aware that
WSS4J installs it on behalf of CXF for supporting e.g. GCM
algorithms,
which is not an option. However the question is still
reasonable; assuming
the CXF stack is not the only framework running in the
JVM, other
frameworks are going to be affected by that. They might or
might not want
BC installed (for instance, just an example, because of
[1]). They might
prefer different providers for a given set of algorithm
requirements.
Ultimately, it should be up to the user to decide which
providers are set
as global security provider, application should either
rely on the
installed global providers without touching them, or
explicitly use what
they want.
So I'm wondering if there's a way we could modify
CXF/WSS4J/Santuario for
using BC (or whatever we want to use ;-) ) e.g. when
needing GCM without
installing it as a global provider. Something around e.g.
getting ciphers
through the javax.crypto.Cipher#getInstance(String
transformation,
Provider provider) method instead of the
javax.crypto.Cipher#getInstance(String
transformation) after having loaded the provider without
installing it
globally, etc.
Any thought / idea?
Thanks
Alessio

[1] http://bouncycastle.org/jira/browse/BJA-19 /
https://issues.apache.org/jira/browse/HARMONY-3789,
BouncyCastle DH
KeyPairGenerator algorithm can hang / eat lots of CPU

--
Alessio Soldano
    Web Service Lead, JBoss





-- 
Alessio Soldano

Web Service Lead, JBoss




--
Colm O hEigeartaigh

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



--
Alessio Soldano
Web Service Lead, JBoss

Re: On BouncyCastle installed as a global security provider

[Alessio Soldano]

Hi Colm,
I've came up with a proposal, please see 
https://issues.apache.org/jira/browse/WSS-507 and 
https://issues.apache.org/jira/browse/CXF-5905 .
The CXF side of the proposal patch is still to be finished, but it 
should give an idea of the approach.

Please let me know what you think.
Thanks
Alessio

On 23/07/14 12:49, Colm O hEigeartaigh wrote:

Hi Alessio,

I'm open to the idea of passing the BouncyCastle Provider Object to the
various classes in WSS4J etc rather than installing it as a global
provider, IF it can be done without large code changes. Ultimately, CXF
does not ship with BouncyCastle installed by default, and you can use GCM
algorithms by upgrading to Java 8 as Sergey said, and so most users will
not have to install/use BouncyCastle.

Colm.


On Wed, Jul 23, 2014 at 10:44 AM, Alessio Soldano 
wrote:


Hi,
I've been asked whether it's possible to avoid having BC installed as a
global security provider when using Apache CXF. I'm of course aware that
WSS4J installs it on behalf of CXF for supporting e.g. GCM algorithms,
which is not an option. However the question is still reasonable; assuming
the CXF stack is not the only framework running in the JVM, other
frameworks are going to be affected by that. They might or might not want
BC installed (for instance, just an example, because of [1]). They might
prefer different providers for a given set of algorithm requirements.
Ultimately, it should be up to the user to decide which providers are set
as global security provider, application should either rely on the
installed global providers without touching them, or explicitly use what
they want.
So I'm wondering if there's a way we could modify CXF/WSS4J/Santuario for
using BC (or whatever we want to use ;-) ) e.g. when needing GCM without
installing it as a global provider. Something around e.g. getting ciphers
through the javax.crypto.Cipher#getInstance(String transformation,
Provider provider) method instead of the javax.crypto.Cipher#getInstance(String
transformation) after having loaded the provider without installing it
globally, etc.
Any thought / idea?
Thanks
Alessio

[1] http://bouncycastle.org/jira/browse/BJA-19 /
https://issues.apache.org/jira/browse/HARMONY-3789, BouncyCastle DH
KeyPairGenerator algorithm can hang / eat lots of CPU

--
Alessio Soldano
Web Service Lead, JBoss







--
Alessio Soldano
Web Service Lead, JBoss

On BouncyCastle installed as a global security provider

[Alessio Soldano]

Hi,
I've been asked whether it's possible to avoid having BC installed as a 
global security provider when using Apache CXF. I'm of course aware that 
WSS4J installs it on behalf of CXF for supporting e.g. GCM algorithms, 
which is not an option. However the question is still reasonable; 
assuming the CXF stack is not the only framework running in the JVM, 
other frameworks are going to be affected by that. They might or might 
not want BC installed (for instance, just an example, because of [1]). 
They might prefer different providers for a given set of algorithm 
requirements. Ultimately, it should be up to the user to decide which 
providers are set as global security provider, application should either 
rely on the installed global providers without touching them, or 
explicitly use what they want.
So I'm wondering if there's a way we could modify CXF/WSS4J/Santuario 
for using BC (or whatever we want to use ;-) ) e.g. when needing GCM 
without installing it as a global provider. Something around e.g. 
getting ciphers through the javax.crypto.Cipher#getInstance(String 
transformation, Provider provider) method instead of the 
javax.crypto.Cipher#getInstance(String transformation) after having 
loaded the provider without installing it globally, etc.

Any thought / idea?
Thanks
Alessio

[1] http://bouncycastle.org/jira/browse/BJA-19 / 
https://issues.apache.org/jira/browse/HARMONY-3789, BouncyCastle DH 
KeyPairGenerator algorithm can hang / eat lots of CPU


--
Alessio Soldano
Web Service Lead, JBoss

Re: [VOTE] CXF 2.6.15/2.7.12/3.0.1

[Alessio Soldano]

+1

On 15/07/14 21:57, Daniel Kulp wrote:

This is a vote to release the latest patch releases on all three branches.

There are over 80 fixes for 3.0.1 with most back ported to 2.7.12 and some to 
2.6.15.

Note: this is expected to be the last release of the 2.6.x branch.

Tags:
2.6.15:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=67f6d1aaba4108b4e42bb2cfee098b8e6bec8ccd
2.7.12:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=18e0bb93814c9c8d244816ed9b2ea48a30a7fb38
3.0.1:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=dffa15d68cbcea75faa138bfee7c2443ff930505


Staging repos:
2.6.15:
https://repository.apache.org/content/repositories/orgapachecxf-1024/
2.7.12
https://repository.apache.org/content/repositories/orgapachecxf-1025/
3.0.1
https://repository.apache.org/content/repositories/orgapachecxf-1026/

Vote will be open for 72 hours.





--
Alessio Soldano
Web Service Lead, JBoss

Re: Releases on Friday/Monday?

[Alessio Soldano]

OK, thanks for the explanation Colm! Let's add this to the release notes.

I agree in retrospective it would have been better to apply changes for 
versions previous to 1.49 ;-)


Cheers
Alessio

On 14/07/14 12:46, Colm O hEigeartaigh wrote:

Hi Alessio,

Some changes were made in XML Security 2.0.1 with regards to GCM support.
Namely, JDK 8 requires that javax.crypto.spec.GCMParameterSpec be used
instead of IVParameterSpec. However the former is only available as of JDK
7. So the solution was to try to load it reflectively, and to fall back on
IVParameterSpec if it is not available.

However, BouncyCastle does not add support for GCMParameterSpec until 1.50,
and there is a bug which means it won't work properly until 1.51 is
released. So the solution in WSS4J 2.0.1 is to set a system property in
Santuario to force it to use IVParametersSpec if BouncyCastle v.1.49 is in
use. In retrospect it was a mistake not to do this for BouncyCastle <=
1.49, but this was only intended to be a temporary workaround until
BouncyCastle 1.51 is released. This is why the CXF systests are working
correctly.

So in a nutshell, we require one of the following things for GCM to work
with the next set of CXF releases:

a) Upgrade to BouncyCastle 1.49 (or 1.51 when it gets released) OR
b) Set the system property
"org.apache.xml.security.cipher.gcm.useIvParameterSpec" to "true".

Colm.




On Fri, Jul 11, 2014 at 3:42 PM, Alessio Soldano 
wrote:


Hi Dan,
I started testing the JBoss integration with current 3.0.1-SNAPSHOT and
noticed some issues with the WS-Security endpoints using GCM algorithms.
After updating both JDK and BouncyCastle I got past them, but I believe
the release notes should properly clarify the actual new version
requirements and backward compatibility limitations.

The exception I had was:

Caused by: java.security.InvalidAlgorithmParameterException: unknown
parameter type.
 at org.bouncycastle.jce.provider.JCEBlockCipher.engineInit(Unknown
Source)
 at javax.crypto.Cipher.implInit(Cipher.java:791) [jce.jar:1.7.0_10]
 at javax.crypto.Cipher.chooseProvider(Cipher.java:849)
[jce.jar:1.7.0_10]
 at javax.crypto.Cipher.init(Cipher.java:1348) [jce.jar:1.7.0_10]
 at javax.crypto.Cipher.init(Cipher.java:1282) [jce.jar:1.7.0_10]
 at org.apache.xml.security.encryption.XMLCipher.
encryptData(XMLCipher.java:1184)
 at org.apache.xml.security.encryption.XMLCipher.
encryptData(XMLCipher.java:1134)
 at org.apache.xml.security.encryption.XMLCipher.encryptElementContent(
XMLCipher.java:907)
 at org.apache.xml.security.encryption.XMLCipher.doFinal(
XMLCipher.java:1038)
 at 
org.apache.wss4j.dom.message.WSSecEncrypt.encryptElement(WSSecEncrypt.java:602)
[wss4j-ws-security-dom.jar:2.0.1]
 ... 51 more

Cheers
Alessio

On 09/07/14 15:00, Daniel Kulp wrote:


Now that we have the new WSS4J releases, is there anything left
outstanding that would prevent releases of 2.6.15/2.7.12/3.0.1 later this
week or on Monday?   If not, I’ll plan on doing the releases one of those
days.

I’m really looking forward to the 2.6.x release so we can drop that
version and start the 3.1 updates for Java7.   :-)



--
Alessio Soldano
Web Service Lead, JBoss







--
Alessio Soldano
Web Service Lead, JBoss

Re: Performance issue with Content-ID computation of multipart MTOM/XOP messages

[Alessio Soldano]

On 14/07/14 11:58, Aki Yoshida wrote:

I'm not sure whether it is really necessary to make the cid part
depend on the namespace string.

If we only need to guarantee uniquness within a document, a single
thread calling the createContentID method will get a series of unique
IDs. However, as the static variable counter is not synchronously
updated, currently two threads may get the same ID value but this
situation is not relevant as long as these two threads are working on
two different documents. And even if two threads may be working on the
same document, using the namespace depending value for the cid part
won't decrease the collision chance very much as they are likely to be
using the same namespace value. If we need to guarantee uniqueness
among multiple documents, we will need a different mechanism anyway.
So, I see not much benefit in using the namespace depending variable
here.
Thanks for the consideration Aki. This is basically my first question; 
the reason why I asked about existing spec requirement is also that in 
most cases the namespace there will simply be null, so we're already 
skipping the if block very often...

I see not much benefit in the namespace usage here too.

Cheers
Alessio

--
Alessio Soldano
Web Service Lead, JBoss

Re: Performance issue with Content-ID computation of multipart MTOM/XOP messages

[Alessio Soldano]

On 14/07/14 09:54, Alessio Soldano wrote:
2) if that's required, would you mind me trying to add some 
preliminary checks to avoid the URL generation when that's clearly 
going to raise an exception (for instance by parsing the string using 
a pre-computed regular expression) ?

Apache Commons UrlValidator [1] might be a solution for this, btw.

[1] 
http://commons.apache.org/proper/commons-validator/apidocs/src-html/org/apache/commons/validator/routines/UrlValidator.html


--
Alessio Soldano
Web Service Lead, JBoss