Re: SpringWebUtils in CXF in TomEE

[Romain Manni-Bucau]

Le lun. 20 mai 2024 à 17:29, Jonathan Gallimore <
jonathan.gallim...@gmail.com> a écrit :

> Thanks Andriy and Romain for your replies.
>
> > This is quite an interesting issue, is it possible to share (or point out
> to an example) small reproducer project for this problem?
>
> Yes - here's a reproducer: https://github.com/jgallimore/demo
>
> If you clone this and run mvn clean install tomee:run, it will boot up a
> TomEE 9.1.3 (which includes CXF 4.0.4). If you invoke a GET
> http://localhost:8080/hello you'll see the error on the console.
>
> > * openejb.cxf.CxfContainerClassLoader is false
>
> This didn't work.
>
> > * cxf is in the webapp, tomee cxf services disabled and cxf packages
> "forced-load"
>
> I haven't tried this. As I noted in the original email, I would imagine
> that if this were deployed in Tomcat, and both CXF and Spring were included
> in the application's WEB-INF/lib, this would not be an issue. I suspect
> this would essentially give the same setup and I would imagine it would
> work, but I would expect we'd lose the integration functionality in TomEE
> (which we run the TCK against). Its also a big ask ask for anyone using
> JAX-RS services, and just so happens to have Spring in their application,
> as this did work ok in TomEE 9.1.2 (CXF 4.0.3).
>
> > If not it can just be to detect it in tomee and setup the webapp
> properly?
>
> Can you give me some pointers on what you mean here? I'm happy to make
> adjustments in TomEE, and equally happy to work on a suitable update for
> CXF if preferred.
>

Like we detect the slf4j api is in the webapp or not to use the container
or webapp binding it would be done the same for cxf/spring integration I
suspect.
Ideally I agree cxf should only use spring stuff if the bus is a spring one
- it is ok to not use spring with cxf but have spring ;) - but tomee can
likely workaround that.
Something like loading the class SpringWebUtils in cxfrsservice#init method
would be sufficient IMHO.


>
> Many thanks!
>
> Jon
>
> On Fri, May 17, 2024 at 3:56 AM Romain Manni-Bucau 
> wrote:
>
> > Hi Jon,
> >
> > Does it happen in the following both cases:
> >
> > * openejb.cxf.CxfContainerClassLoader is false
> > * cxf is in the webapp, tomee cxf services disabled and cxf packages
> > "forced-load"
> >
> > ?
> >
> > If not it can just be to detect it in tomee and setup the webapp
> properly?
> >
> > Le jeu. 16 mai 2024 à 23:25, Andriy Redko  a écrit :
> >
> >> Hey Jonathan,
> >>
> >> This is quite an interesting issue, is it possible to share (or point
> out
> >> to an example) small reproducer project for this problem? I think I
> >> understand
> >> what is happening but don't have a clear fix for that to suggest at the
> >> moment.
> >>
> >> Thank you.
> >>
> >> Best Regards,
> >> Andriy Redko
> >>
> >> > Hi,
> >>
> >> > Firstly, thank you for all the amazing work you do in CXF. I
> >> participate in
> >> > the Apache TomEE project, which includes CXF to enable TomEE to
> provide
> >> > REST and SOAP based services.
> >>
> >> > We've had a slightly unusual problem crop up that specifically affects
> >> > applications that expose Jakarta REST endpoints (through the included
> >> CXF
> >> > in TomEE), and include the Spring Framework in the application's
> >> > WEB-INF/lib.
> >>
> >> > The exception we see is:
> >>
> >> > java.lang.NoClassDefFoundError:
> >> > org/springframework/web/filter/ServerHttpObservationFilter
> >> > at
> >> >
> >>
> org.apache.cxf.jaxrs.springmvc.SpringWebUtils.setHttpRequestURI(SpringWebUtils.java:51)
> >> > ~[cxf-rt-frontend-jaxrs-4.0.4.jar:4.0.4]
> >> > at
> >> >
> >>
> org.apache.cxf.jaxrs.utils.HttpUtils.setHttpRequestURI(HttpUtils.java:380)
> >> > ~[cxf-rt-frontend-jaxrs-4.0.4.jar:4.0.4]
> >> > at
> >> >
> >>
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.setExchangeProperties(JAXRSInInterceptor.java:246)
> >> > ~[cxf-rt-frontend-jaxrs-4.0.4.jar:4.0.4]
> >> > at
> >> >
> >>
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:183)
> >> > ~[cxf-rt-frontend-jaxrs-4.0.4.jar:4.0.4]
> >> > at
> >> >
> >>
> org.apache.cxf.jaxr

Re: SpringWebUtils in CXF in TomEE

[Romain Manni-Bucau]

Hi Jon,

Does it happen in the following both cases:

* openejb.cxf.CxfContainerClassLoader is false
* cxf is in the webapp, tomee cxf services disabled and cxf packages
"forced-load"

?

If not it can just be to detect it in tomee and setup the webapp properly?

Le jeu. 16 mai 2024 à 23:25, Andriy Redko  a écrit :

> Hey Jonathan,
>
> This is quite an interesting issue, is it possible to share (or point out
> to an example) small reproducer project for this problem? I think I
> understand
> what is happening but don't have a clear fix for that to suggest at the
> moment.
>
> Thank you.
>
> Best Regards,
> Andriy Redko
>
> > Hi,
>
> > Firstly, thank you for all the amazing work you do in CXF. I participate
> in
> > the Apache TomEE project, which includes CXF to enable TomEE to provide
> > REST and SOAP based services.
>
> > We've had a slightly unusual problem crop up that specifically affects
> > applications that expose Jakarta REST endpoints (through the included CXF
> > in TomEE), and include the Spring Framework in the application's
> > WEB-INF/lib.
>
> > The exception we see is:
>
> > java.lang.NoClassDefFoundError:
> > org/springframework/web/filter/ServerHttpObservationFilter
> > at
> >
> org.apache.cxf.jaxrs.springmvc.SpringWebUtils.setHttpRequestURI(SpringWebUtils.java:51)
> > ~[cxf-rt-frontend-jaxrs-4.0.4.jar:4.0.4]
> > at
> >
> org.apache.cxf.jaxrs.utils.HttpUtils.setHttpRequestURI(HttpUtils.java:380)
> > ~[cxf-rt-frontend-jaxrs-4.0.4.jar:4.0.4]
> > at
> >
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.setExchangeProperties(JAXRSInInterceptor.java:246)
> > ~[cxf-rt-frontend-jaxrs-4.0.4.jar:4.0.4]
> > at
> >
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:183)
> > ~[cxf-rt-frontend-jaxrs-4.0.4.jar:4.0.4]
> > at
> >
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:78)
> > ~[cxf-rt-frontend-jaxrs-4.0.4.jar:4.0.4]
> > at
> >
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> > ~[cxf-core-4.0.4.jar:4.0.4]
> > at
> >
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> > ~[cxf-core-4.0.4.jar:4.0.4]
> > at
> >
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265)
> > ~[cxf-rt-transports-http-4.0.4.jar:4.0.4]
> > at
> >
> org.apache.openejb.server.cxf.rs.CxfRsHttpListener.doInvoke(CxfRsHttpListener.java:266)
> > ~[openejb-cxf-rs-9.1.3.jar:9.1.3]
> > at
> >
> org.apache.tomee.webservices.CXFJAXRSFilter.doFilter(CXFJAXRSFilter.java:99)
> > ~[tomee-jaxrs-9.1.3.jar:9.1.3]
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:185)
> > ~[catalina.jar:10.0.27]
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:158)
> > ~[catalina.jar:10.0.27]
> > at
> > org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
> > ~[tomcat-websocket.jar:10.0.27]
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:185)
> > ~[catalina.jar:10.0.27]
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:158)
> > ~[catalina.jar:10.0.27]
> > at
> org.apache.openejb.server.httpd.EEFilter.doFilter(EEFilter.java:67)
> > ~[openejb-http-9.1.3.jar:9.1.3]
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:185)
> > ~[catalina.jar:10.0.27]
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:158)
> > ~[catalina.jar:10.0.27]
> > at
> >
> org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:100)
> > ~[spring-web-6.0.19.jar:6.0.19]
> > at
> >
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:116)
> > ~[spring-web-6.0.19.jar:6.0.19]
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:185)
> > ~[catalina.jar:10.0.27]
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:158)
> > ~[catalina.jar:10.0.27]
> > at
> >
> org.springframework.web.filter.FormContentFilter.doFilterInternal(FormContentFilter.java:93)
> > ~[spring-web-6.0.19.jar:6.0.19]
> > at
> >
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:116)
> > ~[spring-web-6.0.19.jar:6.0.19]
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:185)
> > ~[catalina.jar:10.0.27]
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:158)
> > ~[catalina.jar:10.0.27]
> > at
> >
> org.springframework.boot.web.servlet.support.ErrorPageFilter.doFilter(ErrorPageFil

Re: [VOTE] CXF 4.0.3/3.6.2/3.5.7

[Romain Manni-Bucau]

+1 (non binding)

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 jeu. 14 sept. 2023 à 11:29, Alessio Soldano  a
écrit :

> +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 <mailto:dk...@apache.org>
> > Qlik - https://qlik.com <https://qlik.com/>
> >
>

Re: [VOTE] Apache CXF 4.0.0

[Romain Manni-Bucau]

+1 and thanks a lot for the hard work

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. 19 déc. 2022 à 18:01, Freeman Fang  a
écrit :

> +1
> Thanks everyone!
>
> Freeman
>
> On Sun, 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
> >
> >
>

Re: CXF 4.0.0 jakarta release

[Romain Manni-Bucau]

Hi,

Ok so just to clarify it means
1. the cxf-core split (soap, rs, integration) is postponed > 4.x
2. the compiler setting is updated to add release (current setup is only
source/target which does not guarantee that compiled with a jdk > version
set in pom run on a lower jdk).

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 mar. 8 nov. 2022 à 13:25, Jim Ma  a écrit :

> Yes. Spring is optional for CXF runtime for a long time.  Now all CXF
> binary classes/artifacts are all JDK-11 version (class major version
> 55) as Andriy
> mentioned
> we set target/source to JDK-11.  I believe this setting on CXF at the
> moment is the best option:
>
>- Users don't need to upgrade the JDK version if they are using CXF
>without Spring. FWIK, there are a lot of  non-Spring CXF users out
> there.
>- For the CXF Spring users, because the Spring 6 Jakarta version is
>JDK-17 baseline and built classes are JDK-17 versions(class major
> version
>61),  they have to use JDK17 in runtime to run Spring and CXF. JDK-17 is
>mandatory from Spring 6 and not from CXF.
>
>
> On Tue, Nov 8, 2022 at 2:31 AM Freeman Fang 
> wrote:
>
> > Hello,
> >
> > FWIW,  Spring isn't mandatory for CXF, cxf-core only depends on spring
> > optionally and we don't need to have spring artifacts on the classpath if
> > we don't want to use spring/spring boot features, and this has been the
> > case for a very long time.
> >
> > Freeman
> >
> > On Mon, Nov 7, 2022 at 1:22 PM Romain Manni-Bucau  >
> > wrote:
> >
> > > I was more referencing the long awaited split of cxf-core (it is still
> > the
> > > same old content than for the early jaxws time and without a modular
> > design
> > > - this is where spring comes from mainly IIRC) so for a 4.0.0 this
> sounds
> > > like a big awaited features (don't start by bringing 1.4M said
> > otherwise).
> > > Since several part of OSGi dropped I think it would be good to create
> > > cxf-spring (and maybe spring-boot thanks some generator like camel).
> > > Since next release is mainly enabling cxf to hit jakarta, it sounds
> fine
> > > for me to drop spring if the refactor is too much and would delay a lot
> > the
> > > release - agree on this one.
> > > But keeping it like that means it will stay for years so likely that
> cxf
> > 4
> > > will be the same than cxf 3 on this point which would be sad IMHO.
> > >
> > > Side note: indeed the obvious answer to that point is "v5" but it is
> > > pushing again this issue (coming from v2 ;)) and also makes the
> > versioning
> > > harder to follow if not pushed too far IMHO.
> > >
> > > Hope it makes sense.
> > >
> > > 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 à 19:10, Andriy Redko  a écrit :
> > >
> > > > Hi Romain,
> > > >
> > > > Thanks a lot for the feedback, just to clarify: we won't be dropping
> > > > Spring
> > > > (this is basically another "few months long" effort), it is merely to
> > try
> > > > to
> > > > not bring any dependency with JDK-17 baseline (== Spring / Spring
> Boot
> > at
> > > > this moment) by default. It would definitely require more work for
> the
> > > > users
> > > > to wire everything properly but at least that would allow us to
> > preserve
> > > > JDK-11
> > > > baseline. Apologies if I am rephrasing what you intended to say, just
> > an
> > > > attempt to eliminate the possible confusion.
> > > >
> > > > Thank you.
> > > >
> > > >
> > > > > Think Java 11 is a good baseline as of today 

Re: CXF 4.0.0 jakarta release

[Romain Manni-Bucau]

I was more referencing the long awaited split of cxf-core (it is still the
same old content than for the early jaxws time and without a modular design
- this is where spring comes from mainly IIRC) so for a 4.0.0 this sounds
like a big awaited features (don't start by bringing 1.4M said otherwise).
Since several part of OSGi dropped I think it would be good to create
cxf-spring (and maybe spring-boot thanks some generator like camel).
Since next release is mainly enabling cxf to hit jakarta, it sounds fine
for me to drop spring if the refactor is too much and would delay a lot the
release - agree on this one.
But keeping it like that means it will stay for years so likely that cxf 4
will be the same than cxf 3 on this point which would be sad IMHO.

Side note: indeed the obvious answer to that point is "v5" but it is
pushing again this issue (coming from v2 ;)) and also makes the versioning
harder to follow if not pushed too far IMHO.

Hope it makes sense.

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 à 19:10, Andriy Redko  a écrit :

> Hi Romain,
>
> Thanks a lot for the feedback, just to clarify: we won't be dropping
> Spring
> (this is basically another "few months long" effort), it is merely to try
> to
> not bring any dependency with JDK-17 baseline (== Spring / Spring Boot at
> this moment) by default. It would definitely require more work for the
> users
> to wire everything properly but at least that would allow us to preserve
> JDK-11
> baseline. Apologies if I am rephrasing what you intended to say, just an
> attempt to eliminate the possible confusion.
>
> Thank you.
>
>
> > Think Java 11 is a good baseline as of today - at least to enable Jakarta
> > vendors to use CXF as an implementation and pass tck.
> > +1 to drop spring if it bothers to get a first 4.0.0 release out, we can
> > 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

Re: CXF 4.0.0 jakarta release

[Romain Manni-Bucau]

Think Java 11 is a good baseline as of today - at least to enable Jakarta
vendors to use CXF as an implementation and pass tck.
+1 to drop spring if it bothers to get a first 4.0.0 release out, we can
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  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
> > >>
> >
> >
>

Re: CXF 4.0.0 jakarta release

[Romain Manni-Bucau]

+1 to release, there are too much forks out there already so better to
release partially than not release at all 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 à 14:25, Misagh  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
>

[RELEASE REQUEST] Next 3.x release?

[Romain Manni-Bucau]

Hi all,

Is it possible to get a 3.5.4 or 3.6 out to be able to get back
https://issues.apache.org/jira/browse/CXF-8732 please ?

Thanks,
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>

Re: [Proposal] CXF OSGI Jakarta EE 9.x support

[Romain Manni-Bucau]

Hi,

Think it makes sense to split a bit CXF in a strong "core" leveraging
minimal dependency (thinking strongly to servlet there which enables most
of the runtimes from standalone to EE without forgetting microprofile and
OSGi) and extract outside the core project all integrations which have
different lifecycle (spring, OSGi and friends).
Ultimately it can makes sense to move these integrations to the projects
they belong to like aries-jaxrs, karaf and spring itself 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 jeu. 3 mars 2022 à 14:10, Freeman Fang  a écrit :

> Hi Jim,
>
> +1 to comment out OSGi bit for now so this won't  block the whole Jakarta
> namespace migration work on CXF 4.x. And we can move fast without waiting
> for the OSGi spec to be JakartaEE9+ compatible.
>
> Going forward, I think we can extract the CXF OSGi/Karaf to a subproject of
> CXF,  maybe with a different release cycle(like the relationship between
> CXF and cxf-xjc-utils), and this way our "core" CXF project can offer us
> more flexibility.
>
> Apache Camel has already done the similar thing
> https://github.com/apache/camel-karaf
>
> My 2 cents.
> Best Regards
> Freeman
>
> On Wed, Mar 2, 2022 at 9:40 PM Jim Ma  wrote:
>
> > Hi,
> > I took more time to look at more things about Jakarta EE9.x support work
> > from last week.
> > Like Spring integration code, now OSGI relevant code is in different
> maven
> > modules :
> >
> > ./core/src/main/java/org/apache/cxf/bus/osgi
> >
> >
> ./rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/osgi
> > ./rt/transports/http/src/main/java/org/apache/cxf/transport/http/osgi
> > ./rt/features/logging/src/main/java/org/apache/cxf/ext/logging/osgi
> >
> >
> ./rt/transports/http-undertow/src/main/java/org/apache/cxf/transport/http_undertow/osgi
> >
> >
> ./services/sts/systests/sts-osgi/src/main/java/org/apache/cxf/systest/sts/osgi
> >
> > When CXF moves to support the Jakarta namespace,  these should be
> > changed to support Jakarta internally. But as Andriy Redko figured out on
> > the https://issues.apache.org/jira/browse/CXF-8371, the
> > OSGI dependency is one of these blockers.  From [1] and [2] OSGI Jakarta
> > release won't
> > come in the near future.  This made me think if CXF can support Jakarta
> > with OSGI as optional
> > for the first step.  That means we temporally remove these OSGI code and
> > add it back when OSGI
> > Jakarta release is ready.   What do you think ?
> >
> > [1] https://issues.apache.org/jira/browse/FELIX-6247
> > [2] https://issues.apache.org/jira/browse/FELIX-6389
> >
> > Thanks,
> > Jim
> >
>

Re: Regression on classpath tolerance in 3.5?

[Romain Manni-Bucau]

Sure, here it is https://issues.apache.org/jira/browse/CXF-8654 :)

Think it is simple enough to not be worth a PR but happy to jump on it if
it helps too.

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 mar. 8 févr. 2022 à 14:08, Andriy Redko  a écrit :

> Hey Romain,
>
> Sneaked in while we were fixing the JAX-RS TCK tests, certainly should be
> optional,
> could you please create a JIRA ticket? Thank you.
>
> Best Regards,
> Andriy Redko
>
> RMB> Hi all,
>
> RMB> Is there a known regression in 3.5.0 regarding the optional status of
> RMB> javax.activation?
>
> RMB> I'm more particularly pointing org.apache.cxf.jaxrs.utils.JAXRSUtils
> which
> RMB> requires its presence whereas it should be optional AFAIK so
> RMB> InputStreamDataSource shouldn't be hardcoded IMO.
>
>
> RMB> Wdyt?
>
> 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
> >
>
>

Regression on classpath tolerance in 3.5?

[Romain Manni-Bucau]

Hi all,

Is there a known regression in 3.5.0 regarding the optional status of
javax.activation?

I'm more particularly pointing org.apache.cxf.jaxrs.utils.JAXRSUtils which
requires its presence whereas it should be optional AFAIK so
InputStreamDataSource shouldn't be hardcoded IMO.


Wdyt?

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>

Re: [VOTE] Apache CXF 3.5.0

[Romain Manni-Bucau]

+1, upgraded meecrowave with success, thanks a lot!

Side note: I noticed there is now a cxf.fixml in the jars. From the code it
looks like a spring "boosted" option but wonder if it shouldnt end as
generated code instead of an abandonned format for future releases (in
particular due to the content of these files ;)).

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 sam. 18 déc. 2021 à 00:36, Alessio Soldano  a
écrit :

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

Re: Release 3.5.0 next week?

[Romain Manni-Bucau]

+1

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 mer. 8 déc. 2021 à 18:33, Alexey Markevich  a écrit :

> +1
>
> On 12/8/21, Daniel Kulp  wrote:
> >
> > Question for everyone:
> >
> > Would it make sense to release 3.5.0 next week?Things seem fairly
> stable
> > and I think getting it out would be a good thing.  We could then move
> master
> > to “4.0”, drop support for Java8, and likely move to Jakarta specs.
> > Possibly target a 4.0 release for Q2 or so with those big updates?
> >
> > Thoughts?
> >
> > --
> > Daniel Kulp
> > dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog
> > <http://dankulp.com/blog>
> > Talend - http://talend.com <http://coders.talend.com/>
> >
>

Re: Jakarta namespace and OSGI

[Romain Manni-Bucau]

Well, fact is that with jakarta namespace boot delegation is never needed -
javax was a bit different and harder to solve.
So if we want an OSGi solution it must not be in boot delegation -
otherwise you defeat OSGi and can only support a single version which is
only part of the full story - usages ;).

So think there are a few points:

1. Where to do spec jars. Indeed i'm biased but tempted to say this is why
Geronimo#specs are (still) there, if you all decide it is Karaf role then
we'll drop this Geronimo role at some point,
2. What to do with CXF build before the big bang? Indeed I think shade
enables to solve it elegantly where eclipse transformer is less powerful
and requires more build hacks but at the end it is to CXF core dev to pick
a solution they will maintain ;)

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. 8 nov. 2021 à 07:44, Grzegorz Grzybek  a
écrit :

> Hello
>
> Interesting and very important discussion!
>
> After all the years working with OSGi, one thing didn't change in my view
> of it - OSGi is full of contrasts. I can think of at least 3 different ways
> to make OSGi runtime like Karaf work with JakartaEE:
>
>- ClassLoading hooks that do the transformation - ivory tower approach
>without worrying about performance
>- Exposing jakarta.* packages from system bundle
>(${karaf.etc}/jre.properties) and (to be sure) boot delegation of entire
>jakarta.* package namespace
>- Simply installing Jakarta API jars as bundles (they're not as bad in
>terms of OSGi manifests - I've even pushed some PRs merged to
>jakarta.transactions API) and let them coexist with javax.* packages -
>that's what OSGi is for after all.
>
> The contrasts in OSGi are in several aspects:
>
>- OSGi is claimed to be µservices platform (remember the blog post from
>2010? https://blog.osgi.org/2010/03/services.html) and is used as
>application server
>- When used as application server, every application "deployed" into it
>can (by default) alter everything by replacing system services with
> custom,
>higher-ranked services. There's no system–application separation here
>(without special tricks)
>- OSGi encourages careful design with carefully crafted manifests and
>coupling by interfaces, while most of the applications rely on default
>configuration of bnd/bundle-maven-plugin
>- OSGi specifications are generally very well written, but when
>something goes wrong in practice, devs switch to private-packaging and
>re-exporting
>- good enough amount of Maven Central libraries are OSGi aware, but
>usually due to one-time contributions made in the golden age of OSGi,
>because library authors usually "are not OSGi developers in day-to-day
> work"
>
> So what's the solution here? I ... don't know. Recently I was working on
> making Fuse product (custom Karaf distro) running consistently on both JDK
> 8 and JDK11+. Taking into account ext/endorsed libraries for JDK8 and
> patch/opens/exports for JDK11 my decision was (after some consideration)
> clear:
>
> The more javax.* packages exported from system bundle and boot-delegated,
> the better.
>
> This was obvious for JAXB, JAX-RS, JWS, Activation APIs which were simply
> removed after JDK11 (JDK9 still contained this java.ee module) - finally!
> These should NEVER have been put into JavaSE in the first place.
> But then, I decided to put several more APIs to system bundle.
>
> So I'd rather do:
>
>- drop the OSGi promise that everything should be a bundle and put
>jakarta.* packages to boot/system classloader
>   - ${karaf.etc}/jre.properties should specify the exported packages in
>   desired versions
>   - boot-delegate jakarta.* packages
>   - Jakarta API jars don't have to be proper bundles with the above
>- however, service discovery will be a problem if the Jakarta APIs are
>boot delegated. Karaf's locator/activator can help
>   - JAXB is fine for Karaf, because Karaf requires JAXB implementation
>   anyway (feature parsing)
>   - After all - how many different Jakarta API implementations there
>   are to choose from? IMO the original promise of JavaEE (now
> JakartaEE) that
>   one can switch implementations every day didn't work well - you
> have to be
>   aware of the implementation and (IMO) you

Re: Jakarta namespace and OSGI

[Romain Manni-Bucau]

Hi JB,

You mean wrap on jakarta official bundles? Can become tricky if you want to
do it right with capabilities and resource rewriting (thinking to xml which
can be handled by shade transformers) so maybe not an actual solution?

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 sam. 6 nov. 2021 à 18:51, JB Onofré  a écrit :

> Hi
>
> My point is to include wrap spec bundle as SMX for those spec features.
>
> It should fix our issue in flexible way.
>
> Regards
> JB
>
> > Le 6 nov. 2021 à 17:59, Freeman Fang  a écrit :
> >
> > Hi JB,
> >
> > Thanks for jumping on this.
> >
> > But to be honest, I doubt this spec feature can provide such flexibility.
> >
> > Currently in Karaf we actually expose javax packages from system bundle
> 0,
> > and those classes are from bootstrap classloader.  We also use endorse
> > mechanism(for JDK8) and patch-module(for JDK9+) to use our revised
> > APIs(from karaf specs module), so in most cases, the specs in different
> > karaf features.xml are not installed because they have dependency="true"
> > flag, and the packages/versions from system bundle 0 can already meet the
> > OSGi resolution. We need use those APIs from bootstrap classloader and
> > system bundle 0 because Karaf itself needs to use some javax APIs and we
> > need to ensure those fundamental API classes only have one copy in the
> OSGi
> > container, otherwise we can run into ClassCastExceptions during runtime.
> So
> > AFAICS, once Karaf is started, it can work with javax. API or jakarta.
> API
> > is determined. And it's not a trivial task to keep both javax. API or
> > jakarta. API in a certain Karaf version,so this be a "this" or "that"
> > choice.
> >
> > Best Regards
> > Freeman
> >
> >> On Sat, Nov 6, 2021 at 11:31 AM JB Onofré  wrote:
> >>
> >> Hi guys
> >>
> >> What I proposed and started is to provide spec feature. We can have both
> >> javax and Jakarta spec features and use the one needed.
> >>
> >> That’s probably the most flexible approach.
> >>
> >> FYI Karaf 4.3.3 already includes specs feature repo that we can extend.
> >>
> >> Regards
> >> JB
> >>
> >>>> Le 6 nov. 2021 à 16:17, Freeman Fang  a
> écrit :
> >>>
> >>> Hi Romain,
> >>>
> >>> Thanks for the feedback, and please see my comments inline below.
> >>>
> >>>> On Sat, Nov 6, 2021 at 9:53 AM Romain Manni-Bucau <
> >> rmannibu...@gmail.com>
> >>>> wrote:
> >>>>
> >>>> If it helps: maven shade plugin rewrited manifest meta using
> relocation
> >>>> making it often osgi friendly at some header exception and several
> >> apache
> >>>> projects use that so can actually be trivial after all to run cxf +
> >> spec in
> >>>> osgi if all are relocated properly short term.
> >>>>
> >>> Yes, I know maven-shade-plugin, Apache Servicemix bundles/specs
> projects
> >>> use it to OSGi-fy(or simply fix OSGGi headers) non-OSGi jars. But I
> can't
> >>> follow how this can help cxf-module-jarkarta.jar(using jakarta package
> >> API)
> >>> to work in Karaf container short term, especially considering that
> Karaf
> >>> ecosystem(karaf and other projects deployed in Karaf) still lingers
> with
> >>> javax API for a while.
> >>>
> >>>>
> >>>> Long term guess geronimo would likely be a natural asf home (joined
> with
> >>>> karaf for some serious "common" spec jars).
> >>>>
> >>>
> >>>
> >>> Historically we have such specs jars from Apache Servicemix ;), and we
> >> can
> >>> also add jakarta api there if needed
> >>>
> >>> Side note: as an cxf consumer a common cxf pain is the transitive spec
> >>>> jars, making them all provided or optional would make their
> integration
> >>>> smoother so can be a low hanging fruit in this track too.
> >>>>
> >>> We surely can discuss it  further along the track.
> >>>
> >>> A

Re: Jakarta namespace and OSGI

[Romain Manni-Bucau]

Maven-shade-plugin has transformers, some are about manifest and they
rewrite the manifest with relocation rules so imports/exports can transform
javax to jakarta so long story short, if desired you can have a javax code
which runs in OSGi and a shade with relocation which runs in OSGi but with
jakarta package for (almost) free (just a transformer to adjust if the
default is not sufficient). Sounds like the best quick win to me- before
the big bang.

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 sam. 6 nov. 2021 à 17:59, Freeman Fang  a écrit :

> Hi JB,
>
> Thanks for jumping on this.
>
> But to be honest, I doubt this spec feature can provide such flexibility.
>
> Currently in Karaf we actually expose javax packages from system bundle 0,
> and those classes are from bootstrap classloader.  We also use endorse
> mechanism(for JDK8) and patch-module(for JDK9+) to use our revised
> APIs(from karaf specs module), so in most cases, the specs in different
> karaf features.xml are not installed because they have dependency="true"
> flag, and the packages/versions from system bundle 0 can already meet the
> OSGi resolution. We need use those APIs from bootstrap classloader and
> system bundle 0 because Karaf itself needs to use some javax APIs and we
> need to ensure those fundamental API classes only have one copy in the OSGi
> container, otherwise we can run into ClassCastExceptions during runtime. So
> AFAICS, once Karaf is started, it can work with javax. API or jakarta. API
> is determined. And it's not a trivial task to keep both javax. API or
> jakarta. API in a certain Karaf version,so this be a "this" or "that"
> choice.
>
> Best Regards
> Freeman
>
> On Sat, Nov 6, 2021 at 11:31 AM JB Onofré  wrote:
>
> > Hi guys
> >
> > What I proposed and started is to provide spec feature. We can have both
> > javax and Jakarta spec features and use the one needed.
> >
> > That’s probably the most flexible approach.
> >
> > FYI Karaf 4.3.3 already includes specs feature repo that we can extend.
> >
> > Regards
> > JB
> >
> > > Le 6 nov. 2021 à 16:17, Freeman Fang  a écrit
> :
> > >
> > > Hi Romain,
> > >
> > > Thanks for the feedback, and please see my comments inline below.
> > >
> > >> On Sat, Nov 6, 2021 at 9:53 AM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > >> wrote:
> > >>
> > >> If it helps: maven shade plugin rewrited manifest meta using
> relocation
> > >> making it often osgi friendly at some header exception and several
> > apache
> > >> projects use that so can actually be trivial after all to run cxf +
> > spec in
> > >> osgi if all are relocated properly short term.
> > >>
> > > Yes, I know maven-shade-plugin, Apache Servicemix bundles/specs
> projects
> > > use it to OSGi-fy(or simply fix OSGGi headers) non-OSGi jars. But I
> can't
> > > follow how this can help cxf-module-jarkarta.jar(using jakarta package
> > API)
> > > to work in Karaf container short term, especially considering that
> Karaf
> > > ecosystem(karaf and other projects deployed in Karaf) still lingers
> with
> > > javax API for a while.
> > >
> > >>
> > >> Long term guess geronimo would likely be a natural asf home (joined
> with
> > >> karaf for some serious "common" spec jars).
> > >>
> > >
> > >
> > > Historically we have such specs jars from Apache Servicemix ;), and we
> > can
> > > also add jakarta api there if needed
> > >
> > > Side note: as an cxf consumer a common cxf pain is the transitive spec
> > >> jars, making them all provided or optional would make their
> integration
> > >> smoother so can be a low hanging fruit in this track too.
> > >>
> > > We surely can discuss it  further along the track.
> > >
> > > And guys,
> > > What I want to express is that if feasible, we can get Jim's PR in if
> > it's
> > > a good start along the track, even though it's not a full support of
> all
> > > features from CXF. So that we can get feedback earlier(like run JAXRS
> TCK
> > > and see the result). Moving fo

Re: Jakarta namespace and OSGI

[Romain Manni-Bucau]

If it helps: maven shade plugin rewrited manifest meta using relocation
making it often osgi friendly at some header exception and several apache
projects use that so can actually be trivial after all to run cxf + spec in
osgi if all are relocated properly short term.

Long term guess geronimo would likely be a natural asf home (joined with
karaf for some serious "common" spec jars).

Side note: as an cxf consumer a common cxf pain is the transitive spec
jars, making them all provided or optional would make their integration
smoother so can be a low hanging fruit in this track too.

Le sam. 6 nov. 2021 à 14:02, Freeman Fang  a écrit :

> Hi Guys,
>
> In Karaf features, we use specs bundles created from Apache Servicemix,
> which are using javax package name. Also in Apache Karaf, there is a specs
> module which is also using javax package name. Given the Karaf is a
> universal OSGi container and needs to support a lot more projects(Camel,
> Activemq, OPS4J, etc) outside CXF, I don't think the ecosystem around Karaf
> can move to jakarta package name that fast.
>
> So I think we can start the jakarta package rename work from a restricted
> scope in CXF , say, Jim's PR can skip the OSGi support for now(as we still
> have cxf released jars without the jakarta classifier which have full OSGi
> support). We can see if this transformer plugin solution will work out for
> non-OSGi scenarios first.
>
> Moving forward, we can add OSGi support for CXF jakarta package name jars
> once the ecosystem in OSGi matures. IMO, ideally the best time to support
> CXF work with jakarta ee 9.1/10.0 API in OSGi container is when jakarta ee
> 9.1/10.0 API becomes the first citizen in CXF(we use jarkarta package name
> in CXF but not the transform solution)
>
> Best Regards
> Freeman
>
> On Sat, Nov 6, 2021 at 3:07 AM Romain Manni-Bucau 
> wrote:
>
> > Hi,
> >
> > There are several Karaf users, as well as aries-jaxrs which use CXF in
> > OSGi.
> > Not sure SMix will but Geronimo#specs still targets Jakarta and if needed
> > we can create all the artifacts there - it is one of the reason we didn't
> > stop doing specs, cause Jakarta does not care of OSGi, even if now the
> > licensing is better.
> >
> > 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 sam. 6 nov. 2021 à 03:00, Andriy Redko  a écrit :
> >
> > > Hi Jim,
> > >
> > > Thank you for working on this. I actually don't know about ServiceMix,
> > but
> > > over the
> > > years I have seen CXF being used inside OSGi containers along with
> Apache
> > > Camel, as
> > > well as independently, for JAX-RS / JAX-WS services. I am certain that
> > > @Freeman could
> > > provide more broader context. Thank you!
> > >
> > > Best Regards,
> > > Andriy Redko
> > >
> > > JM> Hi Andriy,
> > > JM> Sorry for the long delay about the work for
> > > JM> https://github.com/apache/cxf/pull/855
> > > JM> I tried to find some information about ServiceMix's plan about
> > jakarta
> > > JM> namespace support. I guess ServiceMix is the only user of CXF's
> OSGI
> > > stuff,
> > > JM> right ?  Any other downstream projects which consume CXF's OSGI
> > thing ?
> > >
> > > JM> Thanks,
> > > JM> Jim
> > >
> > >
> >
>

Re: Jakarta namespace and OSGI

[Romain Manni-Bucau]

Hi,

There are several Karaf users, as well as aries-jaxrs which use CXF in OSGi.
Not sure SMix will but Geronimo#specs still targets Jakarta and if needed
we can create all the artifacts there - it is one of the reason we didn't
stop doing specs, cause Jakarta does not care of OSGi, even if now the
licensing is better.

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 sam. 6 nov. 2021 à 03:00, Andriy Redko  a écrit :

> Hi Jim,
>
> Thank you for working on this. I actually don't know about ServiceMix, but
> over the
> years I have seen CXF being used inside OSGi containers along with Apache
> Camel, as
> well as independently, for JAX-RS / JAX-WS services. I am certain that
> @Freeman could
> provide more broader context. Thank you!
>
> Best Regards,
> Andriy Redko
>
> JM> Hi Andriy,
> JM> Sorry for the long delay about the work for
> JM> https://github.com/apache/cxf/pull/855
> JM> I tried to find some information about ServiceMix's plan about jakarta
> JM> namespace support. I guess ServiceMix is the only user of CXF's OSGI
> stuff,
> JM> right ?  Any other downstream projects which consume CXF's OSGI thing ?
>
> JM> Thanks,
> JM> Jim
>
>

Re: [VOTE] Apache CXF 3.4.5 and 3.3.12

[Romain Manni-Bucau]

+1

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 jeu. 30 sept. 2021 à 03:57, Andy McCright 
a écrit :

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

Re: [DISCUSS] CXF 3.5.x and beyond

[Romain Manni-Bucau]

Le ven. 3 sept. 2021 à 11:30, Jim Ma  a écrit :

>
>
> On Wed, Aug 25, 2021 at 9:39 PM Romain Manni-Bucau 
> wrote:
>
>>
>>
>> Le mer. 25 août 2021 à 13:39, Jim Ma  a écrit :
>>
>>>
>>>
>>> On Fri, Aug 20, 2021 at 2:10 PM Romain Manni-Bucau <
>>> rmannibu...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko  a écrit :
>>>>
>>>>> Hi Romain,
>>>>>
>>>>> Sorry for the delayed response. I have been thinking about your (and
>>>>> Jim) suggestions
>>>>> and came to surprising conclusion: do we actually need to officially
>>>>> release anything
>>>>> to shade/overwrite javax <-> jakarta? Generally, we could shade Spring
>>>>> or/and any other
>>>>> dependency but we would certainly not bundle it as part of CXF
>>>>> distribution (I hope you
>>>>> would agree), so not really useful unless we publish them. As such,
>>>>> probably the best
>>>>> interim solution is to document what it takes to shade CXF (javax <->
>>>>> jakarta) and let
>>>>> the end users (application/service developers) use that when needed?
>>>>> In this case
>>>>> basically CXF, Spring, Geronimo, Swagger, ... would follow the same
>>>>> shading rules. At
>>>>> least, we could start with that (documenting the shading process) and
>>>>> likely get some
>>>>> early feedback while working on full-fledged support? WDYT?
>>>>>
>>>>
>>>>
>>>> This is what is done and makes it hard for nothing to maintain/fix -
>>>> dont even look at tomee solution for shading please ;) - IMHO.
>>>> Being said it costs nothing to cxf to produce jakarta jars, that it
>>>> makes it ee 9 compliant and more consistent for all but spring usage (ee
>>>> integrators, plain tomcat 10 users etc...), I think it is worth doing it,
>>>> at minimum.
>>>> At least a jakarta jaxrs (over jakarta servlet) bundle would be a good
>>>> progress, not sure jaxws and other parts would be helpful since they tend
>>>> to be in maintainance mode from what I saw.
>>>> So IMHO the best is a shade/relocation in the parent to deliver a
>>>> jakarta artifact for all module + a few jakarta bom. But if too much -
>>>> which I can see/hear  - a jakarta jaxrs bundle would work too short term.
>>>>
>>>
>>> I agree to start with something to preview and collect more ideas to
>>> support ee9. It's good to have a branch to really start something for this
>>> topic.
>>> @Romain, do you have a prototype with shading or other tools for a
>>> jakarta jaxrs bundle or just some basic idea that we can have a look at ?
>>>
>>
>>
>> Not ready for cxf but looking at meecrowave-core pom you would have some
>> idea.
>> I just suspect pom deps need some refinement like with/without the client
>> (it is useless with java 11 now and less and less desired AFAIK).
>>
>
>  @Romain Manni-Bucau  Thanks for the update.  I
> looked at the meecrowave-core pom and understood how it transforms package
> names with the shade plugin.  Both shade plugin or eclipse transformer tool
> works for this purpose .
>
> I created one prototype project which pulls in cxf dependencies,
> transforms to jakarta namespace  and installs to local maven repository :
> https://github.com/jimma/cxf-ee9-transformer
> This doesn't need more effort and no need the code/dependency change which
> breaks/mixes with javax support codebase. It can be simply added with
> another maven module in cxf repo to produce transformed jakata cxf
> artifacts or binary distribution.  Your thoughts ?
>

If not all artifacts are proposed with jakarta support it is an option
otherwise it would need a build module to synchronize this submodule(s) to
ensure none are forgotten - this is where I prefer the classifier approach
even if it has this exclusion pitfalls - but cxf has it anyway due to its
transitive dependencies so not worse IMHO ;).


>
>

>
>
>
>
>>
>>
>>> Thanks,
>>> Jim
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>> Thank you.
>>>>>
>>>>> Best Regards,
>>>>> Andriy Redko
>>>>>
>>>>>
>>

Re: [DISCUSS] CXF 3.5.x and beyond

[Romain Manni-Bucau]

Le mer. 25 août 2021 à 13:39, Jim Ma  a écrit :

>
>
> On Fri, Aug 20, 2021 at 2:10 PM Romain Manni-Bucau 
> wrote:
>
>>
>>
>> Le jeu. 19 août 2021 à 22:45, Andriy Redko  a écrit :
>>
>>> Hi Romain,
>>>
>>> Sorry for the delayed response. I have been thinking about your (and
>>> Jim) suggestions
>>> and came to surprising conclusion: do we actually need to officially
>>> release anything
>>> to shade/overwrite javax <-> jakarta? Generally, we could shade Spring
>>> or/and any other
>>> dependency but we would certainly not bundle it as part of CXF
>>> distribution (I hope you
>>> would agree), so not really useful unless we publish them. As such,
>>> probably the best
>>> interim solution is to document what it takes to shade CXF (javax <->
>>> jakarta) and let
>>> the end users (application/service developers) use that when needed? In
>>> this case
>>> basically CXF, Spring, Geronimo, Swagger, ... would follow the same
>>> shading rules. At
>>> least, we could start with that (documenting the shading process) and
>>> likely get some
>>> early feedback while working on full-fledged support? WDYT?
>>>
>>
>>
>> This is what is done and makes it hard for nothing to maintain/fix - dont
>> even look at tomee solution for shading please ;) - IMHO.
>> Being said it costs nothing to cxf to produce jakarta jars, that it makes
>> it ee 9 compliant and more consistent for all but spring usage (ee
>> integrators, plain tomcat 10 users etc...), I think it is worth doing it,
>> at minimum.
>> At least a jakarta jaxrs (over jakarta servlet) bundle would be a good
>> progress, not sure jaxws and other parts would be helpful since they tend
>> to be in maintainance mode from what I saw.
>> So IMHO the best is a shade/relocation in the parent to deliver a jakarta
>> artifact for all module + a few jakarta bom. But if too much - which I can
>> see/hear  - a jakarta jaxrs bundle would work too short term.
>>
>
> I agree to start with something to preview and collect more ideas to
> support ee9. It's good to have a branch to really start something for this
> topic.
> @Romain, do you have a prototype with shading or other tools for a jakarta
> jaxrs bundle or just some basic idea that we can have a look at ?
>


Not ready for cxf but looking at meecrowave-core pom you would have some
idea.
I just suspect pom deps need some refinement like with/without the client
(it is useless with java 11 now and less and less desired AFAIK).


> Thanks,
> Jim
>
>
>
>
>
>
>
>
>>
>>
>>> Thank you.
>>>
>>> Best Regards,
>>> Andriy Redko
>>>
>>>
>>> RMB> I'm not sure I see why you need spring to start this work. The
>>> expected is
>>> RMB> there already so spring module can still rely on javax, be made
>>> jakarta
>>> RMB> friendly using shade plugin or alike and that's it until a spring
>>> native
>>> RMB> integration is there.
>>> RMB> Worse case cxf-spring will not be usable with jakarta - which still
>>> enabled
>>> RMB> all other usages, best case if spring makes the transition smooth
>>> is that
>>> RMB> it will work smoothly without more investment than for the rest of
>>> the
>>> RMB> build.
>>> RMB> The pro of that options is that it will reduce the number of
>>> unofficial cxf
>>> RMB> relocations sooner 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. 16 août 2021 à 23:40, Andriy Redko  a
>>> écrit :
>>>
>>> >> Hi Jim,
>>>
>>> >> I will try to answer your questions, other guys will definitely share
>>> more
>>> >> thoughts, please see mine inlined.
>>>
>>> >> >> What's the task for JDK-17 LTS preparation ?  Do we need to support
>>> >> build 3.5.0 with JDK-17 ?
>>>
>>> >> Bui

Re: [DISCUSS] CXF 3.5.x and beyond

[Romain Manni-Bucau]

Le jeu. 19 août 2021 à 22:45, Andriy Redko  a écrit :

> Hi Romain,
>
> Sorry for the delayed response. I have been thinking about your (and Jim)
> suggestions
> and came to surprising conclusion: do we actually need to officially
> release anything
> to shade/overwrite javax <-> jakarta? Generally, we could shade Spring
> or/and any other
> dependency but we would certainly not bundle it as part of CXF
> distribution (I hope you
> would agree), so not really useful unless we publish them. As such,
> probably the best
> interim solution is to document what it takes to shade CXF (javax <->
> jakarta) and let
> the end users (application/service developers) use that when needed? In
> this case
> basically CXF, Spring, Geronimo, Swagger, ... would follow the same
> shading rules. At
> least, we could start with that (documenting the shading process) and
> likely get some
> early feedback while working on full-fledged support? WDYT?
>


This is what is done and makes it hard for nothing to maintain/fix - dont
even look at tomee solution for shading please ;) - IMHO.
Being said it costs nothing to cxf to produce jakarta jars, that it makes
it ee 9 compliant and more consistent for all but spring usage (ee
integrators, plain tomcat 10 users etc...), I think it is worth doing it,
at minimum.
At least a jakarta jaxrs (over jakarta servlet) bundle would be a good
progress, not sure jaxws and other parts would be helpful since they tend
to be in maintainance mode from what I saw.
So IMHO the best is a shade/relocation in the parent to deliver a jakarta
artifact for all module + a few jakarta bom. But if too much - which I can
see/hear  - a jakarta jaxrs bundle would work too short term.


> Thank you.
>
> Best Regards,
> Andriy Redko
>
>
> RMB> I'm not sure I see why you need spring to start this work. The
> expected is
> RMB> there already so spring module can still rely on javax, be made
> jakarta
> RMB> friendly using shade plugin or alike and that's it until a spring
> native
> RMB> integration is there.
> RMB> Worse case cxf-spring will not be usable with jakarta - which still
> enabled
> RMB> all other usages, best case if spring makes the transition smooth is
> that
> RMB> it will work smoothly without more investment than for the rest of the
> RMB> build.
> RMB> The pro of that options is that it will reduce the number of
> unofficial cxf
> RMB> relocations sooner 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. 16 août 2021 à 23:40, Andriy Redko  a
> écrit :
>
> >> Hi Jim,
>
> >> I will try to answer your questions, other guys will definitely share
> more
> >> thoughts, please see mine inlined.
>
> >> >> What's the task for JDK-17 LTS preparation ?  Do we need to support
> >> build 3.5.0 with JDK-17 ?
>
> >> Build + All tests are green.
> >> Apache Karaf 4.3.3 will support JDK17 so our OSGi test suites will pass.
> >> Besides that, there is still some work to do [1] but at least we have
> >> workarounds.
>
> >> >> For Jakarta ee9 support branch 4.x with source code change to support
> >> jakarta namespace , we have to wait for spring and other
> >> >> third party dependencies jakarta ee9 ready.  Now we don't know when
> >> these dependencies are all ready and we can start this work.
>
> >> This is correct, the earliest we could expect something is Q4/2021 (fe
> >> Spring).
>
> >> >> Given there is no features added in Jakarta ee 9.1 besides the
> >> namespace change, we can provide the jakarta calssfier maven artifacts
> >> >> and binary release in 3.6.x or 4.x with transformation or other
> better
> >> approach will be enough.We provide jakarta ee9 support early,
> >> >> then we can get more feedback on this topic.
>
> >> It is definitely the option we have among others to discuss. I have no
> >> doubts that everyone has rough idea of the pros and cons
> >> each option has, as the team we are trying to pick the best path
> forward.
> >> Jakarta EE 10 is coming in Q1/2022 [2], we should keep it
> >> in mind as well.
>
> >> Thank you!
>
> >> 

Re: [DISCUSS] CXF 3.5.x and beyond

[Romain Manni-Bucau]

I'm not sure I see why you need spring to start this work. The expected is
there already so spring module can still rely on javax, be made jakarta
friendly using shade plugin or alike and that's it until a spring native
integration is there.
Worse case cxf-spring will not be usable with jakarta - which still enabled
all other usages, best case if spring makes the transition smooth is that
it will work smoothly without more investment than for the rest of the
build.
The pro of that options is that it will reduce the number of unofficial cxf
relocations sooner 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. 16 août 2021 à 23:40, Andriy Redko  a écrit :

> Hi Jim,
>
> I will try to answer your questions, other guys will definitely share more
> thoughts, please see mine inlined.
>
> >> What's the task for JDK-17 LTS preparation ?  Do we need to support
> build 3.5.0 with JDK-17 ?
>
> Build + All tests are green.
> Apache Karaf 4.3.3 will support JDK17 so our OSGi test suites will pass.
> Besides that, there is still some work to do [1] but at least we have
> workarounds.
>
> >> For Jakarta ee9 support branch 4.x with source code change to support
> jakarta namespace , we have to wait for spring and other
> >> third party dependencies jakarta ee9 ready.  Now we don't know when
> these dependencies are all ready and we can start this work.
>
> This is correct, the earliest we could expect something is Q4/2021 (fe
> Spring).
>
> >> Given there is no features added in Jakarta ee 9.1 besides the
> namespace change, we can provide the jakarta calssfier maven artifacts
> >> and binary release in 3.6.x or 4.x with transformation or other better
> approach will be enough.We provide jakarta ee9 support early,
> >> then we can get more feedback on this topic.
>
> It is definitely the option we have among others to discuss. I have no
> doubts that everyone has rough idea of the pros and cons
> each option has, as the team we are trying to pick the best path forward.
> Jakarta EE 10 is coming in Q1/2022 [2], we should keep it
> in mind as well.
>
> Thank you!
>
> [1] https://issues.apache.org/jira/browse/CXF-8407
> [2]
> https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee10/JakartaEE10#jakarta-ee-10-release-plan
>
>
> Best Regards,
> Andriy Redko
>
> JM> On Wed, Aug 11, 2021 at 8:26 PM Andriy Redko  wrote:
>
> >> Hey Jim, Romain,
>
> >> Thank you guys, I think Romain's suggestion to move 3.5.x to JDK-11
> >> baseline is good idea, we would
> >> still be maintaining 3.4.x for a while, covering JDK-8 based
> deployments.
> >> Regarding Jakarta, yes, I
> >> certainly remember the discussion regarding the build time approach,
> >> personally with time I came to the
> >> conclusion that this is not the best option for at least 2 reasons:
> >>  - differences between source vs binary artifacts are very confusing
> >> (source imports javax,
> >>binary has jakarta, or vice versa), I think we all run into that from
> >> time to time
> >>  - Jakarta is the way to go, the mainstream should have first class
> support
>
> >> Just my 5 cents, but we certainly should consider this approach as well,
> >> there are good points to
> >> follow it, summarizing what we have at the moment:
>
> >> Option #1:
> >>  - release 3.5.0 in preparation to JDK-17 LTS, keeping JDK-8 as baseline
> >>  - move master to 3.6.x (4.x?) with JDK-11 as the minimal required JDK
> >> version (Jetty 10, ...)
> >>  - branch off 5.x (4.x?) to continue the work on supporting Jakarta
> 9.0+,
> >> with JDK-11 as the minimal
> >>required JDK version (Jetty 11, ...)
>
>
> JM> What's the task for JDK-17 LTS preparation ?  Do we need to support
> build
> JM> 3.5.0 with JDK-17 ?
>
> JM> For Jakarta ee9 support branch 4.x with source code change to support
> JM> jakarta namespace , we have to wait for spring and other
> JM> third party dependencies jakarta ee9 ready.  Now we don't know when
> these
> JM> dependencies are all ready and we can start this work.
>
> JM> Given there is no features added in Jakarta ee 9.1 besides the
> namespace
> JM> change, we can provide the jakarta calssfier maven artifacts and binary
> JM> 

Re: [DISCUSS] CXF 3.5.x and beyond

[Romain Manni-Bucau]

Le mer. 11 août 2021 à 14:27, Andriy Redko  a écrit :

> Hey Jim, Romain,
>
> Thank you guys, I think Romain's suggestion to move 3.5.x to JDK-11
> baseline is good idea, we would
> still be maintaining 3.4.x for a while, covering JDK-8 based deployments.
> Regarding Jakarta, yes, I
> certainly remember the discussion regarding the build time approach,
> personally with time I came to the
> conclusion that this is not the best option for at least 2 reasons:
>  - differences between source vs binary artifacts are very confusing
> (source imports javax,
>binary has jakarta, or vice versa), I think we all run into that from
> time to time
>

Think maven shade plugin fixed that (and if you still find an issue it
easier to fix it than handling 2 branches right?).


>  - Jakarta is the way to go, the mainstream should have first class support
>

This is compatible as explained.


>
> Just my 5 cents, but we certainly should consider this approach as well,
> there are good points to
> follow it, summarizing what we have at the moment:
>
> Option #1:
>  - release 3.5.0 in preparation to JDK-17 LTS, keeping JDK-8 as baseline
>  - move master to 3.6.x (4.x?) with JDK-11 as the minimal required JDK
> version (Jetty 10, ...)
>  - branch off 5.x (4.x?) to continue the work on supporting Jakarta 9.0+,
> with JDK-11 as the minimal
>required JDK version (Jetty 11, ...)
>

Think 4/5 should stay for user features changes (like making cxf-core very
slim and jaxrs way lighter and less monolitic to quote one I have in mind
since years).
Moving its major with no impact on end users is always weird IMHO.


>
> Option #2:
>  - release 3.5.0 in preparation to JDK-17 LTS, use JDK-11 as baseline
>  - handle javax by a build setup (with api validation at build time to
> avoid regressions) and use jakarta package as main api in the project
> (Romain), or
>adding a new maven module to transform cxf artifacts with jakarta
> package name (Jim)


+1 indeed ;)


>
>
>  Option #3:
>  - release 3.5.0 in preparation to JDK-17 LTS, use JDK-11 as baseline
>  - move master to 4.x to continue the work on supporting Jakarta 9.0+,
> with JDK-11 as the minimal
>required JDK version (Jetty 11, ...)
>
> Thank you!
>
> Best Regards,
> Andriy Redko
>
>
> JM> On Wed, Aug 11, 2021 at 10:05 AM Andriy Redko 
> wrote:
>
> >> Hey guys,
>
> >> I would like to initiate (or better to say, resume) the discussion
> >> regarding CXF 3.5.x and beyond.
> >> The 3.5.x has been  in the making for quite a while but has not seen any
> >> releases yet. As far as
> >> I know, we have only pending upgrade to Apache Karaf 4.3.3 (on SNAPSHOT
> >> now) so be ready to meet
> >> JDK 17 LTS next month. I think this is a good opportunity to release
> 3.5.0
> >> but certainly looking
> >> for ideas and opinions here. Importantly, I think for 3.5.x the JDK-8
> >> should be supported as the minimal
> >> required JDK version (just an opinion since JDK-8 is still very widely
> >> used).
>
> >> On the other side, many libraries (Jetty, wss4j, ...) are bumping the
> >> baseline to JDK-11. The work
> >> @Colm is doing to update to OpenSaml 4.x [1] is a good argument to have
> >> the JDK-11+ release line. Should
> >> we have a dedicated 3.6.x or 4.x.x branch(es) for that?
>
> >> Last but not least, Jakarta 9.0+ support. Last year we briefly talked
> >> about it [2], at this moment it
> >> looks like having dedicated release line (4.x/5.x) with Jakarta
> artifacts
> >> is beneficial in long term.
> >> Large chunk [3] of work has been already done in this direction. The
> >> Spring 6 milestones with Jakarta
> >> support are expected to land in Q4/2021 [4] but I am not sure what plans
> >> Apache Karaf team has, @Freeman
> >> do you have any insights?
>
>
> JM> For Jakarta EE9 support , the another option could be adding a new
> maven
> JM> module to transform cxf artifacts
> JM> with jakarta package name. This transformed artifact can coexist with
> the
> JM> javax namespace with "jakarta" classifier,
> JM> and we don't have to maintain two branches until Jakarta EE10 and
> there are
> JM> new features added.
>
> JM> Other projects like hibernate and jackson use this shade plugin or
> Eclipse
> JM> transformer to support jakarta ee9:
>
> JM>
> https://github.com/hibernate/hibernate-orm/blob/main/hibernate-core-jakarta/hibernate-core-jakarta.gradle#L100
>
> JM>
> https://github.com/FasterXML/jackson-jaxrs-providers/blob/2.12/json/pom.xml#L115
>
>
>
> >> To summarize briefly:
> >>  - release 3.5.0 in preparation to JDK-17 LTS, keeping JDK-8 as baseline
> >>  - move master to 3.6.x (4.x?) with JDK-11 as the minimal required JDK
> >> version (Jetty 10, ...)
> >>  - branch off 5.x (4.x?) to continue the work on supporting Jakarta
> 9.0+,
> >> with JDK-11 as the minimal
> >>required JDK version (Jetty 11, ...)
>
> >> I think it is very clear that maintaining JavaEE + JDK8 / JavaEE +
> JDK11 /
> >> Jakarta + JDK11 would consume
> >> much more time from the team, but I am not

Re: [DISCUSS] CXF 3.5.x and beyond

[Romain Manni-Bucau]

Hi Andriy,

commented inline


Le mer. 11 août 2021 à 04:05, Andriy Redko  a écrit :

> Hey guys,
>
> I would like to initiate (or better to say, resume) the discussion
> regarding CXF 3.5.x and beyond.
> The 3.5.x has been  in the making for quite a while but has not seen any
> releases yet. As far as
> I know, we have only pending upgrade to Apache Karaf 4.3.3 (on SNAPSHOT
> now) so be ready to meet
> JDK 17 LTS next month. I think this is a good opportunity to release 3.5.0
> but certainly looking
> for ideas and opinions here. Importantly, I think for 3.5.x the JDK-8
> should be supported as the minimal
> required JDK version (just an opinion since JDK-8 is still very widely
> used).


That's true but it is also true no app using java 8 will be created anymore
and no existing app needs a minor upgrade (just security patches) so java
11 can be the minimal requirement there too.


>
>
> On the other side, many libraries (Jetty, wss4j, ...) are bumping the
> baseline to JDK-11. The work
> @Colm is doing to update to OpenSaml 4.x [1] is a good argument to have
> the JDK-11+ release line. Should
> we have a dedicated 3.6.x or 4.x.x branch(es) for that?
>
> Last but not least, Jakarta 9.0+ support. Last year we briefly talked
> about it [2], at this moment it
> looks like having dedicated release line (4.x/5.x) with Jakarta artifacts
> is beneficial in long term.
> Large chunk [3] of work has been already done in this direction. The
> Spring 6 milestones with Jakarta
> support are expected to land in Q4/2021 [4] but I am not sure what plans
> Apache Karaf team has, @Freeman
> do you have any insights?
>

>From my experience this requires some serious effort while a proper
shading + bom setup avoids that completely and when API will evolve it can
fully be maintained using org.apache.cxf.javaxcompat package for new API or
alike (worse case you can rewrite part of the jakarta code for javax) so
long story short master should be jakarta and javax handled with a build
configuration IMHO until you can do the backport (manually since it is not
the same packages) and systematically with a double release and doc each
time.


>
> To summarize briefly:
>  - release 3.5.0 in preparation to JDK-17 LTS, keeping JDK-8 as baseline
>  - move master to 3.6.x (4.x?) with JDK-11 as the minimal required JDK
> version (Jetty 10, ...)
>  - branch off 5.x (4.x?) to continue the work on supporting Jakarta 9.0+,
> with JDK-11 as the minimal
>required JDK version (Jetty 11, ...)
>
> I think it is very clear that maintaining JavaEE + JDK8 / JavaEE + JDK11 /
> Jakarta + JDK11 would consume
> much more time from the team, but I am not sure we have other options if
> we aim to evolve and keep CXF
> up to date. Any thought, ideas, comments, suggestions guys?


So my proposal would be:

1. min java version: 11
2. handle javax by a build setup (with api validation at build time to
avoid regressions) and use jakarta package as main api in the project

Hope it makes sense


>
>
> Thank you!
>
> [1] https://github.com/apache/cxf/tree/opensaml4
> [2]
> http://mail-archives.apache.org/mod_mbox/cxf-dev/202012.mbox/%3c1503263798.20201226124...@gmail.com%3E
> [3] https://github.com/apache/cxf/pull/737
> [4]
> https://github.com/spring-projects/spring-framework/issues/25354#issuecomment-875915960
>
> Best Regards,
> Andriy Redko
>
>

Re: [VOTE] Apache CXF 3.4.4 and 3.3.11

[Romain Manni-Bucau]

+1 thanks!

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 sam. 5 juin 2021 à 13:21, Andy McCright  a
écrit :

> +1 Thanks!
>
> On Sat, Jun 5, 2021 at 4:51 AM Francesco Chicchiriccò  >
> wrote:
>
> > On 04/06/21 21:41, Daniel Kulp wrote:
> > > This is a vote to release CXF 3.4.4 and 3.3.11.   We have fixed over 26
> > issues and it’s been over 2 months since the last releases.
> > >
> > >
> > > Staging repositories:
> > > https://repository.apache.org/content/repositories/orgapachecxf-1166 <
> > https://repository.apache.org/content/repositories/orgapachecxf-1166>
> > > https://repository.apache.org/content/repositories/orgapachecxf-1167 <
> > https://repository.apache.org/content/repositories/orgapachecxf-1167>
> > >
> > > Tags:
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=e7f5899c3b158b50b68981ef5f6c20bd960375e4
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=7c90a225dd3f2ca73cf4673e12e8092e3378caff
> >
> > +1, thanks Dan.
> > Regards.
> >
> > --
> > Francesco Chicchiriccò
> >
> > Tirasa - Open Source Excellence
> > http://www.tirasa.net/
> >
> > Member at The Apache Software Foundation
> > Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
> > http://home.apache.org/~ilgrosso/
> >
> >
>

Re: [VOTE] Apache CXF 3.4.3 and 3.3.10

[Romain Manni-Bucau]

+1

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 mar. 16 mars 2021 à 07:13, Francesco Chicchiriccò 
a écrit :

> On 15/03/21 21:59, 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
>
> +1
>
> Thanks Dan.
>
> --
> 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: Jakarta target

[Romain Manni-Bucau]

Yes, few more info hoping it helps:

1. relocation does not prevent to implement new features, it just requires
to do it using org.apache.cxf.whatever.jakarta in javax codebase and
relocate it under jakarta package so no technical blocker for relocation
(very worse case some rewriting at build time with a transformer would work
too but I dont see the need for it)
2. Karaf mainly depends on the http/jaxrs whiteboards so it is more at OSGi
level but I don't think it will be jakarta friendly right now but in a few
- same as jakarta will die or be adopted I guess. Main issue is part of
javax leaked in the http-whiteboard API (same applies with osgi-cdi spec)
so just changing the impl under the hood is not trivial without a weaver
which is back to keeping javax branch IMO.
3. Overall goal of the shade is to avoid to maintain 2 branches which is
some work but also makes it harder to contribute IMHO. This stays until
there is a real big bang in the spec and cost(new feature) > cost(to
maintain 2 branches + use the relocation) [to have used it a few it is
quite late ;)].

Jersey is a RI so must be jakarta driven, Tomcat is used to handle active
branches (always ~3) - whereas CXF is not AFAIK, not sure for Jetty. The
overall point here is that it is really linked to "how to maintain the
forks/code base*s*". Shading reduces a lot the cost whereas fork makes it
quick and fast to have something working with the new namespace but harder
to maintain in the time in general.

My 2cts

Le sam. 26 déc. 2020 à 18:43, Andriy Redko  a écrit :

> Hey guys,
>
> I have been following somewhat heated discussion on the PR. At this moment
> I personally do not see a clear, the only way to support JakartaEE 9 where
> all
> impacted parties win. I think we should also align with the others projects
> the large parts of CXF heavily depend on: Apache Karaf, Spring, WSS4J,
> Tomcat,
> Jetty, Swagger.
>
> It is clear that we want to support JakartaEE 9 and this is the way
> forward.
> Nevertheless `javax` has been declared "dead", it won't be as such for the
> next
> 3-5 years (blind guess from past experiences). So we have to live with
> both
> for the time being.
>
> What could be the strategies (mainly conclusions from
> https://github.com/apache/cxf/pull/737 and
> personal thoughts)?
> 1) "Big bang": let say 4.x is moved completely to JakartaEE 9 (
> https://github.com/apache/cxf/pull/737),
>3.5.x would stay on `javax`. AFAIK this is the route Jersey 3/2, Tomcat
> 10/9, Jetty 11/10 [1] [2]
>have taken.
>
> 2) Keep Baseline on `javax` but use Maven Shade to relocate javax ->
> jarkarta packages. This is
>well understood technique, it still require some code changes but much
> less than "big bang". It
>should work in a short term but for a long run won't be sustainable
> (the definition of "long" is
>uncertain).
>
> With respect to Spring, Apache Karaf, Swagger and others:
>  - Spring: "No immediate plans to support jakarta namespace ... Spring
> Framework 6 is likely to adopt the
>jakarta namespace at a later point." [3]
>  - Apache Karaf: I was not able to find anything related to JakartaEE 9
> support, @Freeman Fang do you have
>insights there?
>  - WSS4J: @Colm, any plans to share?
>  - Swagger: no plans yet [4]
>
> [1] https://webtide.com/renaming-from-javax-to-jakarta/
> [2] https://webtide.com/jetty-10-and-11-have-arrived/
> [3] https://github.com/spring-projects/spring-framework/issues/25354
> [4] https://github.com/swagger-api/swagger-core/issues/3836
>
> I think understanding the large picture is going to help us take a right
> approach.
> Thanks.
>
> Best Regards,
> Andriy Redko
>
>
> Saturday, December 26, 2020, 6:52:31 AM, you wrote:
>
> RMB>  Hi everyone,
>
> RMB> As a follow up of https://github.com/apache/cxf/pull/737 I'd like to
> RMB> discuss the plain to support jakarta namespace.
> RMB> To summarize the long exchanges of the thread, I think we should go
> with
> RMB> relocations (shade plugin) and that's it - more details in the thread.
> RMB> Markus wants/asked the big bang which happened on EE to happen on CXF.
> RMB> Long story short I think it would wrongly deserve end users.
>
> RMB> What do you think? Anything planned - there is no hurry indeed?
>
> 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
> >
>
>

Jakarta target

[Romain Manni-Bucau]

 Hi everyone,

As a follow up of https://github.com/apache/cxf/pull/737 I'd like to
discuss the plain to support jakarta namespace.
To summarize the long exchanges of the thread, I think we should go with
relocations (shade plugin) and that's it - more details in the thread.
Markus wants/asked the big bang which happened on EE to happen on CXF.
Long story short I think it would wrongly deserve end users.

What do you think? Anything planned - there is no hurry indeed?

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>

Re: [VOTE] CXF 3.4.2/3.3.9

[Romain Manni-Bucau]

+1 (non binding)

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 jeu. 24 déc. 2020 à 06:32, Francesco Chicchiriccò 
a écrit :

> +1, thanks Dan.
>
> Regards.
>
> On 23/12/20 20:55, Daniel Kulp wrote:
> > This is a vote to release CXF 3.4.2 and 3.3.9.   We have several fixes
> and dependency updates that would be good to get into peoples hands before
> the end of the year.
> >
> >
> > Staging repositories:
> > https://repository.apache.org/content/repositories/orgapachecxf-1162
> > https://repository.apache.org/content/repositories/orgapachecxf-1163
> >
> > Tags:
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=e95c32aa6f661f4d5078048309880d7ca28ee2fe
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=a868e153ab0513385e622f9321fdd5fe88940b67
> >
> > Vote will likely be open until at least the 28th.
> >
> >
> > Here is my +1.
>
> --
> 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: dependencies management

[Romain Manni-Bucau]

Hi Andriy,

Sure, here is a public pom - a few excludes are likely no more needed like
javax ones but overall it is working as expected like that, ie
dependency:tree is minimal and functional:
https://github.com/apache/openwebbeans-meecrowave/blob/master/meecrowave-core/pom.xml#L139

Le mer. 11 nov. 2020 à 23:07, Andriy Redko  a écrit :

> Hey Romain,
>
> I think it is worth the efforts to do housekeeping work and cleanup
> the dependencies. I am not sure we could do this as one big bang change
> but delivering iterative improvements with each release should work. The
> idea with grouping dependencies into separate POMs/BOMs should be
> implementable.
> Do you have examples of the exclusions you have seen people do most often,
> may
> be would could target those first?
>
> AFAIK we try to use optional dependencies whenever possible, indentifying
> which
> modules do not follow and fixing that would be definitely useful. Anyway,
> I think
> the exclusions should be more like an exception than a rule, if they are
> required
> in most cases, this is not good.
>
> Thanks.
>
> Best Regards,
> Andriy Redko
>
> RMB> Hi everyone,
>
> RMB> CXF dependency management is based on being self contained.
> RMB> Was not working bad years ago when it was using geronimo bundles but
> since
> RMB> some years it becomes more and more work to integrate each cxf release
> RMB> because dependencies became greedy.
>
> RMB> Here are the main challenges:
>
> RMB> 1. spec jars are using jakarta (whereas the app/soft can use javax,
> RMB> geronimo, smix and other flavors)
> RMB> 2. most modules leak not required dependencies (thinking to jta, jms,
> rmi
> RMB> out of my head)
> RMB> 3. some java 11 oriented dependencies are popping up whereas they are
> not
> RMB> needed in 80% of the cases (activation, jaxb for ex)
> RMB> 4. module rarely/never mark not required dependencies as being
> RMB> optional/provided
>
> RMB> To give you an idea, it is not uncommon to have ~15 exclusions to all
> cxf
> RMB> modules when importing them.
>
> RMB> Is it something identified? Any plan to enhance this (like having
> RMB> aggregator poms "cxf-spec", "cxf-dep-optional", "cxf-java9" to ease
> the
> RMB> exclusions? making it provided and having aggregator pom with the
> RMB> depencencies marked as required (strict module vs consumed pom
> modules))?
>
> RMB> Side note: explosing cxf-core can also help, it contains a lot of
> optional
> RMB> stuff which can also make this work harder to maintain.
>
> 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
> >
>

dependencies management

[Romain Manni-Bucau]

Hi everyone,

CXF dependency management is based on being self contained.
Was not working bad years ago when it was using geronimo bundles but since
some years it becomes more and more work to integrate each cxf release
because dependencies became greedy.

Here are the main challenges:

1. spec jars are using jakarta (whereas the app/soft can use javax,
geronimo, smix and other flavors)
2. most modules leak not required dependencies (thinking to jta, jms, rmi
out of my head)
3. some java 11 oriented dependencies are popping up whereas they are not
needed in 80% of the cases (activation, jaxb for ex)
4. module rarely/never mark not required dependencies as being
optional/provided

To give you an idea, it is not uncommon to have ~15 exclusions to all cxf
modules when importing them.

Is it something identified? Any plan to enhance this (like having
aggregator poms "cxf-spec", "cxf-dep-optional", "cxf-java9" to ease the
exclusions? making it provided and having aggregator pom with the
depencencies marked as required (strict module vs consumed pom modules))?

Side note: explosing cxf-core can also help, it contains a lot of optional
stuff which can also make this work harder to maintain.

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>

Some weirdness in oauth2 module

[Romain Manni-Bucau]

Hi CXF dev,

Reviewing and integrating the CXF OAuth2 module in Meecrowave I got some
weirdness. Opened issues about:

- https://issues.apache.org/jira/browse/CXF-8369: code_challenge_method is
not stored in authorization_code/PKCE dance so you have to hardcode the
method in your deployment which is not always desired - and can
unlikely/theoretically lead to comparing a S256 challenge with a plain
verifier. I guess it is just a matter of forwarding this value in all DTO
but wonder if there was a rational about it.
- https://issues.apache.org/jira/browse/CXF-8368: using jose state encoding
(to be stateless) the code_challenge is forwarded too late in the logic so
it makes it ignored (just inversing some calls makes it working
- https://issues.apache.org/jira/browse/CXF-8370: to call authorize
endpoint of authorization_code flow you must be logged (define a user
subject) so how are you supposed to log in using authorization_code?

Is PKCE supported or are only bricks provided? Didn't find the doc about it
.

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>

Re: [VOTE] Apache CXF 3.4.1 and 3.3.8

[Romain Manni-Bucau]

+1

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 mer. 4 nov. 2020 à 07:13, Alexey Markevich  a écrit :

> +1
>
> On 11/4/20, Jean-Baptiste Onofre  wrote:
> > +1 (non binding)
> >
> > Slight note: Karaf 4.3.0 doesn’t provide the jetty feature anymore (used
> by
> > cxf-http-jetty one). For "transition" purpose, I’m re-adding this
> feature in
> > Karaf 4.3.1 (that I will release soon). I will propose a CXF PR to
> leverage
> > capability and updated feature.
> >
> > Regards
> > JB
> >
> >> Le 3 nov. 2020 à 22:30, Daniel Kulp  a écrit :
> >>
> >>
> >> 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 <mailto:dk...@apache.org> - http://dankulp.com/blog
> >> <http://dankulp.com/blog>
> >> Talend - http://talend.com <http://coders.talend.com/>
> >
> >
>

Re: [VOTE] Apache CXF 3.4.0

[Romain Manni-Bucau]

+1

Le ven. 21 août 2020 à 08:12, Jean-Baptiste Onofre  a
écrit :

> +1 (non binding)
>
> Regards
> JB
>
> > Le 20 août 2020 à 20:28, Daniel Kulp  a écrit :
> >
> > 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
> <
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=e034b0b68e9604f4062ae1c4b719789ec51f77b6
> >
> >
> > Here is my +1!
> >
> > --
> > Daniel Kulp
> > dk...@apache.org  - http://dankulp.com/blog <
> http://dankulp.com/blog>
> > Talend - http://talend.com 
>
>

Re: [VOTE] CXF 3.3.7 and 3.2.14

[Romain Manni-Bucau]

+1 (non binding)

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 mer. 24 juin 2020 à 06:28, Jean-Baptiste Onofre  a
écrit :

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

Re: Segregate client and server logging

[Romain Manni-Bucau]

Hi Andriy,

Guess it can be neat to add "client"/"server" (or new EventTypes) to just
have different parent loggers:
https://github.com/apache/cxf/blob/4b43096d1d79d3ba8e169eff1f09b38ea3ec929e/rt/features/logging/src/main/java/org/apache/cxf/ext/logging/slf4j/Slf4jEventSender.java#L55

final String cat = "org.apache.cxf.services." + *[client|server.]* + event.
getPortTypeName().getLocalPart() + "." + event.getType();

to be concrete ;)

Then slf4j binding can be configure to split between client and server
properly.

That said, I suspect it can need the opposite, client+server in the same
file, so the reverse pattern, so it can need to be a configurable pattern
at the end (which has other benefit like putting it in the app namespace
instead of o.a.cxf.services) and being able to configure it per client
(even on the same service). So I'd make this category a feature config
personally.

Hope it makes sense.

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 ven. 24 avr. 2020 à 04:34, Andriy Redko  a écrit :

> Hello Mohana,
>
> The CXF's `org.apache.cxf.ext.logging.LoggingFeature` can be used with
> JAX-WS servers
> as well JAX-RS Endpoints and Clients (as per documentation [1]). Is it
> something you
> have found to be insufficient to segregate client / server logs (at least,
> for JAX-RS)
> or you have different idea in mind? May be some example(s) would help,
> thank you.
>
> Best Regards,
> Andriy Redko
>
> [1] https://cxf.apache.org/docs/message-logging.html
>
> MRSV> In the existing `org.apache.cxf.ext.logging.LoggingFeature`
> implementation it
> MRSV> is possible to segregate the server jaxws/jaxrs logs and It would be
> nice to
> MRSV> enhance to feature to segregate server/client logs.
>
> MRSV> Ex:  Ideally application can have jaxrs Rest API at the same time it
> can
> MRSV> have rest-client integrations.
>
> MRSV> It would be nice to have separate for logging,  Of course, we can
> achieve
> MRSV> this by introducing custom LogEventSender but it would be nice if
> the CXF
> MRSV> framework having this as a built-in feature.  I would like to submit
> a PR if
> MRSV> this proposal is agreed upon.
>
> MRSV> Ref: https://cxf.apache.org/docs/message-logging.html
>
>
>
> MRSV> --
> MRSV> Sent from: http://cxf.547215.n5.nabble.com/cxf-dev-f569328.html
>
>

Re: [VOTE] CXF 3.3.6 and 3.2.13

[Romain Manni-Bucau]

+1 (non binding)

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 jeu. 26 mars 2020 à 06:44, Jim Ma  a écrit :

> The maven-plugins/wadl2java-plugin/target/it/wadl-generate-rx/build.log has
> this failure:
> [ERROR] Plugin org.apache.cxf:cxf-wadl2java-plugin:3.3.6 or one of its
> dependencies could not be resolved: Could not find artifact
> org.apache.cxf:cxf-wadl2java-plugin:jar:3.3.6
> Looks like this requires org.apache.cxf:cxf-wadl2java-plugin:3.3.6 build
> first .
>
> On Thu, Mar 26, 2020 at 11:14 AM Andriy Redko  wrote:
>
> > Hey Jim,
> >
> > What is printed out in the log:
> > maven-plugins/wadl2java-plugin/target/it/wadl-generate-rx/build.log?
> > Is it something like "org/apache/cxf/tools/wadlto/WADLToJava has been
> > compiled by a more recent version of the Java Runtime"?
> > Thanks.
> >
> > Best Regards,
> > Andriy Redko
> >
> > JM> I tried to build cxf 3.3.6 tag with "mvn clean install -Pfastinstall"
> > and
> > JM> get these failures .
> >
> > JM> [INFO] Build Summary:
> > JM> [INFO]   Passed: 0, Failed: 2, Errors: 0, Skipped: 0
> > JM> [INFO] -[ERROR] The
> > JM> following builds failed:[ERROR] *  wadl-generate-rx/pom.xml[ERROR] *
> > JM> wsdl-artifact-resolution/pom.xml
> >
> >
> > JM> Does anyone get this same error ?
> >
> >
> >
> > JM> Cheers,
> > JM> Jim
> >
> >
> > JM> On Thu, Mar 26, 2020 at 7:35 AM Jeff Genender 
> > wrote:
> >
> > >> +1
> >
> > >> Jeff
> >
> > >> > On Mar 25, 2020, at 12:38 PM, Daniel Kulp  wrote:
> > >> >
> > >> >
> > >> > This is a vote to release CXF 3.3.6 and 3.2.13.   We’ve fixed over
> 30
> > >> JIRA issues and it’s been over 2 months since the last set of
> releases.
> > >> >
> > >> > Staging repos:
> > >> >
> https://repository.apache.org/content/repositories/orgapachecxf-1151/
> > <
> > >> https://repository.apache.org/content/repositories/orgapachecxf-1151/
> >
> > >> >
> https://repository.apache.org/content/repositories/orgapachecxf-1152/
> > <
> > >> https://repository.apache.org/content/repositories/orgapachecxf-1152/
> >
> > >> >
> > >> >
> > >> > Tags:
> > >> >
> > >>
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=118421ee51886d47caf8b279e9b7e04dae067181
> > >> <
> > >>
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=118421ee51886d47caf8b279e9b7e04dae067181
> > >> >
> > >> >
> > >>
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=b38351b34549a851a2cf1aa95e94d29089d1c598
> > >> <
> > >>
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=b38351b34549a851a2cf1aa95e94d29089d1c598
> > >> >
> > >> >
> > >> > Here is my +1
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Daniel Kulp
> > >> > dk...@apache.org <mailto:dk...@apache.org> -
> http://dankulp.com/blog
> > <
> > >> http://dankulp.com/blog>
> > >> > Talend Community Coder - http://talend.com <
> http://coders.talend.com/
> > >
> >
> >
> >
> >
>

Re: UriBuilder issue

[Romain Manni-Bucau]

Hi Jon

Sounds like the fix respects the spec now,
https://docs.oracle.com/javaee/7/api/javax/ws/rs/core/UriBuilder.html#schemeSpecificPart-java.lang.String-
implies there is no path so
https://docs.oracle.com/javaee/7/api/javax/ws/rs/core/UriBuilder.html#path-java.lang.String-
is a noop even if unnatural.

Can request a spec clarification and tck challenge IMHO to let cxf fix the
buildUriString and setUriParts methods.

A likely trivial way to fix is to test file:// protocol, tck will pass and
behavior will be more natural IMHO.

Le jeu. 23 janv. 2020 à 21:59, Jonathan Gallimore <
jonathan.gallim...@gmail.com> a écrit :

> Hi
>
> I'm looking into an issue where appending a path to file:// URI with
> UriBuilder doesn't work - this has been flagged up in TomEE 8.0.1 which is
> using CXF 3.3.4, but works ok with TomEE 7.1.1 (which uses CXF 3.1.18).
>
> In essence, this fails:
>
> UriBuilder.fromUri("file:///~/calendar").path("extra").build().toString() -
> the result is file:///~/calendar. without the "/extra" on the end. This is
> because the schemeSpecificPart field is set in this if block:
>
> https://github.com/apache/cxf/blob/e6ec5b785e67bbd2464796119a9cdcacf59598c8/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/UriBuilderImpl.java#L642-L645
> and
> is used when building the URI, so the appended path is lost.
>
> I've attempted to patch this, by adding a check for a path as well as a
> query in this if block:
>
> diff --git
>
> a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/UriBuilderImpl.java
>
> b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/UriBuilderImpl.java
> index 8de34fbb0d..26e7ca357d 100644
> ---
>
> a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/UriBuilderImpl.java
> +++
>
> b/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/UriBuilderImpl.java
> @@ -651,8 +651,9 @@ public class UriBuilderImpl extends UriBuilder
> implements Cloneable {
>  } else {
>  schemeSpecificPart = uri.getSchemeSpecificPart();
>  }
> -if (scheme != null && host == null && (query == null ||
> query.isEmpty()) && userInfo == null
> -&& uri.getSchemeSpecificPart() != null) {
> +if (scheme != null && host == null
> +&& queryEmpty() && pathEmpty() && userInfo == null
> +&& uri.getSchemeSpecificPart() != null) {
>  schemeSpecificPart = uri.getSchemeSpecificPart();
>  }
>  String theFragment = uri.getFragment();
> @@ -661,6 +662,14 @@ public class UriBuilderImpl extends UriBuilder
> implements Cloneable {
>  }
>  }
>
> +private boolean queryEmpty() {
> +return query == null || query.isEmpty();
> +}
> +
> +private boolean pathEmpty() {
> +return paths == null || paths.isEmpty();
> +}
> +
>
> This fixes the issue with the file URI above, but causes this test failure:
>
> [ERROR]   UriBuilderImplTest.testURItoStringMatchesOriginalURI:1631
> expected: but
> was:
>
> I note that this check was added in this commit:
>
> https://github.com/apache/cxf/commit/e6ec5b785e67bbd2464796119a9cdcacf59598c8
> ,
> and that references some TCK tests. Is the fakePort scenario necessary to
> pass the TCK, or is there other rationale for that case?
>
> I'm very happy to work on a PR to fix along with tests, but would
> appreciate a little guidance if there's a specific approach to take. I'll
> keep looking to find a way to handle the failing assert I mention above,
> but if I've missed something blindingly obvious, please do let me know!
>
> Many thanks
>
> Jon
>

Re: [VOTE] Apache CXF 3.3.5 and 3.2.12

[Romain Manni-Bucau]

+1 (non binding), thanks Dan

Le sam. 11 janv. 2020 à 02:47, Freeman Fang  a
écrit :

> +1
>
> Thanks!
> Freeman
>
> On Fri, Jan 10, 2020 at 5:29 PM Daniel Kulp  wrote:
>
> > After a couple of hiccups due to LDAP downtime, I was finally able to get
> > the builds staged. These releases are long overdue due to the
> > holidays.   Over 30 JIRA issues have been fixed.
> >
> >
> > Tags:
> > Buildutils-3.4.4:
> >
> >
> https://gitbox.apache.org/repos/asf?p=cxf-build-utils.git;a=tag;h=7c47996f32cf366b05223bd6e614db271158786a
> > <
> >
> https://gitbox.apache.org/repos/asf?p=cxf-build-utils.git;a=tag;h=7c47996f32cf366b05223bd6e614db271158786a
> > >
> > xjc-utils 3.3.1:
> >
> >
> https://gitbox.apache.org/repos/asf?p=cxf-xjc-utils.git;a=tag;h=3b847753d5ffa01018f03edaa4dc3175808ca0a6
> > <
> >
> https://gitbox.apache.org/repos/asf?p=cxf-xjc-utils.git;a=tag;h=3b847753d5ffa01018f03edaa4dc3175808ca0a6
> > >
> >
> > 3.2.12
> >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=33895edbf4fd5baabba94ab336b1068a33321f36
> > <
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=33895edbf4fd5baabba94ab336b1068a33321f36
> > >
> > 3.3.5:
> >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=33b4f4285601539cf4e5a5738b7a7823ccb82edc
> > <
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=33b4f4285601539cf4e5a5738b7a7823ccb82edc
> > >
> >
> > Staging areas:
> > Buildutils and XJC:
> > https://repository.apache.org/content/repositories/orgapachecxf-1148 <
> > https://repository.apache.org/content/repositories/orgapachecxf-1148>
> > 3.2.12:
> > https://repository.apache.org/content/repositories/orgapachecxf-1149 <
> > https://repository.apache.org/content/repositories/orgapachecxf-1149>
> > 3.3.5:
> > https://repository.apache.org/content/repositories/orgapachecxf-1150 <
> > https://repository.apache.org/content/repositories/orgapachecxf-1150>
> >
> >
> > Here is my +1
> >
> > --
> > Daniel Kulp
> > dk...@apache.org  - http://dankulp.com/blog <
> > http://dankulp.com/blog>
> > Talend Community Coder - http://talend.com 
> >
>

Re: WebApplicationExceptionMapper not being called

[Romain Manni-Bucau]

Hi Ivan

You can set it with a cxf interceptor or even jaxrs filter but looks like a
bug, at least the default. Default should be true only if there is no
custom mapper, not if there is any registered mapper matching and this is
known at deploy time. Guess you should open a ticket.

Le mer. 25 déc. 2019 à 15:32, Ivan Junckes Filho  a
écrit :

> It seems the issue is with:
> wae.spec.optimization property, it needs to be false or it
> webapplicationexception  will be skipped.
>
> But I can't find the way to set it to false. Property is part of
> org.apache.cxf.message.Message.
>
> Anyone can help? system.properties didn't work.
>
> On Wed, Dec 25, 2019 at 10:23 AM Ivan Junckes Filho  >
> wrote:
>
> > Hello guys, I am trying to log the exception thrown by
> > WebApplicationExceptionMapper but the exception mapper is never called.
> >
> > Instead of calling it tomee calls ExceptionUtils.convertFaultToResponse.
> > Even writing a new default exception mapper doesn't work. Anyone knows
> how
> > can I print the exception of WebApplicationException? It can be using the
> > mapper or not.
> >
> > public static  Response convertFaultToResponse(T
> ex, Message currentMessage) {
> > if (ex == null || currentMessage == null) {
> > return null;
> > }e
> > Message inMessage = currentMessage.getExchange().getInMessage();
> > Response response = null;
> > if (ex instanceof WebApplicationException) {
> > WebApplicationException webEx = (WebApplicationException)ex;
> > if (webEx.getResponse().hasEntity()
> > && webEx.getCause() == null
> > && MessageUtils.getContextualBoolean(inMessage,
> SUPPORT_WAE_SPEC_OPTIMIZATION, true)) {
> > response = webEx.getResponse();
> > }
> > }
> >
> > if (response == null) {
> > ExceptionMapper  mapper =
> >
>  
> ServerProviderFactory.getInstance(inMessage).createExceptionMapper(ex.getClass(),
> inMessage);
> > if (mapper != null) {
> > try {
> > response = mapper.toResponse(ex);
> > } catch (Throwable mapperEx) {
> >
>  inMessage.getExchange().put(JAXRSUtils.EXCEPTION_FROM_MAPPER, "true");
> > mapperEx.printStackTrace();
> > return Response.serverError().build();
> > }
> > }
> > }
> > if (response == null) {
> > Throwable unwrappedException = ex.getCause();
> > if (unwrappedException instanceof WebApplicationException) {
> > WebApplicationException webEx =
> (WebApplicationException)unwrappedException;
> > response = webEx.getResponse();
> > }
> > }
> > JAXRSUtils.setMessageContentType(currentMessage, response);
> > return response;
> > }
> >
> >
>

Re: Packaging javax.xml.ws as jakarta.xml.ws

[Romain Manni-Bucau]

Hi David,

Guess enhnacements will go in jaxrs (better router etc)
On packages, no change is the only viable option for end users (javaagent,
maven plugins, sed, etc dont work in enough envs, break the portability ee
had been after for years and requires actual work and validation - qa time)
so guess the sanest is to freeze it until there is a real need.

Just my 2cts

Le mar. 26 nov. 2019 à 21:49, David Blevins  a
écrit :

> There is a discussion and vote going on the Jakarta EE side of the fence
> as to if the following APIs should be moved from javax into jakarta
> namespaces.
>
>  - JAXB (javax.xml.bind -> jakarta.xml.bind)
>  - JAX-WS (javax.xml.ws -> jakarta.xml.ws)
>
> What "move" means is these APIs would be able to continue to evolve.  If
> they are not moved, they could still be supported but will be frozen
> forever.  At this time there is no intention of revisiting the topic in
> future Jakarta EE versions and migrating things later; it's been explicitly
> and widely voted down.
>
> So if JAXB and JAX-WS were to have a future in jakarta.xml.* that would
> need to happen during Jakarta EE 9.
>
> As this is the project at Apache that implements JAX-WS:
>
>  - Is there anyone who has ideas or desires to improve JAX-WS?
>  - If they were migrated:
>- Would javax.xml -> jakarta.xml changes be welcome?
>- Are there people willing to help or do the work?
>
> Do people have any thoughts, questions or preferences?
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
>

Re: [VOTE] Apache CXF 3.2.11

[Romain Manni-Bucau]

+1 (non binding)

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 jeu. 24 oct. 2019 à 18:33, Andrey Redko  a écrit :

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

Re: [VOTE] Apache CXF 3.3.4

[Romain Manni-Bucau]

+1 (non binding)

Le lun. 21 oct. 2019 à 21:54, 方越  a
écrit :

> +1 (binding)
> Thanks!
>
> Freeman
>
> > On Oct 21, 2019, at 3: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: 3.3.4 release on Monday

[Romain Manni-Bucau]

Hi Dan,

Would be awesome if we can get https://github.com/apache/cxf/pull/589 in.

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 ven. 18 oct. 2019 à 17:10, Daniel Kulp  a écrit :

> It’s been over 2 months since the 3.3.3 release.   Thus, I’m thinking of
> doing 3.3.4 on Monday.   If anyone has anything they think needs to be in
> it and cannot be there by Monday, let me know.   Otherwise, I’ll proceed
> with the release on Monday.
>
> Thanks!
>
> --
> 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/>
>

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

[Romain Manni-Bucau]

+1 (non binding)

Le jeu. 8 août 2019 à 20:57, Dennis Kieselhorst  a écrit :

> +1
>
> Thanks!
>
>

Re: LoggingFeature with slf4j

[Romain Manni-Bucau]

Don't have the history but looks like it is only for the MDC since LogUtils
supports slf4j. Maybe a feature to move to logutils abstraction
(org.apache.cxf.logging.MDC?)

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 sam. 27 juil. 2019 à 08:11, vEnkaTa mohAna rAo SriperumbUdUru <
mohanara...@gmail.com> a écrit :

> Why slf4j : The Simple Logging Facade for Java (SLF4J) serves as a simple
> facade or abstraction for various logging frameworks (e.g.
> *java.util.logging*, logback, log4j) allowing the end user to plug in the
> desired logging framework at *deployment* time.
> Rerf :  https://www.slf4j.org/
>
> Wrapped implementation logback, log4j and jdk14
>
> In order to give more flexibility to the users to decide which logging
> framework according to their needs.
>
> Thanks,
> Mohana Rao S V
>
> On Fri, Jul 26, 2019 at 2:52 PM Jim Ma  wrote:
>
> > Do you remember why we need slf4j dependency in cxf-rt-features-logging ?
> > Is it because it needs support MDC in
> >
> >
> https://github.com/apache/cxf/blob/master/rt/features/logging/src/main/java/org/apache/cxf/ext/logging/slf4j/Slf4jEventSender.java
> > ?
> > Can the slf4j logger  be replaced with cxf's LogUtils.getLogger and it
> > won't include a slf4j dependency if user uses jdk logging?
> >
> > Thanks,
> > Jim
> >
>

Re: The need for multi-release JAR(s)

[Romain Manni-Bucau]

Hi Andriy,

Think it makes sense but wanted to mention another option:

1. At dev time you do what you did + use ASMifer to generate
CXFJavaNxASMGenerator classes
2. You package them all normally
3. At run time you pick the right one depending java.version value,
generate the bytecode and load it through a new dedicated classloader.
Then, if you ensure you implemented a common interface you just call it
4. Still requires toolchain to test on breaking java version (surefire)

Hope it makes sense

Le jeu. 11 juil. 2019 à 04:29, Andriy Redko  a écrit :

> Hey guys,
>
> It's been a few weeks I have noticed that out builds against OpenJDK 13
> started to fail, suddenly,
> right after it entered the rampdown phase. So I started to look at the
> cause and opened the Pandora
> box. There are quite a few details squeezed into this message, but I would
> really appreciate the feedback
> for the approach being explored [1].
>
> The problem: our java2wadl plugin uses some part of Javadoc API to extract
> the documentation pieces from the
> Java classes / methods / parameters. Since OpenJDK13, this API has been
> removed completely [2], [3]. To support
> JDK13 and above, we essentially have to rewrite the implementation
> completely. However, we would face another blocker
> here: how to support JDK8-11 and JDK13+ at the same time?
>
> The solution: use multi-release JAR. This is exactly the use case this
> feature has been designed for. So what it means
> is that java2wadl has additional source folder 'src/main/java13' with
> JDK13 implementation. It would be it however there
> is another subtle complication.
>
> The complication: for multi-release JAR, the java2wadl has to be build
> with 2 JDKs (ideally), pre-JDK13 and JDK13, or
> alternatively by latest JDK13 twice, once for 'src/main/java' (using
> --release 8) and once for 'src/main/java13'
> (equivalent to --release 13). The issue is that Javadoc-related API comes
> from tools.jar, which is not in scope
> of javac's --release flag [4], it really needs to be built by JDK8. As the
> workaround, we could used --release 9 to
> mitigate this issue (since tools.jar was merged into JDK9+). This is not
> ideal (see please the next paragraph) but
> we get JDK13 builds back on track, the PR is out [1].
>
> The impact: as of now, since our release jobs are using JDK8, there is no
> impact on release artifacts BUT java2wadl
> will fail when used with JDK13+ea builds. When JDK13 is out, we could rely
> on toolchain plugin to build java2wadl with
> 2 JDKs (JDK8 and JDK13).
>
> I think this is the first real precedent when we have to deal with large
> features / API removal from JDK, whereas
> reflection served as very well before. But this is certainly not the last
> one. The tests I have done so far have
> shown that the approach works really well, depending on the JDK project
> uses, the right implementation is being
> picked up. What do you think guys, does it make sense? Any other options
> to consider?
>
> Thanks a lot!
>
> [1] https://github.com/apache/cxf/pull/566
> [2] https://bugs.openjdk.java.net/browse/JDK-8215608
> [3] https://jdk.java.net/13/release-notes
> [4] https://bugs.openjdk.java.net/browse/JDK-8199325
>
> Best Regards,
> Andriy Redko
>
>
>

Re: Some not deterministic tests in async case?

[Romain Manni-Bucau]

Le ven. 7 juin 2019 à 20:28, Andriy Redko  a écrit :

> I didn't check the "pure" server flow, but I suspect it could be impacted
> as well. For the last few weeks I
> was trying to configure Jakartee EE TCK to run against CXF (it is not very
> straightforward, but I am slowly
> getting somewhere), so we could actually catch such corner (and not only)
> cases. I will create a ticket
> shortly so we won't forget about this issue. Thanks!
>


If it helps: tomee probably has a setup IIRC, it is a particular
integration but runtime is the same so can help. Getting in touch with pmc
can surely give you some pointers at least.


> Best Regards,
> Andriy Redko
>
> RMB> Well, sadly it is the same as soon as a client can be embed in a
> server (MP is about that only case AFAIK) for the exact same point.
> RMB> In other words the question is: does the code impacts the call or a
> system more related to the app than the HTTP call itself.
> RMB> Client or server is not that important here and I think we have the
> issue both sides, no?
>
>
> RMB> Romain Manni-Bucau
> RMB> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>
> RMB> Le ven. 7 juin 2019 à 18:10, Andriy Redko  a écrit
> :
>
> RMB> Hi Romain,
>
> RMB>  Yes, there are things which worry me as well, but we are talking
> about client here, not the server. When
> RMB>  response is received, it is there, and if client disconnects, should
> not impact server or status code anyhow.
> RMB>  However, the processing chain on the client side may not be
> completed, and probably in some cases client may
> RMB>  expect a slightly different response ... For the note, MP Rest
> Client TCK does not use CXF server(s), it uses
> RMB>  Wiremock.
>
> RMB>  Best Regards,
> RMB>  Andriy Redko
>
>  RMB>> Hi Andriy,
>
>
>  RMB>> This is what I suspected and actually it triggers a question: if I
> have an interceptor which must work on the
>  RMB>> response, how can it be executed before the response is actually
> sent? Typically a 200 can become a 500 because the
>  RMB>> client disconnected or so, so if you don't behave as CXF does today
> you can have some wrong data in your interceptors - or filters if you use
> the spec directly.
>
>
>  RMB>> Personally I think we should use phases (Priorities in jaxrs IIRC)
> to support that. In other words, it should be
>  RMB>> possible to execute code after the response was actually sent but
> serialization etc happens before the completion happens.
>
>
>  RMB>> Does it make any sense?
>
>
>  RMB>> Romain
>
>
>
>  RMB>> Le ven. 7 juin 2019 à 17:45, Andriy Redko  a
> écrit :
>
>  RMB>> Hi Roman,
>
>  RMB>>  Sorry, took me a bit longer to troubleshoot the test cases but at
> this point the picture
>  RMB>>  is very clear. So yeah, test in question is not deterministic
> (flaky, in other words) due
>  RMB>>  to the way CXF handles async flows (in this case, on client side).
> The interceptors are
>  RMB>>  called in the context of the dedicated work pool. The response
> completion is tied to the moment
>  RMB>>  the stream is closed, after that the interceptors chain is
> resumed. Which essentially
>  RMB>>  is the cause why the test may fail from time to time:
>
>  RMB>>  1) Response is completed, the callback is triggered (worker
> thread), completing the CompletableFuture
>  RMB>>  2) The interceptor chain is still ongoing (worker thread)
>  RMB>>  3) The test unblocks (main thread) and proceed with assertions
>  RMB>>  4) Here we come with the timing issue
>
>  RMB>>  It turned out to be very easy to reproduce, however it also seems
> to be the issue
>  RMB>>  specific to CXF implementation. We could make the test more
> reliable (but it would leak
>  RMB>>  CXF specifics, either directly or indirectly) or we could delay
> the response completion
>  RMB>>  till the moment interceptors do actually finish the processing,
> could be not trivial change
>  RMB>>  though. Do you have any thoughts on that?
>
>
>  RMB>>  Best Regards,
>  RMB>>  Andriy Redko
>
>
>   AR>>> Hi Romain,
>
>   AR>>> Run the test suite probably few dozen times on Windows and Ubuntu
> boxes, got it failing a few times on Ubuntu (but no failures on Windows):
>
>   AR>>> [INFO] RequestHandlerClass from context returned
> com.github.tomakehurst.wiremock.http.AdminRequestHandler. Normalized mapped
> under returned 'null'
>   AR>>> [ERROR] Tests ru

Re: Some not deterministic tests in async case?

[Romain Manni-Bucau]

Well, sadly it is the same as soon as a client can be embed in a server (MP
is about that only case AFAIK) for the exact same point.
In other words the question is: does the code impacts the call or a system
more related to the app than the HTTP call itself.
Client or server is not that important here and I think we have the issue
both sides, no?

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 ven. 7 juin 2019 à 18:10, Andriy Redko  a écrit :

> Hi Romain,
>
> Yes, there are things which worry me as well, but we are talking about
> client here, not the server. When
> response is received, it is there, and if client disconnects, should not
> impact server or status code anyhow.
> However, the processing chain on the client side may not be completed, and
> probably in some cases client may
> expect a slightly different response ... For the note, MP Rest Client TCK
> does not use CXF server(s), it uses
> Wiremock.
>
> Best Regards,
> Andriy Redko
>
> RMB> Hi Andriy,
>
>
> RMB> This is what I suspected and actually it triggers a question: if I
> have an interceptor which must work on the
> RMB> response, how can it be executed before the response is actually
> sent? Typically a 200 can become a 500 because the
> RMB> client disconnected or so, so if you don't behave as CXF does today
> you can have some wrong data in your interceptors - or filters if you use
> the spec directly.
>
>
> RMB> Personally I think we should use phases (Priorities in jaxrs IIRC) to
> support that. In other words, it should be
> RMB> possible to execute code after the response was actually sent but
> serialization etc happens before the completion happens.
>
>
> RMB> Does it make any sense?
>
>
> RMB> Romain
>
>
>
> RMB> Le ven. 7 juin 2019 à 17:45, Andriy Redko  a écrit
> :
>
> RMB> Hi Roman,
>
> RMB>  Sorry, took me a bit longer to troubleshoot the test cases but at
> this point the picture
> RMB>  is very clear. So yeah, test in question is not deterministic
> (flaky, in other words) due
> RMB>  to the way CXF handles async flows (in this case, on client side).
> The interceptors are
> RMB>  called in the context of the dedicated work pool. The response
> completion is tied to the moment
> RMB>  the stream is closed, after that the interceptors chain is resumed.
> Which essentially
> RMB>  is the cause why the test may fail from time to time:
>
> RMB>  1) Response is completed, the callback is triggered (worker thread),
> completing the CompletableFuture
> RMB>  2) The interceptor chain is still ongoing (worker thread)
> RMB>  3) The test unblocks (main thread) and proceed with assertions
> RMB>  4) Here we come with the timing issue
>
> RMB>  It turned out to be very easy to reproduce, however it also seems to
> be the issue
> RMB>  specific to CXF implementation. We could make the test more reliable
> (but it would leak
> RMB>  CXF specifics, either directly or indirectly) or we could delay the
> response completion
> RMB>  till the moment interceptors do actually finish the processing,
> could be not trivial change
> RMB>  though. Do you have any thoughts on that?
>
>
> RMB>  Best Regards,
> RMB>  Andriy Redko
>
>
>  AR>> Hi Romain,
>
>  AR>> Run the test suite probably few dozen times on Windows and Ubuntu
> boxes, got it failing a few times on Ubuntu (but no failures on Windows):
>
>  AR>> [INFO] RequestHandlerClass from context returned
> com.github.tomakehurst.wiremock.http.AdminRequestHandler. Normalized mapped
> under returned 'null'
>  AR>> [ERROR] Tests run: 145, Failures: 1, Errors: 0, Skipped: 1, Time
> elapsed: 90.181 s <<< FAILURE! - in TestSuitealized mapped under returned
> 'null'
>  AR>> [ERROR]
> testAsyncInvocationInterceptorProvider(org.eclipse.microprofile.rest.client.tck.asynctests.AsyncMethodTest)
> Time elapsed: 0.103 s  <<< FAILURE!
>  AR>> java.lang.AssertionError: expected [80] but found [null]
>  AR>> at
>  AR>>
> org.eclipse.microprofile.rest.client.tck.asynctests.AsyncMethodTest.testAsyncInvocationInterceptorProvider(AsyncMethodTest.java:235)
>
>  AR>> [INFO]
>  AR>> [INFO] Results:
>  AR>> [INFO]
>  

Re: Some not deterministic tests in async case?

[Romain Manni-Bucau]

Hi Andriy,

This is what I suspected and actually it triggers a question: if I have an
interceptor which must work on the response, how can it be executed before
the response is actually sent? Typically a 200 can become a 500 because the
client disconnected or so, so if you don't behave as CXF does today you can
have some wrong data in your interceptors - or filters if you use the spec
directly.

Personally I think we should use phases (Priorities in jaxrs IIRC) to
support that. In other words, it should be possible to execute code after
the response was actually sent but serialization etc happens before the
completion happens.

Does it make any sense?

Romain


Le ven. 7 juin 2019 à 17:45, Andriy Redko  a écrit :

> Hi Roman,
>
> Sorry, took me a bit longer to troubleshoot the test cases but at this
> point the picture
> is very clear. So yeah, test in question is not deterministic (flaky, in
> other words) due
> to the way CXF handles async flows (in this case, on client side). The
> interceptors are
> called in the context of the dedicated work pool. The response completion
> is tied to the moment
> the stream is closed, after that the interceptors chain is resumed. Which
> essentially
> is the cause why the test may fail from time to time:
>
> 1) Response is completed, the callback is triggered (worker thread),
> completing the CompletableFuture
> 2) The interceptor chain is still ongoing (worker thread)
> 3) The test unblocks (main thread) and proceed with assertions
> 4) Here we come with the timing issue
>
> It turned out to be very easy to reproduce, however it also seems to be
> the issue
> specific to CXF implementation. We could make the test more reliable (but
> it would leak
> CXF specifics, either directly or indirectly) or we could delay the
> response completion
> till the moment interceptors do actually finish the processing, could be
> not trivial change
> though. Do you have any thoughts on that?
>
>
> Best Regards,
> Andriy Redko
>
>
> AR> Hi Romain,
>
> AR> Run the test suite probably few dozen times on Windows and Ubuntu
> boxes, got it failing a few times on Ubuntu (but no failures on Windows):
>
> AR> [INFO] RequestHandlerClass from context returned
> com.github.tomakehurst.wiremock.http.AdminRequestHandler. Normalized mapped
> under returned 'null'
> AR> [ERROR] Tests run: 145, Failures: 1, Errors: 0, Skipped: 1, Time
> elapsed: 90.181 s <<< FAILURE! - in TestSuitealized mapped under returned
> 'null'
> AR> [ERROR]
> testAsyncInvocationInterceptorProvider(org.eclipse.microprofile.rest.client.tck.asynctests.AsyncMethodTest)
> Time elapsed: 0.103 s  <<< FAILURE!
> AR> java.lang.AssertionError: expected [80] but found [null]
> AR> at
> AR>
> org.eclipse.microprofile.rest.client.tck.asynctests.AsyncMethodTest.testAsyncInvocationInterceptorProvider(AsyncMethodTest.java:235)
>
> AR> [INFO]
> AR> [INFO] Results:
> AR> [INFO]
> AR> [ERROR] Failures:
> AR> [ERROR]
>  
> AsyncMethodTest>Arquillian.run:138->testAsyncInvocationInterceptorProvider:235
> expected [80] but found [null]
> AR> [INFO]
> AR> [ERROR] Tests run: 145, Failures: 1, Errors: 0, Skipped: 1
> AR> [INFO]
>
> AR> Yes, you are right, the test is non-deterministic. Trying to
> understand what is going on, may take some time.
> AR> Thanks for noticing it.
>
> AR> Best Regards,
> AR> Andriy Redko
>
>
> RMB>> Hi Andriy,
>
>
> RMB>> Result is random but it is
> RMB>>
> org.eclipse.microprofile.rest.client.tck.asynctests.AsyncMethodTest.testAsyncInvocationInterceptorProvider
>
>
>
> RMB>> Le dim. 2 juin 2019 à 19:12, Andriy Redko  a
> écrit :
>
> RMB>> Hi Romain,
>
> RMB>>  Yes, the async flows are difficult to test, which test cases for MP
> rest client are
> RMB>>  intermittently failing for you? I would be able to take a look.
> Thanks.
>
> RMB>>  Best Regards,
> RMB>>  Andriy Redko
>
>  RMB>>> Hi everyone,
>
>  RMB>>> I just realize - thanks for failling test on jenkins, that part of
> the test
>  RMB>>> suite is not deterministic.
>  RMB>>> It mainly affects async calls. I found some opentracing ones -
> fixed by
>  RMB>>>
> https://github.com/apache/cxf/pull/561/commits/23cbbb9db73a74913fd4294f805032f923ffcf09
>  RMB>>> -
>  RMB>>> and there are some in MP rest client TCK (async interceptor
> provider).
>
>  RMB>>> I didn't dig deep into the root cause but I suspect we ack the
> client
>  RMB>>> before the full chain is processed on the server side.
>  RMB>>> Does it ring any bell to anyone?
>
>  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
> >
>
>
>
>

Re: Some not deterministic tests in async case?

[Romain Manni-Bucau]

Hi Andriy,

Result is random but it is
org.eclipse.microprofile.rest.client.tck.asynctests.AsyncMethodTest.testAsyncInvocationInterceptorProvider

Le dim. 2 juin 2019 à 19:12, Andriy Redko  a écrit :

> Hi Romain,
>
> Yes, the async flows are difficult to test, which test cases for MP rest
> client are
> intermittently failing for you? I would be able to take a look. Thanks.
>
> Best Regards,
> Andriy Redko
>
> RMB> Hi everyone,
>
> RMB> I just realize - thanks for failling test on jenkins, that part of
> the test
> RMB> suite is not deterministic.
> RMB> It mainly affects async calls. I found some opentracing ones - fixed
> by
> RMB>
> https://github.com/apache/cxf/pull/561/commits/23cbbb9db73a74913fd4294f805032f923ffcf09
> RMB> -
> RMB> and there are some in MP rest client TCK (async interceptor provider).
>
> RMB> I didn't dig deep into the root cause but I suspect we ack the client
> RMB> before the full chain is processed on the server side.
> RMB> Does it ring any bell to anyone?
>
> 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
> >
>
>

Re: Can LoggingFeature not depend on javax.xml.ws?

[Romain Manni-Bucau]

And it is blue/green (https://builds.apache.org/job/CXF-Trunk-PR/1206/) :)

Le sam. 1 juin 2019 à 10:57, Romain Manni-Bucau  a
écrit :

> Converted it to a PR -> https://github.com/apache/cxf/pull/561
> For now i'm waiting for some CI feedback but basic mecanism is functional
> :).
>
> 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 ven. 31 mai 2019 à 19:50, Romain Manni-Bucau  a
> écrit :
>
>> Here is a draft - I didn't rerun the build but wanted to share the idea:
>> https://github.com/rmannibucau/cxf/commit/53c3c7016ce72dab61035a5417a7bba448fc3e43.
>> The pattern is the same for all: add a nested Portable feature which is
>> preferred for jaxrs over jaxws.
>>
>> Do you think we can get a fix for the original soon - this one or another?
>> On my side I'd love to drop jaxws dead dependency ASAP in my apps which
>> are using logging feature and gzip feature.
>>
>> 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 ven. 31 mai 2019 à 18:38, Romain Manni-Bucau 
>> a écrit :
>>
>>> Created https://issues.apache.org/jira/browse/CXF-8053 to try to
>>> summarize it, feel free to comment/adjust the description if I miss
>>> anything.
>>>
>>> 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 ven. 31 mai 2019 à 18:17, Daniel Kulp  a écrit :
>>>
>>>>
>>>>
>>>> > On May 31, 2019, at 11:09 AM, Romain Manni-Bucau <
>>>> rmannibu...@gmail.com> wrote:
>>>> >
>>>> > Hmm, wouldn't a jaxws factory be a good replacement. So plan would be
>>>>
>>>> I’d prefer not as then you’d have a different programming model for
>>>> jax-ws built in features (MTOMFeature, AddressingFeature) and CXF provided
>>>> features.  And of course there is the “it would break everyone’s existing
>>>> code” issue.
>>>>
>>>> Having the JAX-WS versions wrapper/delegate to the native versions
>>>> would be fine and should be mostly seamless.   For the most part, there
>>>> aren’t any protected fields or anything that subclasses would be using so
>>>> it should work.
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>> > 1. deprecate current impl
>>>> > 2. replace them by CxfFeature native implementations (+ delegation
>>>> for 1)
>>>> > 3. provide a WSFeature.convert(cxfFeature) factory, also cxf can
>>>> surely
>>>> > wrap them automatically in its impl.
>>>> >
>>>> > wdyt?
>>>> >
>>>> > Romain Manni-Bucau
>>>> > @rmannibucau <https://twitter.com/rmannibucau <
>>>> https://twitter.com/rmannibucau>> |  Blog
>>>> > <https://rmannibucau.metawerx.net/ <https://rmannibucau.metawerx.net/>>
>>>> | Old Blog
>>>> > <http://rmannibucau.wordpress.com <http://rmannibucau.wordpress.com/>>
>>>> | Github <https://github.com/rmannibucau <
>>>> https://github.com/rmannibucau>> |
>>>> > LinkedIn <https://www.linkedin.com/in/rmannibucau <
>>>> https://www.linkedin.com/in/rmannibucau>> | Book
>>>> > <
>>>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>>> <
>>>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>>

Some not deterministic tests in async case?

[Romain Manni-Bucau]

Hi everyone,

I just realize - thanks for failling test on jenkins, that part of the test
suite is not deterministic.
It mainly affects async calls. I found some opentracing ones - fixed by
https://github.com/apache/cxf/pull/561/commits/23cbbb9db73a74913fd4294f805032f923ffcf09
-
and there are some in MP rest client TCK (async interceptor provider).

I didn't dig deep into the root cause but I suspect we ack the client
before the full chain is processed on the server side.
Does it ring any bell to anyone?

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>

Bypass archiving on PR?

[Romain Manni-Bucau]

Hello everyone,

Is it intended that jenkins builds for pull-requests archive artifacts? It
takes quite some time so I wonder if it can be turned off for PR to save
some cycles - in particular when it fails ;).

Corollar potentially being: why not just turning it on for master?

Wdyt?

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>

Re: Can LoggingFeature not depend on javax.xml.ws?

[Romain Manni-Bucau]

Converted it to a PR -> https://github.com/apache/cxf/pull/561
For now i'm waiting for some CI feedback but basic mecanism is functional
:).

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 ven. 31 mai 2019 à 19:50, Romain Manni-Bucau  a
écrit :

> Here is a draft - I didn't rerun the build but wanted to share the idea:
> https://github.com/rmannibucau/cxf/commit/53c3c7016ce72dab61035a5417a7bba448fc3e43.
> The pattern is the same for all: add a nested Portable feature which is
> preferred for jaxrs over jaxws.
>
> Do you think we can get a fix for the original soon - this one or another?
> On my side I'd love to drop jaxws dead dependency ASAP in my apps which
> are using logging feature and gzip feature.
>
> 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 ven. 31 mai 2019 à 18:38, Romain Manni-Bucau  a
> écrit :
>
>> Created https://issues.apache.org/jira/browse/CXF-8053 to try to
>> summarize it, feel free to comment/adjust the description if I miss
>> anything.
>>
>> 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 ven. 31 mai 2019 à 18:17, Daniel Kulp  a écrit :
>>
>>>
>>>
>>> > On May 31, 2019, at 11:09 AM, Romain Manni-Bucau <
>>> rmannibu...@gmail.com> wrote:
>>> >
>>> > Hmm, wouldn't a jaxws factory be a good replacement. So plan would be
>>>
>>> I’d prefer not as then you’d have a different programming model for
>>> jax-ws built in features (MTOMFeature, AddressingFeature) and CXF provided
>>> features.  And of course there is the “it would break everyone’s existing
>>> code” issue.
>>>
>>> Having the JAX-WS versions wrapper/delegate to the native versions would
>>> be fine and should be mostly seamless.   For the most part, there aren’t
>>> any protected fields or anything that subclasses would be using so it
>>> should work.
>>>
>>> Dan
>>>
>>>
>>>
>>> > 1. deprecate current impl
>>> > 2. replace them by CxfFeature native implementations (+ delegation for
>>> 1)
>>> > 3. provide a WSFeature.convert(cxfFeature) factory, also cxf can surely
>>> > wrap them automatically in its impl.
>>> >
>>> > wdyt?
>>> >
>>> > Romain Manni-Bucau
>>> > @rmannibucau <https://twitter.com/rmannibucau <
>>> https://twitter.com/rmannibucau>> |  Blog
>>> > <https://rmannibucau.metawerx.net/ <https://rmannibucau.metawerx.net/>>
>>> | Old Blog
>>> > <http://rmannibucau.wordpress.com <http://rmannibucau.wordpress.com/>>
>>> | Github <https://github.com/rmannibucau <https://github.com/rmannibucau>>
>>> |
>>> > LinkedIn <https://www.linkedin.com/in/rmannibucau <
>>> https://www.linkedin.com/in/rmannibucau>> | Book
>>> > <
>>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> <
>>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> >>
>>> >
>>> >
>>> > Le ven. 31 mai 2019 à 17:00, Daniel Kulp >> dk...@apache.org>> a écrit :
>>> >
>>> >>
>>> >>
>>> >>> On May 31, 2019, at 10:54 AM, Romain Manni-Bucau <
>>> rmannibu...@gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> Was not thinking to drop it from the parent but more to get soap free
>>> >>> flavors of cxf features which would then be usabl

Re: Can LoggingFeature not depend on javax.xml.ws?

[Romain Manni-Bucau]

Here is a draft - I didn't rerun the build but wanted to share the idea:
https://github.com/rmannibucau/cxf/commit/53c3c7016ce72dab61035a5417a7bba448fc3e43.
The pattern is the same for all: add a nested Portable feature which is
preferred for jaxrs over jaxws.

Do you think we can get a fix for the original soon - this one or another?
On my side I'd love to drop jaxws dead dependency ASAP in my apps which are
using logging feature and gzip feature.

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 ven. 31 mai 2019 à 18:38, Romain Manni-Bucau  a
écrit :

> Created https://issues.apache.org/jira/browse/CXF-8053 to try to
> summarize it, feel free to comment/adjust the description if I miss
> anything.
>
> 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 ven. 31 mai 2019 à 18:17, Daniel Kulp  a écrit :
>
>>
>>
>> > On May 31, 2019, at 11:09 AM, Romain Manni-Bucau 
>> wrote:
>> >
>> > Hmm, wouldn't a jaxws factory be a good replacement. So plan would be
>>
>> I’d prefer not as then you’d have a different programming model for
>> jax-ws built in features (MTOMFeature, AddressingFeature) and CXF provided
>> features.  And of course there is the “it would break everyone’s existing
>> code” issue.
>>
>> Having the JAX-WS versions wrapper/delegate to the native versions would
>> be fine and should be mostly seamless.   For the most part, there aren’t
>> any protected fields or anything that subclasses would be using so it
>> should work.
>>
>> Dan
>>
>>
>>
>> > 1. deprecate current impl
>> > 2. replace them by CxfFeature native implementations (+ delegation for
>> 1)
>> > 3. provide a WSFeature.convert(cxfFeature) factory, also cxf can surely
>> > wrap them automatically in its impl.
>> >
>> > wdyt?
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau <https://twitter.com/rmannibucau <
>> https://twitter.com/rmannibucau>> |  Blog
>> > <https://rmannibucau.metawerx.net/ <https://rmannibucau.metawerx.net/>>
>> | Old Blog
>> > <http://rmannibucau.wordpress.com <http://rmannibucau.wordpress.com/>>
>> | Github <https://github.com/rmannibucau <https://github.com/rmannibucau>>
>> |
>> > LinkedIn <https://www.linkedin.com/in/rmannibucau <
>> https://www.linkedin.com/in/rmannibucau>> | Book
>> > <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >>
>> >
>> >
>> > Le ven. 31 mai 2019 à 17:00, Daniel Kulp > dk...@apache.org>> a écrit :
>> >
>> >>
>> >>
>> >>> On May 31, 2019, at 10:54 AM, Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> >> wrote:
>> >>>
>> >>> Was not thinking to drop it from the parent but more to get soap free
>> >>> flavors of cxf features which would then be usable in jaxrs apps
>> without
>> >>> any issue.
>> >>> In other words we would get a cxf.AbstractCxfFeature used as base for
>> all
>> >>> impl and current existing ones would be deprecated and would delegate
>> to
>> >>> the new ones. No backward compat issue I think.
>> >>
>> >> We cannot deprecate them as they would still be required for JAX-WS
>> >> users.We then have extra naming issues which can be confusing.
>> >> “LoggingFeature” is the jax-ws one, what is the non-jax-ws one called?
>> >> Maybe prefix them all with CXF like “CXFLoggingFeature”.
>> >>
>> >>
>> >>
>> >> --
>> >> Daniel Kulp
>> >> dk...@apache.org <mailto:dk...@apache.org> <mailto:dk...@apache.org
>> <mailto:dk...@apache.org>> - http://dankulp.com/blog <
>> http://dankulp.com/blog> <
>> >> http://dankulp.com/blog <http://dankulp.com/blog>>
>> >> Talend Community Coder - http://talend.com <http://talend.com/> <
>> http://coders.talend.com/ <http://coders.talend.com/>>
>>
>> --
>> 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/>
>>
>

Re: Can LoggingFeature not depend on javax.xml.ws?

[Romain Manni-Bucau]

Created https://issues.apache.org/jira/browse/CXF-8053 to try to summarize
it, feel free to comment/adjust the description if I miss anything.

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 ven. 31 mai 2019 à 18:17, Daniel Kulp  a écrit :

>
>
> > On May 31, 2019, at 11:09 AM, Romain Manni-Bucau 
> wrote:
> >
> > Hmm, wouldn't a jaxws factory be a good replacement. So plan would be
>
> I’d prefer not as then you’d have a different programming model for jax-ws
> built in features (MTOMFeature, AddressingFeature) and CXF provided
> features.  And of course there is the “it would break everyone’s existing
> code” issue.
>
> Having the JAX-WS versions wrapper/delegate to the native versions would
> be fine and should be mostly seamless.   For the most part, there aren’t
> any protected fields or anything that subclasses would be using so it
> should work.
>
> Dan
>
>
>
> > 1. deprecate current impl
> > 2. replace them by CxfFeature native implementations (+ delegation for 1)
> > 3. provide a WSFeature.convert(cxfFeature) factory, also cxf can surely
> > wrap them automatically in its impl.
> >
> > wdyt?
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau <
> https://twitter.com/rmannibucau>> |  Blog
> > <https://rmannibucau.metawerx.net/ <https://rmannibucau.metawerx.net/>>
> | Old Blog
> > <http://rmannibucau.wordpress.com <http://rmannibucau.wordpress.com/>>
> | Github <https://github.com/rmannibucau <https://github.com/rmannibucau>>
> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau <
> https://www.linkedin.com/in/rmannibucau>> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>
> >
> >
> > Le ven. 31 mai 2019 à 17:00, Daniel Kulp  dk...@apache.org>> a écrit :
> >
> >>
> >>
> >>> On May 31, 2019, at 10:54 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> >> wrote:
> >>>
> >>> Was not thinking to drop it from the parent but more to get soap free
> >>> flavors of cxf features which would then be usable in jaxrs apps
> without
> >>> any issue.
> >>> In other words we would get a cxf.AbstractCxfFeature used as base for
> all
> >>> impl and current existing ones would be deprecated and would delegate
> to
> >>> the new ones. No backward compat issue I think.
> >>
> >> We cannot deprecate them as they would still be required for JAX-WS
> >> users.We then have extra naming issues which can be confusing.
> >> “LoggingFeature” is the jax-ws one, what is the non-jax-ws one called?
> >> Maybe prefix them all with CXF like “CXFLoggingFeature”.
> >>
> >>
> >>
> >> --
> >> Daniel Kulp
> >> dk...@apache.org <mailto:dk...@apache.org> <mailto:dk...@apache.org
> <mailto:dk...@apache.org>> - http://dankulp.com/blog <
> http://dankulp.com/blog> <
> >> http://dankulp.com/blog <http://dankulp.com/blog>>
> >> Talend Community Coder - http://talend.com <http://talend.com/> <
> http://coders.talend.com/ <http://coders.talend.com/>>
>
> --
> 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/>
>

Re: Can LoggingFeature not depend on javax.xml.ws?

[Romain Manni-Bucau]

Hmm, wouldn't a jaxws factory be a good replacement. So plan would be

1. deprecate current impl
2. replace them by CxfFeature native implementations (+ delegation for 1)
3. provide a WSFeature.convert(cxfFeature) factory, also cxf can surely
wrap them automatically in its impl.

wdyt?

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 ven. 31 mai 2019 à 17:00, Daniel Kulp  a écrit :

>
>
> > On May 31, 2019, at 10:54 AM, Romain Manni-Bucau 
> wrote:
> >
> > Was not thinking to drop it from the parent but more to get soap free
> > flavors of cxf features which would then be usable in jaxrs apps without
> > any issue.
> > In other words we would get a cxf.AbstractCxfFeature used as base for all
> > impl and current existing ones would be deprecated and would delegate to
> > the new ones. No backward compat issue I think.
>
> We cannot deprecate them as they would still be required for JAX-WS
> users.We then have extra naming issues which can be confusing.
>  “LoggingFeature” is the jax-ws one, what is the non-jax-ws one called?
>  Maybe prefix them all with CXF like “CXFLoggingFeature”.
>
>
>
> --
> 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/>
>

Re: Can LoggingFeature not depend on javax.xml.ws?

[Romain Manni-Bucau]

Was not thinking to drop it from the parent but more to get soap free
flavors of cxf features which would then be usable in jaxrs apps without
any issue.
In other words we would get a cxf.AbstractCxfFeature used as base for all
impl and current existing ones would be deprecated and would delegate to
the new ones. No backward compat issue I think.

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 ven. 31 mai 2019 à 16:49, Daniel Kulp  a écrit :

>
>
> > I just realized LoggingFeature depends on javax.xml.ws.WebServiceFeature
> >
> > Is it possible to drop that dependency in the target to run on java ~11
> > without javax.xml.ws dependencies?
>
> Certainly not without breaking compatibility and everyone using any of the
> CXF provided features.   AbstractFeature (in core) subclasses
> WebServiceFeature so that any of the features can be added directly to any
> of the jax-ws endpoints/clients directly and everyone using them does so.
>  Thus, removing that as a parent would completely break everyone.
>
>
> --
> 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/>
>

Can LoggingFeature not depend on javax.xml.ws?

[Romain Manni-Bucau]

Hi everyone,

I just realized LoggingFeature depends on javax.xml.ws.WebServiceFeature

Is it possible to drop that dependency in the target to run on java ~11
without javax.xml.ws dependencies?

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>

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

[Romain Manni-Bucau]

+1, will just note that ClassUnwrapper got a new method with no default -
not really trivial to impl - so implementations are broken. Don't think it
is a blocker because it is mainly an integrator API and not an user API.

Romain Manni-Bucau
@rmannibucau <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 ven. 10 mai 2019 à 17:58, Andrey Redko  a écrit :

> +1, Andriy
>
> Best Regards,
> Andriy Redko
>
> On Fri, May 10, 2019, 11:36 AM Daniel Kulp  wrote:
>
> >
> > This is vote to release CXF 3.2.9 and CXF 3.3.2.   3.3.2 also required
> the
> > release of cxf-build-utils 3.4.2 to pickup the new PMD config required by
> > the new PMD maven plugin.  This fixes over 30 JIRA issues reported by
> > users.
> >
> >
> > Staging areas:
> > 3.2.9:
> > https://repository.apache.org/content/repositories/orgapachecxf-1140
> > 3.3.2 + buildutils:
> > https://repository.apache.org/content/repositories/orgapachecxf-1141
> >
> > Tags:
> > 3.2.9:
> >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=45bbf578434ed66e03a3488d4dedea77a1a3e855
> > <
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=45bbf578434ed66e03a3488d4dedea77a1a3e855
> > >
> > 3.3.2:
> >
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=ea9dc8805f5c4aca142c574bc9758b56d14460c6
> > <
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=ea9dc8805f5c4aca142c574bc9758b56d14460c6
> > >
> > buildutils:
> >
> >
> https://gitbox.apache.org/repos/asf?p=cxf-build-utils.git;a=tag;h=4363ce17b167077b56543c3b7aa00b4c118782c3
> > <
> >
> https://gitbox.apache.org/repos/asf?p=cxf-build-utils.git;a=tag;h=4363ce17b167077b56543c3b7aa00b4c118782c3
> > >
> >
> > Here is my +1
> >
> > --
> > Daniel Kulp
> > dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog <
> > http://dankulp.com/blog>
> > Talend Community Coder - http://talend.com <http://coders.talend.com/>
> >
>

Re: http sig implementation

[Romain Manni-Bucau]

Hi David,

I can't share the signature/digest code since it is not OS but I did a
quick prototype to try to share the idea:
https://github.com/rmannibucau/signature-digest-cxf-arch

Hope it makes sense

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 mer. 10 avr. 2019 à 00:21, David Karlsen  a
écrit :

> Hmm, do you have any example code which does this?
>
> man. 8. apr. 2019 kl. 06:43 skrev Romain Manni-Bucau <
> rmannibu...@gmail.com>:
>
>> Hi guys,
>>
>> You can ensure digest interceptor or filter is executed before the
>> signature one, that digest one adds a property which supports a completion
>> callback and if signature uses digest and the property is there it uses it
>> - else it throws an exception requesting the user to register the digest
>> filter. The only trick is to replace the outputstream in that case to
>> prevent headers writing before it is computed but nothing crazy with
>> interceptors, didnt try with filters.
>>
>> Le lun. 8 avr. 2019 à 00:33, David Karlsen  a
>> écrit :
>>
>>> Hm - came to think about this again:
>>> * filters always run before interceptors
>>> * Interceptors only run if there is a message-body (and digest only
>>> happens
>>> for message-bodies)
>>>
>>> So I guess the most viable option is:
>>>
>>> * have a filter which does signing if no message-body
>>> * have an interceptor which does digest + signing
>>>
>>> Or would it be possible to replace the outputstream in a filter with
>>> a CachedOutputStream and hook into any lifecycle where the entity-body
>>> has
>>> been written to it, but not yet streamed onto the wire?
>>>
>>> Also note that the digest is not strictly required by the spec:
>>> https://tools.ietf.org/html/draft-cavage-http-signatures-10#page-8 and
>>> as
>>> such should probably be configurable to run or not.
>>>
>>> WDYT?
>>>
>>>
>>> lør. 6. apr. 2019 kl. 12:00 skrev David Karlsen >> >:
>>>
>>> > I think the signature filter should become a writer interceptor
>>> instead:
>>> >
>>> https://access.redhat.com/documentation/en-us/red_hat_jboss_fuse/6.2/html/apache_cxf_development_guide/JAXRS20Filters#JAXRS20Filters-Intro-FigCSFIEP
>>> > It runs later - so that hooking into that phase - any other headers
>>> can be
>>> > set - including the digest one - and then adjust the @Priority of the
>>> two
>>> > filters so that digest runs 1st, then signing.
>>> >
>>> > fre. 5. apr. 2019 kl. 12:21 skrev Colm O hEigeartaigh <
>>> cohei...@apache.org
>>> > >:
>>> >
>>> >> Hi David,
>>> >>
>>> >> Now that the digest functionality is implemented and tested properly,
>>> we
>>> >> need to think about combining it with the signature functionality. I
>>> added
>>> >> an initial test to systests to use both the HTTPSignature filter + the
>>> >> digest interceptor. The test passes, but the filter runs before the
>>> >> interceptor, and so the filter never signs the digest header.
>>> >>
>>> >> We need to either make the interceptor run before the filter, or else
>>> have
>>> >> the interceptor as a "standalone" interceptor just supporting digest,
>>> and
>>> >> instead incorporate the digest functionality into the signature
>>> filter as
>>> >> well.
>>> >>
>>> >> Colm.
>>> >>
>>> >> On Fri, Mar 29, 2019 at 10:55 AM David Karlsen <
>>> davidkarl...@gmail.com>
>>> >> wrote:
>>> >>
>>> >> > Hi @coheigea - I noticed you are cleaning a bit in the http
>>> signature
>>> >> > stuff lately.
>>> >> >
>>> >> > There are a few things I'm wondering about.
>>> >> >
>>> >> >
>>> >> >
>>> >>
>>> https://github.com/apache/cxf/tree/master/rt/rs/security/http-signature/src/main/java/org/apache/cxf/rs/security/httpsignature/filters
>>> >> 

Re: http sig implementation

[Romain Manni-Bucau]

Hi guys,

You can ensure digest interceptor or filter is executed before the
signature one, that digest one adds a property which supports a completion
callback and if signature uses digest and the property is there it uses it
- else it throws an exception requesting the user to register the digest
filter. The only trick is to replace the outputstream in that case to
prevent headers writing before it is computed but nothing crazy with
interceptors, didnt try with filters.

Le lun. 8 avr. 2019 à 00:33, David Karlsen  a
écrit :

> Hm - came to think about this again:
> * filters always run before interceptors
> * Interceptors only run if there is a message-body (and digest only happens
> for message-bodies)
>
> So I guess the most viable option is:
>
> * have a filter which does signing if no message-body
> * have an interceptor which does digest + signing
>
> Or would it be possible to replace the outputstream in a filter with
> a CachedOutputStream and hook into any lifecycle where the entity-body has
> been written to it, but not yet streamed onto the wire?
>
> Also note that the digest is not strictly required by the spec:
> https://tools.ietf.org/html/draft-cavage-http-signatures-10#page-8 and as
> such should probably be configurable to run or not.
>
> WDYT?
>
>
> lør. 6. apr. 2019 kl. 12:00 skrev David Karlsen :
>
> > I think the signature filter should become a writer interceptor instead:
> >
> https://access.redhat.com/documentation/en-us/red_hat_jboss_fuse/6.2/html/apache_cxf_development_guide/JAXRS20Filters#JAXRS20Filters-Intro-FigCSFIEP
> > It runs later - so that hooking into that phase - any other headers can
> be
> > set - including the digest one - and then adjust the @Priority of the two
> > filters so that digest runs 1st, then signing.
> >
> > fre. 5. apr. 2019 kl. 12:21 skrev Colm O hEigeartaigh <
> cohei...@apache.org
> > >:
> >
> >> Hi David,
> >>
> >> Now that the digest functionality is implemented and tested properly, we
> >> need to think about combining it with the signature functionality. I
> added
> >> an initial test to systests to use both the HTTPSignature filter + the
> >> digest interceptor. The test passes, but the filter runs before the
> >> interceptor, and so the filter never signs the digest header.
> >>
> >> We need to either make the interceptor run before the filter, or else
> have
> >> the interceptor as a "standalone" interceptor just supporting digest,
> and
> >> instead incorporate the digest functionality into the signature filter
> as
> >> well.
> >>
> >> Colm.
> >>
> >> On Fri, Mar 29, 2019 at 10:55 AM David Karlsen 
> >> wrote:
> >>
> >> > Hi @coheigea - I noticed you are cleaning a bit in the http signature
> >> > stuff lately.
> >> >
> >> > There are a few things I'm wondering about.
> >> >
> >> >
> >> >
> >>
> https://github.com/apache/cxf/tree/master/rt/rs/security/http-signature/src/main/java/org/apache/cxf/rs/security/httpsignature/filters
> >> > There are no ClientRequestInterceptor to do the digest which is
> crucial
> >> to
> >> > the security protocol:
> >> > https://tools.ietf.org/html/draft-cavage-http-signatures-10
> >> >
> >> > Maybe that should be added as a WriterInterceptor (e.g. quite late in
> >> the
> >> > chain) - as one of the required headers is the Date header?
> >> >
> >> > Also - should digest + sign maybe be in one filter - as they go
> together
> >> > to implement the spec?
> >> >
> >> > Can the interceptors and filters be made non-final - this allows to
> >> extend
> >> > them and add additional logic - for instance I'm planning on creating
> a
> >> > custom annotation @IgnoreSignature to place on certain public
> resources
> >> -
> >> > so that this can be introspected in a filter with ResourceInfo in
> order
> >> to
> >> > determine if signature-checking should be skipped or not - of course
> >> this
> >> > can be implemented as a delegate pattern - but if they are non-final
> it
> >> > would be easier.
> >> >
> >> > Likewise the server-side digest-check and signature check - these
> happen
> >> > at different phases - could it not be bundled into one filter as the
> >> same
> >> > applies here.
> >> >
> >> > WDYT?
> >> >
> >> > --
> >> > --
> >> > David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
> >> >
> >>
> >>
> >> --
> >> Colm O hEigeartaigh
> >>
> >> Talend Community Coder
> >> http://coders.talend.com
> >>
> >
> >
> > --
> > --
> > David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
> >
>
>
> --
> --
> David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
>

Re: Dynamic JAX-RS filters (per request/response)

[Romain Manni-Bucau]

Hi

Thought to James proposal as well but the idea being more at interceptor
level. You write a custom interceptor mapping your config to impls. If CXF
does anything it will need user code anyway so not sure it does make sense
to provide this abstraction hard to test properly in cxf code itself.
Hiwever can be interesting to make it rely on CompletionStage if your
config is read remotely and move interceptorchain to a reactive approach if
not too costly.

Hope it makes sense


Le sam. 6 avr. 2019 à 00:14, Andrei Shakirin  a
écrit :

> Hi James,
>
> There are some reasons:
> - it will be possible to reuse a bunch of standard CXF filters like Jose
> JwsSignatureProvider, JwsSignatureVerifier, KeyEncryptionProvider,
> KeyDecryptionProvider, etc
> - filters will be sorted by priority in correct order
> - necessary context injection will be fulfilled
> - service pre-match and post-match filters will be executed in right moment
>
> Regards,
> Andrei.
>
> > -Original Message-
> > From: James Carman [mailto:ja...@carmanconsulting.com]
> > Sent: Freitag, 5. April 2019 18:51
> > To: dev@cxf.apache.org
> > Subject: Re: Dynamic JAX-RS filters (per request/response)
> >
> > Why not just have one ContainerRequestFilter that determines what to do
> > dynamically and just does it?  This way, you don't have to do the
> interceptor
> > chain gymnastics.
> >
> > On Fri, Apr 5, 2019 at 12:02 PM Andrei Shakirin 
> > wrote:
> > >
> > > Hi Andriy,
> > >
> > > DynamicFeature is still too static for these requirement: I would like
> to have
> > an option to configure interceptors per request/response basis.
> > > Regarding the risk: my intention is only to open the option for the
> user to
> > configure such dynamic filters (for example through message property).
> > > Instantiation, configuration, communication with external repo will be
> > customer specific code and stays outside the CXF.
> > >
> > > In other words, filter controlling interceptors (JAXRSInInterceptor,
> > JAXRSOutInterceptor, ClientRequestFilterInterceptor,
> > ClientResponseFilterInterceptor) will just check if any dynamic filters
> are
> > configured in the message and, if yes: add, resort and execute them
> together
> > with static once from ClientProviderFactory and ServerProviderFactory.
> > >
> > > I do not see any impacts on performance / memory or traceability in
> this
> > case: we just provide one more option for the user.
> > >
> > > Regards,
> > > Andrei.
> > >
> > > > -Original Message-
> > > > From: Andriy Redko [mailto:drr...@gmail.com]
> > > > Sent: Freitag, 5. April 2019 02:02
> > > > To: Andrei Shakirin; dev@cxf.apache.org
> > > > Subject: Re: Dynamic JAX-RS filters (per request/response)
> > > >
> > > > Hi Andrei,
> > > >
> > > > Understood, thank you for explanation. I am wondering if JAX-RS's
> > > > DynamicFeature may cover some of these use cases? (although it is
> > > > not per request but per resource). In general, I personally see the
> > > > following risks /
> > > > issues:
> > > >  - performance degradation: the need to recreate the filter chains
> > > > for each request (potentially, worst case scenario)may significantly
> > > > impact the response times (especially if the external central
> > > > repository has to be contacted)
> > > >  - memory pressure: recreating the filter chains for each request
> > > > (again, just worst case scenario) would fill up the heap quickly,
> > > > particularly under high server load
> > > >  - traceability: the presence of the dynamic filter chains means
> > > > each message would get special treatment, even two identical calls
> > > > may have different outcomes, potentially, how one would understand
> why
> > and nail the cause?
> > > >  - what about async flows? should the decision regarding the dynamic
> > > > response filter chain be taken at request time or at response time?
> > > > more contextual details should be passed along?
> > > >
> > > > To be fair, I am not sure if such a flexibility is worth the risks.
> > > > But in any case, I believe the flow which is used by 99% of the
> > > > users should not be impacted anyhow. Hope it makes sense, what do you
> > think?
> > > >
> > > > Thanks!
> > > >
> > > > Best Regards,
> > > > Andriy Redko
> > > >
> > > > AS> Hi Andriy,
> > > >
> > > > AS> Yes, kind of. The service must proceed parallel requests from
> > > > AS> different
> > > > clients having own security requirements:
> > > > AS> - activated/deactivated JWT authentication
> > > > AS> - JWS
> > > > AS> - JWE
> > > > AS> - authorization
> > > >
> > > > AS> The security requirements are controlled dynamically through the
> > > > AS> central
> > > > repository and are obtained on runtime by client and services.
> > > > AS> It will be useful for such use case to control filters chain
> > > > AS> dynamically per
> > > > request base, in the same way as SOAP interceptors.
> > > >
> > > > AS> Regards,
> > > > AS> Andrei.
> > > >
> > > > >> -Original Message-
> > > 

Re: RestClient issue - different apps with same client

[Romain Manni-Bucau]

Cxf rest cdi extension leaks beans, think i opened n issue last week or the
week before about it. Dropping the static from the extension fixes that.

Guess it was done as a workaround for ears but probably better to use
another mecanism like the one of deltaspike or just not do it.

Le mar. 12 mars 2019 à 20:46, Daniel Cunha  a écrit :

> Hi Ivan,
>
> Can you share a sample?
>
> Em ter, 12 de mar de 2019 às 16:34, Ivan Junckes Filho <
> ivanjunc...@gmail.com> escreveu:
>
> > Hey guys, there is a very annoying bug when using rest client from cxf
> > 3.2.7 in TomEE M2. When 2 apps have the same client the server throws the
> > error below and shuts down?
> >
> > Shouldn't we allow different apps in the same server use the same client?
> >
> > *Error*
> > Caused by: org.apache.webbeans.exception.WebBeansException:
> > org.apache.webbeans.exception.DuplicateDefinitionException:
> > PassivationCapable bean id is not unique:
> > br.com.gbrsistemas.crvirtual.classificacao.SiemClassificacaoServiceClient
> > bean:SiemClassificacaoServiceClient, WebBeansType:THIRDPARTY,
> >
> >
> Name:br.com.gbrsistemas.crvirtual.classificacao.SiemClassificacaoServiceClient,
> > API
> >
> >
> Types:[br.com.gbrsistemas.crvirtual.classificacao.SiemClassificacaoServiceClient],
> >
> >
> Qualifiers:[javax.enterprise.inject.Default,org.eclipse.microprofile.rest.client.inject.RestClient,javax.enterprise.inject.Any],
> > existing: SiemClassificacaoServiceClient, WebBeansType:THIRDPARTY,
> >
> >
> Name:br.com.gbrsistemas.crvirtual.classificacao.SiemClassificacaoServiceClient,
> > API
> >
> >
> Types:[br.com.gbrsistemas.crvirtual.classificacao.SiemClassificacaoServiceClient],
> >
> >
> Qualifiers:[javax.enterprise.inject.Default,org.eclipse.microprofile.rest.client.inject.RestClient,javax.enterprise.inject.Any]
> > at
> >
> >
> org.apache.webbeans.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:371)
> > at
> >
> >
> org.apache.webbeans.event.NotificationManager.invokeObserverMethod(NotificationManager.java:818)
> > at
> >
> >
> org.apache.webbeans.event.NotificationManager.fireEvent(NotificationManager.java:714)
> > ... 42 more
> >
>
>
> --
> Daniel "soro" Cunha
> https://twitter.com/dvlc_
>

Re: [VOTE] CXF 3.3.1

[Romain Manni-Bucau]

+1 (non binding)

Le ven. 1 mars 2019 à 07:27, Jean-Baptiste Onofré  a
écrit :

> +1 (non binding)
>
> Regards
> JB
>
> On 28/02/2019 19:56, 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
> >
> >
>

Re: 3.3.1 tomorrow?

[Romain Manni-Bucau]

+1 to get it out

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 mer. 27 févr. 2019 à 16:33, Andy McCright 
a écrit :

> +1
>
> There is also a minor issue where a warning is issued if using MP Rest
> Client with CDI but without specifying any providers - pretty minor, but
> would be nice to get that fix out.  The fix is part of commit:
>
> https://github.com/apache/cxf/commit/d70589ed28942692f86753590fa23712850b3854
>
> Thanks!
>
> Andy
>
> On Wed, Feb 27, 2019 at 9:29 AM Daniel Kulp  wrote:
>
> >
> >
> > > On Feb 27, 2019, at 9:55 AM, David Karlsen 
> > wrote:
> > >
> > > Do you have a jira ID for the performance issue?
> >
> > There was a brief discussion on the users list:
> >
> >
> https://lists.apache.org/thread.html/f9c6c5b504bcdfc280307ed8b7a630e9b5923ee1536bff51661b886c@%3Cusers.cxf.apache.org%3E
> > <
> >
> https://lists.apache.org/thread.html/f9c6c5b504bcdfc280307ed8b7a630e9b5923ee1536bff51661b886c@%3Cusers.cxf.apache.org%3E
> > >
> >
> > Dan
> >
> >
> > >
> > > Den ons. 27. feb. 2019, 15:55 skrev Daniel Kulp :
> > >
> > >>
> > >> I’d like to get 3.3.1 out real soon as it does fix a fairly severe
> > >> performance issue and I’d like to get a “.1” out to appease folks that
> > >> refuse to touch a .0.  :)
> > >>
> > >> Anyone have any objections if I do the build tomorrow?
> > >>
> > >> Thanks!
> > >>
> > >> --
> > >> Daniel Kulp
> > >> dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog
> <
> > >> http://dankulp.com/blog>
> > >> Talend Community Coder - http://talend.com <http://coders.talend.com/
> >
> > >>
> >
> > --
> > 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/>
> >
>

Re: [VOTE] CXF 3.2.8

[Romain Manni-Bucau]

+1 (non binding)

Le ven. 25 janv. 2019 08:07, Francesco Chicchiriccò  a
écrit :

> On 24/01/19 22:36, Daniel Kulp wrote:
> > It’s been 3 months since 3.2.7 so we should do another release.  We’ve
> fixed 18 JIRA issues
> >
> > Staging area:
> > https://repository.apache.org/content/repositories/orgapachecxf-1134 <
> https://repository.apache.org/content/repositories/orgapachecxf-1134>
> >
> >
> > Tag:
> >
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=a34bf55dea00c354bf3f49ad5b98fb18f01d9258
> <
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=a34bf55dea00c354bf3f49ad5b98fb18f01d9258
> >
>
> Also verified with Syncope 2.1.4-SNAPSHOT, +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] CXF 3.3.0 and CXF XJC Utils 3.3.0

[Romain Manni-Bucau]

+1 (non-binding) works great and no breaking change in meecrowave (except
oauth2 ehcache provider which was removed but it was intended so no big
deal), good work everyone!

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 ven. 25 janv. 2019 à 04:28, Freeman Fang  a
écrit :

> +1
>
> Thanks!
> －
> Freeman(Yue) Fang
>
> Red Hat, Inc.
>
>
>
>
>
> > On Jan 25, 2019, at 5:33 AM, 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 <mailto:dk...@apache.org> - http://dankulp.com/blog <
> http://dankulp.com/blog>
> > Talend Community Coder - http://talend.com <http://coders.talend.com/>
>
>

Re: 3.3.0 soon?

[Romain Manni-Bucau]

+1

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 mer. 23 janv. 2019 à 15:32, Jean-Baptiste Onofré  a
écrit :

> +1
>
> Regards
> JB
>
> On 23/01/2019 15:06, Colm O hEigeartaigh wrote:
> > +1, I think we are good to go.
> >
> > Colm.
> >
> > On Tue, Jan 22, 2019 at 2:05 AM Andrey Redko  wrote:
> >
> >> +1 as well, long due. I am working on examples for Java 11 and JPMS,
> but it
> >> is not blocking anyhow the vote / release. Thanks guys.
> >>
> >> Best Regards,
> >> Andriy Redko
> >>
> >> On Mon, Jan 21, 2019, 8:53 PM Freeman Fang  wrote:
> >>
> >>> +1, we should be ready to go.
> >>> －
> >>> Freeman(Yue) Fang
> >>>
> >>> Red Hat, Inc.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>> On Jan 21, 2019, at 9:06 PM, Dennis Kieselhorst 
> >> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> in my view everything we discussed is finished. So we can cut a
> release
> >>> and start a vote, can't we?
> >>>>
> >>>> Cheers
> >>>> Dennis
> >>>
> >>>
> >>
> >
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: New Maven coordinates for Jakarta EE specs

[Romain Manni-Bucau]

I guess jakarta will "relocate" ([1]) the jars so frameworks will start
getting warnings and fix it so sounds like a move forward anyway.

Side note: we got the same issue with geronimo spec jars for years and it
never had been a real issue in practise so not a big deal IMHO.

[1] https://maven.apache.org/guides/mini/guide-relocation.html

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 jeu. 10 janv. 2019 à 16:54, Dennis Kieselhorst  a écrit :

>
> > For me, as a CXF user, the easiest way would be to get the old artifacts,
> > as I expect other frameworks
> > that I already have in the project would still use the existing Maven
> > coordinates and then I will have a mix of old and new coordinates until
> all
> > of them upgrade.
>
> Hi Andrei,
>
> I understand your concerns. I don't like the renaming too as there is no
> benefit and this causes lots of effort. But at some point in time every
> framework will pick up the new coordinates and you have to deal with it.
> If you want to keep the old ones, you can just add an exclusion or stick
> to CXF 3.2.x.
>
> Regards
> Dennis
>

Re: GraphQL Project?

[Romain Manni-Bucau]

Hi Dennis,

Side note o  openapi: CXF works well with Geronimo impl [1], not sure
duplicating it would bring much, in particular since spec requires to be
cdi based and not deployment based as swagger integration is
(classes/resources cxf has in its factory are not enough)

[1] http://github.com/apache/geronimo-openapi

Le ven. 4 janv. 2019 13:10, Dennis Kieselhorst  a écrit :

> Great idea. I think it would be great for CXF to have both OpenAPI and
> GraphQL support.
>
> Cheers
> Dennis
>

Re: GraphQL Project?

[Romain Manni-Bucau]

+1

Two small side notes:

1. If cxf is not the right "home", geronimo would definitively be (
http://geronimo.apache.org/microprofile/ to be concrete)
2. From my past experience having a graphql parser API (body reader for
jaxrs/mp) is the most important feature, everything else is mainly the link
to the backend and highly depends impl choices and the abstraction a
framework gives is often  more an issue (N+1 queries to cite one obvious
common problem) than a solution even if tempting

Le jeu. 3 janv. 2019 23:29, Andy McCright  a
écrit :

> Hi All,
>
> I've been involved in an effort to create a MicroProfile GraphQL project
> that would provide a Java framework for building and deploying GraphQL
> apps.  The API would look similar to JAX-RS (i.e. @Query annotations
> instead of @GET, etc.).
>
> We have a draft project proposal available here:
>
> https://docs.google.com/document/d/1prwMGxgr0cI5yx4lrvMET5x6rD-CQ1y7XuS1PCegE4A/edit#
>
> Would this be something that we could implement in a new CXF module?  And
> would anybody on this list be interested in participating in the MP spec
> project?
>
> Thanks in advance!
>
> Andy
>
> PS - we have a spec project meeting tomorrow at 10:30am US Eastern time.
> Meeting minutes (and a link to the webex) is available here:
>
> https://docs.google.com/document/d/1gb3jirFGrJwDZSbrtnFPVTNjPNe3Y0dUYfm-HkU1c3U/edit#
>

Re: 3.3.0 soon?

[Romain Manni-Bucau]

Just to echo to my previous question of this thread (jaxb/activation made
optional): I started a PR on that topic at
https://github.com/apache/cxf/pull/487, I have to rebuild CXF and fixe the
likely happening issues but it runs well on java 11 without jaxb and
javax.action required :). Not sure it is likely it makes it in a coming
soon release but would be great to tackle that at some point.

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 ven. 21 déc. 2018 à 12:16, Andrey Redko  a écrit :

> Hey guys,
>
> I also noticed that some of our integrations, like fe Swagger / OpenApi do
> explicitly depend on JAXB APIs artifacts. I think we should be careful here
> and at least add exclusions, avoiding classpath collisions. There could be
> more examples like that. Thanks.
>
> Best Regards,
>     Andriy Redko
>
> On Fri, Dec 21, 2018, 3:55 AM Romain Manni-Bucau  wrote:
>
> > Please don't pull it from staging - you can use oss release repo to get
> > early access to the binaries before it gets synch-ed with central - but
> if
> > stagings are dropped then you will not be able to rebuild the tag/branch
> :(
> >
> > 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 ven. 21 déc. 2018 à 09:54, Andrei Ivanov  a
> > écrit :
> >
> > > Hi,
> > >
> > > On Fri, Dec 21, 2018 at 10:24 AM Dennis Kieselhorst 
> > > wrote:
> > >
> > > > > > think we should definitely integrate the JakartaEE dependencies
> > > > (groupId/
> > > > > artifactId change as announced earlier). According to schedule they
> > > will
> > > > be
> > > > > release next Friday (14.12.2018).
> > > > >
> > > > > +1.
> > > >
> > > > Unfortunately the JAXB and JAX-WS releases are still not available on
> > > > central. Haven't found an updated schedule yet. I asked on the
> > > mailinglist
> > > > but so far I got no response :-(
> > > >
> > > > Since the JAX-RS API dependency was just updated, I was looking
> through
> > > its changes and I noticed this:
> > >
> > >
> >
> https://github.com/eclipse-ee4j/jaxrs-api/commit/13f7fd093a0deaae3aea626bf35e4562f6439efd
> > >
> > > Maybe that approach can also be used for CXF?
> > >
> > >
> > > > Regards
> > > > Dennis
> > > >
> > >
> >
>

Re: 3.3.0 soon?

[Romain Manni-Bucau]

Please don't pull it from staging - you can use oss release repo to get
early access to the binaries before it gets synch-ed with central - but if
stagings are dropped then you will not be able to rebuild the tag/branch :(

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 ven. 21 déc. 2018 à 09:54, Andrei Ivanov  a
écrit :

> Hi,
>
> On Fri, Dec 21, 2018 at 10:24 AM Dennis Kieselhorst 
> wrote:
>
> > > > think we should definitely integrate the JakartaEE dependencies
> > (groupId/
> > > artifactId change as announced earlier). According to schedule they
> will
> > be
> > > release next Friday (14.12.2018).
> > >
> > > +1.
> >
> > Unfortunately the JAXB and JAX-WS releases are still not available on
> > central. Haven't found an updated schedule yet. I asked on the
> mailinglist
> > but so far I got no response :-(
> >
> > Since the JAX-RS API dependency was just updated, I was looking through
> its changes and I noticed this:
>
> https://github.com/eclipse-ee4j/jaxrs-api/commit/13f7fd093a0deaae3aea626bf35e4562f6439efd
>
> Maybe that approach can also be used for CXF?
>
>
> > Regards
> > Dennis
> >
>

Re: CxfTypeSafeClientBuilderTest failing on JDK9+

[Romain Manni-Bucau]

Guess the hack on modifiers can be ignored, it is not deterministic anyway
- it can lead to a noop since java 8. While in unamed modules
unreflectSpecial will be available which should be enough for cxf for now,
no?

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 ven. 21 déc. 2018 à 09:15, Dennis Kieselhorst  a écrit :

> Thanks Andriy, looks good for 8-11 now, but 12 is now failing with:
>
> Caused by: java.lang.NoSuchFieldException: allowedModes
> at
> org.apache.cxf.microprofile.client.CxfTypeSafeClientBuilderTest.testCanInvokeDefaultInterfaceMethods(CxfTypeSafeClientBuilderTest.java:173)
>
>
> https://builds.apache.org/view/A-D/view/CXF/job/CXF-Master-JDK12/lastCompletedBuild/org.apache.cxf$cxf-rt-rs-mp-client/testReport/org.apache.cxf.microprofile.client/CxfTypeSafeClientBuilderTest/testCanInvokeDefaultInterfaceMethods/
>
> Regards
> Dennis
>

Re: CxfTypeSafeClientBuilderTest failing on JDK9+

[Romain Manni-Bucau]

Hi, yes, in j > 10 the workaround is different and the one you pushed :(.

Le ven. 21 déc. 2018 04:43, Andriy Redko  a écrit :

> Hi Andy,
>
> I've committed a small patch to master [1] to fallback to
> MethodHandles.privateLookupIn (JDK9+)
> in case the main flow fails with IllegalAccessException, it seems to fix
> the issue and properly
> invoke the default method for JDK9+. As far as I know, at the moment there
> is no universal
> solution which works for JDK 8, 9, 10 and 11. Please let me know what do
> you think.
>
> Thank you!
>
> [1]
> https://github.com/apache/cxf/commit/58d9bcd12059c46713902b756881e80c2f28f030
>
> Best Regards,
> Andriy Redko
>
> Thursday, December 20, 2018, 3:52:29 PM, you wrote:
>
> AM> Hi Dennis,
>
> AM> I most likely introduced this with my fix for CXF-7922 - in that fix, I
> AM> made some changes to internal JDK classes in ClientProxyImpl's
> AM> invokeDefaultMethod method.  The MP Rest Client (as well as the CXF
> proxy
> AM> client) should be able to invoke default methods, and there doesn't
> seem to
> AM> be a good way of doing that... Romain wrote a blog post on the subject
> AM> here:
> AM>
> https://rmannibucau.wordpress.com/2014/03/27/java-8-default-interface-methods-and-jdk-dynamic-proxies/
> AM> - this was the idea behind that change, but I would bet that it is not
> AM> allowed with JPMS enabled - and is most likely causing the failure.
>
> AM> It sounds like I need to find a better way to invoke default interface
> AM> methods without using JDK internals.  If anyone knows of a better way
> or
> AM> has any hints, please let me know.  In the meantime, I could add
> something
> AM> like "assume Java 8" to skip the test in Java 9+ environments.  What
> do you
> AM> think?
>
> AM> Thanks,
>
> AM> Andy
>
> AM> On Thu, Dec 20, 2018 at 2:33 PM Dennis Kieselhorst 
> wrote:
>
> >> Hi,
>
> >> only CxfTypeSafeClientBuilderTest is missing to have a stable build from
> >> JDK 9 - 11.
>
> >> java.lang.reflect.UndeclaredThrowableException
> >> at
> >>
> org.apache.cxf.microprofile.client.CxfTypeSafeClientBuilderTest.testCanInvokeDefaultInterfaceMethods(CxfTypeSafeClientBuilderTest.java:173)
> >> Caused by: java.lang.IllegalAccessException: access to public member
> >> failed:
> >>
> org.apache.cxf.microprofile.client.mock.MyClient.myDefaultMethod[Ljava.lang.Object;@10cf09e8
> /invokeSpecial,
> >> from org.apache.cxf.microprofile.client.mock.MyClient/2 (unnamed module
> >> @14dd9eb7)
> >> at
> >>
> org.apache.cxf.microprofile.client.CxfTypeSafeClientBuilderTest.testCanInvokeDefaultInterfaceMethods(CxfTypeSafeClientBuilderTest.java:173)
>
> >> Anyone seen something similar before?
>
> >> Cheers
> >> Dennis
>
>
>

Re: 3.3.0 soon?

[Romain Manni-Bucau]

Hello Andriy

It is just about ensuring an indirection in code (class loading) then if
the code is not triggered at runtime it passes well. Link is not the first
citizen of the api so i dont think it is a blocker. Default cxf providers
are more intrusive so making them loaded if possible only - like jettison -
would be a first good step IMHO.

Le sam. 8 déc. 2018 03:29, Andriy Redko  a écrit :

> Hi Romain,
>
> I think it would be great but may be not feasible, the JAX-RS API has tons
> of
> dependencies on JAXB (f.e.
> https://github.com/jax-rs/api/blob/master/jaxrs-api/src/main/java/javax/ws/rs/core/Link.java),
> we could not do much about it. Do you see the ways how we could pull it off?
>
> Best Regards,
> Andriy Redko
>
> RMB> Any hope javax.activation and jaxb becomes optional for the 3.3 and
> jaxrs?
> RMB> I can surely help in 10 days if not too late
>
> RMB> Le ven. 7 déc. 2018 10:39, Jean-Baptiste Onofré  a
> écrit :
>
> >> Hi Colm,
>
> >> I'm working on a couple of new features for Karaf/OSGi (SCR support +
> >> simple whiteboard). I will try to submit the PRs soon, but definitely
> >> not a blocker for the 3.3.0 release.
>
> >> Regards
> >> JB
>
> >> On 07/12/2018 10:27, Colm O hEigeartaigh wrote:
> >> > Hi all,
> >> >
> >> > XML Schema 2.2.4 is under vote, and I believe a vote will also be
> called
> >> on
> >> > Karaf 4.2.2 shortly. We should be good to go then for CXF 3.3.0 either
> >> next
> >> > week or the week after, so if there is anything anyone needs to get
> in,
> >> now
> >> > is the time to do it.
> >> >
> >> > Colm.
> >> >
> >> >
>
> >> --
> >> Jean-Baptiste Onofré
> >> jbono...@apache.org
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
>
>
>

Re: 3.3.0 soon?

[Romain Manni-Bucau]

Any hope javax.activation and jaxb becomes optional for the 3.3 and jaxrs?
I can surely help in 10 days if not too late

Le ven. 7 déc. 2018 10:39, Jean-Baptiste Onofré  a écrit :

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

Re: CXF 3.1.x and Java 11

[Romain Manni-Bucau]

Hi Gary

If it helps im using
https://github.com/Talend/component-runtime/blob/master/component-server-parent/component-server/pom.xml#L531
.
It is for a 3.2 but in terms of dependencies it should be ok for 3.1 if
target bytecode is supported by 3.1.

Le jeu. 6 déc. 2018 22:14, Gary Gregory  a écrit :

> Hi All:
>
> Do you have a recommendation for updating a POM to build, embed, and run
> CXF 3.1.x on Java 11. IOW what dependencies to add to make up for the
> missing javax.xml.soap and javax.xml.ws packages removed in Java 11?
>
> Thank you,
> Gary
>

Re: microprofile openapi @asf?

[Romain Manni-Bucau]

Hi Dennis,

yes likely, you can also probably starts from the maven plugin which just
uses a manually listed set of classes and bypasses cdi integration (since
it is at build time without a container launch)

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 jeu. 15 nov. 2018 à 10:24, Dennis Kieselhorst  a écrit :

> Hi,
> I want to catch up with this topic and start to think about CXF-7601. My
> suggestion is to add a new module description-microprofile-openapi oder
> description-openapi-microprofile for it.
>
> > RMB> Just to update you: we just passed the TCK. Impl is likely not
> perfect but I proposed @geronimo to start a 1.0.0
> > RMB> vote with that since we are tck friendly and then iterate with the
> classical reports/bugs/... flow.
> > RMB> I introduced a very light reflection abstraction to isolate most of
> the logic from CDI so assuming the scanning
> > RMB> logic is rewritten (this is not much code but it is technology
> specific) then it should be quite easy to make it
> > RMB> match CXF. Technically, doing a maven plugin to prebuild the
> openapi.json is very feasible too (i'm planning to do some tests on this
> one soon).
>
> We would need to implement a replacement for GeronimoOpenAPIExtension,
> right?
>
> Regards
> Dennis
>

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

[Romain Manni-Bucau]

+1

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 jeu. 25 oct. 2018 à 08:52, Dennis Kieselhorst  a écrit :

> +1
>
> Thanks!
>

Re: (CXF-7852) - CX 3.3

[Romain Manni-Bucau]

Any way to have milestones with subparts supporting j11 like optional jaxb,
jaxrs, jaxws then extensions maybe?


Le ven. 28 sept. 2018 18:28, Colm O hEigeartaigh  a
écrit :

> From my POV probably early spring next year. I'd like to cut new major
> releases of Santuario (switch to using CXF's StaxUtils for DOM parsing) +
> WSS4J (switch to a new major version of ehcache / jcache).
>
> Colm.
>
> On Fri, Sep 28, 2018 at 5:23 PM David Karlsen 
> wrote:
>
> > When will CXF 3.3 be cut - this is the missing piece in our puzzle to be
> > java11 ready.
> >
> > -- Forwarded message -
> > From: Dennis Kieselhorst (JIRA) 
> > Date: fre. 28. sep. 2018 kl. 16:26
> > Subject: [jira] [Commented] (CXF-7852) Cannot generate code on jdk 11
> > To: 
> >
> >
> >
> > [
> >
> >
> https://issues.apache.org/jira/browse/CXF-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16631920#comment-16631920
> > ]
> >
> > Dennis Kieselhorst commented on CXF-7852:
> > -
> >
> > We don't have an ETA yet, but you can start the discussion on the
> > mailinglist: https://lists.apache.org/list.html?dev@cxf.apache.org
> >
> > > Cannot generate code on jdk 11
> > > --
> > >
> > > Key: CXF-7852
> > > URL: https://issues.apache.org/jira/browse/CXF-7852
> > > Project: CXF
> > >  Issue Type: Bug
> > >  Components: Tooling
> > >Affects Versions: 3.2.6
> > >Reporter: David J. M. Karlsen
> > >Assignee: Freeman Fang
> > >Priority: Major
> > > Fix For: 3.3.0
> > >
> > >
> > > the codegen maven plugin seems to add an non-existing module when
> running
> > on java11:
> > > {noformat}
> > > [INFO] --- cxf-codegen-plugin:3.2.6:wsdl2java (default) @
> jfr-srv-schemas
> > ---
> > > [INFO] Using proxy server configured in maven.
> > > [INFO] Running code generation in fork mode...
> > > [INFO] The java executable is
> > /Library/Java/JavaVirtualMachines/openjdk-11.jdk/Contents/Home/bin/java
> > > [INFO] Building jar:
> >
> >
> /var/folders/c7/18m1hlzs075_z0f5nfnt44jmgn/T/cxf-tmp-2107463654183740055/cxf-codegen14725056335928137302.jar
> > > [INFO] Error occurred during initialization of boot layer
> > > [INFO] java.lang.module.FindException: Module java.xml.ws not found
> > > {noformat}
> > > {noformat}
> > > Command line was:
> > /Library/Java/JavaVirtualMachines/openjdk-11.jdk/Contents/Home/bin/java
> > --add-modules java.activation,java.xml.bind,java.xml.ws
> >
> >
> --add-exports=java.xml.bind/com.sun.xml.internal.bind.v2.runtime=ALL-UNNAMED
> > --add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED
> >
> >
> --add-exports=java.xml/com.sun.org.apache.xerces.internal.impl.xs=ALL-UNNAMED
> >
> >
> --add-exports=java.xml.bind/com.sun.xml.internal.bind.marshaller=ALL-UNNAMED
> > --add-opens java.xml.ws/javax.xml.ws.wsaddressing=ALL-UNNAMED
> --add-opens
> > java.base/java.security=ALL-UNNAMED --add-opens java.base/java.net
> > =ALL-UNNAMED
> > --add-opens java.base/java.lang=ALL-UNNAMED --add-opens
> > java.base/java.util=ALL-UNNAMED --add-opens
> > java.base/java.util.concurrent=ALL-UNNAMED -jar
> >
> >
> /var/folders/c7/18m1hlzs075_z0f5nfnt44jmgn/T/cxf-tmp-2107463654183740055/cxf-codegen14725056335928137302.jar
> >
> >
> /var/folders/c7/18m1hlzs075_z0f5nfnt44jmgn/T/cxf-tmp-2107463654183740055/cxf-w2j4026495259386863606args
> > > at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> > (MojoExecutor.java:213)
> > > at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> > (MojoExecutor.java:154)
> > > at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> > (MojoExecutor.java:146)
> > > at
> > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> > (LifecycleModuleBuilder.java:117)
> > > at
> > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> > (LifecycleModuleBuilder.java:81)
> > > at
> >
> >
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> > (SingleThreadedBuilder.java:56)
> > > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> > (LifecycleStarter.java:128)
> > > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> > > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> > > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> > > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:954)
> > > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> > > at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> > > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native
> > Method)
> > > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> > (NativeMethodAccessorImpl.java:62)
> > > at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> > (DelegatingMetho

Re: [VOTE] Apache CXF 3.2.6

[Romain Manni-Bucau]

+1 (non binding)

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 jeu. 9 août 2018 à 08:50, Francesco Chicchiriccò  a
écrit :

> On 09/08/2018 01:14, Daniel Kulp wrote:
> > 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
> >
>
>
> +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: microprofile openapi @asf?

[Romain Manni-Bucau]

Hi guys,

Just to update you: we just passed the TCK. Impl is likely not perfect but
I proposed @geronimo to start a 1.0.0 vote with that since we are tck
friendly and then iterate with the classical reports/bugs/... flow.
I introduced a very light reflection abstraction to isolate most of the
logic from CDI so assuming the scanning logic is rewritten (this is not
much code but it is technology specific) then it should be quite easy to
make it match CXF. Technically, doing a maven plugin to prebuild the
openapi.json is very feasible too (i'm planning to do some tests on this
one soon).

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 dim. 24 juin 2018 à 23:04, Romain Manni-Bucau  a
écrit :

>
>
> Le dim. 24 juin 2018 21:59, Andriy Redko  a écrit :
>
>> Hi Romain,
>>
>> Just went through the issues and comment threads. I am not really
>> involved in MP (sadly)
>> but the YAML+JSON discussion makes sense to me, at least from the
>> platform perspective. JSON
>> should be a must, YAML is optional (although it is very popular in
>> OpenAPI community). My personal
>> position regarding the builder vs annotations is a matter of choice /
>> preference. There are
>> centainly pros and cons of both, valid arguments are listed. I don't
>> think either of them is
>> perfect for everyone, supporting both options sounds like a good
>> trade-off, let devs pick whatever
>> fits better to the particular project / context.
>>
>
> It assumes the ee5 pattern and forgets the cdi/event ones. I agree it is
> not yet mainstream but it is a convergence opportunity. In particular when
> you see all the reference workarounds annotation require and an
> event/programmatic solution doesnt. It is a huge gain in practise if you
> have endpoints using the same models.
>
> Kind of theory vs practise feedback probably.
>
>
>> The issue related to model serialization takes unexpected turn towards
>> https://github.com/OpenAPITools
>> project ... I don't know the full details but afaik these guys are
>> forking Swagger projects (swagger-codegen notably)
>> and rebranding under OpenApiTools umbrella. I am working on the PR
>> https://github.com/swagger-api/swagger-codegen-generators/pull/101 to
>> replace code generation of old Swagger / OpenAPI 2.x with OpenAPI 3.x
>> (since Apache CXF
>> supports that out of the box). If things work out here as expected, I
>> would be happy to help to introduce MP part
>> (server stubs or/and client) as well.
>>
>
> Yep. My concern here is that using a custom serializer leads to limit the
> spec usage to the spec endpoint. It is likely 20% only of the main usages
> so spec will likely be replaced by something else anyway if it stays as
> such :(.
>
>
>> Thanks.
>>
>> Best Regards,
>> Andriy Redko
>>
>> RMB> Hi guys,
>>
>> RMB> opened several issues about the spec and a few of them are serious
>> concerns
>> RMB> for me (others are easier):
>>
>> RMB> 1. https://github.com/eclipse/microprofile-open-api/issues/231
>> RMB> 2. https://github.com/eclipse/microprofile-open-api/issues/230
>> RMB> 3. https://github.com/eclipse/microprofile-open-api/issues/228
>>
>> RMB> Seems like there was no time to think about an API so swagger was
>> just
>> RMB> copied (and adapted to openapi) which leads to something quite
>> inconsistent
>> RMB> for end users and also inconsistent with the platform.
>> RMB> It doesn't prevent us to implement it but would be great if some of
>> you can
>> RMB> check out issues and potentially vote for them. There is no Strong
>> API
>> RMB> stability requirement at microprofile so there is stilla  hope the
>> API is
>> RMB> made simpler and usable by end users.
>>
>> RMB> In short (if you don't want to open the links) the issues are:
>>
>> RMB> 1. YAML is mandatory but there is nothing standard to modelize it so
>> it is
>> RMB> an internal of the implementation and the format is not user
>> friendly until
>> RMB> you use something outside the spec
>> RMB> 2. The model is using OpenAPI object graph but it is not integrated
>> with
>> RMB> JSON-B so it is not (de)serializable correctly for end user. It also
>> breaks
>

Re: Change master to 3.3?

[Romain Manni-Bucau]

+1, would be awesome to have jaxb optional in cxf for all JSON only users
(and not just imported as a mandatory dep). Anyway being ready in september
for the new LTS is clearly important for the community.

Thanks guys!
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 mer. 27 juin 2018 à 09:21, Daniel Kulp  a écrit :

> I generally just consider Java 9/10/11 as one.  :)
>
> Basically, whatever is currently somewhat supported by Oracle whenever 3.3
> is finally ready.
>
> Dan
>
>
>
> > On Jun 26, 2018, at 6:24 PM, Andy McCright 
> wrote:
> >
> > +1
> >
> > For Java levels, I'd recommend that we skip Java 10 and plan for Java 11.
> > Java 10 support ends in September, whereas Java 11 is a long term support
> > release.
> > http://www.oracle.com/technetwork/java/javase/eol-135779.html
> >
> > Thanks!
> > Andy
> >
> > On Tue, Jun 26, 2018 at 9:49 AM Dennis Kieselhorst 
> wrote:
> >
> >> Definitely +1
> >>
> >>> And how about for the master we also have spring 5 + spring boot 2,
> >> basically merge the spring-5-boot-2 branch?
> >>
> >> Yes, I started the branch for testing and it looks good. Thank you for
> >> fixing some tests.
> >>
> >> Regards
> >> Dennis
> >>
>
> --
> Daniel Kulp
> dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog <
> http://dankulp.com/blog>
> Talend Community Coder - http://coders.talend.com <
> http://coders.talend.com/>
>

Re: microprofile openapi @asf?

[Romain Manni-Bucau]

Le dim. 24 juin 2018 21:59, Andriy Redko  a écrit :

> Hi Romain,
>
> Just went through the issues and comment threads. I am not really involved
> in MP (sadly)
> but the YAML+JSON discussion makes sense to me, at least from the platform
> perspective. JSON
> should be a must, YAML is optional (although it is very popular in OpenAPI
> community). My personal
> position regarding the builder vs annotations is a matter of choice /
> preference. There are
> centainly pros and cons of both, valid arguments are listed. I don't think
> either of them is
> perfect for everyone, supporting both options sounds like a good
> trade-off, let devs pick whatever
> fits better to the particular project / context.
>

It assumes the ee5 pattern and forgets the cdi/event ones. I agree it is
not yet mainstream but it is a convergence opportunity. In particular when
you see all the reference workarounds annotation require and an
event/programmatic solution doesnt. It is a huge gain in practise if you
have endpoints using the same models.

Kind of theory vs practise feedback probably.


> The issue related to model serialization takes unexpected turn towards
> https://github.com/OpenAPITools
> project ... I don't know the full details but afaik these guys are forking
> Swagger projects (swagger-codegen notably)
> and rebranding under OpenApiTools umbrella. I am working on the PR
> https://github.com/swagger-api/swagger-codegen-generators/pull/101 to
> replace code generation of old Swagger / OpenAPI 2.x with OpenAPI 3.x
> (since Apache CXF
> supports that out of the box). If things work out here as expected, I
> would be happy to help to introduce MP part
> (server stubs or/and client) as well.
>

Yep. My concern here is that using a custom serializer leads to limit the
spec usage to the spec endpoint. It is likely 20% only of the main usages
so spec will likely be replaced by something else anyway if it stays as
such :(.


> Thanks.
>
> Best Regards,
> Andriy Redko
>
> RMB> Hi guys,
>
> RMB> opened several issues about the spec and a few of them are serious
> concerns
> RMB> for me (others are easier):
>
> RMB> 1. https://github.com/eclipse/microprofile-open-api/issues/231
> RMB> 2. https://github.com/eclipse/microprofile-open-api/issues/230
> RMB> 3. https://github.com/eclipse/microprofile-open-api/issues/228
>
> RMB> Seems like there was no time to think about an API so swagger was just
> RMB> copied (and adapted to openapi) which leads to something quite
> inconsistent
> RMB> for end users and also inconsistent with the platform.
> RMB> It doesn't prevent us to implement it but would be great if some of
> you can
> RMB> check out issues and potentially vote for them. There is no Strong API
> RMB> stability requirement at microprofile so there is stilla  hope the
> API is
> RMB> made simpler and usable by end users.
>
> RMB> In short (if you don't want to open the links) the issues are:
>
> RMB> 1. YAML is mandatory but there is nothing standard to modelize it so
> it is
> RMB> an internal of the implementation and the format is not user friendly
> until
> RMB> you use something outside the spec
> RMB> 2. The model is using OpenAPI object graph but it is not integrated
> with
> RMB> JSON-B so it is not (de)serializable correctly for end user. It also
> breaks
> RMB> the JAXRS serialization since each single object of the graph will
> need a
> RMB> custom message reader/writer to work (but the spec doesnt spec about
> that
> RMB> so payloads will not be the expected ones, in particular if you send
> back
> RMB> from a client which got OpenAPI instance some subgraph!)
> RMB> 3. There are 2 API in the spec: a builder one and an annotation
> driven one.
> RMB> The builder is sufficient and associated with a startup event allows
> to
> RMB> avoid the annotations need which just duplicates the builder 1-1 with
> very
> RMB> few semantic differences for ref and map management.
>
> RMB> In one sentence it means that the API could be easier, less ambiguous
> for
> RMB> end users, the integration with the platform more consistent and that
> it is
> RMB> a very simple investment and work. It just needs to be made portable
> RMB> accross vendor.
>
> 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-deve

Re: microprofile openapi @asf?

[Romain Manni-Bucau]

Hi guys,

opened several issues about the spec and a few of them are serious concerns
for me (others are easier):

1. https://github.com/eclipse/microprofile-open-api/issues/231
2. https://github.com/eclipse/microprofile-open-api/issues/230
3. https://github.com/eclipse/microprofile-open-api/issues/228

Seems like there was no time to think about an API so swagger was just
copied (and adapted to openapi) which leads to something quite inconsistent
for end users and also inconsistent with the platform.
It doesn't prevent us to implement it but would be great if some of you can
check out issues and potentially vote for them. There is no Strong API
stability requirement at microprofile so there is stilla  hope the API is
made simpler and usable by end users.

In short (if you don't want to open the links) the issues are:

1. YAML is mandatory but there is nothing standard to modelize it so it is
an internal of the implementation and the format is not user friendly until
you use something outside the spec
2. The model is using OpenAPI object graph but it is not integrated with
JSON-B so it is not (de)serializable correctly for end user. It also breaks
the JAXRS serialization since each single object of the graph will need a
custom message reader/writer to work (but the spec doesnt spec about that
so payloads will not be the expected ones, in particular if you send back
from a client which got OpenAPI instance some subgraph!)
3. There are 2 API in the spec: a builder one and an annotation driven one.
The builder is sufficient and associated with a startup event allows to
avoid the annotations need which just duplicates the builder 1-1 with very
few semantic differences for ref and map management.

In one sentence it means that the API could be easier, less ambiguous for
end users, the integration with the platform more consistent and that it is
a very simple investment and work. It just needs to be made portable
accross vendor.

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 jeu. 21 juin 2018 à 16:20, Raymond Auge  a
écrit :

> Great!
>
>
> On Thu, Jun 21, 2018 at 10:12 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com> wrote:
>
>> @Raymond: the diff between CDI and OSGi will be where the OpenAPI
>> instance will be created mainly so very doable (aries can even import
>> G-openapi for that). Only diff which can be quite intrusive is that @G we
>> don't use plain reflection to enable CDI meta model to be mutated during
>> startup and therefore let the user configure most of the model instead of
>> hardcoding it, but it is not that hard to abstract so I'm very confident to
>> keep it abstracted and to support OSGi once we support the spec with CDI
>> (and why not supporting CDI in aries ;)).
>>
>
> Regarding supporting CDI in Aries ;) it should look pretty much like any
> normal CDI extension with a tiny amount of extra OSGi metadata and what I
> hope are very reasonable restrictions on how extensions provide beans, if
> any.
>
> Sincerely,
> - Ray
>
>
>>
>> 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 jeu. 21 juin 2018 à 15:21, Raymond Auge  a
>> écrit :
>>
>>> It would be _nice_ if we could figure out a way for this to be usable by
>>> Apache Aries JAXRS Whiteboard [1] which is an implementation of OSGi JAXRS
>>> Whiteboard [2].
>>>
>>> It would seem that a small SPI on the part of Geronimo's mp-openapi
>>> might be enough (so as not to pressure this up onto the mp spec).
>>>
>>> [1] https://github.com/apache/aries-jax-rs-whiteboard
>>> [2] https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html
>>>
>>>
>>> On Thu, Jun 21, 2018 at 9:06 AM, Mark Struberg <
>>> strub...@yahoo.de.invalid> wrote:
>>>
>>>> I think it fits well to geronimo.
>>>> The question is rather if CXF is fine with relying on CDI for openapi?
>>>> But since MicroProfile _requires_ CDI I think there is safe to assume
>>>> so.
>>>>
>>>> LieGru

Re: microprofile openapi @asf?

[Romain Manni-Bucau]

@Raymond: the diff between CDI and OSGi will be where the OpenAPI instance
will be created mainly so very doable (aries can even import G-openapi for
that). Only diff which can be quite intrusive is that @G we don't use plain
reflection to enable CDI meta model to be mutated during startup and
therefore let the user configure most of the model instead of hardcoding
it, but it is not that hard to abstract so I'm very confident to keep it
abstracted and to support OSGi once we support the spec with CDI (and why
not supporting CDI in aries ;)).

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 jeu. 21 juin 2018 à 15:21, Raymond Auge  a
écrit :

> It would be _nice_ if we could figure out a way for this to be usable by
> Apache Aries JAXRS Whiteboard [1] which is an implementation of OSGi JAXRS
> Whiteboard [2].
>
> It would seem that a small SPI on the part of Geronimo's mp-openapi might
> be enough (so as not to pressure this up onto the mp spec).
>
> [1] https://github.com/apache/aries-jax-rs-whiteboard
> [2] https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html
>
>
> On Thu, Jun 21, 2018 at 9:06 AM, Mark Struberg 
> wrote:
>
>> I think it fits well to geronimo.
>> The question is rather if CXF is fine with relying on CDI for openapi?
>> But since MicroProfile _requires_ CDI I think there is safe to assume so.
>>
>> LieGrue,
>> strub
>>
>> > Am 21.06.2018 um 09:59 schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com>:
>> >
>> > Hello guys,
>> >
>> > we created a repo for that and to be able to share what we do:
>> > https://gitbox.apache.org/repos/asf?p=geronimo-openapi.git
>> >
>> > I pushed a basic starting structure of the code. The big TODO is the
>> > conversion from the model (annotations) to OpenAPI instance (which
>> should
>> > be somewhere here
>> >
>> https://gitbox.apache.org/repos/asf?p=geronimo-openapi.git;a=blob;f=src/main/java/org/apache/geronimo/microprofile/openapi/impl/processor/AnnotationProcessor.java;h=141227b579495e2b072710fadb28f2d08ab07616;hb=HEAD
>> > or split in multiple "visitors" if desired).
>> >
>> > If anyone wants to help it is welcomed. Also note it is not too late to
>> > change the project hosting or other details if there is some points we
>> > missed until now.
>> >
>> > 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 mar. 19 juin 2018 à 07:39, Romain Manni-Bucau 
>> a
>> > écrit :
>> >
>> >> Basically read metadata from AnnotatedTypes (cdi) used by jaxrs cdi
>> >> extension. Im not yet sure i will need the extension itself or not
>> (doesnt
>> >> seem hard to not use it for that and would stay portable).
>> >>
>> >>
>> >> Le mar. 19 juin 2018 00:36, Andriy Redko  a écrit :
>> >>
>> >>> Hey Romain,
>> >>>
>> >>> Thanks for starting work on that. Indeed,
>> >>> https://issues.apache.org/jira/browse/CXF-7601 is
>> >>> opened but not started yet, sadly. So what is your plan / scope,
>> generate
>> >>> the OpenAPI 3.x
>> >>> specs from JAX-RS 2.1 metadata? Or someting else? May be we could also
>> >>> help you with that?
>> >>> Thanks!
>> >>>
>> >>> Best Regards,
>> >>>Andriy Redko
>> >>>
>> >>> RMB> Independent, cdi based (not reflection based)
>> >>>
>> >>> RMB> Le lun. 18 juin 2018 22:34, John D. Ament 
>> a
>> >>> écrit :
>> >>>
>> >>>>> If it's hosted at Geronimo will it be platform independent?  Or only
>> >>> work
>> >>>>> with CXF?
>> >>>
>> >>>>> On Mon, Jun 18, 2018, 3:30 PM Romain

Re: microprofile openapi @asf?

[Romain Manni-Bucau]

Hello guys,

we created a repo for that and to be able to share what we do:
https://gitbox.apache.org/repos/asf?p=geronimo-openapi.git

I pushed a basic starting structure of the code. The big TODO is the
conversion from the model (annotations) to OpenAPI instance (which should
be somewhere here
https://gitbox.apache.org/repos/asf?p=geronimo-openapi.git;a=blob;f=src/main/java/org/apache/geronimo/microprofile/openapi/impl/processor/AnnotationProcessor.java;h=141227b579495e2b072710fadb28f2d08ab07616;hb=HEAD
or split in multiple "visitors" if desired).

If anyone wants to help it is welcomed. Also note it is not too late to
change the project hosting or other details if there is some points we
missed until now.

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 mar. 19 juin 2018 à 07:39, Romain Manni-Bucau  a
écrit :

> Basically read metadata from AnnotatedTypes (cdi) used by jaxrs cdi
> extension. Im not yet sure i will need the extension itself or not (doesnt
> seem hard to not use it for that and would stay portable).
>
>
> Le mar. 19 juin 2018 00:36, Andriy Redko  a écrit :
>
>> Hey Romain,
>>
>> Thanks for starting work on that. Indeed,
>> https://issues.apache.org/jira/browse/CXF-7601 is
>> opened but not started yet, sadly. So what is your plan / scope, generate
>> the OpenAPI 3.x
>> specs from JAX-RS 2.1 metadata? Or someting else? May be we could also
>> help you with that?
>> Thanks!
>>
>> Best Regards,
>> Andriy Redko
>>
>> RMB> Independent, cdi based (not reflection based)
>>
>> RMB> Le lun. 18 juin 2018 22:34, John D. Ament  a
>> écrit :
>>
>> >> If it's hosted at Geronimo will it be platform independent?  Or only
>> work
>> >> with CXF?
>>
>> >> On Mon, Jun 18, 2018, 3:30 PM Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> >> wrote:
>>
>> >> > Hi guys,
>> >> >
>> >> > I'm planning to implement microprofile-openapi at geronimo (next to
>> other
>> >> > microprofile specs) soon (probably beginning of next month). Before
>> doing
>> >> > so I wanted to get in touch with you to ensure it was not already
>> there
>> >> > (@asf). I know CXF has a swagger impl but here, we speak about a new
>> API
>> >> > and I hope to make it dep free and aligned on other geronimo impls
>> >> > (assuming jsonb+jaxrs+cdi is in the server already which is very
>> >> acceptable
>> >> > for a MP server).
>> >> >
>> >> > Anything I should check before launching the project or is the road
>> as
>> >> open
>> >> > as I think?
>> >> >
>> >> > Technical side note: compared to the MP rest client which was way
>> easier
>> >> to
>> >> > impl @cxf cause all the code was already there, the openapi is more
>> based
>> >> > on CDI than CXF internal model so not hosting it @cxf is not an
>> issue for
>> >> > this one so don't feel any pressure please.
>> >> >
>> >> > Thanks,
>> >> > 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
>> >> > >
>> >> >
>>
>>
>>

Re: [VOTE] CXF 3.2.5/3.1.16

[Romain Manni-Bucau]

+1, tested on my apps and Apache Meecrowave

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 mar. 19 juin 2018 à 09:24, Francesco Chicchiriccò 
a écrit :

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

Re: microprofile openapi @asf?

[Romain Manni-Bucau]

Basically read metadata from AnnotatedTypes (cdi) used by jaxrs cdi
extension. Im not yet sure i will need the extension itself or not (doesnt
seem hard to not use it for that and would stay portable).


Le mar. 19 juin 2018 00:36, Andriy Redko  a écrit :

> Hey Romain,
>
> Thanks for starting work on that. Indeed,
> https://issues.apache.org/jira/browse/CXF-7601 is
> opened but not started yet, sadly. So what is your plan / scope, generate
> the OpenAPI 3.x
> specs from JAX-RS 2.1 metadata? Or someting else? May be we could also
> help you with that?
> Thanks!
>
> Best Regards,
> Andriy Redko
>
> RMB> Independent, cdi based (not reflection based)
>
> RMB> Le lun. 18 juin 2018 22:34, John D. Ament  a
> écrit :
>
> >> If it's hosted at Geronimo will it be platform independent?  Or only
> work
> >> with CXF?
>
> >> On Mon, Jun 18, 2018, 3:30 PM Romain Manni-Bucau  >
> >> wrote:
>
> >> > Hi guys,
> >> >
> >> > I'm planning to implement microprofile-openapi at geronimo (next to
> other
> >> > microprofile specs) soon (probably beginning of next month). Before
> doing
> >> > so I wanted to get in touch with you to ensure it was not already
> there
> >> > (@asf). I know CXF has a swagger impl but here, we speak about a new
> API
> >> > and I hope to make it dep free and aligned on other geronimo impls
> >> > (assuming jsonb+jaxrs+cdi is in the server already which is very
> >> acceptable
> >> > for a MP server).
> >> >
> >> > Anything I should check before launching the project or is the road as
> >> open
> >> > as I think?
> >> >
> >> > Technical side note: compared to the MP rest client which was way
> easier
> >> to
> >> > impl @cxf cause all the code was already there, the openapi is more
> based
> >> > on CDI than CXF internal model so not hosting it @cxf is not an issue
> for
> >> > this one so don't feel any pressure please.
> >> >
> >> > Thanks,
> >> > 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
> >> > >
> >> >
>
>
>

Re: microprofile openapi @asf?

[Romain Manni-Bucau]

Independent, cdi based (not reflection based)

Le lun. 18 juin 2018 22:34, John D. Ament  a écrit :

> If it's hosted at Geronimo will it be platform independent?  Or only work
> with CXF?
>
> On Mon, Jun 18, 2018, 3:30 PM Romain Manni-Bucau 
> wrote:
>
> > Hi guys,
> >
> > I'm planning to implement microprofile-openapi at geronimo (next to other
> > microprofile specs) soon (probably beginning of next month). Before doing
> > so I wanted to get in touch with you to ensure it was not already there
> > (@asf). I know CXF has a swagger impl but here, we speak about a new API
> > and I hope to make it dep free and aligned on other geronimo impls
> > (assuming jsonb+jaxrs+cdi is in the server already which is very
> acceptable
> > for a MP server).
> >
> > Anything I should check before launching the project or is the road as
> open
> > as I think?
> >
> > Technical side note: compared to the MP rest client which was way easier
> to
> > impl @cxf cause all the code was already there, the openapi is more based
> > on CDI than CXF internal model so not hosting it @cxf is not an issue for
> > this one so don't feel any pressure please.
> >
> > Thanks,
> > 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
> > >
> >
>

microprofile openapi @asf?

[Romain Manni-Bucau]

Hi guys,

I'm planning to implement microprofile-openapi at geronimo (next to other
microprofile specs) soon (probably beginning of next month). Before doing
so I wanted to get in touch with you to ensure it was not already there
(@asf). I know CXF has a swagger impl but here, we speak about a new API
and I hope to make it dep free and aligned on other geronimo impls
(assuming jsonb+jaxrs+cdi is in the server already which is very acceptable
for a MP server).

Anything I should check before launching the project or is the road as open
as I think?

Technical side note: compared to the MP rest client which was way easier to
impl @cxf cause all the code was already there, the openapi is more based
on CDI than CXF internal model so not hosting it @cxf is not an issue for
this one so don't feel any pressure please.

Thanks,
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>

Re: CXF-7753

[Romain Manni-Bucau]

+1, https://github.com/tomitribe/http-signatures-java is also a good
candidate and not that hard to integrate with CXF. The only trick I found
was to handle it correctly incase of a header requires a payload
information (for instance if you implement Digest header you need to add
the header after having processed the whole payload) but there are tricks
to do it in CXF ;).

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 ven. 15 juin 2018 à 10:39, David Karlsen  a
écrit :

> https://issues.apache.org/jira/browse/CXF-7753
>
> What do you think?
> If we make code - is it a feature you see room for in CXF?
>
> --
> --
> David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
>

Re: org.apache.cxf.cdi.CdiResourceProvider#isSingleton?

[Romain Manni-Bucau]

Le mar. 22 mai 2018 à 13:29, Andriy Redko  a écrit :

> Hi Romain,
>
> As far as I remember, we did the simplest thing possible, by relying on
> beanManager.isNormalScope(bean.getScope()), as per
> https://issues.apache.org/jira/browse/CXF-7336.
> I think the only scope we care is request one, did you run into issues
> with other scopes?
>

well there are two things to keep in mind:

1.  the resource provider is a singleton (for cxf usage)
2. cdi normal scope references are proxies handling the context and
therefore usable as singleton

=> the advtange of 2 is it is way faster than creating a new instance each
time and manage a new context
=> the issue you can get with 2 is that the creational context for normal
scoped beans is managed by the container and you don't have to release
anything if you don't want to breaks some cases
=> the issue with 1 in current form is that we are not thread safe without
my PR and we just fail with NPE in a lot of cases - this is where i was
coming from

Side note: @Depdendent management is undefined, some containers like tomee
decided to handle it request scoped to stay thread safe and current cxf
impl is singleton scoped, it is fine but just something to keep in mind
when trying to write a portable app.

Thanks.
>
> Best Regards,
> Andriy Redko
>
> Tuesday, May 22, 2018, 4:34:37 AM, you wrote:
>
> RMB> Hi guys,
>
> RMB> why org.apache.cxf.cdi.CdiResourceProvider#isSingleton returns false
> for
> RMB> normal scoped beans? In such a case the instance is a proxy which can
> be
> RMB> considered as a singleton, no?
>
> 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
> >
>
>

Re: org.apache.cxf.cdi.CdiResourceProvider#isSingleton?

[Romain Manni-Bucau]

Sent a PR since CdiResourceProvider doesn't handle correctly scopes
currently: https://github.com/apache/cxf/pull/418

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 mar. 22 mai 2018 à 10:34, Romain Manni-Bucau  a
écrit :

> Hi guys,
>
> why org.apache.cxf.cdi.CdiResourceProvider#isSingleton returns false for
> normal scoped beans? In such a case the instance is a proxy which can be
> considered as a singleton, no?
>
> 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>
>

org.apache.cxf.cdi.CdiResourceProvider#isSingleton?

[Romain Manni-Bucau]

Hi guys,

why org.apache.cxf.cdi.CdiResourceProvider#isSingleton returns false for
normal scoped beans? In such a case the instance is a proxy which can be
considered as a singleton, no?

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>