Re: Help wanted please :-)

[John D. Ament]

I attached a screenshot of the javascript errors that are popping up as
well.

On Sun, Jul 8, 2018 at 9:30 AM Andriy Redko  wrote:

> Done, https://issues.apache.org/jira/browse/INFRA-16736 (linked to
> Francesco's ticket as well).
>
> CS> I see the same problem. It also happens for other builds outside CXF.
> CS> Can you open an INFRA issue?
>
>
> CS> Christian
> CS> Am So., 8. Juli 2018 um 00:37 Uhr schrieb Andriy Redko <
> drr...@gmail.com>:
>
> CS> Hey guys,
>
> CS>  I would really appreciate if someone could help. I have created the
> Jenkins build for 3.2.x
> CS> (https://builds.apache.org/job/CXF-3.2.x) out of the CXF-Trunk-JDK18.
> For some reasons, the configuration page
> CS> (https://builds.apache.org/job/CXF-3.2.x/configure) never loads for
> me, always stuck in "Loading" spinner (tried it
> CS> many times during the day), so I cannot change the branch to
> */3.2.x-fixes for this job. Anyone would be able to help me there (or hint
> the workaround)? Thanks!
>
> CS>  Best Regards,
> CS>  Andriy Redko
>
>
>
>
>
> CS> --
>
>

Re: microprofile openapi @asf?

[John D. Ament]

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  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>

Re: Builds on Jenkins

[John D. Ament]

I'll take a look at Jenkins when back in the office.  Worst case probably
ask infra on hipchat

On Thu, Jun 14, 2018, 7:42 AM Andriy Redko  wrote:

> Hey guys,
>
> So here is what I found. I was able to get the thread dump with Apache
> Maven 3.5.2 and here is the victim:
>
> "DefaultMetadataResolver-1-0" #31 daemon prio=5 os_prio=0
> tid=0x1a9ae800 nid=0x18bc waiting on condition [0x2021e000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at
> org.eclipse.aether.connector.basic.PartialFile$LockFile.lock(PartialFile.java:113)
>
> at
> org.eclipse.aether.connector.basic.PartialFile$LockFile.(PartialFile.java:69)
>
> at
> org.eclipse.aether.connector.basic.PartialFile$Factory.newInstance(PartialFile.java:278)
>
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:438)
>
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:360)
>
> at
> org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:75)
>
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:583)
>
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:232)
>
> at
> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run(DefaultMetadataResolver.java:593)
>
> at
> org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:75)
>
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>
> at java.lang.Thread.run(Thread.java:748)
>
> Maven stuck on obtaining file lock, in this case for:
>
> Downloading from apache.snapshots:
> https://repository.apache.org/snapshots/org/apache/cxf/xjcplugins/cxf-xjc-dv/3.2.2-SNAPSHOT/maven-metadata.xml
> Downloading from apache.snapshots:
> https://repository.apache.org/snapshots/org/apache/cxf/xjcplugins/cxf-xjc-dv/3.2.2-SNAPSHOT/maven-metadata.xml
> Downloaded from apache.snapshots:
> https://repository.apache.org/snapshots/org/apache/cxf/xjcplugins/cxf-xjc-dv/3.2.2-SNAPSHOT/maven-metadata.xml
> (785 B at 2.1 kB/s)
>
> It seems to be related to https://issues.apache.org/jira/browse/MNG-6323
> and fixed in Apache Maven 3.5.3. Indeed, I have tried Apache Maven 3.5.3
> and the issue is not there anymore, at least for me. It is reproducible
> 100% (just switching from 3.5.3 back to 3.5.2 and below manifests the
> problem right away). It is still not clear to me why Colm sees slow builds
> with 3.5.3, could be another issue?
>
> Regarding Jenkins, I am not able to find what is behind "Maven 3 (latest)"
> in the tooling, I don't have right permissions. Dennis, John any chance you
> guys could help to figure it out? Thanks.
>
> Best Regards,
> Andriy Redko
>
>
>
> Friday, June 8, 2018, 6:58:37 AM, you wrote:
>
>
> The latest - 3.5.3.
>
> Colm.
>
> On Fri, Jun 8, 2018 at 11:55 AM, Andriy Redko  wrote:
>
> Hi Colm,
>
> Thanks for confirming, what version of Apache Maven you are using? As a
> temp workaround,
> if you build with Maven 3.2.1 (or I think 3.2.x in general), the issue
> shouldn't manifest.
>
> Best Regards,
> Andriy Redko
>
>
> Friday, June 8, 2018, 5:14:38 AM, you wrote:
>
> COh> I've also noticed Maven "pausing" recently when downloading SNAPSHOTs
> on my local machine (ubuntu).
>
>
> COh> Colm.
>
>
> COh> On Fri, Jun 8, 2018 at 2:27 AM, Andriy Redko 
> wrote:
>
> COh> Hey guys,
>
> COh>  Quick update on this. The issue is not resolved, BUT I accidentally
> reproduced the it on my local box. So I used to
> COh>  build with `Apache Maven 3.2.1` and have never seen any issues, but
> recently I run the CXF build with `Apache Maven 3.5.2`,
> COh>  by accident actually, and ... the same 15 mins delay on snapshot
> downloads ... !!! 100% of the time, I don't know the cause
> COh>  yet but I believe this is not an infrastructure problem so I closed
> COh> https://issues.apache.org/jira/browse/INFRA-16489 ticket.
> COh>  I will be looking into this, at least with a goal to pinpoint the
> Maven version to blame, so we could figure out the root of
> COh>  it.
>
> COh>  PS: FYI, running build on Windows box / Java 8. Will check on Linux
> shortly (but gut feeling tells me the 15 mins delay
> COh>  will be there)
>
> COh>  Best Regards,
> COh>  Andriy Redko
>
> COh>  Sunday, May 6, 2018, 2:42:05 AM, you wrote:
>
>  DK>> Hi Andriy,
>
>  DK>> thanks for the analysis.
>  >>> John, guys, any hints who might help us here? Infra team?
>
>  DK>> Could you please open an issue at:
>  DK>> https://issues.apache.org/jira/projects/INFRA/
>
>  DK>> Cheers
>  DK>> Dennis
>
>
>
>
>
>
>
>
>
> --
> Colm O 

Re: Start 3.3.x development

[John D. Ament]

Sounds like a feasible approach.  Agreed that right now using CXF in > Java
8 is a bit of a pain if you want to leverage the JPMS.  Depending on the
provided modules isn't a good idea, highly inconsistent and makes things
harder for other EE techs (e.g. CDI).

John

On Sun, May 13, 2018 at 3:37 PM David Karlsen 
wrote:

> I've started a few branches at work for applications (also one that is
> using cxf) - the way to fix it is to add the spec apis and jaxb as
> dependencies and it worked out fine.
>
> Maybe a spring5/boot2.x compatible release could be done for 3.3, then a
> 3.4 for java > 8?
>
> My .02$
>
> Den søn. 13. mai 2018 kl. 19:56 skrev Andriy Redko :
>
> > Hey Romain,
> >
> > Spring integration indeed is not a big deal (by and large). The JAXB/SOAP
> > is. To give you some background / ideas,
> > the JAXB got moved into the dedicated module as of JDK 9 and stays like
> > that in JDK 10. So the usual approach to
> > solve this dependency issue is (among others) to add modules to compiler
> > and runtime. However, with JDK 11, the JAXB
> > module (with a dozen of others) will be removed completely. The only
> > available option would be to switch the dependencies
> > to JAXB 2.3.0 (or 2.3.1 if released, and other modules from
> > github.com/javaee). This is a risky part as CXF is used in a
> > variety of context ... What we can do also is to have a spike and
> estimate
> > the impact on the CXF with all these changes
> > incorporated, than decided for 3.3.x or keeping 3.2.x. Thoughts?
> >
> > Best Regards,
> > Andriy Redko
> >
> >
> > RMB> Hey guys
> >
> >
> > RMB> Cant an option be to use subprojects? Spring integrations sound like
> > good candidate for that and now cxf is modular it should be easier.
> > RMB> Le dim. 13 mai 2018 18:27, Andriy Redko  a écrit
> :
> >
> > RMB> Hi Dennis,
> >
> > RMB>  In general, I think it would be great to accelerate the work in
> this
> > direction and having dedicated
> > RMB>  release branch sounds like a good idea. Moreover, JDK 11 will bring
> > even more challenges for us
> > RMB>  regarding the JAXB (and tons of related specs). I have been doing
> > some work related to that and from
> > RMB>  dependencies perspective, it is large but envitable change (since
> > JDK 11 cuts more stuff). Same goes
> > RMB>  for Spring Boot 2.0, the integration would need to be changed. The
> > concern I have though is that we
> > RMB>  would have to support 3.1.x, 3.2.x and 3.3.x (if it is a go) for
> > quite a while. 3.1.x is still being
> > RMB>  used and we are getting requests from time to time to backport some
> > changes from 3.2.x. 3.2.x has to
> > RMB>  stay for older Spring Boot integrations (1.5.x which is still
> > majority) and Java 8 (who knows for how
> > RMB>  long). I would be curious to hear what Dan and other guys think,
> > since they have seen similar large
> > RMB>  changes over the years. But I cerntainly agree we have to think
> > about that, dedicated branch gives
> > RMB>  us more freedom to stabilize things and experiment while 3.2.x
> > serves as a stable backup.
> >
> > RMB>  Thanks for bringing this up!
> >
> > RMB>  Best Regards,
> > RMB>  Andriy Redko
> >
> >  DK>> Hi,
> >
> >  DK>> i'd like to update CXF to Spring/ Spring Security 5 and Spring Boot
> > 2. There were also discussions about JAXB 2.3.0
> >  DK>> and we might have additional changes for Java 9/10. In my view that
> > would be a good start for CXF 3.3.x or what do you think?
> >
> >  DK>> Cheers
> >  DK>> Dennis
> >
> >
> >
> >
>
> --
> --
> David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
>

Re: Builds on Jenkins

[John D. Ament]

Andriy,

You now have access to configure the jobs.

I've reconfigured the JDK18 job to show timestamps.  I also changed the
time out strategy from absolute to no activity.  Still needs tweaking.
Though I agree a 3 hour build is not good.

John

On Sat, May 5, 2018 at 9:48 AM Andriy Redko  wrote:

> Hey guys,
>
> I think many of you noticed that builds on Jenkins (
> https://builds.apache.org/job/CXF-Trunk-JDK18/,
> https://builds.apache.org/job/CXF-Trunk-PR/)
> started to take much longer (more than 3 hours) and eventually are aborted
> due to timeout (the last one we have is dated April 24th). Anyone has
> looked at it or has an idea why it started to happen? I don't have access
> to Jenkins configuration, but if someone could assist with adding the
> Timestamper (https://plugins.jenkins.io/timestamper), it would help to
> capture the timeline. The agents builds are run on seem to be the same.
>
> On another topic, since JDK9 is end of life, do we need to keep
> https://builds.apache.org/job/CXF-Master-JDK9/ active?
> Thanks!
>
> Best Regards,
> Andriy Redko
>
>
>
>
>
>
>

Re: please disable GitBox spamming to dev@

[John D. Ament]

Lots of projects have been struggling with this.  Many podlings have been
creating notifications@ to reduce the dev list clutter.  Those interested
can subscribe there.

On Wed, Apr 25, 2018, 4:51 PM Daniel Kulp  wrote:

>
> I disagree…. Comments on PR’s should go to dev so the developers can see
> what is happening with the discussions.
>
> Dan
>
>
>
> > On Apr 25, 2018, at 4:14 PM, Mark Struberg 
> wrote:
> >
> > GitBox should imo get directed to committs@cxf.a.o
> >
> > Would make it much easier to see what's going on.
> >
> > txs and LieGrue,
> > strub
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

Re: Failed CXF 3.1.X build

[John D. Ament]

I changed the inactivity check to 30 mins.  But is the build really silent
for 3 minutes and that's not an issue?

John

On Sun, Apr 8, 2018 at 11:01 AM Andriy Redko  wrote:

> Thanks John, now the build fails with "Build timed out (after 3 minutes).
> Marking the build as aborted.", is it possible to increase the inactivity
> timeout a bit? Thanks.
>
> Saturday, April 7, 2018, 8:09:24 PM, you wrote:
>
> JDA> I just changed the job config similar to what I did for master, it'll
> time out from inactivity instead of the absolute timeout.
>
>
> JDA> John
>
>
> JDA> On Sat, Apr 7, 2018 at 7:49 PM Andriy Redko  wrote:
>
> JDA> I see "Build timed out (after 90 minutes). Marking the build as
> aborted." right before this error, let me try to schedule another one.
>
>  AS>> Hi,
>
>  AS>> Any ideas why the Jenkins build was failed?
>  AS>> Look like infrastructure issue for me:
>
>  AS>>
> https://builds.apache.org/view/A-D/view/CXF/job/CXF-3.1.x/1405/console
>
>  AS>> java.io.IOException: Failed to extract
> /home/jenkins/jenkins-slave/workspace/CXF-3.1.x/rt/frontend/js/transfer of
> 2 files
>  AS>> at hudson.FilePath.readFromTar(FilePath.java:2317)
>  AS>> at hudson.FilePath.copyRecursiveTo(FilePath.java:2221)
>  AS>> at
> jenkins.model.StandardArtifactManager.archive(StandardArtifactManager.java:61)
>  AS>> at
> com.cloudbees.jenkins.plugins.jsync.archiver.JSyncArtifactManager.remoteSync(JSyncArtifactManager.java:128)
>  AS>> at
> com.cloudbees.jenkins.plugins.jsync.archiver.JSyncArtifactManager.archive(JSyncArtifactManager.java:76)
>  AS>> at
> hudson.maven.MavenBuild$ProxyImpl.performArchiving(MavenBuild.java:512)
>  AS>> at
> hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:881)
>  AS>> at
> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:504)
>  AS>> at hudson.model.Run.execute(Run.java:1724)
>  AS>> at
> hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:543)
>  AS>> at
> hudson.model.ResourceController.execute(ResourceController.java:97)
>  AS>> at hudson.model.Executor.run(Executor.java:429)
>  AS>> Caused by: java.io.IOException: java.lang.InterruptedException
>
>  AS>> Regards,
>  AS>> Andrei.
>
>
>
>

Re: Failed CXF 3.1.X build

[John D. Ament]

I just changed the job config similar to what I did for master, it'll time
out from inactivity instead of the absolute timeout.

John

On Sat, Apr 7, 2018 at 7:49 PM Andriy Redko  wrote:

> I see "Build timed out (after 90 minutes). Marking the build as aborted."
> right before this error, let me try to schedule another one.
>
> AS> Hi,
>
> AS> Any ideas why the Jenkins build was failed?
> AS> Look like infrastructure issue for me:
>
> AS> https://builds.apache.org/view/A-D/view/CXF/job/CXF-3.1.x/1405/console
>
> AS> java.io.IOException: Failed to extract
> /home/jenkins/jenkins-slave/workspace/CXF-3.1.x/rt/frontend/js/transfer of
> 2 files
> AS> at hudson.FilePath.readFromTar(FilePath.java:2317)
> AS> at hudson.FilePath.copyRecursiveTo(FilePath.java:2221)
> AS> at
> jenkins.model.StandardArtifactManager.archive(StandardArtifactManager.java:61)
> AS> at
> com.cloudbees.jenkins.plugins.jsync.archiver.JSyncArtifactManager.remoteSync(JSyncArtifactManager.java:128)
> AS> at
> com.cloudbees.jenkins.plugins.jsync.archiver.JSyncArtifactManager.archive(JSyncArtifactManager.java:76)
> AS> at
> hudson.maven.MavenBuild$ProxyImpl.performArchiving(MavenBuild.java:512)
> AS> at
> hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:881)
> AS> at
> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:504)
> AS> at hudson.model.Run.execute(Run.java:1724)
> AS> at
> hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:543)
> AS> at
> hudson.model.ResourceController.execute(ResourceController.java:97)
> AS> at hudson.model.Executor.run(Executor.java:429)
> AS> Caused by: java.io.IOException: java.lang.InterruptedException
>
> AS> Regards,
> AS> Andrei.
>
>

Re: [VOTE] CXF 2.3.4

[John D. Ament]

+1 plus this fixes an issue for Romain.

On Thu, Mar 22, 2018 at 5:18 PM Daniel Kulp  wrote:

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

Re: [VOTE] Apache CXF 3.2.3

[John D. Ament]

+1 looks good to me.  I'll work on updating docs for some of my bigger
changes.

On Fri, Mar 16, 2018 at 4:54 PM Daniel Kulp  wrote:

>
> This is a vote to release CXF 3.2.3.   We’ve fixed over 27 JIRA issues.
>
>
> Staging area:
> https://repository.apache.org/content/repositories/orgapachecxf-1114/
>
>
> Tag:
>
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=commit;h=b82303bfb6802817d3ce3be1ce30df74fee50675
>
>
> Here is my +1.
>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

Re: Handling the case where CXF Servlet doesn't match expected transport ID

[John D. Ament]

I created https://issues.apache.org/jira/browse/CXF-7659


On Sun, Feb 25, 2018 at 11:38 AM Andriy Redko <drr...@gmail.com> wrote:

> Sounds reasonable, would you mind to create a ticket? I could pick it up
> shortly (or if you have time, please go ahead). Thanks.
>
> JDA> Actually here's another way.
>
>
> JDA> Create a new property on bus for the default transport ID
> JDA> Default it to the HTTP one
> JDA> in the SSE extension, override it to SSE.
>
>
> JDA> On Sun, Feb 25, 2018 at 10:47 AM John D. Ament <johndam...@apache.org>
> wrote:
>
> JDA> Basically, yes.
>
>
> JDA> So here's what I'm thinking.
>
>
> JDA> - Determine that transportId is null
> JDA> - ask for the registered HTTP one ending with /configuration
> JDA> - If that's null, loop through all registered and return the first
> one ending with /configuration
>
>
> JDA> Thoughts?
>
>
>
> JDA> On Sun, Feb 25, 2018 at 10:44 AM Andriy Redko <drr...@gmail.com>
> wrote:
>
> JDA> Hey John,
>
> JDA>  You mean add the capability to DestinationFactoryManager to list all
> registered
> JDA>  destination factories and in case transport id is not set, just pick
> the first
> JDA>  one? We could try it out, may be we could also give a preference to
> HTTP transport
> JDA>  in case more than one is available (at least to minimize the effect
> of the change).
>
> JDA>  Also, the documentation should be updated to reflect the SSE
> transport presence, I
> JDA>  will do that shortly. Thanks for spotting it.
>
> JDA>  Makes sense?
>
> JDA>  Best Regards,
> JDA> Andriy Redko
>
>  JDA>> Andriy,
>
>  JDA>> Sadly no.  Honestly, this leads to broken apps.  Just to clarify my
> setup:
>
>  JDA>> - WAR File deployed to Tomcat
>  JDA>> - Has Weld Servlet + CXF CDI + CXF SSE modules deployed
>  JDA>> - Has no SSE server side components
>
>  JDA>> At this point, I may use the client to talk to a remote server (for
>  JDA>> inter-node communication) but don't rely on it long term.  I have
> no server
>  JDA>> side components.  But you're saying I must set the transportId to
> SSE.
>
>  JDA>> The SSE transportId requirement is not documented anywhere as best
> as I can
>  JDA>> tell.  SSE isn't listed at
> http://cxf.apache.org/docs/transports.html for
>  JDA>> Atmosphere.
>
>  JDA>> I think a better approach would be to modify
>  JDA>> CXFNonSpringServlet.getDestinationRegistryFromBusOrDefault (
>  JDA>>
> https://github.com/apache/cxf/blob/master/rt/transports/http/src/main/java/org/apache/cxf/transport/servlet/CXFNonSpringServlet.java#L119
>  JDA>> )
>  JDA>> so that instead of hard coding the HTTP transport as the default,
> we ask
>  JDA>> for the first destination factory it finds registered (if one is).
>
>  JDA>> Thoughts?
>
>  JDA>> John
>
>  JDA>> On Sun, Feb 25, 2018 at 9:25 AM Andriy Redko <drr...@gmail.com>
> wrote:
>
>  >>> I wish it could be as easy as that :) Hope my previous messages give
> some
>  >>> context and explanations why we have dedicated transport and why we
> need
>  >>> to set Transport Id in a few places, not just one. It would be ideal
> to
>  >>> enrich HTTP transport with SSE support but it will take some time, not
>  >>> an easy one (certainly doable).
>
>  >>> Best Regards,
>  >>> Andriy Redko
>
>  >>> JDA> I see a bit more when this is failing.
>
>  >>> JDA> When the JAXRS bean has the transport ID set, In
>  >>> DestinationFactoryManager
>  >>> JDA> you have two factories created, both for SSE (regular & config
>  >>> JDA> namespaces).  However, since on the servlet the transportId is
> null
>  >>> when it
>  >>> JDA> tries to look up the namespace it defaults to the HTTP transport.
>  >>> This
>  >>> JDA> causes it to create a new destination factory where nothing has
> been
>  >>> found.
>
>  >>> JDA> So I think what I would recommend is coming up with a way for
> CXF to
>  >>> figure
>  >>> JDA> out a better default, instead of the using the default
> transportId.
>
>  >>> JDA> Or do as Romain says and make it so that SSE works on the normal
>  >>> JDA> transportId.
>
>  >>> JDA> John
>
>  >>> JDA> On Sun, Feb 25, 2018 at 3:05 AM Romain Manni-Bucau <
>  >>> rmannibu...@gmail

Re: Handling the case where CXF Servlet doesn't match expected transport ID

[John D. Ament]

Actually here's another way.

Create a new property on bus for the default transport ID
Default it to the HTTP one
in the SSE extension, override it to SSE.

On Sun, Feb 25, 2018 at 10:47 AM John D. Ament <johndam...@apache.org>
wrote:

> Basically, yes.
>
> So here's what I'm thinking.
>
> - Determine that transportId is null
> - ask for the registered HTTP one ending with /configuration
> - If that's null, loop through all registered and return the first one
> ending with /configuration
>
> Thoughts?
>
>
> On Sun, Feb 25, 2018 at 10:44 AM Andriy Redko <drr...@gmail.com> wrote:
>
>> Hey John,
>>
>> You mean add the capability to DestinationFactoryManager to list all
>> registered
>> destination factories and in case transport id is not set, just pick the
>> first
>> one? We could try it out, may be we could also give a preference to HTTP
>> transport
>> in case more than one is available (at least to minimize the effect of
>> the change).
>>
>> Also, the documentation should be updated to reflect the SSE transport
>> presence, I
>> will do that shortly. Thanks for spotting it.
>>
>> Makes sense?
>>
>> Best Regards,
>>Andriy Redko
>>
>> JDA> Andriy,
>>
>> JDA> Sadly no.  Honestly, this leads to broken apps.  Just to clarify my
>> setup:
>>
>> JDA> - WAR File deployed to Tomcat
>> JDA> - Has Weld Servlet + CXF CDI + CXF SSE modules deployed
>> JDA> - Has no SSE server side components
>>
>> JDA> At this point, I may use the client to talk to a remote server (for
>> JDA> inter-node communication) but don't rely on it long term.  I have no
>> server
>> JDA> side components.  But you're saying I must set the transportId to
>> SSE.
>>
>> JDA> The SSE transportId requirement is not documented anywhere as best
>> as I can
>> JDA> tell.  SSE isn't listed at
>> http://cxf.apache.org/docs/transports.html for
>> JDA> Atmosphere.
>>
>> JDA> I think a better approach would be to modify
>> JDA> CXFNonSpringServlet.getDestinationRegistryFromBusOrDefault (
>> JDA>
>> https://github.com/apache/cxf/blob/master/rt/transports/http/src/main/java/org/apache/cxf/transport/servlet/CXFNonSpringServlet.java#L119
>> JDA> )
>> JDA> so that instead of hard coding the HTTP transport as the default, we
>> ask
>> JDA> for the first destination factory it finds registered (if one is).
>>
>> JDA> Thoughts?
>>
>> JDA> John
>>
>> JDA> On Sun, Feb 25, 2018 at 9:25 AM Andriy Redko <drr...@gmail.com>
>> wrote:
>>
>> >> I wish it could be as easy as that :) Hope my previous messages give
>> some
>> >> context and explanations why we have dedicated transport and why we
>> need
>> >> to set Transport Id in a few places, not just one. It would be ideal to
>> >> enrich HTTP transport with SSE support but it will take some time, not
>> >> an easy one (certainly doable).
>>
>> >> Best Regards,
>> >> Andriy Redko
>>
>> >> JDA> I see a bit more when this is failing.
>>
>> >> JDA> When the JAXRS bean has the transport ID set, In
>> >> DestinationFactoryManager
>> >> JDA> you have two factories created, both for SSE (regular & config
>> >> JDA> namespaces).  However, since on the servlet the transportId is
>> null
>> >> when it
>> >> JDA> tries to look up the namespace it defaults to the HTTP transport.
>> >> This
>> >> JDA> causes it to create a new destination factory where nothing has
>> been
>> >> found.
>>
>> >> JDA> So I think what I would recommend is coming up with a way for CXF
>> to
>> >> figure
>> >> JDA> out a better default, instead of the using the default
>> transportId.
>>
>> >> JDA> Or do as Romain says and make it so that SSE works on the normal
>> >> JDA> transportId.
>>
>> >> JDA> John
>>
>> >> JDA> On Sun, Feb 25, 2018 at 3:05 AM Romain Manni-Bucau <
>> >> rmannibu...@gmail.com>
>> >> JDA> wrote:
>>
>> >> >> +1 wondered the same and technically sse can just be activated for
>> http
>> >> >> transport IMHO
>>
>> >> >> Le 25 févr. 2018 05:10, "John D. Ament" <johndam...@apache.org> a
>> >> écrit :
>>
>> >> >> > Here's a 

Re: Handling the case where CXF Servlet doesn't match expected transport ID

[John D. Ament]

Basically, yes.

So here's what I'm thinking.

- Determine that transportId is null
- ask for the registered HTTP one ending with /configuration
- If that's null, loop through all registered and return the first one
ending with /configuration

Thoughts?

On Sun, Feb 25, 2018 at 10:44 AM Andriy Redko <drr...@gmail.com> wrote:

> Hey John,
>
> You mean add the capability to DestinationFactoryManager to list all
> registered
> destination factories and in case transport id is not set, just pick the
> first
> one? We could try it out, may be we could also give a preference to HTTP
> transport
> in case more than one is available (at least to minimize the effect of the
> change).
>
> Also, the documentation should be updated to reflect the SSE transport
> presence, I
> will do that shortly. Thanks for spotting it.
>
> Makes sense?
>
> Best Regards,
>Andriy Redko
>
> JDA> Andriy,
>
> JDA> Sadly no.  Honestly, this leads to broken apps.  Just to clarify my
> setup:
>
> JDA> - WAR File deployed to Tomcat
> JDA> - Has Weld Servlet + CXF CDI + CXF SSE modules deployed
> JDA> - Has no SSE server side components
>
> JDA> At this point, I may use the client to talk to a remote server (for
> JDA> inter-node communication) but don't rely on it long term.  I have no
> server
> JDA> side components.  But you're saying I must set the transportId to SSE.
>
> JDA> The SSE transportId requirement is not documented anywhere as best as
> I can
> JDA> tell.  SSE isn't listed at http://cxf.apache.org/docs/transports.html
> for
> JDA> Atmosphere.
>
> JDA> I think a better approach would be to modify
> JDA> CXFNonSpringServlet.getDestinationRegistryFromBusOrDefault (
> JDA>
> https://github.com/apache/cxf/blob/master/rt/transports/http/src/main/java/org/apache/cxf/transport/servlet/CXFNonSpringServlet.java#L119
> JDA> )
> JDA> so that instead of hard coding the HTTP transport as the default, we
> ask
> JDA> for the first destination factory it finds registered (if one is).
>
> JDA> Thoughts?
>
> JDA> John
>
> JDA> On Sun, Feb 25, 2018 at 9:25 AM Andriy Redko <drr...@gmail.com>
> wrote:
>
> >> I wish it could be as easy as that :) Hope my previous messages give
> some
> >> context and explanations why we have dedicated transport and why we need
> >> to set Transport Id in a few places, not just one. It would be ideal to
> >> enrich HTTP transport with SSE support but it will take some time, not
> >> an easy one (certainly doable).
>
> >> Best Regards,
> >> Andriy Redko
>
> >> JDA> I see a bit more when this is failing.
>
> >> JDA> When the JAXRS bean has the transport ID set, In
> >> DestinationFactoryManager
> >> JDA> you have two factories created, both for SSE (regular & config
> >> JDA> namespaces).  However, since on the servlet the transportId is null
> >> when it
> >> JDA> tries to look up the namespace it defaults to the HTTP transport.
> >> This
> >> JDA> causes it to create a new destination factory where nothing has
> been
> >> found.
>
> >> JDA> So I think what I would recommend is coming up with a way for CXF
> to
> >> figure
> >> JDA> out a better default, instead of the using the default transportId.
>
> >> JDA> Or do as Romain says and make it so that SSE works on the normal
> >> JDA> transportId.
>
> >> JDA> John
>
> >> JDA> On Sun, Feb 25, 2018 at 3:05 AM Romain Manni-Bucau <
> >> rmannibu...@gmail.com>
> >> JDA> wrote:
>
> >> >> +1 wondered the same and technically sse can just be activated for
> http
> >> >> transport IMHO
>
> >> >> Le 25 févr. 2018 05:10, "John D. Ament" <johndam...@apache.org> a
> >> écrit :
>
> >> >> > Here's a reproducer app, if anyone else is curious.
> >> >> > https://github.com/johnament/cxf-demo-reactive-cdi
> >> >> >
> >> >> > If you comment out
> >> >> > https://github.com/johnament/cxf-demo-reactive-cdi/blob/
> >> >> > master/src/main/webapp/WEB-INF/web.xml#L10-L13
> >> >> > then
> >> >> > you'll see the issue, but deploying this as is to tomcat will work
> >> just
> >> >> > fine.
> >> >> >
> >> >> > On Sat, Feb 24, 2018 at 10:59 PM John D. Ament <
> johndam...@apache.org
> >> >
> >> >> > wrote:
> >> >> >
> >> >> > > Hi,
> >> >> > >
> >> >> > > So I've finally been able to confirm an issue.
> >> >> > >
> >> >> > > When CXF's SSE libraries are on the classpath, if the
> transportId of
> >> >> the
> >> >> > > servlet does not match the transport ID set with the SSE
> component,
> >> >> then
> >> >> > no
> >> >> > > services are discovered.
> >> >> > >
> >> >> > > IMHO, there may be cases where the SSE libraries are present
> (client
> >> >> > only)
> >> >> > > and no server runtimes are there.  In this case, the transport ID
> >> will
> >> >> > not
> >> >> > > match.
> >> >> > >
> >> >> > > I'm curious, do both need to be set?  What is the benefit/need on
> >> the
> >> >> > > servlet layer needing the transport ID set when the underlying
> >> feature
> >> >> > also
> >> >> > > does it?
> >> >> > >
> >> >> > > John
> >> >> > >
> >> >> >
>
>
>
>

Re: Handling the case where CXF Servlet doesn't match expected transport ID

[John D. Ament]

Andriy,

Sadly no.  Honestly, this leads to broken apps.  Just to clarify my setup:

- WAR File deployed to Tomcat
- Has Weld Servlet + CXF CDI + CXF SSE modules deployed
- Has no SSE server side components

At this point, I may use the client to talk to a remote server (for
inter-node communication) but don't rely on it long term.  I have no server
side components.  But you're saying I must set the transportId to SSE.

The SSE transportId requirement is not documented anywhere as best as I can
tell.  SSE isn't listed at http://cxf.apache.org/docs/transports.html for
Atmosphere.

I think a better approach would be to modify
CXFNonSpringServlet.getDestinationRegistryFromBusOrDefault (
https://github.com/apache/cxf/blob/master/rt/transports/http/src/main/java/org/apache/cxf/transport/servlet/CXFNonSpringServlet.java#L119
)
so that instead of hard coding the HTTP transport as the default, we ask
for the first destination factory it finds registered (if one is).

Thoughts?

John

On Sun, Feb 25, 2018 at 9:25 AM Andriy Redko <drr...@gmail.com> wrote:

> I wish it could be as easy as that :) Hope my previous messages give some
> context and explanations why we have dedicated transport and why we need
> to set Transport Id in a few places, not just one. It would be ideal to
> enrich HTTP transport with SSE support but it will take some time, not
> an easy one (certainly doable).
>
> Best Regards,
> Andriy Redko
>
> JDA> I see a bit more when this is failing.
>
> JDA> When the JAXRS bean has the transport ID set, In
> DestinationFactoryManager
> JDA> you have two factories created, both for SSE (regular & config
> JDA> namespaces).  However, since on the servlet the transportId is null
> when it
> JDA> tries to look up the namespace it defaults to the HTTP transport.
> This
> JDA> causes it to create a new destination factory where nothing has been
> found.
>
> JDA> So I think what I would recommend is coming up with a way for CXF to
> figure
> JDA> out a better default, instead of the using the default transportId.
>
> JDA> Or do as Romain says and make it so that SSE works on the normal
> JDA> transportId.
>
> JDA> John
>
> JDA> On Sun, Feb 25, 2018 at 3:05 AM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> JDA> wrote:
>
> >> +1 wondered the same and technically sse can just be activated for http
> >> transport IMHO
>
> >> Le 25 févr. 2018 05:10, "John D. Ament" <johndam...@apache.org> a
> écrit :
>
> >> > Here's a reproducer app, if anyone else is curious.
> >> > https://github.com/johnament/cxf-demo-reactive-cdi
> >> >
> >> > If you comment out
> >> > https://github.com/johnament/cxf-demo-reactive-cdi/blob/
> >> > master/src/main/webapp/WEB-INF/web.xml#L10-L13
> >> > then
> >> > you'll see the issue, but deploying this as is to tomcat will work
> just
> >> > fine.
> >> >
> >> > On Sat, Feb 24, 2018 at 10:59 PM John D. Ament <johndam...@apache.org
> >
> >> > wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > > So I've finally been able to confirm an issue.
> >> > >
> >> > > When CXF's SSE libraries are on the classpath, if the transportId of
> >> the
> >> > > servlet does not match the transport ID set with the SSE component,
> >> then
> >> > no
> >> > > services are discovered.
> >> > >
> >> > > IMHO, there may be cases where the SSE libraries are present (client
> >> > only)
> >> > > and no server runtimes are there.  In this case, the transport ID
> will
> >> > not
> >> > > match.
> >> > >
> >> > > I'm curious, do both need to be set?  What is the benefit/need on
> the
> >> > > servlet layer needing the transport ID set when the underlying
> feature
> >> > also
> >> > > does it?
> >> > >
> >> > > John
> >> > >
> >> >
>
>
>

Re: Handling the case where CXF Servlet doesn't match expected transport ID

[John D. Ament]

I see a bit more when this is failing.

When the JAXRS bean has the transport ID set, In DestinationFactoryManager
you have two factories created, both for SSE (regular & config
namespaces).  However, since on the servlet the transportId is null when it
tries to look up the namespace it defaults to the HTTP transport.  This
causes it to create a new destination factory where nothing has been found.

So I think what I would recommend is coming up with a way for CXF to figure
out a better default, instead of the using the default transportId.

Or do as Romain says and make it so that SSE works on the normal
transportId.

John

On Sun, Feb 25, 2018 at 3:05 AM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> +1 wondered the same and technically sse can just be activated for http
> transport IMHO
>
> Le 25 févr. 2018 05:10, "John D. Ament" <johndam...@apache.org> a écrit :
>
> > Here's a reproducer app, if anyone else is curious.
> > https://github.com/johnament/cxf-demo-reactive-cdi
> >
> > If you comment out
> > https://github.com/johnament/cxf-demo-reactive-cdi/blob/
> > master/src/main/webapp/WEB-INF/web.xml#L10-L13
> > then
> > you'll see the issue, but deploying this as is to tomcat will work just
> > fine.
> >
> > On Sat, Feb 24, 2018 at 10:59 PM John D. Ament <johndam...@apache.org>
> > wrote:
> >
> > > Hi,
> > >
> > > So I've finally been able to confirm an issue.
> > >
> > > When CXF's SSE libraries are on the classpath, if the transportId of
> the
> > > servlet does not match the transport ID set with the SSE component,
> then
> > no
> > > services are discovered.
> > >
> > > IMHO, there may be cases where the SSE libraries are present (client
> > only)
> > > and no server runtimes are there.  In this case, the transport ID will
> > not
> > > match.
> > >
> > > I'm curious, do both need to be set?  What is the benefit/need on the
> > > servlet layer needing the transport ID set when the underlying feature
> > also
> > > does it?
> > >
> > > John
> > >
> >
>

Re: Handling the case where CXF Servlet doesn't match expected transport ID

[John D. Ament]

Here's a reproducer app, if anyone else is curious.
https://github.com/johnament/cxf-demo-reactive-cdi

If you comment out
https://github.com/johnament/cxf-demo-reactive-cdi/blob/master/src/main/webapp/WEB-INF/web.xml#L10-L13
then
you'll see the issue, but deploying this as is to tomcat will work just
fine.

On Sat, Feb 24, 2018 at 10:59 PM John D. Ament <johndam...@apache.org>
wrote:

> Hi,
>
> So I've finally been able to confirm an issue.
>
> When CXF's SSE libraries are on the classpath, if the transportId of the
> servlet does not match the transport ID set with the SSE component, then no
> services are discovered.
>
> IMHO, there may be cases where the SSE libraries are present (client only)
> and no server runtimes are there.  In this case, the transport ID will not
> match.
>
> I'm curious, do both need to be set?  What is the benefit/need on the
> servlet layer needing the transport ID set when the underlying feature also
> does it?
>
> John
>

Handling the case where CXF Servlet doesn't match expected transport ID

[John D. Ament]

Hi,

So I've finally been able to confirm an issue.

When CXF's SSE libraries are on the classpath, if the transportId of the
servlet does not match the transport ID set with the SSE component, then no
services are discovered.

IMHO, there may be cases where the SSE libraries are present (client only)
and no server runtimes are there.  In this case, the transport ID will not
match.

I'm curious, do both need to be set?  What is the benefit/need on the
servlet layer needing the transport ID set when the underlying feature also
does it?

John

Re: Failing MonoReactorTest on master

[John D. Ament]

It looks like its passing on master in jenkins.  are you able to debug why
its failing?

On Mon, Feb 19, 2018 at 11:26 AM Colm O hEigeartaigh 
wrote:

> Hi all,
>
> The following test is failing for me on master:
>
> [INFO] Running org.apache.cxf.systest.jaxrs.reactor.MonoReactorTest
> [ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 2.444 s <<< FAILURE! - in
> org.apache.cxf.systest.jaxrs.reactor.MonoReactorTest
> [ERROR]
> testTextJsonImplicitListAsyncStream(org.apache.cxf.systest.jaxrs.reactor.MonoReactorTest)
> Time elapsed: 0.525 s  <<< FAILURE!
> java.lang.AssertionError
> at
> org.apache.cxf.systest.jaxrs.reactor.MonoReactorTest.testTextJsonImplicitListAsyncStream(MonoReactorTest.java:80)
>
> Colm.
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>

Re: 3.2.2 cdi integration and @Context.

[John D. Ament]

Feel free to raise an issue on JIRA and a PR.

Personally, I'd like for the javax.servlet stuff to remain, so maybe we
make this configuration driven instead.

On Mon, Feb 12, 2018 at 9:42 AM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> side note: temporary work around which makes 3.2.2 usable directly:
>
> InjectionUtils.STANDARD_CONTEXT_CLASSES.removeIf(s ->
> s.startsWith("javax.servlet."));
>
>
>
>
> 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
> >
>
> 2018-02-06 21:07 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>
> > Mainly but I strongly think cxf shouldnt assume it can own default. At
> > least we should observe beans to skip the add if already here and have a
> > bus property to fully skip it - or extension event to configure jaxrs
> > extension.
> >
> > Le 6 févr. 2018 20:53, "John D. Ament" <johndam...@apache.org> a écrit :
> >
> >> So then your issue is simply the javax.servlet ones, right?
> >>
> >> On Tue, Feb 6, 2018 at 2:14 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> >> wrote:
> >>
> >> > Le 6 févr. 2018 20:07, "John D. Ament" <johndam...@apache.org> a
> écrit
> >> :
> >> >
> >> > If we remove @Default then it won't be injectable without
> >> > @ContextResolved.  Are you seeing an issue though?
> >> >
> >> >
> >> > Yes. Owb-web provides all servlet beans so it leads to ambiguous
> >> > resolution.
> >> >
> >> > Also not being in the spec it must use a custom classifier imo - think
> >> of
> >> > request issue deltaspike had cause of that.
> >> >
> >> > Min is to toggle them off by default and probably another toggle for
> >> other
> >> > context types. Typically meecrowave supports context injection without
> >> > @Inject (as in the spec) so this just slows down the runtime for no
> >> gain.
> >> >
> >> > Side note: vetoing conflicting bean doeznt work since in a container
> cxf
> >> > would be wrong more often than the built in bean. Think to a
> >> > jaxrs/jsf/servlet app, the cdi container knows better how to inject
> the
> >> > request for instance - no need of cxf threadlocal which is not set by
> >> jsf
> >> > ;).
> >> >
> >> >
> >> >
> >> > On Tue, Feb 6, 2018 at 1:59 PM Romain Manni-Bucau <
> >> rmannibu...@gmail.com>
> >> > wrote:
> >> >
> >> > > Cdi provides a servlet context, request etc... bean. With cxf
> >> contextbean
> >> > > it is now ambiguous and you cant use a cdi container with cxf. The
> >> > default
> >> > > qualifier must be dropped from that bean.
> >> > >
> >> > > Le 6 févr. 2018 19:57, "John D. Ament" <john.d.am...@gmail.com> a
> >> écrit
> >> > :
> >> > >
> >> > > > Sorry don't really understand your response.
> >> > > >
> >> > > > On Tue, Feb 6, 2018 at 1:52 PM Romain Manni-Bucau <
> >> > rmannibu...@gmail.com
> >> > > >
> >> > > > wrote:
> >> > > >
> >> > > > > @Inject X x; should match not a single CXF injection but
> >> > > > > ContextProducerBean matches @Default. Read too fast and though
> it
> >> was
> >> > > > > @Context but just looks like @Default shouldnt be in the beans.
> >> > > > >
> >> > > > >
> >> > > > > 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
> >> > > > > >
> >> > > > >
> >> > > > > 2018-02-06 19:50 GMT+01:00 John D. Ament <johndam...@apache.org
> >:
> >> > > > >
> >> > > > > > On Tue, Feb 6, 2018 at 1:49 PM Romain Manni-Bucau <
> >> > > > rmannibu...@gmail.com
> >> > > > > >
> >> > > > > > wrote:
> >> > > > > >
> >> > > > > > > Hi guys,
> >> > > > > > >
> >> > > > > > > doesn't cdi integration of jaxrs miss a:
> >> > > > > > >
> >> > > > > > > bbd.addQualifier(Context.class);
> >> > > > > > >
> >> > > > > > >
> >> > > > > > What class is that?
> >> > > > > >
> >> > > > > >
> >> > > > > > > ?
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > 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: Going offline soon

[John D. Ament]

Hi Sergey,

Thanks for all your hard work.  Definitely have learned quite a bit from
you.  Best of luck to you in your next venture, I'm sure you'll be missed
over here.  Hopefully, if they are in the JAX-RS space we'll all cross
paths again some day.

John

On Fri, Feb 9, 2018 at 6:23 AM Sergey Beryozkin 
wrote:

> Hi Guys,
> Just a short note that I'll be going offline for a while pretty soon, at
> the end of next week, this is due to me starting a new job in a company
> with their own JAX-RS investment/interest, and joining the project which
> depends on that, with no CXF JAX-RS link.
>
> Please get in touch privately if you reckon I might be of some help,
>
> Thank you all and best of luck :-)
>
> Sergey
>

3.2.3 in JIRA?

[John D. Ament]

Would someone mind adding 3.2.3 to JIRA?

John

Re: 3.2.2 cdi integration and @Context.

[John D. Ament]

So then your issue is simply the javax.servlet ones, right?

On Tue, Feb 6, 2018 at 2:14 PM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Le 6 févr. 2018 20:07, "John D. Ament" <johndam...@apache.org> a écrit :
>
> If we remove @Default then it won't be injectable without
> @ContextResolved.  Are you seeing an issue though?
>
>
> Yes. Owb-web provides all servlet beans so it leads to ambiguous
> resolution.
>
> Also not being in the spec it must use a custom classifier imo - think of
> request issue deltaspike had cause of that.
>
> Min is to toggle them off by default and probably another toggle for other
> context types. Typically meecrowave supports context injection without
> @Inject (as in the spec) so this just slows down the runtime for no gain.
>
> Side note: vetoing conflicting bean doeznt work since in a container cxf
> would be wrong more often than the built in bean. Think to a
> jaxrs/jsf/servlet app, the cdi container knows better how to inject the
> request for instance - no need of cxf threadlocal which is not set by jsf
> ;).
>
>
>
> On Tue, Feb 6, 2018 at 1:59 PM Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
> > Cdi provides a servlet context, request etc... bean. With cxf contextbean
> > it is now ambiguous and you cant use a cdi container with cxf. The
> default
> > qualifier must be dropped from that bean.
> >
> > Le 6 févr. 2018 19:57, "John D. Ament" <john.d.am...@gmail.com> a écrit
> :
> >
> > > Sorry don't really understand your response.
> > >
> > > On Tue, Feb 6, 2018 at 1:52 PM Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > > wrote:
> > >
> > > > @Inject X x; should match not a single CXF injection but
> > > > ContextProducerBean matches @Default. Read too fast and though it was
> > > > @Context but just looks like @Default shouldnt be in the beans.
> > > >
> > > >
> > > > 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
> > > > >
> > > >
> > > > 2018-02-06 19:50 GMT+01:00 John D. Ament <johndam...@apache.org>:
> > > >
> > > > > On Tue, Feb 6, 2018 at 1:49 PM Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Hi guys,
> > > > > >
> > > > > > doesn't cdi integration of jaxrs miss a:
> > > > > >
> > > > > > bbd.addQualifier(Context.class);
> > > > > >
> > > > > >
> > > > > What class is that?
> > > > >
> > > > >
> > > > > > ?
> > > > > >
> > > > > >
> > > > > >
> > > > > > 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: 3.2.2 cdi integration and @Context.

[John D. Ament]

If we remove @Default then it won't be injectable without
@ContextResolved.  Are you seeing an issue though?

On Tue, Feb 6, 2018 at 1:59 PM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Cdi provides a servlet context, request etc... bean. With cxf contextbean
> it is now ambiguous and you cant use a cdi container with cxf. The default
> qualifier must be dropped from that bean.
>
> Le 6 févr. 2018 19:57, "John D. Ament" <john.d.am...@gmail.com> a écrit :
>
> > Sorry don't really understand your response.
> >
> > On Tue, Feb 6, 2018 at 1:52 PM Romain Manni-Bucau <rmannibu...@gmail.com
> >
> > wrote:
> >
> > > @Inject X x; should match not a single CXF injection but
> > > ContextProducerBean matches @Default. Read too fast and though it was
> > > @Context but just looks like @Default shouldnt be in the beans.
> > >
> > >
> > > 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
> > > >
> > >
> > > 2018-02-06 19:50 GMT+01:00 John D. Ament <johndam...@apache.org>:
> > >
> > > > On Tue, Feb 6, 2018 at 1:49 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Hi guys,
> > > > >
> > > > > doesn't cdi integration of jaxrs miss a:
> > > > >
> > > > > bbd.addQualifier(Context.class);
> > > > >
> > > > >
> > > > What class is that?
> > > >
> > > >
> > > > > ?
> > > > >
> > > > >
> > > > >
> > > > > 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: 3.2.2 cdi integration and @Context.

[John D. Ament]

Sorry don't really understand your response.

On Tue, Feb 6, 2018 at 1:52 PM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> @Inject X x; should match not a single CXF injection but
> ContextProducerBean matches @Default. Read too fast and though it was
> @Context but just looks like @Default shouldnt be in the beans.
>
>
> 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
> >
>
> 2018-02-06 19:50 GMT+01:00 John D. Ament <johndam...@apache.org>:
>
> > On Tue, Feb 6, 2018 at 1:49 PM Romain Manni-Bucau <rmannibu...@gmail.com
> >
> > wrote:
> >
> > > Hi guys,
> > >
> > > doesn't cdi integration of jaxrs miss a:
> > >
> > > bbd.addQualifier(Context.class);
> > >
> > >
> > What class is that?
> >
> >
> > > ?
> > >
> > >
> > >
> > > 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: 3.2.2 cdi integration and @Context.

[John D. Ament]

On Tue, Feb 6, 2018 at 1:49 PM Romain Manni-Bucau 
wrote:

> Hi guys,
>
> doesn't cdi integration of jaxrs miss a:
>
> bbd.addQualifier(Context.class);
>
>
What class is that?


> ?
>
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>

Re: Remove obsolete RxJava code and keep RxJava2 only one

[John D. Ament]

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

John

On Wed, Nov 15, 2017 at 6:53 PM Andriy Redko  wrote:

> Hey Sergey,
>
> That would be ideal I think (move RxJava into separate module). RxJava2 and
> RxJava are quite different frameworks, some people just stuck with RxJava
> so
> we could support them there. Thanks.
>
> Best Regards,
> Andriy Redko
>
> JDA> What about just leaving the old RxJava code in a module by itself
> (when I
> JDA> was looking recently, it didn't make much sense to see both RxJava and
> JDA> RxJava2 in one module).
>
> JDA> On Wed, Nov 15, 2017 at 10:56 AM Sergey Beryozkin <
> sberyoz...@gmail.com>
> JDA> wrote:
>
> >> Hi
>
> >> cxf-rt-rs-extension-rx ships the code for both (old) RxJava and RxJava2
> >> code. It supports returning RxJava2 Flowable and Observable on the
> >> server and accepting it on the client, and the same for the (old) RxJava
> >> Observable...
>
> >> While even the (old) RxJava code is very new for CXF, the reality is
> >> that RxJava has been around for a while now and with RxJava2 embracing
> >> org.reactivestreams, it's hard to see CXF users preferring to start with
> >> the (old) RxJava.
>
> >> The other minor problem is that cxf-rt-rs-extension-rx has optional
> >> RxJava and RxJava2 deps to be able to ship the relevant code in the same
> >> module and splitting it into 2 modules will be too much at this point.
>
> >> I suggest that unless some users confirm (I CC to the users) that they
> >> need to use the (old) RxJava code, then we just remove it and make
> >> things much simpler...
>
> >> Thanks, Sergey
>
>
>

Re: How to use rx() with proxy clients?

[John D. Ament]

Yes, treating it like a MBR would work.  However, there needs to be a way
as you mention to make it go async.  I'm more trying to see if this is
already supported somehow.

There's a few ways I could see executor working:

- when building the proxy, include an executor() method (I think this is
already inherited from JAX-RS 2.1)
- use a property() call (already supported it seems in the core client)
- one of the method arguments on the proxy

John

On Sun, Feb 4, 2018 at 3:12 PM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Why not using the response type? It is not hard to detect it is a
> CompletionStage and therefore call rx().
>
> Side note: if there is an Executor param it should be forwarded/configured
> IMHO.
>
> Le 4 févr. 2018 20:49, "John D. Ament" <john.d.am...@gmail.com> a écrit :
>
> > So far, it looks like proxy clients don't support rx() invocations.  I do
> > see rx() methods within WebClient that would allow its use, but I don't
> see
> > a straight forward way that those methods could be invoked within a
> proxy.
> > It could be that a custom annotation is used, indicating the response
> > should be from an rx() invocation.
> >
> > John
> >
>

How to use rx() with proxy clients?

[John D. Ament]

So far, it looks like proxy clients don't support rx() invocations.  I do
see rx() methods within WebClient that would allow its use, but I don't see
a straight forward way that those methods could be invoked within a proxy.
It could be that a custom annotation is used, indicating the response
should be from an rx() invocation.

John

Re: Reactive Streams dependency in Project Reactor module

[John D. Ament]

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

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

But either way, I'm not sure I follow your thoughts yet, since my use case
is just taking an existing Flux/Mono and piping it to a AsyncResponse
(nothing to do with client).

Granted, by doing that, I'm relying on internal CXF code, but it works.

John

On Sun, Feb 4, 2018 at 2:04 PM Sergey Beryozkin <sberyoz...@gmail.com>
wrote:

> The same though applies to the client code - it makes no sense on the
> server side, so may be it is just simpler to make that dep non-optional
> for the consistency purpose, up to you guys...
>
> Sergey
> On 04/02/18 18:57, Sergey Beryozkin wrote:
> > You've already concluded it is a bug...
> >
> > I recall now, I made it optional because that code makes no sense on the
> > client side only, while the reactive streams api is also pulled from the
> > reactor dep...
> >
> > Cheers, Sergey
> > On 04/02/18 18:12, Andriy Redko wrote:
> >> Same conclusion, it shouldn't be optional/provided.
> >> Thanks for spotting it.
> >>
> >> Best Regards,
> >>  Andriy Redko
> >>
> >> JDA> That's what I'm asking basically.  If you look at
> >> JDA>
> >>
> https://github.com/apache/cxf/blob/master/rt/rs/extensions/reactor/pom.xml#L47-L49
> >>
> >> JDA> I
> >> JDA> don't believe it should be provided/optional.
> >>
> >> JDA> On Sun, Feb 4, 2018 at 12:49 PM Sergey Beryozkin
> >> <sberyoz...@gmail.com>
> >> JDA> wrote:
> >>
> >>>> Why should be optional ?
> >>
> >>>> Sergey
> >>>> On 04/02/18 14:00, John D. Ament wrote:
> >>>>> Hi,
> >>>>>
> >>>>> As far as I can tell, the dependency on reactive streams isn't
> >>>>> optional
> >>>> in
> >>>>> the project reactor module.  I'm wondering, was this just a typo,
> >>>>> or am I
> >>>>> missing something?
> >>>>>
> >>>>> John
> >>>>>
> >>
> >>
> >>
> >
>
>

Re: Reactive Streams dependency in Project Reactor module

[John D. Ament]

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

On Sun, Feb 4, 2018 at 12:49 PM Sergey Beryozkin <sberyoz...@gmail.com>
wrote:

> Why should be optional ?
>
> Sergey
> On 04/02/18 14:00, John D. Ament wrote:
> > Hi,
> >
> > As far as I can tell, the dependency on reactive streams isn't optional
> in
> > the project reactor module.  I'm wondering, was this just a typo, or am I
> > missing something?
> >
> > John
> >
>
>

Reactive Streams dependency in Project Reactor module

[John D. Ament]

Hi,

As far as I can tell, the dependency on reactive streams isn't optional in
the project reactor module.  I'm wondering, was this just a typo, or am I
missing something?

John

Re: [VOTE] CXF 3.2.2

[John D. Ament]

+1

On Fri, Feb 2, 2018 at 2:57 PM Daniel Kulp  wrote:

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

Re: Avoiding the use of PerRequestResourceProvider in CDI classes

[John D. Ament]

Andriy,

Maybe it could do that in a prior state, but presently if there is no
no-args constructor it throws an exception ->
https://github.com/apache/cxf/blob/master/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/lifecycle/PerRequestResourceProvider.java#L51-L54

Hence why this is an issue.  Take a look at the BookStore class in CDI
Systests to see my work around, even though the @Inject constructor should
be the one used.

John

On Sun, Jan 14, 2018 at 12:53 PM Andriy Redko <drr...@gmail.com> wrote:

> It makes a lot of sense to have the intantiation mechanism aligned with the
> dependency injection framework being used. Right now it is CXF-driven in
> most
> cases (static method calls, which translate to one of the newInstance()
> calls).
>
> IMFO PerRequestResourceProvider does not actually require to have a
> default (noarg?)
> constructor, it is able to call one with (injectable) arguments as well.
>
> Best Regards,
> Andriy Redko
>
> RMB> My thinking was to move it to the provider itself since you can mix a
> CDI
> RMB> (multiple scopes)/Spring/Custom set of providers in the same app with
> RMB> different constraints.
>
>
> 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>
>
> RMB> 2018-01-14 16:43 GMT+01:00 John D. Ament <johndam...@apache.org>:
>
> >> So you're thinking along the lines of moving some of these features
> into an
> >> instance method on JAXRSServerFactoryBean so that implementors can
> >> extend/override the behavior?
>
> >> One thing I just noticed, this problem only happens when you have a
> JAX-RS
> >> Application that declares getClasses().
>
> >> John
>
> >> On Sun, Jan 14, 2018 at 10:08 AM Romain Manni-Bucau <
> rmannibu...@gmail.com
> >> >
> >> wrote:
>
> >> > +1, basically it leads to delegate all the bean validation (not the
> spec)
> >> > to the impl and skip the static utilities. This should probably be a
> >> > general rule in CXF: never use a static method, it prevents to do a
> lot
> >> of
> >> > things (like support meta annotation for jaxrs annotations for
> instance
> >> to
> >> > cite only another feature current design locks).
> >> >
> >> >
> >> > 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>
> >> >
> >> > 2018-01-14 14:36 GMT+01:00 John D. Ament <johndam...@apache.org>:
> >> >
> >> > > Hi
> >> > >
> >> > > I noticed that CXF requires a default constructor, even when it
> >> delegates
> >> > > down to a CDI container to do the work.  This is because all of the
> >> > > resources/providers are passed to ResourceUtils.createApplication
> >> which
> >> > in
> >> > > turn creates the default PerRequestResourceProvider for those
> resource
> >> > > classes.
> >> > >
> >> > > When I create a dependent scoped CDI bean, I would expect I don't
> need
> >> a
> >> > > default constructor, but right now its required.  I think we could
> >> > create a
> >> > > replacement if we passed the List to
> >> > > the JAXRSServerFactoryBean being created, instead of letting the
> >> default
> >> > > version be created first.
> >> > >
> >> > > John
> >> > >
> >> >
>
>
>

Timeframe for 3.2.2?

[John D. Ament]

Just wondering, since 3.2.1 was released ~2 months ago do we have a
timeframe for when 3.2.2 will be released?

John

Re: Avoiding the use of PerRequestResourceProvider in CDI classes

[John D. Ament]

So you're thinking along the lines of moving some of these features into an
instance method on JAXRSServerFactoryBean so that implementors can
extend/override the behavior?

One thing I just noticed, this problem only happens when you have a JAX-RS
Application that declares getClasses().

John

On Sun, Jan 14, 2018 at 10:08 AM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> +1, basically it leads to delegate all the bean validation (not the spec)
> to the impl and skip the static utilities. This should probably be a
> general rule in CXF: never use a static method, it prevents to do a lot of
> things (like support meta annotation for jaxrs annotations for instance to
> cite only another feature current design locks).
>
>
> 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>
>
> 2018-01-14 14:36 GMT+01:00 John D. Ament <johndam...@apache.org>:
>
> > Hi
> >
> > I noticed that CXF requires a default constructor, even when it delegates
> > down to a CDI container to do the work.  This is because all of the
> > resources/providers are passed to ResourceUtils.createApplication which
> in
> > turn creates the default PerRequestResourceProvider for those resource
> > classes.
> >
> > When I create a dependent scoped CDI bean, I would expect I don't need a
> > default constructor, but right now its required.  I think we could
> create a
> > replacement if we passed the List to
> > the JAXRSServerFactoryBean being created, instead of letting the default
> > version be created first.
> >
> > John
> >
>

Avoiding the use of PerRequestResourceProvider in CDI classes

[John D. Ament]

Hi

I noticed that CXF requires a default constructor, even when it delegates
down to a CDI container to do the work.  This is because all of the
resources/providers are passed to ResourceUtils.createApplication which in
turn creates the default PerRequestResourceProvider for those resource
classes.

When I create a dependent scoped CDI bean, I would expect I don't need a
default constructor, but right now its required.  I think we could create a
replacement if we passed the List to
the JAXRSServerFactoryBean being created, instead of letting the default
version be created first.

John

Re: Could CXF team give Geronimo a pointer (Confluence export related)?

[John D. Ament]

On Mon, Jan 8, 2018 at 10:48 AM Daniel Kulp <dk...@apache.org> wrote:

>
>
> > On Jan 8, 2018, at 9:39 AM, John D. Ament <johndam...@apache.org> wrote:
> >
> >
> > I don't know much about this process.  I've kind of picked ti up in lieu
> of
> > existing Geronimo community who may have known about this.
> >
> > Is https://svn.apache.org/repos/asf/geronimo/site/trunk/ the equivalent
> of
> > the ActiveMQ repo you pointed to?
> >
> > If so, it looks like we're pointing to CXF 2.7.4
> > https://svn.apache.org/repos/asf/geronimo/site/trunk/wiki-export/pom.xml
>
> It looks like there is an svn:externals on the wiki-export dir that pulls
> in the CXF source code.   First step would be to remove that.   Then update
> the pom to match what the ActiveMQ pom looks like, more or less.
>
> That said, I see you have also created a pom in the parent directory that
> is now being called instead.   If you svn mv the conf dir up to the parent,
> update the update-site script to pass the -Pconfluence profile, it should
> work.   At that point, I think you can just rm the wiki-export dir.
>
>
>
I'm definitely making progress, thanks.

At this point, I'm stuck on a NPE
https://ci.apache.org/builders/geronimo-site-production/builds/3692/steps/compile/logs/stdio

I haven't done any svn mv or rm's yet.


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

Re: Could CXF team give Geronimo a pointer (Confluence export related)?

[John D. Ament]

Daniel,

On Mon, Jan 8, 2018 at 9:26 AM Daniel Kulp <dk...@apache.org> wrote:

>
> > On Jan 8, 2018, at 9:14 AM, John D. Ament <johndam...@apache.org> wrote:
> >
> > Hi guys (maybe Daniel specifically)
> >
> > Geronimo uses the same buildbot config that CXF does for their website
> > (exporting from confluence).  Seems our build is broke, like the CXF
> build
> > was.
> >
> https://ci.apache.org/builders/geronimo-site-production/builds/3687/steps/compile/logs/stdio
> >
> > Are there any pointers you could give me to resolve this?
>
> That looks like a CXF version issue…. What version is the pom picking up?
>
> That said, why is it even compiling the source?   Can it not just depend
> on the deployed jar?   The ActiveMQ pom for example grabs the 1.0-SNAPSHOT
> jar which then pulls in the needed CXF dependencies transitively so you
> don’t need to worry about it:
>
> https://svn.apache.org/repos/asf/activemq/activemq-website/



I don't know much about this process.  I've kind of picked ti up in lieu of
existing Geronimo community who may have known about this.

Is https://svn.apache.org/repos/asf/geronimo/site/trunk/ the equivalent of
the ActiveMQ repo you pointed to?

If so, it looks like we're pointing to CXF 2.7.4
https://svn.apache.org/repos/asf/geronimo/site/trunk/wiki-export/pom.xml



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

Could CXF team give Geronimo a pointer (Confluence export related)?

[John D. Ament]

Hi guys (maybe Daniel specifically)

Geronimo uses the same buildbot config that CXF does for their website
(exporting from confluence).  Seems our build is broke, like the CXF build
was.
https://ci.apache.org/builders/geronimo-site-production/builds/3687/steps/compile/logs/stdio

Are there any pointers you could give me to resolve this?

John

Change in Checkstyles?

[John D. Ament]

I just pulled in master a bit ago and received a bunch of compilation
failures due to changes in checkstyle.  Was there a vote or something to
change our checkstyle rules?

John

Re: How to automatically register OpenTracingFeature?

[John D. Ament]

DA> customizations outside of CDI to ensure that it can be auto
> >> >> > registered.
> >> >> >
> >> >> >
> >> >> > >> JDA> John
> >> >> >
> >> >> >
> >> >> > >> JDA> On Fri, Dec 22, 2017 at 11:12 AM Andriy Redko <
> >> drr...@gmail.com>
> >> >> > wrote:
> >> >> >
> >> >> > >> JDA> Hey John,
> >> >> >
> >> >> > >> JDA>  The OpenTracingFeature
> >> (org.apache.cxf.tracing.opentracing.jaxrs
> >> >> > package) is JAX-RS feature,
> >> >> > >> JDA>  which JAXRS CDI extension should recognize out of the box.
> >> There
> >> >> > is also CXF feature (
> >> >> > >> JDA>  in org.apache.cxf.tracing.opentracing package) to be used
> for
> >> >> > JAX-WS services. The only explanation
> >> >> > >> JDA>  I have why it is not being picked up it the absense of
> >> bean.xml
> >> >> > so we could fix that. I will
> >> >> > >> JDA>  take a look shorly (if you haven't figured this one out
> >> already).
> >> >> > Thanks.
> >> >> >
> >> >> > >> JDA>  Best Regards,
> >> >> > >> JDA>  Andriy Redko
> >> >> >
> >> >> >
> >> >> > >>   JDA>> I'm not sure either, this is the behavior I see in the
> >> code:
> >> >> >
> >> >> > >>   JDA>> - Register JAX-RS resources (with @ApplicationPath)
> >> >> > >>   JDA>> - Register JAX-RS resources (with @Path)
> >> >> > >>   JDA>> - Register JAX-RS providers (with JAX-RS @Provider)
> >> >> > >>   JDA>> - Register JAX-RS features (with JAX-RS @Feature)
> >> >> > >>   JDA>> - Register CXF features (doesn't care if it has a CXF
> >> @Provider
> >> >> > annotation but I see the OpenTracing one does have it)
> >> >> > >>   JDA>> - Otherwise we assume its the CXF Bus object
> >> >> >
> >> >> > >>   JDA>> There's not much happening with a CXF @Provider
> >> declaration in
> >> >> > the extension.  But at the end of the day, I'm only
> >> >> > >>   JDA>> dealing with a JAX-RS @Provider and that doesn't get
> >> registered
> >> >> > since it's not a CDI bean.  I don't see any issue
> >> >> > >>   JDA>> registering CXF @Provider this way as well, but its
> >> possible
> >> >> > it's not a CDI bean still, but that's ultimately what the
> customizer
> >> was
> >> >> > put in for.
> >> >> >
> >> >> > >>   JDA>> John
> >> >> >
> >> >> > >>   JDA>> On 2017-12-22 09:56, Sergey Beryozkin <
> >> sberyoz...@gmail.com>
> >> >> > wrote:
> >> >> > >>   >>> Sure, I just don't understand what is the difference
> between
> >> a
> >> >> > JAX-RS
> >> >> > >>   >>> feature and CXF feature, as far as the CXF CDI code is
> >> concerned.
> >> >> > If it
> >> >> > >>   >>> can load the JAX-RS features which have not been written
> >> with CDI
> >> >> > in
> >> >> > >>   >>> mind, why can't it load CXF features without some extra
> work
> >> >> > going into
> >> >> > >>   >>> these features...
> >> >> >
> >> >> > >>   >>> Thanks, Sergey
> >> >> > >>   >>> On 22/12/17 14:50, John D. Ament wrote:
> >> >> > >>   >>> > That's not really the issue though.  The extension will
> >> only
> >> >> > receive CDI managed beans.  Take a look at my pull to see what I
> had
> >> to do
> >> >> > to get it to register automatically.  If nothing else, this is an
> >> argument
> >> >> > for moving JAXRSServer Customization into core and using service
> >> loader
> >> >> > :-)  Perhaps after the new year.
> >> >> > >>   >>> >
> >> >> > >>   >>> > On 2017-12-22 09:23, Sergey Beryozkin <
> >> sberyoz...@gmail.com>
> >> >> > wrote:
> >> >> > >>   >>> >> I was not referring the OpenTracing module offering a
> CDI
> >> >> > extension, but
> >> >> > >>   >>> >> to the work Andriy did in the CXF CDI integration where
> >> the
> >> >> > providers
> >> >> > >>   >>> >> and feature are picked up. Thought, when we were
> >> discussing
> >> >> > the SSE
> >> >> > >>   >>> >> feature I thought Andriy said it was looking at the CXF
> >> >> > @Provider as
> >> >> > >>   >>> >> well, may be I misunderstood.
> >> >> > >>   >>> >> Updating the CDI code to check CXF @Provider, if it is
> not
> >> >> > already
> >> >> > >>   >>> >> checked, makes sense IMHO
> >> >> > >>   >>> >>
> >> >> > >>   >>> >> Sergey
> >> >> > >>   >>> >> On 22/12/17 14:08, John D. Ament wrote:
> >> >> > >>   >>> >>> Actually one more thing.  The CDI extension only looks
> >> for
> >> >> > JAX-RS @Provider not CXF @Provider.
> >> >> > >>   >>> >>>
> >> >> > >>   >>> >>> On 2017-12-22 09:06, "John D. Ament"<
> >> johndam...@apache.org>
> >> >> > wrote:
> >> >> > >>   >>> >>>> I'm not sure what the CDI extension has to do with
> >> this.  It
> >> >> > has no bean defining annotations, and there is no beans.xml in the
> >> JAR that
> >> >> > it ships with so I'm not sure it would be picked up by the
> extension.
> >> >> > >>   >>> >>>>
> >> >> > >>   >>> >>>> There's nothing special done for TomcatwarTest to
> make
> >> more
> >> >> > JARs available, right?
> >> >> > >>   >>> >>>>
> >> >> > >>   >>> >>>> On 2017-12-22 08:15, Sergey Beryozkin <
> >> sberyoz...@gmail.com>
> >> >> > wrote:
> >> >> > >>   >>> >>>>> It is annotated with CXF @Provider annotation -
> should
> >> be
> >> >> > picked up by
> >> >> > >>   >>> >>>>> the CXF CDI extension
> >> >> > >>   >>> >>>>>
> >> >> > >>   >>> >>>>> Sergey
> >> >> > >>   >>> >>>>> On 22/12/17 13:07, John D. Ament wrote:
> >> >> > >>   >>> >>>>>> I'm trying to finish up testing CDI injection of
> >> Context
> >> >> > objects.  The one
> >> >> > >>   >>> >>>>>> area I'm struggling with is the automatic
> >> registration of
> >> >> > this feature.  I
> >> >> > >>   >>> >>>>>> added a dependency on OpenTracing, just to confirm
> >> that
> >> >> > injection via CDI
> >> >> > >>   >>> >>>>>> works (and to be honest, this is one of my use
> cases,
> >> >> > working with
> >> >> > >>   >>> >>>>>> tracing).  However, it seems that this feature
> isn't
> >> >> > automatically
> >> >> > >>   >>> >>>>>> registered via CDI.  Is there something I have to
> do
> >> to
> >> >> > make it work?
> >> >> > >>   >>> >>>>>>
> >> >> > >>   >>> >>>>>> John
> >> >> > >>   >>> >>>>>>
> >> >> > >>   >>> >>>>>
> >> >> > >>   >>> >>>>
> >> >> > >>   >>> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
>
>
>
>

Re: How to automatically register OpenTracingFeature?

[John D. Ament]

 - Register JAX-RS resources (with @ApplicationPath)
> >> > >>   JDA>> - Register JAX-RS resources (with @Path)
> >> > >>   JDA>> - Register JAX-RS providers (with JAX-RS @Provider)
> >> > >>   JDA>> - Register JAX-RS features (with JAX-RS @Feature)
> >> > >>   JDA>> - Register CXF features (doesn't care if it has a CXF
> @Provider
> >> > annotation but I see the OpenTracing one does have it)
> >> > >>   JDA>> - Otherwise we assume its the CXF Bus object
> >> >
> >> > >>   JDA>> There's not much happening with a CXF @Provider
> declaration in
> >> > the extension.  But at the end of the day, I'm only
> >> > >>   JDA>> dealing with a JAX-RS @Provider and that doesn't get
> registered
> >> > since it's not a CDI bean.  I don't see any issue
> >> > >>   JDA>> registering CXF @Provider this way as well, but its
> possible
> >> > it's not a CDI bean still, but that's ultimately what the customizer
> was
> >> > put in for.
> >> >
> >> > >>   JDA>> John
> >> >
> >> > >>   JDA>> On 2017-12-22 09:56, Sergey Beryozkin <
> sberyoz...@gmail.com>
> >> > wrote:
> >> > >>   >>> Sure, I just don't understand what is the difference between
> a
> >> > JAX-RS
> >> > >>   >>> feature and CXF feature, as far as the CXF CDI code is
> concerned.
> >> > If it
> >> > >>   >>> can load the JAX-RS features which have not been written
> with CDI
> >> > in
> >> > >>   >>> mind, why can't it load CXF features without some extra work
> >> > going into
> >> > >>   >>> these features...
> >> >
> >> > >>   >>> Thanks, Sergey
> >> > >>   >>> On 22/12/17 14:50, John D. Ament wrote:
> >> > >>   >>> > That's not really the issue though.  The extension will
> only
> >> > receive CDI managed beans.  Take a look at my pull to see what I had
> to do
> >> > to get it to register automatically.  If nothing else, this is an
> argument
> >> > for moving JAXRSServer Customization into core and using service
> loader
> >> > :-)  Perhaps after the new year.
> >> > >>   >>> >
> >> > >>   >>> > On 2017-12-22 09:23, Sergey Beryozkin <
> sberyoz...@gmail.com>
> >> > wrote:
> >> > >>   >>> >> I was not referring the OpenTracing module offering a CDI
> >> > extension, but
> >> > >>   >>> >> to the work Andriy did in the CXF CDI integration where
> the
> >> > providers
> >> > >>   >>> >> and feature are picked up. Thought, when we were
> discussing
> >> > the SSE
> >> > >>   >>> >> feature I thought Andriy said it was looking at the CXF
> >> > @Provider as
> >> > >>   >>> >> well, may be I misunderstood.
> >> > >>   >>> >> Updating the CDI code to check CXF @Provider, if it is not
> >> > already
> >> > >>   >>> >> checked, makes sense IMHO
> >> > >>   >>> >>
> >> > >>   >>> >> Sergey
> >> > >>   >>> >> On 22/12/17 14:08, John D. Ament wrote:
> >> > >>   >>> >>> Actually one more thing.  The CDI extension only looks
> for
> >> > JAX-RS @Provider not CXF @Provider.
> >> > >>   >>> >>>
> >> > >>   >>> >>> On 2017-12-22 09:06, "John D. Ament"<
> johndam...@apache.org>
> >> > wrote:
> >> > >>   >>> >>>> I'm not sure what the CDI extension has to do with
> this.  It
> >> > has no bean defining annotations, and there is no beans.xml in the
> JAR that
> >> > it ships with so I'm not sure it would be picked up by the extension.
> >> > >>   >>> >>>>
> >> > >>   >>> >>>> There's nothing special done for TomcatwarTest to make
> more
> >> > JARs available, right?
> >> > >>   >>> >>>>
> >> > >>   >>> >>>> On 2017-12-22 08:15, Sergey Beryozkin <
> sberyoz...@gmail.com>
> >> > wrote:
> >> > >>   >>> >>>>> It is annotated with CXF @Provider annotation - should
> be
> >> > picked up by
> >> > >>   >>> >>>>> the CXF CDI extension
> >> > >>   >>> >>>>>
> >> > >>   >>> >>>>> Sergey
> >> > >>   >>> >>>>> On 22/12/17 13:07, John D. Ament wrote:
> >> > >>   >>> >>>>>> I'm trying to finish up testing CDI injection of
> Context
> >> > objects.  The one
> >> > >>   >>> >>>>>> area I'm struggling with is the automatic
> registration of
> >> > this feature.  I
> >> > >>   >>> >>>>>> added a dependency on OpenTracing, just to confirm
> that
> >> > injection via CDI
> >> > >>   >>> >>>>>> works (and to be honest, this is one of my use cases,
> >> > working with
> >> > >>   >>> >>>>>> tracing).  However, it seems that this feature isn't
> >> > automatically
> >> > >>   >>> >>>>>> registered via CDI.  Is there something I have to do
> to
> >> > make it work?
> >> > >>   >>> >>>>>>
> >> > >>   >>> >>>>>> John
> >> > >>   >>> >>>>>>
> >> > >>   >>> >>>>>
> >> > >>   >>> >>>>
> >> > >>   >>> >>
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
>
>
>

Re: How to automatically register OpenTracingFeature?

[John D. Ament]

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

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

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

John

On 2017-12-22 15:24, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: 
> How can i disable it now? Tink that cxf feature - even if in separate
> modules - shouldnt be auto registered until it has a deactivable flag -
> classpath properties + overridable through system prop.
> 
> Wdyt?
> 
> Le 22 déc. 2017 18:38, "Andriy Redko" <drr...@gmail.com> a écrit :
> 
> > Hi Sergey,
> >
> > It wasn't (for CDI only), but it could have been always included manually.
> > Thanks.
> >
> > Best Regards,
> > Andriy Redko
> >
> > SB> Hi Andriy
> >
> > SB> So how was a JAX-RS (OpenTracing) Feature discovered without beans.xml
> > ?
> >
> > SB> Cheers, Sergey
> > SB> On 22/12/17 17:24, Andriy Redko wrote:
> > >> The beans.xml was missed indeed, I added it and OpenTracingFeature has
> > been discovered right away.
> > >> The commit is on its way. Thanks!
> >
> > >> Best Regards,
> > >>  Andriy Redko
> >
> > >> JDA> I'm holding off on doing anything to fix it.  For one, a user may
> > not want to use the global tracer so making it
> > >> JDA> so that they register it makes more sense.  Ultimately to solve
> > it, I think we should be moving server
> > >> JDA> customizations outside of CDI to ensure that it can be auto
> > registered.
> >
> >
> > >> JDA> John
> >
> >
> > >> JDA> On Fri, Dec 22, 2017 at 11:12 AM Andriy Redko <drr...@gmail.com>
> > wrote:
> >
> > >> JDA> Hey John,
> >
> > >> JDA>  The OpenTracingFeature (org.apache.cxf.tracing.opentracing.jaxrs
> > package) is JAX-RS feature,
> > >> JDA>  which JAXRS CDI extension should recognize out of the box. There
> > is also CXF feature (
> > >> JDA>  in org.apache.cxf.tracing.opentracing package) to be used for
> > JAX-WS services. The only explanation
> > >> JDA>  I have why it is not being picked up it the absense of bean.xml
> > so we could fix that. I will
> > >> JDA>  take a look shorly (if you haven't figured this one out already).
> > Thanks.
> >
> > >> JDA>  Best Regards,
> > >> JDA>  Andriy Redko
> >
> >
> > >>   JDA>> I'm not sure either, this is the behavior I see in the code:
> >
> > >>   JDA>> - Register JAX-RS resources (with @ApplicationPath)
> > >>   JDA>> - Register JAX-RS resources (with @Path)
> > >>   JDA>> - Register JAX-RS providers (with JAX-RS @Provider)
> > >>   JDA>> - Register JAX-RS features (with JAX-RS @Feature)
> > >>   JDA>> - Register CXF features (doesn't care if it has a CXF @Provider
> > annotation but I see the OpenTracing one does have it)
> > >>   JDA>> - Otherwise we assume its the CXF Bus object
> >
> > >>   JDA>> There's not much happening with a CXF @Provider declaration in
> > the extension.  But at the end of the day, I'm only
> > >>   JDA>> dealing with a JAX-RS @Provider and that doesn't get registered
> > since it's not a CDI bean.  I don't see any issue
> > >>   JDA>> registering CXF @Provider this way as well, but its possible
> > it's not a CDI bean still, but that's ultimately what the customizer was
> > put in for.
> >
> > >>   JDA>> John
> >
> > >>   JDA>> On 2017-12-22 09:56, Sergey Beryozkin <sberyoz...@gmail.com>
> > wrote:
> > >>   >>> Sure, I just don't understand what is the difference between a
> > JAX-RS
> > >>   >>> feature and CXF feature, as far as the CXF CDI code is concerned.
> > If it
> > >>   >>> can load the JAX-RS features which have not been written with CDI
> > in
> > >>   >&

Re: How to automatically register OpenTracingFeature?

[John D. Ament]

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

John

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

> Hey John,
>
> The OpenTracingFeature (org.apache.cxf.tracing.opentracing.jaxrs package)
> is JAX-RS feature,
> which JAXRS CDI extension should recognize out of the box. There is also
> CXF feature (
> in org.apache.cxf.tracing.opentracing package) to be used for JAX-WS
> services. The only explanation
> I have why it is not being picked up it the absense of bean.xml so we
> could fix that. I will
> take a look shorly (if you haven't figured this one out already). Thanks.
>
> Best Regards,
> Andriy Redko
>
>
> JDA> I'm not sure either, this is the behavior I see in the code:
>
> JDA> - Register JAX-RS resources (with @ApplicationPath)
> JDA> - Register JAX-RS resources (with @Path)
> JDA> - Register JAX-RS providers (with JAX-RS @Provider)
> JDA> - Register JAX-RS features (with JAX-RS @Feature)
> JDA> - Register CXF features (doesn't care if it has a CXF @Provider
> annotation but I see the OpenTracing one does have it)
> JDA> - Otherwise we assume its the CXF Bus object
>
> JDA> There's not much happening with a CXF @Provider declaration in the
> extension.  But at the end of the day, I'm only
> JDA> dealing with a JAX-RS @Provider and that doesn't get registered since
> it's not a CDI bean.  I don't see any issue
> JDA> registering CXF @Provider this way as well, but its possible it's not
> a CDI bean still, but that's ultimately what the customizer was put in for.
>
> JDA> John
>
> JDA> On 2017-12-22 09:56, Sergey Beryozkin <sberyoz...@gmail.com> wrote:
> >> Sure, I just don't understand what is the difference between a JAX-RS
> >> feature and CXF feature, as far as the CXF CDI code is concerned. If it
> >> can load the JAX-RS features which have not been written with CDI in
> >> mind, why can't it load CXF features without some extra work going into
> >> these features...
> >>
> >> Thanks, Sergey
> >> On 22/12/17 14:50, John D. Ament wrote:
> >> > That's not really the issue though.  The extension will only receive
> CDI managed beans.  Take a look at my pull to see what I had to do to get
> it to register automatically.  If nothing else, this is an argument for
> moving JAXRSServer Customization into core and using service loader :-)
> Perhaps after the new year.
> >> >
> >> > On 2017-12-22 09:23, Sergey Beryozkin <sberyoz...@gmail.com> wrote:
> >> >> I was not referring the OpenTracing module offering a CDI extension,
> but
> >> >> to the work Andriy did in the CXF CDI integration where the providers
> >> >> and feature are picked up. Thought, when we were discussing the SSE
> >> >> feature I thought Andriy said it was looking at the CXF @Provider as
> >> >> well, may be I misunderstood.
> >> >> Updating the CDI code to check CXF @Provider, if it is not already
> >> >> checked, makes sense IMHO
> >> >>
> >> >> Sergey
> >> >> On 22/12/17 14:08, John D. Ament wrote:
> >> >>> Actually one more thing.  The CDI extension only looks for JAX-RS
> @Provider not CXF @Provider.
> >> >>>
> >> >>> On 2017-12-22 09:06, "John D. Ament"<johndam...@apache.org> wrote:
> >> >>>> I'm not sure what the CDI extension has to do with this.  It has
> no bean defining annotations, and there is no beans.xml in the JAR that it
> ships with so I'm not sure it would be picked up by the extension.
> >> >>>>
> >> >>>> There's nothing special done for TomcatwarTest to make more JARs
> available, right?
> >> >>>>
> >> >>>> On 2017-12-22 08:15, Sergey Beryozkin <sberyoz...@gmail.com>
> wrote:
> >> >>>>> It is annotated with CXF @Provider annotation - should be picked
> up by
> >> >>>>> the CXF CDI extension
> >> >>>>>
> >> >>>>> Sergey
> >> >>>>> On 22/12/17 13:07, John D. Ament wrote:
> >> >>>>>> I'm trying to finish up testing CDI injection of Context
> objects.  The one
> >> >>>>>> area I'm struggling with is the automatic registration of this
> feature.  I
> >> >>>>>> added a dependency on OpenTracing, just to confirm that
> injection via CDI
> >> >>>>>> works (and to be honest, this is one of my use cases, working
> with
> >> >>>>>> tracing).  However, it seems that this feature isn't
> automatically
> >> >>>>>> registered via CDI.  Is there something I have to do to make it
> work?
> >> >>>>>>
> >> >>>>>> John
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>
> >>
>
>

Re: How to update cxf.apache.org?

[John D. Ament]

Thanks, I seem to have edit now.

John

On Fri, Dec 22, 2017 at 10:27 AM Daniel Kulp <dk...@apache.org> wrote:

> At the bottom of every page is an “Edit” button that jumps over to
> confluence.Assuming you are in the asf_cla group in Confluence (which I
> just added you to), you should be able to edit.
>
> Dan
>
>
> > On Dec 22, 2017, at 10:21 AM, John D. Ament <johndam...@apache.org>
> wrote:
> >
> > I'd like to make some updates to the CXF website.
> >
> > For one, I want to add information about the MicroProfile Client API.
> I'm
> > not sure if its a dedicated page or a part of
> > http://cxf.apache.org/docs/jax-rs-client-api.html
> >
> > The second, I think http://cxf.apache.org/docs/jax-rs-client-api.html
> isn't
> > actually linked incoming from anywhere.  It may make sense to add it to
> > http://cxf.apache.org/docs/index.html
> >
> > I also want to update
> > http://cxf.apache.org/docs/using-cxf-and-cdi-11-jsr-346.html with
> > information about CDI based context injection, as well as the server
> > customization bits (JAXRSServerFactoryCustomizationExtension).
> >
> > John
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

Re: MonoReactorTest

[John D. Ament]

That's very odd.  If I increase the wait time to 1.5s it works fine.  When the 
bus is launched, does it get launched synchronously or asynchronously?  It 
seems like the delay is the amount of time it takes to deploy.

John

On 2017-12-22 10:39, Sergey Beryozkin  wrote: 
> Hi John
> 
> I've started preparing the reactor invoker to be able to handle Flux 
> which is expected to publish many items, without the service code itself 
> having to do with tying it to AsyncResponse, as I noted earlier at CXF-7535.
> One thing I've noticed, if I run, in systests/jaxrs:
> 
> mvn clean test -Dtest=MonoReactorTest
> 
> then it fails, while
> 
> mvn clean test -Dtest=FluxReactorTest
> 
> passes,
> 
> as well as both MonoReactorTest and FluxReactorTest pass when I do
> 
> mvn clean install
> 
> Minor issue, have a look please after New Year :-)
> 
> Sergey
> 
> 
> 
> 

How to update cxf.apache.org?

[John D. Ament]

I'd like to make some updates to the CXF website.

For one, I want to add information about the MicroProfile Client API.  I'm
not sure if its a dedicated page or a part of
http://cxf.apache.org/docs/jax-rs-client-api.html

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

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

John

Re: How to automatically register OpenTracingFeature?

[John D. Ament]

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

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

There's not much happening with a CXF @Provider declaration in the extension.  
But at the end of the day, I'm only dealing with a JAX-RS @Provider and that 
doesn't get registered since it's not a CDI bean.  I don't see any issue 
registering CXF @Provider this way as well, but its possible it's not a CDI 
bean still, but that's ultimately what the customizer was put in for.

John

On 2017-12-22 09:56, Sergey Beryozkin <sberyoz...@gmail.com> wrote: 
> Sure, I just don't understand what is the difference between a JAX-RS 
> feature and CXF feature, as far as the CXF CDI code is concerned. If it 
> can load the JAX-RS features which have not been written with CDI in 
> mind, why can't it load CXF features without some extra work going into 
> these features...
> 
> Thanks, Sergey
> On 22/12/17 14:50, John D. Ament wrote:
> > That's not really the issue though.  The extension will only receive CDI 
> > managed beans.  Take a look at my pull to see what I had to do to get it to 
> > register automatically.  If nothing else, this is an argument for moving 
> > JAXRSServer Customization into core and using service loader :-)  Perhaps 
> > after the new year.
> > 
> > On 2017-12-22 09:23, Sergey Beryozkin <sberyoz...@gmail.com> wrote:
> >> I was not referring the OpenTracing module offering a CDI extension, but
> >> to the work Andriy did in the CXF CDI integration where the providers
> >> and feature are picked up. Thought, when we were discussing the SSE
> >> feature I thought Andriy said it was looking at the CXF @Provider as
> >> well, may be I misunderstood.
> >> Updating the CDI code to check CXF @Provider, if it is not already
> >> checked, makes sense IMHO
> >>
> >> Sergey
> >> On 22/12/17 14:08, John D. Ament wrote:
> >>> Actually one more thing.  The CDI extension only looks for JAX-RS 
> >>> @Provider not CXF @Provider.
> >>>
> >>> On 2017-12-22 09:06, "John D. Ament"<johndam...@apache.org> wrote:
> >>>> I'm not sure what the CDI extension has to do with this.  It has no bean 
> >>>> defining annotations, and there is no beans.xml in the JAR that it ships 
> >>>> with so I'm not sure it would be picked up by the extension.
> >>>>
> >>>> There's nothing special done for TomcatwarTest to make more JARs 
> >>>> available, right?
> >>>>
> >>>> On 2017-12-22 08:15, Sergey Beryozkin <sberyoz...@gmail.com> wrote:
> >>>>> It is annotated with CXF @Provider annotation - should be picked up by
> >>>>> the CXF CDI extension
> >>>>>
> >>>>> Sergey
> >>>>> On 22/12/17 13:07, John D. Ament wrote:
> >>>>>> I'm trying to finish up testing CDI injection of Context objects.  The 
> >>>>>> one
> >>>>>> area I'm struggling with is the automatic registration of this 
> >>>>>> feature.  I
> >>>>>> added a dependency on OpenTracing, just to confirm that injection via 
> >>>>>> CDI
> >>>>>> works (and to be honest, this is one of my use cases, working with
> >>>>>> tracing).  However, it seems that this feature isn't automatically
> >>>>>> registered via CDI.  Is there something I have to do to make it work?
> >>>>>>
> >>>>>> John
> >>>>>>
> >>>>>
> >>>>
> >>
> 

Re: How to automatically register OpenTracingFeature?

[John D. Ament]

That's not really the issue though.  The extension will only receive CDI 
managed beans.  Take a look at my pull to see what I had to do to get it to 
register automatically.  If nothing else, this is an argument for moving 
JAXRSServer Customization into core and using service loader :-)  Perhaps after 
the new year.

On 2017-12-22 09:23, Sergey Beryozkin <sberyoz...@gmail.com> wrote: 
> I was not referring the OpenTracing module offering a CDI extension, but 
> to the work Andriy did in the CXF CDI integration where the providers 
> and feature are picked up. Thought, when we were discussing the SSE 
> feature I thought Andriy said it was looking at the CXF @Provider as 
> well, may be I misunderstood.
> Updating the CDI code to check CXF @Provider, if it is not already 
> checked, makes sense IMHO
> 
> Sergey
> On 22/12/17 14:08, John D. Ament wrote:
> > Actually one more thing.  The CDI extension only looks for JAX-RS @Provider 
> > not CXF @Provider.
> > 
> > On 2017-12-22 09:06, "John D. Ament"<johndam...@apache.org> wrote:
> >> I'm not sure what the CDI extension has to do with this.  It has no bean 
> >> defining annotations, and there is no beans.xml in the JAR that it ships 
> >> with so I'm not sure it would be picked up by the extension.
> >>
> >> There's nothing special done for TomcatwarTest to make more JARs 
> >> available, right?
> >>
> >> On 2017-12-22 08:15, Sergey Beryozkin <sberyoz...@gmail.com> wrote:
> >>> It is annotated with CXF @Provider annotation - should be picked up by
> >>> the CXF CDI extension
> >>>
> >>> Sergey
> >>> On 22/12/17 13:07, John D. Ament wrote:
> >>>> I'm trying to finish up testing CDI injection of Context objects.  The 
> >>>> one
> >>>> area I'm struggling with is the automatic registration of this feature.  
> >>>> I
> >>>> added a dependency on OpenTracing, just to confirm that injection via CDI
> >>>> works (and to be honest, this is one of my use cases, working with
> >>>> tracing).  However, it seems that this feature isn't automatically
> >>>> registered via CDI.  Is there something I have to do to make it work?
> >>>>
> >>>> John
> >>>>
> >>>
> >>
> 

Re: MP client test failing

[John D. Ament]

I pushed up a fix.  Andy, whenever you get a chance can you take a look and 
confirm this validation is expected as well?

On 2017-12-22 08:16, Sergey Beryozkin <sberyoz...@gmail.com> wrote: 
> Local, Java 1.8.0_144
> 
> Sergey
> On 22/12/17 13:05, John D. Ament wrote:
> > This is on your local or in jenkins?
> > 
> > This was passing at one point, but I see it failing locally right now.  
> > Will take a look.
> > 
> > John
> > 
> > On 2017-12-22 05:52, Sergey Beryozkin <sberyoz...@gmail.com> wrote:
> >> Hi John
> >>
> >> Consistently seeing:
> >>
> >> Method
> >> InvalidInterfaceTest.testExceptionThrownWhenInterfaceHasMethodWithPathParamAnnotationButNoURITemplate()[pri:0,
> >> instance:org.eclipse.microprofile.rest.client.tck.InvalidInterfaceTest@17579e0f]
> >> should have thrown an exception of type class
> >> org.eclipse.microprofile.rest.client.RestClientDefinitionException
> >>
> >> I thought it was passing yesterday though...
> >> Cheers, Sergey
> >>
> 

Re: How to automatically register OpenTracingFeature?

[John D. Ament]

What does your Application class look like, or are you using no application 
class?

On 2017-12-22 08:35, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: 
> In meecrowave im using it and it works while the jar name is not excluded
> of the scanning
> 
> Le 22 déc. 2017 14:16, "Sergey Beryozkin" <sberyoz...@gmail.com> a écrit :
> 
> > It is annotated with CXF @Provider annotation - should be picked up by the
> > CXF CDI extension
> >
> > Sergey
> > On 22/12/17 13:07, John D. Ament wrote:
> >
> >> I'm trying to finish up testing CDI injection of Context objects.  The one
> >> area I'm struggling with is the automatic registration of this feature.  I
> >> added a dependency on OpenTracing, just to confirm that injection via CDI
> >> works (and to be honest, this is one of my use cases, working with
> >> tracing).  However, it seems that this feature isn't automatically
> >> registered via CDI.  Is there something I have to do to make it work?
> >>
> >> John
> >>
> >>
> 

Re: How to automatically register OpenTracingFeature?

[John D. Ament]

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

On 2017-12-22 09:06, "John D. Ament"<johndam...@apache.org> wrote: 
> I'm not sure what the CDI extension has to do with this.  It has no bean 
> defining annotations, and there is no beans.xml in the JAR that it ships with 
> so I'm not sure it would be picked up by the extension.
> 
> There's nothing special done for TomcatwarTest to make more JARs available, 
> right?
> 
> On 2017-12-22 08:15, Sergey Beryozkin <sberyoz...@gmail.com> wrote: 
> > It is annotated with CXF @Provider annotation - should be picked up by 
> > the CXF CDI extension
> > 
> > Sergey
> > On 22/12/17 13:07, John D. Ament wrote:
> > > I'm trying to finish up testing CDI injection of Context objects.  The one
> > > area I'm struggling with is the automatic registration of this feature.  I
> > > added a dependency on OpenTracing, just to confirm that injection via CDI
> > > works (and to be honest, this is one of my use cases, working with
> > > tracing).  However, it seems that this feature isn't automatically
> > > registered via CDI.  Is there something I have to do to make it work?
> > > 
> > > John
> > > 
> > 
> 

Re: How to automatically register OpenTracingFeature?

[John D. Ament]

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

There's nothing special done for TomcatwarTest to make more JARs available, 
right?

On 2017-12-22 08:15, Sergey Beryozkin <sberyoz...@gmail.com> wrote: 
> It is annotated with CXF @Provider annotation - should be picked up by 
> the CXF CDI extension
> 
> Sergey
> On 22/12/17 13:07, John D. Ament wrote:
> > I'm trying to finish up testing CDI injection of Context objects.  The one
> > area I'm struggling with is the automatic registration of this feature.  I
> > added a dependency on OpenTracing, just to confirm that injection via CDI
> > works (and to be honest, this is one of my use cases, working with
> > tracing).  However, it seems that this feature isn't automatically
> > registered via CDI.  Is there something I have to do to make it work?
> > 
> > John
> > 
> 

How to automatically register OpenTracingFeature?

[John D. Ament]

I'm trying to finish up testing CDI injection of Context objects.  The one
area I'm struggling with is the automatic registration of this feature.  I
added a dependency on OpenTracing, just to confirm that injection via CDI
works (and to be honest, this is one of my use cases, working with
tracing).  However, it seems that this feature isn't automatically
registered via CDI.  Is there something I have to do to make it work?

John

Re: MP client test failing

[John D. Ament]

This is on your local or in jenkins?

This was passing at one point, but I see it failing locally right now.  Will 
take a look.

John

On 2017-12-22 05:52, Sergey Beryozkin  wrote: 
> Hi John
> 
> Consistently seeing:
> 
> Method 
> InvalidInterfaceTest.testExceptionThrownWhenInterfaceHasMethodWithPathParamAnnotationButNoURITemplate()[pri:0,
>  
> instance:org.eclipse.microprofile.rest.client.tck.InvalidInterfaceTest@17579e0f]
>  
> should have thrown an exception of type class 
> org.eclipse.microprofile.rest.client.RestClientDefinitionException
> 
> I thought it was passing yesterday though...
> Cheers, Sergey
> 

Re: Increase CXF PR Builder timeout?

[John D. Ament]

I spoke with Gav.  I recommended to him to first try a no activity check.
The build will time out if it was idle for 5 minutes.  If that works worse
or causes other issues we'll do an absolute again at a higher value as
mentioned.

John

On Wed, Dec 20, 2017 at 8:46 PM Andriy Redko  wrote:

> I have checked the last couple of builds (non PR ones), we are very close
> to 90 minutes mark there. I think it would be good to give the builds a bit
> of breathing by increasing the timeout to 100-120 minutes.
>
> Best Regards,
> Andriy Redko
>
> JDA> I've noticed the last couple of PRs have timed out before build
> JDA> completing.  The current build cap is at 90 minutes.  It takes 10
> minutes
> JDA> to do the initial project build in the PR job, so I'm assuming it's
> taking
> JDA> over 80 minutes for the testing phase.
>
> JDA> I believe infra has a preference to ensure that there is a timeout set
> JDA> (since the build infra is a bunch of shared resources).  I was
> thinking of
> JDA> upping the timeout to 120 minutes.  What do others think?
>
> JDA> We can also play with other build timeout settings (e.g. detecting
> stuck
> JDA> builds, no activity monitor) to see if they're better, but I'd
> probably
> JDA> need to chat with infra first so they're aware of the change (at
> least I'm
> JDA> assuming they put in this limit and not the CXF community).
>
> JDA> John
>
>

Re: Default Priority for built in providers

[John D. Ament]

Sergey,

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

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

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

John

On 2017-12-20 05:48, Sergey Beryozkin <sberyoz...@gmail.com> wrote: 
> Hi John
> On 20/12/17 02:47, John D. Ament wrote:
> > The only concrete case I can think of is when someone registers a MBR/MBW 
> > with annotation priority of 5002 and up.  In this case, the CXF provider 
> > will take precedence.  But as I understand the spec, the user
> > defined provider should always take precedence over the container created 
> > one.
> It is a bit more complex, unfortunately. The way the current 
> (spec-compliant) selection algorithm works in CXF is that the user 
> provided provider will win, but only if it is at least equal to the 
> competing built-in provider.
> 
> For example, CXF has a built-in provider typed by String for reading 
> writing strings, with the wildcard Consumes. A user registered provider 
> typed by String will always win, but a custom provider typed by Object 
> and which is meant to read/write String as well will lose to the 
> built-in provider on the basis that Object is less specific then String, 
> before the priorities or the fact it is a user provider will even be 
> considered. (The property mentioned by Romain can be used to change it)
> 
> Another case. CXF ships JSONProvider which is Jettison based. It's not 
> technically a built-in JAX-RS provider, it is optional, just happens, 
> historically, CXF will auto-load it if it is available on the classpath,
> So, if it is loaded, and Jackson is also loaded, Jackson will lose, why 
> ?, because CXF JSONProvider has more specific media types better 
> matching something like application/json. The priorities will not be 
> even taken into consideration.
> 
> Etc...
> > 
> > Take for instance the one that ships with Johnzon or Jackson.  There may be 
> > cases where those providers should be used over the ones shipped by the 
> > JAX-RS runtime.  In fact, I would argue that if a JSON-B/JSON-P impl ships 
> > a JAX-RS provider, we should use that provider over the one created by the 
> > JAX-RS runtime (but that's just my opinion).
> 
> Both CXF JSONProvider (see above - vs Jackson) and the one shipped in 
> the CXF JSONP module (vs Johnson) are optional, they are not 'built-in', 
> as far as ProviderFactory is concerned, only the providers it registers 
> at the init time, before checking the user providers, are built-in ones.
> 
> What happens if, for example, a user adds a CXF JSONP module and Johnson 
> at the same time, which MessageBodyReader/writer will be selected ? I 
> don't know, that will need to be tested, I'd assume both providers have 
> exactly the same default priority though and both will be treated as 
> custom providers.
> 
> I feel the built-in providers (namely MBRs and MBWs) should have the 
> default priority, and it is up to the custom providers to ensure they 
> are selected first (have more specific Consumes or Produces, more 
> specific type, and if it ever comes to it - the right priority value).
> 
> 
> Thanks, Sergey
> 
> > 
> > John
> > 
> > On 2017-12-19 10:17, Sergey Beryozkin <sberyoz...@gmail.com> wrote:
> >> Hi John
> >>
> >> Thinking more about it, adding some protection in the form of the max
> >> priority to the built-in MBRs and MBWs will probably not harm, but it is
> >> just difficult to see how it can practically help either, for now at least.
> >>
> >> The existing selection algo should be sufficient to ensure the
> >> absolutely equal user provider candidate prevails over the built in one.
> >>
> >> There might be some cases I'm not aware of where the allocating of the
> >> max priority values to the built-in ones can indeed help, but without
> >> identifying such cases it can be also risky, hence I'd like us to come
> >> up with such a case.
> >>
> >>

Increase CXF PR Builder timeout?

[John D. Ament]

I've noticed the last couple of PRs have timed out before build
completing.  The current build cap is at 90 minutes.  It takes 10 minutes
to do the initial project build in the PR job, so I'm assuming it's taking
over 80 minutes for the testing phase.

I believe infra has a preference to ensure that there is a timeout set
(since the build infra is a bunch of shared resources).  I was thinking of
upping the timeout to 120 minutes.  What do others think?

We can also play with other build timeout settings (e.g. detecting stuck
builds, no activity monitor) to see if they're better, but I'd probably
need to chat with infra first so they're aware of the change (at least I'm
assuming they put in this limit and not the CXF community).

John

Re: Default Priority for built in providers

[John D. Ament]

The only concrete case I can think of is when someone registers a MBR/MBW with 
annotation priority of 5002 and up.  In this case, the CXF provider will take 
precedence.  But as I understand the spec, the user 
defined provider should always take precedence over the container created one.

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

John

On 2017-12-19 10:17, Sergey Beryozkin <sberyoz...@gmail.com> wrote: 
> Hi John
> 
> Thinking more about it, adding some protection in the form of the max 
> priority to the built-in MBRs and MBWs will probably not harm, but it is 
> just difficult to see how it can practically help either, for now at least.
> 
> The existing selection algo should be sufficient to ensure the 
> absolutely equal user provider candidate prevails over the built in one.
> 
> There might be some cases I'm not aware of where the allocating of the 
> max priority values to the built-in ones can indeed help, but without 
> identifying such cases it can be also risky, hence I'd like us to come 
> up with such a case.
> 
> The extra sporting key in the form of the priority value can prob make 
> sense when 2 absolutely equal *user* providers are available, but to be 
> honest I can't even thing of the case where one would want to register 
> sat 2 MBRs with the same Consumes and the same Type but with different 
> priorities, it does not make much sense, the priority can help with 
> ordering the filters/interceptors, but in case of MBR/MBW where the 
> action affecting the streams is expected it is just to imagine...
> 
> Thanks, Sergey
> On 19/12/17 12:08, Sergey Beryozkin wrote:
> > I'd like to avoid starting introducing the fixes against the problems
> > which might *not* be the actual problems, as far as the selection of 
> > MBRs and
> > MBWs in the spec compliant manner is concerned
> > ...
> > 
> > On 19/12/17 12:07, Sergey Beryozkin wrote:
> >> Lets talk about some specific case. The only built in providers CXF 
> >> has are Message Body Reader and Writers. Well, there's a default 
> >> excpetion mapper there as well, but lets deal with it later.
> >>
> >> So, giving these built-in MBRs and MBWs, lets have a look at a 
> >> specific case where you think having some high priority will matter, 
> >> example, describe some case where a user provider (with some type) is 
> >> registered and the current implementation is not sufficient to get 
> >> this user provider selected.
> >>
> >> I'd like to avoid starting introducing the fixes against the problems 
> >> which might be the actual problems, as far as the selection of MBRs 
> >> and MBWs in the spec compliant manner is concerned
> >>
> >> Thanks, Sergey
> >> On 19/12/17 11:59, John D. Ament wrote:
> >>> So I figured out most of the issue.  The problem was impacting all of 
> >>> the providers.
> >>>
> >>> Here's basically what happened:
> >>>
> >>> - The type of comparator you pass into setProviderComparator is 
> >>> unbounded, it takes any object.  But its only meant to sort 
> >>> ProviderInfo impls.
> >>> - There's a missing relationship between provider info and the 
> >>> contracts registered in JAX-RS.  To fix that in a typesafe client I 
> >>> added a new comparator that uses the contracts.  However I 
> >>> implemented it against the unbounded comparator you pass in.
> >>> - At one point, I was using this to directly sort the MicroProfile 
> >>> ResponseExceptionMapper impls as well, which have their own priority 
> >>> method.
> >>>
> >>> So bottom line, I was able to get the sorting working properly, at 
> >>> least based on my understanding of the spec.  I do think it would be 
> >>> beneficial to set the built in providers with a very high priority 
> >>> and avoid configurations using the custom flag, since a user may want 
> >>> to register the built in providers with a different priority; 
> >>> presently that is blocked.
> >>>
> >>> On 2017-12-18 04:38, Sergey Beryozkin <sberyoz...@gmail.com> wrote:
> >>>> Which default providers are you referring to ?
> >>>> If it is MBR or MBW then their priority is implicit, based on the spec
> >&

Re: Default Priority for built in providers

[John D. Ament]

So I figured out most of the issue.  The problem was impacting all of the 
providers.

Here's basically what happened:

- The type of comparator you pass into setProviderComparator is unbounded, it 
takes any object.  But its only meant to sort ProviderInfo impls.
- There's a missing relationship between provider info and the contracts 
registered in JAX-RS.  To fix that in a typesafe client I added a new 
comparator that uses the contracts.  However I implemented it against the 
unbounded comparator you pass in.
- At one point, I was using this to directly sort the MicroProfile 
ResponseExceptionMapper impls as well, which have their own priority method.

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

On 2017-12-18 04:38, Sergey Beryozkin <sberyoz...@gmail.com> wrote: 
> Which default providers are you referring to ?
> If it is MBR or MBW then their priority is implicit, based on the spec 
> text re how to sort media types, etc.
> 
> Sergey
> On 17/12/17 14:42, John D. Ament wrote:
> > FWIW, I had assumed I was doing something wrong.  However, I'm just 
> > delegating down to ClientProviderFactory.setProviders, which does pass in 
> > custom as false for the built in providers (look at ProviderFactory#L142).
> > 
> > I'm inclined to align with Romain's thinking, we should just set a high 
> > priority on the built in providers, to avoid any conflicts.  I already did 
> > this to register the Json P provider.  This would more easily allow 
> > consuming frameworks to add their own providers of slightly higher 
> > priorities.
> > 
> > John
> > 
> > On 2017-12-16 21:06, Andy McCright <j.andrew.mccri...@gmail.com> wrote:
> >> True - we would also need to add default priority to the user-specified
> >> providers (‘Priorities.USER’).
> >>
> >> On Sat, Dec 16, 2017 at 2:08 PM Romain Manni-Bucau <rmannibu...@gmail.com>
> >> wrote:
> >>
> >>> Le 16 déc. 2017 20:28, "Andy McCright" <j.andrew.mccri...@gmail.com> a
> >>> écrit :
> >>>
> >>> I don’t have the code in front of me, but I remember that for 
> >>> JAX-RS
> >>> providers there was a check for a “user”/“custom” 
> >>> boolean - the built-in
> >>> providers are false, user providers (regardless of priority) are true.
> >>> That boolean is checked before the ‘@Priority’ annotation.
> >>>
> >>> With the new emphasis on using ‘@Priority’ in the JAX-RS 2.1 
> >>> spec, we could
> >>> probably simplify the code (and possibly speed up the sorting logic) if we
> >>> got rid of the special booleans and set 
> >>> ‘@Priority(Integer.MAX_VALUE)’ for
> >>> all built-in providers.
> >>>
> >>>
> >>> This is not forbidden by the spec so we still need a flag to let the user
> >>> overriding cxf defaults, no? (Unlikely doesnt mean never, libs will have
> >>> the same idea i guess, in particular for generic providers)
> >>>
> >>>
> >>> On Sat, Dec 16, 2017 at 12:55 PM John D. Ament <johndam...@apache.org>
> >>> wrote:
> >>>
> >>>> The JAX-RS spec mandates a certain number of providers by default.  I'm
> >>>> noticing that when these providers are added, they're added without any
> >>>> priority.  Andy mentioned to me that they should be added with the
> >>> priority
> >>>> of USER + 1, but the actual resolved priority I'm seeing is USER.
> >>>>
> >>>> Granted, this is within the proxy client code base.  Is this problem
> >>> going
> >>>> to exist as well in the regular clients?  As well as server?
> >>>>
> >>>> If so, should we annotate them with USER + 1 to avoid the issue?
> >>>>
> >>>> John
> >>>>
> >>>
> >>
> 
> 
> -- 
> Sergey Beryozkin
> 
> Talend Community Coders
> http://coders.talend.com/
> 

Re: Default Priority for built in providers

[John D. Ament]

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

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

John

On 2017-12-17 14:46, Andy McCright <j.andrew.mccri...@gmail.com> wrote: 
> John,
> 
> There is also a setUserProviders(...) method (possibly in the base
> ProviderFactory class) - that method should set the custom boolean to true
> in the ProviderInfo object and should sort them ahead of the built-in
> providers.
> 
> Even so, I like the idea of setting a MAX_INT priority on the built-in
> providers - that would definitely prevent them from being selected over
> user-specified providers.
> 
> Thanks,
> 
> Andy
> 
> On Sun, Dec 17, 2017 at 8:42 AM John D. Ament <johndam...@apache.org> wrote:
> 
> > FWIW, I had assumed I was doing something wrong.  However, I'm just
> > delegating down to ClientProviderFactory.setProviders, which does pass in
> > custom as false for the built in providers (look at ProviderFactory#L142).
> >
> > I'm inclined to align with Romain's thinking, we should just set a high
> > priority on the built in providers, to avoid any conflicts.  I already did
> > this to register the Json P provider.  This would more easily allow
> > consuming frameworks to add their own providers of slightly higher
> > priorities.
> >
> > John
> >
> > On 2017-12-16 21:06, Andy McCright <j.andrew.mccri...@gmail.com> wrote:
> > > True - we would also need to add default priority to the user-specified
> > > providers (‘Priorities.USER’).
> > >
> > > On Sat, Dec 16, 2017 at 2:08 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > Le 16 déc. 2017 20:28, "Andy McCright" <j.andrew.mccri...@gmail.com> a
> > > > écrit :
> > > >
> > > > I don’t have the code in front of me, but I remember that for JAX-RS
> > > > providers there was a check for a “user”/“custom” boolean - the
> > built-in
> > > > providers are false, user providers (regardless of priority) are true.
> > > > That boolean is checked before the ‘@Priority’ annotation.
> > > >
> > > > With the new emphasis on using ‘@Priority’ in the JAX-RS 2.1 spec, 
> > > > we
> > could
> > > > probably simplify the code (and possibly speed up the sorting logic)
> > if we
> > > > got rid of the special booleans and set 
> > > > ‘@Priority(Integer.MAX_VALUE)’
> > for
> > > > all built-in providers.
> > > >
> > > >
> > > > This is not forbidden by the spec so we still need a flag to let the
> > user
> > > > overriding cxf defaults, no? (Unlikely doesnt mean never, libs will
> > have
> > > > the same idea i guess, in particular for generic providers)
> > > >
> > > >
> > > > On Sat, Dec 16, 2017 at 12:55 PM John D. Ament <johndam...@apache.org>
> > > > wrote:
> > > >
> > > > > The JAX-RS spec mandates a certain number of providers by default.
> > I'm
> > > > > noticing that when these providers are added, they're added without
> > any
> > > > > priority.  Andy mentioned to me that they should be added with the
> > > > priority
> > > > > of USER + 1, but the actual resolved priority I'm seeing is USER.
> > > > >
> > > > > Granted, this is within the proxy client code base.  Is this problem
> > > > going
> > > > > to exist as well in the regular clients?  As well as server?
> > > > >
> > > > > If so, should we annotate them with USER + 1 to avoid the issue?
> > > > >
> > > > > John
> > > > >
> > > >
> > >
> >
> 

Re: Default Priority for built in providers

[John D. Ament]

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

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

John

On 2017-12-16 21:06, Andy McCright <j.andrew.mccri...@gmail.com> wrote: 
> True - we would also need to add default priority to the user-specified
> providers (‘Priorities.USER’).
> 
> On Sat, Dec 16, 2017 at 2:08 PM Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
> 
> > Le 16 déc. 2017 20:28, "Andy McCright" <j.andrew.mccri...@gmail.com> a
> > écrit :
> >
> > I don’t have the code in front of me, but I remember that for JAX-RS
> > providers there was a check for a “user”/“custom” boolean - the 
> > built-in
> > providers are false, user providers (regardless of priority) are true.
> > That boolean is checked before the ‘@Priority’ annotation.
> >
> > With the new emphasis on using ‘@Priority’ in the JAX-RS 2.1 spec, we 
> > could
> > probably simplify the code (and possibly speed up the sorting logic) if we
> > got rid of the special booleans and set ‘@Priority(Integer.MAX_VALUE)’ 
> > for
> > all built-in providers.
> >
> >
> > This is not forbidden by the spec so we still need a flag to let the user
> > overriding cxf defaults, no? (Unlikely doesnt mean never, libs will have
> > the same idea i guess, in particular for generic providers)
> >
> >
> > On Sat, Dec 16, 2017 at 12:55 PM John D. Ament <johndam...@apache.org>
> > wrote:
> >
> > > The JAX-RS spec mandates a certain number of providers by default.  I'm
> > > noticing that when these providers are added, they're added without any
> > > priority.  Andy mentioned to me that they should be added with the
> > priority
> > > of USER + 1, but the actual resolved priority I'm seeing is USER.
> > >
> > > Granted, this is within the proxy client code base.  Is this problem
> > going
> > > to exist as well in the regular clients?  As well as server?
> > >
> > > If so, should we annotate them with USER + 1 to avoid the issue?
> > >
> > > John
> > >
> >
> 

Default Priority for built in providers

[John D. Ament]

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

Granted, this is within the proxy client code base.  Is this problem going
to exist as well in the regular clients?  As well as server?

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

John

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

[John D. Ament]

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

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

John

On Sun, Dec 3, 2017 at 5:40 PM Andriy Redko  wrote:

> Hey John,
>
> That would be an interesting feature, useful even beyond just Microprofile
> actually (imho) :)
> Should we have a dedicated module for it instead of using the client one?
> We would
> have the dependency to Microprofile REST Client SPI/API there, may be it
> is better
> not to introduce it into the existing client module (even as an optional)?
>
> Best Regards,
> Andriy Redko
>
> JDA> Hey all
>
> JDA> Andy (McCright) and I (as well as some others who don't contribute to
> CXF)
> JDA> have been working on another project, specifically around
> standardizing how
> JDA> Type Safe rest clients can be built within MIcroProfile.  There's two
> main
> JDA> aspects to this, as well as some changes potentially required for a
> JDA> presently CXF specific provider.
>
> JDA> - Programmatic builder API for creating the clients from a JAX-RS
> annotated
> JDA> interface
> JDA> - CDI injection support for interfaces
>
> JDA> I have most of an implementation for this working, and would like to
> start
> JDA> to bring it into the CXF codebase.  My thought is to bring most of it
> JDA> directly into the client module, and update some of the core logic
> there to
> JDA> work with MicroProfile's APIs.  There are some functional differences
> JDA> though.  One of the things we felt was important was mapping Response
> codes
> JDA> into Exceptions, something that CXF already had support for.  The
> behavior
> JDA> is a little different in that we will evaluate multiple mappers as
> well as
> JDA> handle any response code.
>
> JDA> You can read more about the API and specification at
> JDA> https://github.com/eclipse/microprofile-rest-client
> JDA> You can also see the base impl I've started on at
> JDA> https://github.com/johnament/cxfmprestclient
>
>
> JDA> John
>
>

Implementing MicroProfile's Rest Client here at CXF?

[John D. Ament]

Hey all

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

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

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

You can read more about the API and specification at
https://github.com/eclipse/microprofile-rest-client
You can also see the base impl I've started on at
https://github.com/johnament/cxfmprestclient


John

Re: Rethinking how JAX-RS customizations are looked up in CDI

[John D. Ament]

Andriy,

Well, I think the difference here is that server customizations are not CDI 
specific.  It looks like they were put there, but I can think of other use 
cases where an externally managed JAXRSServerFactoryBean is externally managed, 
and being able to invoke a series of callbacks to further tweak that server 
would be very useful.

It's just a thought, since I was playing around with how to automate SSE 
integration when someone else creates the factory, without using CDI; e.g. 
other cases of CXFNonSpringJaxrsServlet.

John

On 2017-11-27 21:40, Andriy Redko  wrote: 
> Hey John,
> 
> I think this would be a better alternative, we could use the same mechanism
> as for external providers (using ServiceLoader, as also you suggested). I am
> not sure what is the best option, it looks somewhat nature to use CDI 
> capabilities
> to fullfil CDI-specific cases, but practically speaking, ServiceLoader would 
> be
> enough in this case.
> 
> Thanks.
> 
> Best Regards,
> Andriy Redko
> 
> JDA> I was wondering, does it really make sense
> JDA> for JAXRSServerFactoryCustomizationExtension implementations to be CDI
> JDA> beans?  It may sound odd, but typically in CDI that kind of feature is 
> done
> JDA> as a service loader pattern.  These are classes that should only be used
> JDA> once, so keeping them in memory is a bit of a waste.  I think recently we
> JDA> saw some issues with SSE integration, where we had to make the archive a
> JDA> full bean archive (bean-discovery-mode=all) just to ensure that this bean
> JDA> was looked up.  It may make more sense if these are ServiceLoader based
> JDA> classes, this way we just have to register it in META-INF/services 
> without
> JDA> adding any CDI specific features to the JAR.
> 
> JDA> At the same time, I also wonder if this causes an issue for Java 9
> JDA> modules.  Does the dependency have to always be there, or can it be an
> JDA> optional dependency (my module foo is weak, so I have no idea if that's
> JDA> even feasible).
> 
> JDA> John
> 
> 

Rethinking how JAX-RS customizations are looked up in CDI

[John D. Ament]

I was wondering, does it really make sense
for JAXRSServerFactoryCustomizationExtension implementations to be CDI
beans?  It may sound odd, but typically in CDI that kind of feature is done
as a service loader pattern.  These are classes that should only be used
once, so keeping them in memory is a bit of a waste.  I think recently we
saw some issues with SSE integration, where we had to make the archive a
full bean archive (bean-discovery-mode=all) just to ensure that this bean
was looked up.  It may make more sense if these are ServiceLoader based
classes, this way we just have to register it in META-INF/services without
adding any CDI specific features to the JAR.

At the same time, I also wonder if this causes an issue for Java 9
modules.  Does the dependency have to always be there, or can it be an
optional dependency (my module foo is weak, so I have no idea if that's
even feasible).

John

ResourceContext and CDI

[John D. Ament]

Hi,

I'm wondering, should ResourceContextImpl be updated to support Class
Unwrapping, specifically the CdiClassUnwrapper in case the bean passed in
is a CDI bean (see specifically the initResource method).

John

Re: Remove obsolete RxJava code and keep RxJava2 only one

[John D. Ament]

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

On Wed, Nov 15, 2017 at 10:56 AM Sergey Beryozkin 
wrote:

> Hi
>
> cxf-rt-rs-extension-rx ships the code for both (old) RxJava and RxJava2
> code. It supports returning RxJava2 Flowable and Observable on the
> server and accepting it on the client, and the same for the (old) RxJava
> Observable...
>
> While even the (old) RxJava code is very new for CXF, the reality is
> that RxJava has been around for a while now and with RxJava2 embracing
> org.reactivestreams, it's hard to see CXF users preferring to start with
> the (old) RxJava.
>
> The other minor problem is that cxf-rt-rs-extension-rx has optional
> RxJava and RxJava2 deps to be able to ship the relevant code in the same
> module and splitting it into 2 modules will be too much at this point.
>
> I suggest that unless some users confirm (I CC to the users) that they
> need to use the (old) RxJava code, then we just remove it and make
> things much simpler...
>
> Thanks, Sergey
>

JIRA Karma?

[John D. Ament]

Hi,

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

John

Re: JAX-RS Features not used for ClientProxies

[John D. Ament]

Done, submitted https://issues.apache.org/jira/browse/CXF-7543

On 2017-10-29 10:16, Andriy Redko  wrote: 
> One of the long standing ones :-), I think we should make both equally 
> supported. John, could you please create a JIRA for this issue?
> 
> JDA> Hey guys
> 
> JDA> Earlier today I was looking at an issue noted where proxies created for 
> CXF
> JDA> weren't leveraging JAX-RS Features registered as providers.
> 
> JDA> After digging into it further, I noticed that it was likely also true 
> that
> JDA> they're not supported for WebClient.  It seems like the key piece missing
> JDA> is that all of the support is within ConfigurationImpl, but these two
> JDA> stacks are using JAXRSClientFactoryBean as the underlying configuration.
> 
> JDA> So I'm wondering, what makes more sense? Porting a Configuration object 
> to
> JDA> be used within the proxy builder, or porting support for features 
> directly
> JDA> into JAXRSClientFactoryBean.  It does seem like there's a strong divide,
> JDA> ConfigurationImpl classes are using JAX-RS Features,
> JDA> but JAXRSClientFactoryBean classes are using the CXF native Features.
> 
> JDA> John
> 
> 

JAX-RS Features not used for ClientProxies

[John D. Ament]

Hey guys

Earlier today I was looking at an issue noted where proxies created for CXF
weren't leveraging JAX-RS Features registered as providers.

After digging into it further, I noticed that it was likely also true that
they're not supported for WebClient.  It seems like the key piece missing
is that all of the support is within ConfigurationImpl, but these two
stacks are using JAXRSClientFactoryBean as the underlying configuration.

So I'm wondering, what makes more sense? Porting a Configuration object to
be used within the proxy builder, or porting support for features directly
into JAXRSClientFactoryBean.  It does seem like there's a strong divide,
ConfigurationImpl classes are using JAX-RS Features,
but JAXRSClientFactoryBean classes are using the CXF native Features.

John

Re: [VOTE] Apache CXF 3.2.0

[John D. Ament]

+1 ship it!

Just wondering, have docs been updated to point to the new coordinates for the 
new features (e.g. SSE)?

On 2017-09-06 14:14, Daniel Kulp  wrote: 
> It’s been 2 years since the last major CXF release.We have well over 
> 100 JIRA’s of new features and enhancements that are only targeted toward 
> 3.2.   Let’s get it out!
> 
> 
> Staging repo:
> https://repository.apache.org/content/repositories/orgapachecxf-1102/
> 
> Tag:
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=79c1486ed9cf34d90a04d943ed72475500f83c48
> 
> Here is my +1
> 
> 
> -- 
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
> 
> 

Re: [DISCUSS] CDI Beans & BeanManager.getReference

[John D. Ament]

On Mon, Dec 12, 2016 at 3:26 AM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> 2016-12-12 9:13 GMT+01:00 Mark Struberg <strub...@yahoo.de.invalid>:
>
> >
> > > Am 11.12.2016 um 22:24 schrieb John D. Ament <johndam...@apache.org>:
> > >
> > > However, using bean.getBeanClass() is more correct.
> >
> > Nope, read the spec paragraph for producer methods and fields:
> >
> > 11.1. The Bean interface
> > "• getBeanClass() returns the bean class of the managed bean or session
> > bean or of the bean that declares the producer method or field."
> >
> > So for a producer method or field getBeanClass() will NOT give you the
> > type of the produced contextual instance but the class which _contains_
> the
> > producer!
> > Means relying on getBeanClass() to produce the proxy is plain wrong and
> > Weld should not do that (IF they do, did not verify that)!
> >
> >
> Yep + "managed bean" doesn't mean "implementation" so Bus is very valid.
>
>
Hmm you're right.  If anything types should be leveraged now that I'm
thinking about it more.  I've withdrawn my PR for now, but I'll point out
that this means this entire block
https://github.com/apache/cxf/blob/3.1.x-fixes/integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java#L292,L325
has
the potential to be an issue.  Since JAX-RS requires annotations on the
class, I guess its OK then.

Either way Martin's explained why weld's generating the wrong proxy, or at
least a theory why (bad groovy filtering) it still doesn't explain why the
right proxy gets generated when using ExtensionManagerBus instead.


>
> > LieGrue,
> > strub
>

Re: [DISCUSS] CDI Beans & BeanManager.getReference

[John D. Ament]

On Sun, Dec 11, 2016 at 5:38 PM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Le 11 déc. 2016 22:24, "John D. Ament" <johndam...@apache.org> a écrit :
>
> Romain,
>
> On Sun, Dec 11, 2016 at 4:08 PM Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
> > Le 11 déc. 2016 21:30, "John D. Ament" <johndam...@apache.org> a écrit :
> >
> > All,
> >
> > So Romain had a good point, let's not pollute the vote thread with this
> > issue.  I raised a problem with the current release, its related to an
> > issue that's existed in the CDI integration for some time, but was made
> > worse by a recent change in CXF for the 3.1.9 release.
> >
> > In old versions of CXF (e.g. 3.1.8 and prior, into the 3.0 line), the
> > following logic was used to look up references to the bus in the
> > AfterDeploymentValidation stage.
> >
> > bus = (Bus)beanManager.getReference(
> > busBean,
> > busBean.getBeanClass(),
> > beanManager.createCreationalContext(busBean)
> > );
> >
> >
> > R: sounds wrong since beanclass doesnt have to be in types (think @Typed)
> > and therefore proxyable (beanclass has no runtime role normally).
> >
> >
> Agreed and disagreed here.
>
> I agree that bean class doesn't have to be in types, specifically for the
> reason you're bringing up - @Typed.  In addition, you may get back an
> instance created not by the bean instance you're working with, so makes
> sense.
>
> However, using bean.getBeanClass() is more correct.  It has to do with the
> typesafe nature and makes sure you're getting back the type you're
> expecting (for that bean).  Its also more consistent, since we're using the
> bean class everywhere else in the class to do look ups.  Its at least what
> I've always seen it be useful for.
>
>
> Not for a producer and not being a type in types beanclass is not supposed
> handled by cdi so this is really an incorrect usage i think - unspecified
> if not incorrect.
>
>
I don't follow.  This is what the spec says

The second parameter represents a bean type that must be implemented by any
client proxy that is returned.

The only bean type that you know must be implemented by the bean is the
value of Bean.getBeanClass or the return values of getTypes.  Since this is
a client proxy, the passed in type is what gets used as the proxy interface.


>
>
>
> >
> > This fixed an issue in the CdiBusBean that went over looked (even myself
> > missed it when working on that class) where its bean class was always
> > Bus.class (
> > https://github.com/apache/cxf/blob/3.1.x-fixes/integration/
> > cdi/src/main/java/org/apache/cxf/cdi/CdiBusBean.java#L43
> > ).
> > Now you might be wondering why this fixed it.  Since busBean was located
> at
> > runtime, if you overrode the bean, by creating your own producer or
> > implementation, then this issue went away.  The issue being that in Weld,
> > when you use getReference(bean, SomeInterface.class, creationalContext)
> > you're getting a proxy to the interface, which for some reason includes
> > abstract methods.  In the proposed 3.1.9 release, since Bus.class is now
> > hard coded in the extension it causes the proxy to always be based on the
> > interface, regardless of the bean's class.
> >
> > I do suspect there is an underlying Weld issue.  Even if you pass in an
> > interface, you should get an exception when locating the bean and not an
> > invalid proxy implementation (or even better, do what OWB does and give
> you
> > back a valid reference).
> >
> >
> > R: Can you check thus before changing CXF which looks ok. If weld is
> biggy
> > and get fixed the custom bean workaround sounds ok short term.
> >
>
> I filed a ticket against them, will wait to see responses from Martin or
> Tomas, but realistically this means CXF is only compatible with some
> versions of weld (e.g. newer versions).  Fixing this in CXF makes CXF more
> compatible with a broader range of versions.  Basically 3.1.8 works with
> weld 2.3+ from what I can tell (I didn't bother with older versions), 3.1.9
> doesn't, but may work with a 2.4.2 version.
>
>
>
> >
> >
> > Wdyt?
> >
> >
> >
> > The fix, to bring most compatibility back to CXF, I raised a PR that does
> > the following:
> >
> > - Makes CdiBusBean return the right class.  This is for the default case
> > where a user doesn't provide an implementation of Bus at runtime via a
> > producer or direct inheritance.
> > - Makes the extension use the located bean's getBeanClass() method to
> > determine the type of reference to expect.
> > - The ugly part - removed the "final" keyword from a number of methods in
> > ExtensionManagerBus.  In order for it to be a valid CDI bean, you can't
> use
> > final methods.
> >
> > There's another way I can think to fix this, outside of waiting on a new
> > weld release.  Instead of the bean being application scoped, it can be
> > dependent or singleton, which would remove the proxy requirement.
> >
> > Thoughts?
> >
> > John
> >
>

Re: [DISCUSS] CDI Beans & BeanManager.getReference

[John D. Ament]

Romain,

On Sun, Dec 11, 2016 at 4:08 PM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Le 11 déc. 2016 21:30, "John D. Ament" <johndam...@apache.org> a écrit :
>
> All,
>
> So Romain had a good point, let's not pollute the vote thread with this
> issue.  I raised a problem with the current release, its related to an
> issue that's existed in the CDI integration for some time, but was made
> worse by a recent change in CXF for the 3.1.9 release.
>
> In old versions of CXF (e.g. 3.1.8 and prior, into the 3.0 line), the
> following logic was used to look up references to the bus in the
> AfterDeploymentValidation stage.
>
> bus = (Bus)beanManager.getReference(
> busBean,
> busBean.getBeanClass(),
> beanManager.createCreationalContext(busBean)
> );
>
>
> R: sounds wrong since beanclass doesnt have to be in types (think @Typed)
> and therefore proxyable (beanclass has no runtime role normally).
>
>
Agreed and disagreed here.

I agree that bean class doesn't have to be in types, specifically for the
reason you're bringing up - @Typed.  In addition, you may get back an
instance created not by the bean instance you're working with, so makes
sense.

However, using bean.getBeanClass() is more correct.  It has to do with the
typesafe nature and makes sure you're getting back the type you're
expecting (for that bean).  Its also more consistent, since we're using the
bean class everywhere else in the class to do look ups.  Its at least what
I've always seen it be useful for.


>
> This fixed an issue in the CdiBusBean that went over looked (even myself
> missed it when working on that class) where its bean class was always
> Bus.class (
> https://github.com/apache/cxf/blob/3.1.x-fixes/integration/
> cdi/src/main/java/org/apache/cxf/cdi/CdiBusBean.java#L43
> ).
> Now you might be wondering why this fixed it.  Since busBean was located at
> runtime, if you overrode the bean, by creating your own producer or
> implementation, then this issue went away.  The issue being that in Weld,
> when you use getReference(bean, SomeInterface.class, creationalContext)
> you're getting a proxy to the interface, which for some reason includes
> abstract methods.  In the proposed 3.1.9 release, since Bus.class is now
> hard coded in the extension it causes the proxy to always be based on the
> interface, regardless of the bean's class.
>
> I do suspect there is an underlying Weld issue.  Even if you pass in an
> interface, you should get an exception when locating the bean and not an
> invalid proxy implementation (or even better, do what OWB does and give you
> back a valid reference).
>
>
> R: Can you check thus before changing CXF which looks ok. If weld is biggy
> and get fixed the custom bean workaround sounds ok short term.
>

I filed a ticket against them, will wait to see responses from Martin or
Tomas, but realistically this means CXF is only compatible with some
versions of weld (e.g. newer versions).  Fixing this in CXF makes CXF more
compatible with a broader range of versions.  Basically 3.1.8 works with
weld 2.3+ from what I can tell (I didn't bother with older versions), 3.1.9
doesn't, but may work with a 2.4.2 version.



>
>
> Wdyt?
>
>
>
> The fix, to bring most compatibility back to CXF, I raised a PR that does
> the following:
>
> - Makes CdiBusBean return the right class.  This is for the default case
> where a user doesn't provide an implementation of Bus at runtime via a
> producer or direct inheritance.
> - Makes the extension use the located bean's getBeanClass() method to
> determine the type of reference to expect.
> - The ugly part - removed the "final" keyword from a number of methods in
> ExtensionManagerBus.  In order for it to be a valid CDI bean, you can't use
> final methods.
>
> There's another way I can think to fix this, outside of waiting on a new
> weld release.  Instead of the bean being application scoped, it can be
> dependent or singleton, which would remove the proxy requirement.
>
> Thoughts?
>
> John
>

Re: [VOTE] CXF 3.1.9 and 3.0.12

[John D. Ament]

On Sun, Dec 11, 2016 at 11:06 AM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Le 11 déc. 2016 17:03, "Jeff Genender" <jgenen...@apache.org> a écrit :
>
> You -0’d a release because the pull request that you submitted at 12/11/16
> 15:30 GMT didn’t make it into a release whose vote was kicked off nearly 42
> hours before at 12/9/16 21:47 GMT?
>
> In particukar since it is a bug in weld not cxf as Mark pointed out.
>

Nope.  Take a look at the changes Romain, CXF's usage is against what the
spec says it should be doing.


>
>
> Seriously?
>
> Jeff
>
>
>
> > On Dec 11, 2016, at 7:16 AM, John D. Ament <johndam...@apache.org>
> wrote:
> >
> > I did find one issue.  Its not a new issue, but the CDI integration
> changes
> > made the problem more profound when using CXF + Weld in an Arquillian
> test.
> >
> > https://issues.apache.org/jira/browse/CXF-7175
> >
> > So -0 since I won't be able to upgrade yet.
> >
> > On Fri, Dec 9, 2016 at 3:47 PM Daniel Kulp <dk...@apache.org> wrote:
> >
> >> Since there are several folks waiting for this release and it would be
> >> good to get it out before the holidays, I’d like to call a vote for CXF
> >> 3.1.9 and 3.0.12.
> >>
> >> Staging areas:
> >> 3.1.9:
> >> https://repository.apache.org/content/repositories/orgapachecxf-1083/
> >> 3.0.12:
> >> https://repository.apache.org/content/repositories/orgapachecxf-1082/
> >>
> >> Tags:
> >> 3.0.12:
> >>
> >> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=commit;h=
> c98cb3181ae1153c37240a851aefe8e4f3a40ae9
> >> 3.1.9:
> >>
> >> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=commit;h=
> 7cd4d49a7fe7d24a715192112a2170bdd708e6c7
> >>
> >>
> >> Vote will be open for 72h.
> >>
> >> Here is my +1.
> >>
> >> --
> >> Daniel Kulp
> >> dk...@apache.org - http://dankulp.com/blog
> >> Talend Community Coder - http://coders.talend.com
> >>
> >>
>

Re: [VOTE] CXF 3.1.9 and 3.0.12

[John D. Ament]

I did find one issue.  Its not a new issue, but the CDI integration changes
made the problem more profound when using CXF + Weld in an Arquillian test.

https://issues.apache.org/jira/browse/CXF-7175

So -0 since I won't be able to upgrade yet.

On Fri, Dec 9, 2016 at 3:47 PM Daniel Kulp  wrote:

> Since there are several folks waiting for this release and it would be
> good to get it out before the holidays, I’d like to call a vote for CXF
> 3.1.9 and 3.0.12.
>
> Staging areas:
> 3.1.9:
> https://repository.apache.org/content/repositories/orgapachecxf-1083/
> 3.0.12:
> https://repository.apache.org/content/repositories/orgapachecxf-1082/
>
> Tags:
> 3.0.12:
>
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=commit;h=c98cb3181ae1153c37240a851aefe8e4f3a40ae9
> 3.1.9:
>
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=commit;h=7cd4d49a7fe7d24a715192112a2170bdd708e6c7
>
>
> Vote will be open for 72h.
>
> Here is my +1.
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

Re: Becoming a committer?

[John D. Ament]

So, you're thinking its normal for a project to add a committer once per
year?  Looking at the archives, last new committer was added almost 1 year
ago (just shy of two weeks).

On Fri, Nov 18, 2016 at 10:05 AM Sergey Beryozkin 
wrote:

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

Re: is a release early december possible?

[John D. Ament]

Ok, I think the issue's fixed.  Raised PR
https://github.com/apache/cxf/pull/195 to address the issue.

Problem - when a normal scoped CDI bean was being created, it was using the
proxy class as a key instead of the root class.  This was causing the
original PerRequest provider to be invoked instead of the CDI backed
instance since CXF is getting the class from the real class's class.  I
changed the extension to load the original class name for the CDI proxy
instead.

There's one good thing (sort of) that I'm seeing now.  Previously,
dependent scoped beans were getting reused in CXF.  Now, they're acting as
new instances each time.  This is why I changed the scope of
BookStoreService.

John

On Mon, Nov 14, 2016 at 9:30 PM John D. Ament <johndam...@apache.org> wrote:

> Andriy,
>
> Agreed.  It looks like it has to do with the use of getClasses where the
> classes include normal scoped beans.  We can have a more permanent test by
> splitting up BookStore into two services.  It looks like the classes are
> getting instantiated instead of using CDI managed instances.
>
> John
>
>
> On Mon, Nov 14, 2016 at 9:17 PM Andriy Redko <drr...@gmail.com> wrote:
>
> Hey John,
>
> I think the test cases worked due to the presence of multiple resource
> class
> instances (there was a warning in the log). This has been fixed and it
> seems
> like there is a regression. Please let me know if you need any help with
> the
> fix, we should also have a test case for that.
> Thanks a lot.
>
> Best Regards,
> Andriy Redko
>
> JDA> Ok, something's broken right now in 3.1.x :-) (it's an ironic smiley)
>
> JDA> I'm working on a fix.  To replicate the issue, add @RequestScoped to
> JDA> org.apache.cxf.systests.cdi.base.BookStore.  Both multi-app test
> suites
> JDA> fail.
>
> JDA> John
>
> JDA> On Mon, Nov 14, 2016 at 12:47 PM Daniel Kulp <dk...@apache.org>
> wrote:
>
>
> >> > On Nov 14, 2016, at 8:20 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> >> wrote:
> >> >
> >> > does a 3.1.9 release sound feasible for beginning of december? idea
> here
> >> is
> >> > to upgrade meecrowave (in progress subproject of openwebbeans
> depending
> >> on
> >> > the snapshot) to release before Xmas holidays time.
>
> >> That’s normally the time I’d like to see a release anyway.   I don’t
> like
> >> doing one in late December due to the Holidays so not doing one in early
> >> December would mean a wait all the way into January.   Thus, +1 to an
> early
> >> December release.  :)
>
>
> >> --
> >> Daniel Kulp
> >> dk...@apache.org - http://dankulp.com/blog
> >> Talend Community Coder - http://coders.talend.com
>
>
>
>

Re: is a release early december possible?

[John D. Ament]

Andriy,

Agreed.  It looks like it has to do with the use of getClasses where the
classes include normal scoped beans.  We can have a more permanent test by
splitting up BookStore into two services.  It looks like the classes are
getting instantiated instead of using CDI managed instances.

John

On Mon, Nov 14, 2016 at 9:17 PM Andriy Redko  wrote:

> Hey John,
>
> I think the test cases worked due to the presence of multiple resource
> class
> instances (there was a warning in the log). This has been fixed and it
> seems
> like there is a regression. Please let me know if you need any help with
> the
> fix, we should also have a test case for that.
> Thanks a lot.
>
> Best Regards,
> Andriy Redko
>
> JDA> Ok, something's broken right now in 3.1.x :-) (it's an ironic smiley)
>
> JDA> I'm working on a fix.  To replicate the issue, add @RequestScoped to
> JDA> org.apache.cxf.systests.cdi.base.BookStore.  Both multi-app test
> suites
> JDA> fail.
>
> JDA> John
>
> JDA> On Mon, Nov 14, 2016 at 12:47 PM Daniel Kulp 
> wrote:
>
>
> >> > On Nov 14, 2016, at 8:20 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> >> wrote:
> >> >
> >> > does a 3.1.9 release sound feasible for beginning of december? idea
> here
> >> is
> >> > to upgrade meecrowave (in progress subproject of openwebbeans
> depending
> >> on
> >> > the snapshot) to release before Xmas holidays time.
>
> >> That’s normally the time I’d like to see a release anyway.   I don’t
> like
> >> doing one in late December due to the Holidays so not doing one in early
> >> December would mean a wait all the way into January.   Thus, +1 to an
> early
> >> December release.  :)
>
>
> >> --
> >> Daniel Kulp
> >> dk...@apache.org - http://dankulp.com/blog
> >> Talend Community Coder - http://coders.talend.com
>
>
>
>

Re: is a release early december possible?

[John D. Ament]

Ok, something's broken right now in 3.1.x :-) (it's an ironic smiley)

I'm working on a fix.  To replicate the issue, add @RequestScoped to
org.apache.cxf.systests.cdi.base.BookStore.  Both multi-app test suites
fail.

John

On Mon, Nov 14, 2016 at 12:47 PM Daniel Kulp  wrote:

>
> > On Nov 14, 2016, at 8:20 AM, Romain Manni-Bucau 
> wrote:
> >
> > does a 3.1.9 release sound feasible for beginning of december? idea here
> is
> > to upgrade meecrowave (in progress subproject of openwebbeans depending
> on
> > the snapshot) to release before Xmas holidays time.
>
> That’s normally the time I’d like to see a release anyway.   I don’t like
> doing one in late December due to the Holidays so not doing one in early
> December would mean a wait all the way into January.   Thus, +1 to an early
> December release.  :)
>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

Re: [cdi] regression for case without jaxrs resources?

[John D. Ament]

On Sat, Oct 22, 2016 at 3:42 PM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> 2016-10-22 21:31 GMT+02:00 John D. Ament <johndam...@apache.org>:
>
> > On Sat, Oct 22, 2016 at 3:10 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Hi guys,
> > >
> > > think now we have a default Application but without checking we have
> > > anything to deploy. Means that the extension will fail CDI deployment
> if
> > > the module doesn't need JAX-RS which concretely makes the extension
> > > unusable outside a end user application.
> > >
> > > Can it be fixed and deployment skipped if nothing should be deployed?
> > >
> >
> > Yep, I'll raise a PR shortly (eg next day or so).  I still want to add
> some
> > systests for this case.  Do you have a JIRA for this or no?
> >
> >
> No, wanted to check it was unintended before.
>

Well, to put it a different way.  The idea that you would include CXF but
not deploy any JAX-RS resources hadn't come into my mind when working on
it.  If its a real use case, can definitely patch it.



>
>
> >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > <http://www.tomitribe.com> | JavaEE Factory
> > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > >
> >
>

Re: cxi integration: multiple buses during deployment?

[John D. Ament]

Could you raise a PR against 3.1.x?  This way the PR builder runs and can
test that there's no regression w/ Weld.

John

On Wed, Oct 19, 2016 at 2:03 PM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> in the meantime if someone can apply my patch or equivalent and push a
> 3.1.9-SNAPSHOT it would unblock us.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2016-10-19 19:48 GMT+02:00 John D. Ament <johndam...@apache.org>:
>
> > Yep I remember mark mentioned that to me before.  Ok I need to prioritize
> > getting those extra tests too.
> >
> > On Oct 19, 2016 13:29, "Romain Manni-Bucau" <rmannibu...@gmail.com>
> wrote:
> >
> > > @John: yes, didn't check weld but OWB wraps 3rd party Bean (cxf bus
> > > here) where weld doesn't probably.
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > <http://www.tomitribe.com> | JavaEE Factory
> > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > >
> > > 2016-10-19 19:19 GMT+02:00 John D. Ament <johndam...@apache.org>:
> > >
> > > > Ok this makes sense now.  I suspect this is an internal diff between
> > owb
> > > > and weld (hence why i still want those tests).  Thanks Roma!
> > > >
> > > > On Oct 19, 2016 13:16, "Romain Manni-Bucau" <rmannibu...@gmail.com>
> > > wrote:
> > > >
> > > > > http://svn.apache.org/repos/asf/openwebbeans/microwave/trunk/ just
> > run
> > > > > core
> > > > > module
> > > > >
> > > > > Think the extension was written with Weld which behaves a bit
> > > differently
> > > > > from openwebbeans on that point.
> > > > >
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > > > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > > > rmannibucau> |
> > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > > > <http://www.tomitribe.com> | JavaEE Factory
> > > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > > >
> > > > > 2016-10-19 19:08 GMT+02:00 Andrey Redko <drr...@gmail.com>:
> > > > >
> > > > > > Hey Roman,
> > > > > >
> > > > > > Thanks a lot for verifying. Would you mind to share the sample
> > > project
> > > > to
> > > > > > reproduce the issue?
> > > > > > There seems to be more things to take into account.
> > > > > > Thanks.
> > > > > >
> > > > > > Best Regards,
> > > > > > Andriy Redko
> > > > > >
> > > > > > On Wed, Oct 19, 2016 at 9:24 AM, Romain Manni-Bucau <
> > > > > rmannibu...@gmail.com
> > > > > > > wrote:
> > > > > >
> > > > > >> doesn't work but for a weirder reason.
> > > > > >>
> > > > > >> CdiBean is added programmatically - all fine
> > > > > >>
> > > > > >> Then it is directly used to get the bus (in "use the default
> bus"
> > > > mode).
> > > > > >> This is not really fine since the CDI impl is free to wrap this
> so
> > > you
> > > > > >> should retrieve the actual instance of the bus and get it with
> > this
> > > > Bean
> > > > > >> instance and not supposing the CDI container will return you the
> > > > > instance
> > > > > >> you add

Re: cxi integration: multiple buses during deployment?

[John D. Ament]

Yep I remember mark mentioned that to me before.  Ok I need to prioritize
getting those extra tests too.

On Oct 19, 2016 13:29, "Romain Manni-Bucau" <rmannibu...@gmail.com> wrote:

> @John: yes, didn't check weld but OWB wraps 3rd party Bean (cxf bus
> here) where weld doesn't probably.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2016-10-19 19:19 GMT+02:00 John D. Ament <johndam...@apache.org>:
>
> > Ok this makes sense now.  I suspect this is an internal diff between owb
> > and weld (hence why i still want those tests).  Thanks Roma!
> >
> > On Oct 19, 2016 13:16, "Romain Manni-Bucau" <rmannibu...@gmail.com>
> wrote:
> >
> > > http://svn.apache.org/repos/asf/openwebbeans/microwave/trunk/ just run
> > > core
> > > module
> > >
> > > Think the extension was written with Weld which behaves a bit
> differently
> > > from openwebbeans on that point.
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > <http://www.tomitribe.com> | JavaEE Factory
> > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > >
> > > 2016-10-19 19:08 GMT+02:00 Andrey Redko <drr...@gmail.com>:
> > >
> > > > Hey Roman,
> > > >
> > > > Thanks a lot for verifying. Would you mind to share the sample
> project
> > to
> > > > reproduce the issue?
> > > > There seems to be more things to take into account.
> > > > Thanks.
> > > >
> > > > Best Regards,
> > > > Andriy Redko
> > > >
> > > > On Wed, Oct 19, 2016 at 9:24 AM, Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > > wrote:
> > > >
> > > >> doesn't work but for a weirder reason.
> > > >>
> > > >> CdiBean is added programmatically - all fine
> > > >>
> > > >> Then it is directly used to get the bus (in "use the default bus"
> > mode).
> > > >> This is not really fine since the CDI impl is free to wrap this so
> you
> > > >> should retrieve the actual instance of the bus and get it with this
> > Bean
> > > >> instance and not supposing the CDI container will return you the
> > > instance
> > > >> you added.
> > > >>
> > > >> Concretely here are the few fixes (on 3.1.x-fixes branch):
> > > >> https://gist.github.com/rmannibucau/0bb8abf2e164d953be17b24b4a08e6
> 85
> > > >>
> > > >> In CDI you can't assume equals/hashcode of Bean so you need to
> > lookup
> > > >> the bus instance and not use the internal one. This patch solves the
> > > issue.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> Romain Manni-Bucau
> > > >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > >> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > > >> <http://rmannibucau.wordpress.com> | Github
> > > >> <https://github.com/rmannibucau> | LinkedIn
> > > >> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > >> <http://www.tomitribe.com> | JavaEE Factory
> > > >> <https://javaeefactory-rmannibucau.rhcloud.com>
> > > >>
> > > >> 2016-10-19 13:35 GMT+02:00 Andrey Redko <drr...@gmail.com>:
> > > >>
> > > >>> Hi Roman,
> > > >>>
> > > >>> Thanks a lot for clarifying on things. Could you please try latest
> > > >>> 3.1.9-SNAPSHOT / 3.2.0-SNAPSHOT against this issue?
> > > >>> The fix should be there. Thanks!
> > > >>>
> >

Re: cxi integration: multiple buses during deployment?

[John D. Ament]

; >> this
> >>>> > >> > > >> case
> >>>> > >> > > >> if bus is not set, the behaviour would be exactly the same
> >>>> > >> > > >>  - change the way JAXRSServerFactoryBean is being created
> >>>> so we
> >>>> > >> could
> >>>> > >> > > set
> >>>> > >> > > >> the bus before setting the application
> >>>> > >> > > >>
> >>>> > >> > > >> Romain Manni-Bucau, do we have a ticket for it? If not,
> >>>> could you
> >>>> > >> > please
> >>>> > >> > > >> create one, we'll work on a fix for it.
> >>>> > >> > > >> Thanks.
> >>>> > >> > > >>
> >>>> > >> > > >>
> >>>> > >> > > >> On Tue, Oct 18, 2016 at 7:08 AM, Romain Manni-Bucau <
> >>>> > >> > > >> rmannibu...@gmail.com>
> >>>> > >> > > >> wrote:
> >>>> > >> > > >>
> >>>> > >> > > >> Not yet something failling i can share but globally I
> ended
> >>>> up doing
> >>>> > >> > > that:
> >>>> > >> > > >>>
> >>>> > >> > > >>> @Named("cxf")
> >>>> > >> > > >>> @ApplicationScoped
> >>>> > >> > > >>> public class BusInstance implements Bus {
> >>>> > >> > > >>> @Delegate
> >>>> > >> > > >>> private Bus delegate = new ExtensionManagerBus();
> >>>> > >> > > >>> }
> >>>> > >> > > >>> public class OWBAutoSetup implements
> >>>> ServletContainerInitializer {
> >>>> > >> > > >>> @Override
> >>>> > >> > > >>> public void onStartup(final Set<Class> c, final
> >>>> ServletContext
> >>>> > >> > ctx)
> >>>> > >> > > >>> throws ServletException {
> >>>> > >> > > >>>
> >>>> > >> > > >>> ctx.addListener(WebBeansConfigurationListener.class);
> >>>> > >> > > >>> ctx.addListener(WebBeansConfig
> >>>> urationHttpSessionListener.class);
> >>>> > >> > > >>> }
> >>>> > >> > > >>> }
> >>>> > >> > > >>>
> >>>> > >> > > >>>
> >>>> > >> > > >>>
> >>>> > >> > > >>> public class CxfCdiAutoSetup implements
> >>>> > >> ServletContainerInitializer {
> >>>> > >> > > >>> @Override
> >>>> > >> > > >>> public void onStartup(final Set<Class> c, final
> >>>> ServletContext
> >>>> > >> > ctx)
> >>>> > >> > > >>> throws ServletException {
> >>>> > >> > > >>> final ServletRegistration.Dynamic jaxrs =
> >>>> ctx.addServlet("cxf-cdi",
> >>>> > >> > > >>> CXFCdiServlet.class);
> >>>> > >> > > >>>
> >>>> > >> > > >>>
> >>>> > >> > > >>> jaxrs.setLoadOnStartup(1);
> >>>> > >> > > >>> jaxrs.setAsyncSupported(true);
> >>>> > >> > > >>> jaxrs.addMapping("/*"); // TODO: config
> >>>> > >> > > >>> }
> >>>> > >> > > >>> }
> >>>> > >> > > >>>
> >>>> > >> > > >>>
> >>>> > >> > > >>>
> >>>> > >> > > >>> With my workaround extension it works fine, without there
> >>>> is this
> >>>> > >> > > >>> mismatch
> >>>> > >> 

Re: cxi integration: multiple buses during deployment?

[John D. Ament]

So still something isn't clicking as I don't have Romain's issue. Is it
specific to when you have multiple deployments in your JVM?

On Oct 18, 2016 09:02, "Romain Manni-Bucau" <rmannibu...@gmail.com> wrote:

> 2016-10-18 14:43 GMT+02:00 Andrey Redko <drr...@gmail.com>:
>
> > Hi Romain Manni-Bucau,
> >
> > Yes, technically we do have this option, but I would suggest to use
> > explicit wirings instead of thread local context.  It
> > could have quite a number of side effects. I hope you would agree with
> > that.
> >
> >
> I agree it is better but side effect should be null since the value is
> cleaned up after. If not then runtime can have side effects which would be
> a bigger issue ;)
>
>
> > Thanks!
> >
> > Best Regards,
> > Andriy Redko
> >
> >
> > On Tue, Oct 18, 2016 at 7:49 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > wrote:
> >
> > > We also have option 3: set the thread bus as in the workaround I used.
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > <http://www.tomitribe.com> | JavaEE Factory
> > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > >
> > > 2016-10-18 13:47 GMT+02:00 Sergey Beryozkin <sberyoz...@gmail.com>:
> > >
> > > > Hi Andriy
> > > > yes, option 1 is probably the simplest for the CDI integration path,
> > > >
> > > > Thanks, Sergey
> > > >
> > > > On 18/10/16 12:43, Andrey Redko wrote:
> > > >
> > > >> Hey guys,
> > > >>
> > > >> Indeed, there is an issue with CDI and usage of custom bus. I think
> > > there
> > > >> are couple of the options
> > > >> we have here:
> > > >>  - pass the bus instance to ResourceUtils::createApplication, in
> this
> > > >> case
> > > >> if bus is not set, the behaviour would be exactly the same
> > > >>  - change the way JAXRSServerFactoryBean is being created so we
> could
> > > set
> > > >> the bus before setting the application
> > > >>
> > > >> Romain Manni-Bucau, do we have a ticket for it? If not, could you
> > please
> > > >> create one, we'll work on a fix for it.
> > > >> Thanks.
> > > >>
> > > >>
> > > >> On Tue, Oct 18, 2016 at 7:08 AM, Romain Manni-Bucau <
> > > >> rmannibu...@gmail.com>
> > > >> wrote:
> > > >>
> > > >> Not yet something failling i can share but globally I ended up doing
> > > that:
> > > >>>
> > > >>> @Named("cxf")
> > > >>> @ApplicationScoped
> > > >>> public class BusInstance implements Bus {
> > > >>> @Delegate
> > > >>> private Bus delegate = new ExtensionManagerBus();
> > > >>> }
> > > >>> public class OWBAutoSetup implements ServletContainerInitializer {
> > > >>> @Override
> > > >>> public void onStartup(final Set<Class> c, final ServletContext
> > ctx)
> > > >>> throws ServletException {
> > > >>>
> > > >>> ctx.addListener(WebBeansConfigurationListener.class);
> > > >>> ctx.addListener(WebBeansConfigurationHttpSessionListener.class);
> > > >>> }
> > > >>> }
> > > >>>
> > > >>>
> > > >>>
> > > >>> public class CxfCdiAutoSetup implements
> ServletContainerInitializer {
> > > >>> @Override
> > > >>> public void onStartup(final Set<Class> c, final ServletContext
> > ctx)
> > > >>> throws ServletException {
> > > >>> final ServletRegistration.Dynamic jaxrs = ctx.addServlet("cxf-cdi",
> > > >>> CXFCdiServlet.class);
> > > >>>
> > > >>>
> > > >>> jaxrs.setLoadOnStartup(1);
> > > >>> jaxrs.setAsyncSupported(true);
> > > >>> jaxrs.addMapping("/*"); // TODO: config
> 

Re: cxi integration: multiple buses during deployment?

[John D. Ament]

Romain,

Depends on how you're trying to instantiate it.  There is a CdiBusBean
provided by CXF which does what you're trying to do -
https://github.com/apache/cxf/blob/3.1.x-fixes/integration/cdi/src/main/java/org/apache/cxf/cdi/CdiBusBean.java#L40
,
take a look at the create method.

I was actually contemplating removing the @Inject from the CXFCdiServlet's
set method, it seems to work inconsistently.  However, i suspect that your
issue is that you're getting a Bus registered as a valid CDI bean
(bean-discovery-mode=all?).

John

On Tue, Oct 18, 2016 at 5:58 AM Romain Manni-Bucau 
wrote:

> Hi guys,
>
> in cdi-integration I don't get how the deployment can work cause the thread
> local bus is not set
>
> Here what i did to ensure i use a single bus (and prevented the cxf one to
> run):
>
> public class JAXRSCdiResourceExtensionWorkaround extends
> JAXRSCdiResourceExtension {
> @Override
> public void load(@Observes final AfterDeploymentValidation event,
> final BeanManager beanManager) {
> final Bus bus =
>
> Bus.class.cast(beanManager.getReference(beanManager.resolve(beanManager.getBeans(Bus.class)),
> Bus.class, null));
> BusFactory.setThreadDefaultBus(bus); // cause app class will
> rely on that and would create multiple bus and then deployment would
> be broken
> try {
> super.load(event, beanManager);
> } finally {
> BusFactory.clearDefaultBusForAnyThread(bus);
> }
> }
> }
>
>
> Issue was caused by JAXRSCdiResourceExtension#createFactoryInstance which
> calls ResourceUtils.createApplication which uses the thread bus which is
> not set by the extension leading to 2 buses.
>
> Did I miss something?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Wordpress Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Tomitriber
>  | JavaEE Factory
> 
>

Re: [VOTE] CXF 3.0.11/3.1.8

[John D. Ament]

+1 (non-binding)
Excited to have my CDI fixes in production now :-)

John

On Fri, Oct 14, 2016 at 2:59 PM Daniel Kulp  wrote:

>
> This is a vote to release 3.0.11/3.1.8.   We’ve resolved over 55 issues
> for 3.1.8.
>
> Staging areas:
> 3.1.8:
> https://repository.apache.org/content/repositories/orgapachecxf-1081/
> 3.0.11:
> https://repository.apache.org/content/repositories/orgapachecxf-1080/
>
>
> Tags:
> 3.1.8:
>
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=80473c6a929cd797d5b0b0134f31818a716011e8
> 3.0.11:
>
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=209f5f9d04b2b49e05c4894034a719eea40bd0e4
>
> Here is my +1
>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

Re: [VOTE] - Release Apache CXF Fediz 1.3.1

[John D. Ament]

Ah thanks.,  Couldn't find that.

Should the release-notes.txt be updated?   (btw withdraw my -1)


John

On Tue, Aug 9, 2016 at 8:58 AM Colm O hEigeartaigh <cohei...@apache.org>
wrote:

> Hi John,
>
> No, the following is the source release:
>
>
> https://repository.apache.org/content/repositories/orgapachecxf-1077/org/apache/cxf/fediz/fediz/1.3.1/fediz-1.3.1-source-release.zip
>
> Colm.
>
> On Tue, Aug 9, 2016 at 12:14 PM, John D. Ament <johndam...@apache.org>
> wrote:
>
> > Colm,
> >
> > Is
> > https://repository.apache.org/content/repositories/
> > orgapachecxf-1077/org/apache/cxf/fediz/apache-fediz/1.3.1/
> > apache-fediz-1.3.1.zip
> > intended
> > to be the source release of Fediz?  (Apologies if its not, for the next
> > line)
> >
> > If so, then -1 due to binaries in the source release.  Look at idp/war,
> > plugins/*/lib (only WebSphere provides source, ironically).
> >
> > John
> >
> > On Tue, Aug 9, 2016 at 4:10 AM Colm O hEigeartaigh <cohei...@apache.org>
> > wrote:
> >
> > > This is a vote to release Apache CXF Fediz 1.3.1.
> > >
> > > Artifacts:
> > > https://repository.apache.org/content/repositories/orgapachecxf-1077/
> > >
> > > Issues Fixed:
> > > https://issues.apache.org/jira/browse/FEDIZ/fixforversion/12335480
> > >
> > > GIT tag:
> > >
> > > https://git-wip-us.apache.org/repos/asf?p=cxf-fediz.git;a=commit;h=
> > 19053fcfe930f54df7b63643ceeb4d87c29eb9ef
> > >
> > > +1 from me.
> > >
> > > Colm.
> > >
> > > --
> > > Colm O hEigeartaigh
> > >
> > > Talend Community Coder
> > > http://coders.talend.com
> > >
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>

Re: [VOTE] - Release Apache CXF Fediz 1.3.1

[John D. Ament]

Colm,

Is
https://repository.apache.org/content/repositories/orgapachecxf-1077/org/apache/cxf/fediz/apache-fediz/1.3.1/apache-fediz-1.3.1.zip
intended
to be the source release of Fediz?  (Apologies if its not, for the next
line)

If so, then -1 due to binaries in the source release.  Look at idp/war,
plugins/*/lib (only WebSphere provides source, ironically).

John

On Tue, Aug 9, 2016 at 4:10 AM Colm O hEigeartaigh 
wrote:

> This is a vote to release Apache CXF Fediz 1.3.1.
>
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecxf-1077/
>
> Issues Fixed:
> https://issues.apache.org/jira/browse/FEDIZ/fixforversion/12335480
>
> GIT tag:
>
> https://git-wip-us.apache.org/repos/asf?p=cxf-fediz.git;a=commit;h=19053fcfe930f54df7b63643ceeb4d87c29eb9ef
>
> +1 from me.
>
> Colm.
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>

[DISCUSS] PR Builder

[John D. Ament]

Hi,

I wanted to propose that the PR Builder should have a longer window for
builds.  Sometimes a build will fail for random reasons - flakey tests, bad
build nodes, etc.  Depending on how many PRs get raised, the build could
disappear from jenkins and not able to be rebuilt.

I wanted to recommend to keep all builds for the latest 7 days.  If you're
raising a PR, I would expect you're addressing issues within 7 days.

PS - I hope no one minds.  After my latest failure, I made two changes to
the existing job.

Change JDK from "latest1.8" to "JDK 1.8 (latest)" (this is a request from
INFRA) (if you want, I can also fix your other jobs if they're pointing
incorrectly)
Exclude the H10 node explicitly from the pool (for some reason, that seems
to have something bad installed or something or it hates me).

You can find the diff here:
https://builds.apache.org/job/CXF-Trunk-PR/jobConfigHistory/showDiffFiles?timestamp1=2015-11-30_15-55-26=2016-08-08_00-19-12

Re: CDI testing module

[John D. Ament]

Ok, I raised a PR to add parent scanning.  I'm not sure if it makes sense
to do it a bit more cautiously,  but to me it makes sense that app path is
inherited (and hence raised a ticket on JAX-RS spec).

John

On Sun, Aug 7, 2016 at 4:26 PM John D. Ament <johndam...@apache.org> wrote:

> Hi Andriy,
>
> That explains quite a few things then.  I basically rewrote the test from
> scratch, got rid of the original errors, but now just get 404's.
>
> I may actually have a fix for you.  I'll let you know this evening.
>
> John
>
>
> On Sun, Aug 7, 2016 at 4:15 PM Andriy Redko <drr...@gmail.com> wrote:
>
>> Hi John,
>>
>> That's pretty interesting, the issue caused by the fact that in your test
>> the Application class instances are Weld proxies, while in orginal test
>> case
>> they aren't. As such, the @ApplicationPath annotations happen to be lost
>> for Weld
>> proxies, which causes address conflicts for JAXRSServerFactoryBeans. I
>> will
>> try to figure out what are the differences ...
>>
>> Thanks!
>>
>> Best Regards,
>> Andriy Redko
>>
>>
>> JDA> Hi Andriy,
>>
>> JDA> Actually I had come to that conclusion a couple of days ago.  So I
>> have to
>> JDA> wonder, was the test ever valid? I know that JAX-RS 2 specified that
>> it was
>> JDA> OK to have multiple application impls per deployment, so I figure
>> that
>> JDA> should work.
>>
>> JDA> And if this is the issue, how come it was fine with how CXF built it
>> before?
>>
>> JDA> John
>>
>> JDA> On Sun, Aug 7, 2016 at 2:44 PM Andriy Redko <drr...@gmail.com>
>> wrote:
>>
>> >> Hey John,
>>
>> >> The exception in question comes from the fact that your deployment
>> >> descriptor
>> >> contains 2 applications, BookStoreApplication and
>> >> BookStoreCustomApplication:
>>
>> >> return ShrinkWrap.create(WebArchive.class)
>> >> .addClasses(BookStoreApplication.class,
>> >> BookStoreCustomApplication.class,
>> >> BookStoreService.class, BookStore.class)
>>
>> >> It is surely possible to have more than one JAX-RS application but in
>> CDI
>> >> context they
>> >> both try to bind to root path "/" (@ApplicationPath is taken into
>> account
>> >> but later). In this
>> >> case both  JAXRSServerFactoryBean instances try to registered
>> themselved
>> >> under "/" and exception
>> >> is being raised :(
>>
>> >> Thanks.
>>
>> >> Best Regards,
>> >> Andriy Redko
>>
>> >> JDA> So I'm running into an interesting issue.  I'm not sure if I
>> found a
>> >> bug,
>> >> JDA> or if I've gone way far into the deep end here.
>>
>> >> JDA> I'm getting this exception: https://paste.apache.org/8WEp
>>
>> >> JDA> You can see my changes here:
>> >> JDA> https://github.com/johnament/cxf/tree/arquillian
>>
>> >> JDA> I suspect what's happening is that CXF is being initialized twice.
>> >> Now
>> >> JDA> that I've enabled CDI, the static initialization and the CDI
>> >> initialization
>> >> JDA> are both being triggered.  Not sure if you have any ideas.
>>
>> >> JDA> John
>>
>> >> JDA> On Tue, Aug 2, 2016 at 9:46 PM John D. Ament <
>> johndam...@apache.org>
>> >> wrote:
>>
>> >> >> Hi Andriy,
>>
>> >> >> Thanks for the prompt reply.
>>
>> >> >> On Tue, Aug 2, 2016 at 9:28 PM Andriy Redko <drr...@gmail.com>
>> wrote:
>>
>> >> >>> Hi John,
>>
>> >> >>> Thanks a lot for your fixes, much appreciated and of great value
>> for
>> >> CDI
>> >> >>> users. To answer a couple of your questions / concerns.
>>
>>
>>
>> >> >>> *JDA> First, its assuming that Weld is the only testable container.
>> >> *This
>> >> >>> is very true. The reason for that is Weld was the only one
>> implementing
>> >> >>> CDI 1.2 at the moment the CXF/CDI integration was done.
>> OpenWebBeans
>> >> were
>> >> >>> behind but there is no obstacles or objects to have a test suite(s)
>> >> >>> against
>> >&

Re: CDI testing module

[John D. Ament]

Hi Andriy,

That explains quite a few things then.  I basically rewrote the test from
scratch, got rid of the original errors, but now just get 404's.

I may actually have a fix for you.  I'll let you know this evening.

John

On Sun, Aug 7, 2016 at 4:15 PM Andriy Redko <drr...@gmail.com> wrote:

> Hi John,
>
> That's pretty interesting, the issue caused by the fact that in your test
> the Application class instances are Weld proxies, while in orginal test
> case
> they aren't. As such, the @ApplicationPath annotations happen to be lost
> for Weld
> proxies, which causes address conflicts for JAXRSServerFactoryBeans. I will
> try to figure out what are the differences ...
>
> Thanks!
>
> Best Regards,
> Andriy Redko
>
>
> JDA> Hi Andriy,
>
> JDA> Actually I had come to that conclusion a couple of days ago.  So I
> have to
> JDA> wonder, was the test ever valid? I know that JAX-RS 2 specified that
> it was
> JDA> OK to have multiple application impls per deployment, so I figure that
> JDA> should work.
>
> JDA> And if this is the issue, how come it was fine with how CXF built it
> before?
>
> JDA> John
>
> JDA> On Sun, Aug 7, 2016 at 2:44 PM Andriy Redko <drr...@gmail.com> wrote:
>
> >> Hey John,
>
> >> The exception in question comes from the fact that your deployment
> >> descriptor
> >> contains 2 applications, BookStoreApplication and
> >> BookStoreCustomApplication:
>
> >> return ShrinkWrap.create(WebArchive.class)
> >> .addClasses(BookStoreApplication.class,
> >> BookStoreCustomApplication.class,
> >> BookStoreService.class, BookStore.class)
>
> >> It is surely possible to have more than one JAX-RS application but in
> CDI
> >> context they
> >> both try to bind to root path "/" (@ApplicationPath is taken into
> account
> >> but later). In this
> >> case both  JAXRSServerFactoryBean instances try to registered themselved
> >> under "/" and exception
> >> is being raised :(
>
> >> Thanks.
>
> >> Best Regards,
> >> Andriy Redko
>
> >> JDA> So I'm running into an interesting issue.  I'm not sure if I found
> a
> >> bug,
> >> JDA> or if I've gone way far into the deep end here.
>
> >> JDA> I'm getting this exception: https://paste.apache.org/8WEp
>
> >> JDA> You can see my changes here:
> >> JDA> https://github.com/johnament/cxf/tree/arquillian
>
> >> JDA> I suspect what's happening is that CXF is being initialized twice.
> >> Now
> >> JDA> that I've enabled CDI, the static initialization and the CDI
> >> initialization
> >> JDA> are both being triggered.  Not sure if you have any ideas.
>
> >> JDA> John
>
> >> JDA> On Tue, Aug 2, 2016 at 9:46 PM John D. Ament <
> johndam...@apache.org>
> >> wrote:
>
> >> >> Hi Andriy,
>
> >> >> Thanks for the prompt reply.
>
> >> >> On Tue, Aug 2, 2016 at 9:28 PM Andriy Redko <drr...@gmail.com>
> wrote:
>
> >> >>> Hi John,
>
> >> >>> Thanks a lot for your fixes, much appreciated and of great value for
> >> CDI
> >> >>> users. To answer a couple of your questions / concerns.
>
>
>
> >> >>> *JDA> First, its assuming that Weld is the only testable container.
> >> *This
> >> >>> is very true. The reason for that is Weld was the only one
> implementing
> >> >>> CDI 1.2 at the moment the CXF/CDI integration was done. OpenWebBeans
> >> were
> >> >>> behind but there is no obstacles or objects to have a test suite(s)
> >> >>> against
> >> >>> it as well, it's been a while OpenWebBeans implements 1.2.
>
>
> >> >> I just realized that the CDI integration has been around for all of
> the
> >> >> 3.x line.  I only found out about it in the last couple of weeks.
>
> >> >> With that said, I'd like to try to put together a test suite.  I'll
> send
> >> >> it over when ready.  If you guys like it, its yours.
>
> >> >> I created https://issues.apache.org/jira/browse/CXF-6988
>
>
>
>
>
> >> >>> *JDA> Second, its always doing classpath scanning.   *This is also
> >> true,
> >> >>> as there was an intention to test exactly the way it is
> >> >>> going to be used. The suite als

Re: CDI testing module

[John D. Ament]

Hi Andriy,

Actually I had come to that conclusion a couple of days ago.  So I have to
wonder, was the test ever valid? I know that JAX-RS 2 specified that it was
OK to have multiple application impls per deployment, so I figure that
should work.

And if this is the issue, how come it was fine with how CXF built it before?

John

On Sun, Aug 7, 2016 at 2:44 PM Andriy Redko <drr...@gmail.com> wrote:

> Hey John,
>
> The exception in question comes from the fact that your deployment
> descriptor
> contains 2 applications, BookStoreApplication and
> BookStoreCustomApplication:
>
> return ShrinkWrap.create(WebArchive.class)
> .addClasses(BookStoreApplication.class,
> BookStoreCustomApplication.class,
> BookStoreService.class, BookStore.class)
>
> It is surely possible to have more than one JAX-RS application but in CDI
> context they
> both try to bind to root path "/" (@ApplicationPath is taken into account
> but later). In this
> case both  JAXRSServerFactoryBean instances try to registered themselved
> under "/" and exception
> is being raised :(
>
> Thanks.
>
> Best Regards,
> Andriy Redko
>
> JDA> So I'm running into an interesting issue.  I'm not sure if I found a
> bug,
> JDA> or if I've gone way far into the deep end here.
>
> JDA> I'm getting this exception: https://paste.apache.org/8WEp
>
> JDA> You can see my changes here:
> JDA> https://github.com/johnament/cxf/tree/arquillian
>
> JDA> I suspect what's happening is that CXF is being initialized twice.
> Now
> JDA> that I've enabled CDI, the static initialization and the CDI
> initialization
> JDA> are both being triggered.  Not sure if you have any ideas.
>
> JDA> John
>
> JDA> On Tue, Aug 2, 2016 at 9:46 PM John D. Ament <johndam...@apache.org>
> wrote:
>
> >> Hi Andriy,
>
> >> Thanks for the prompt reply.
>
> >> On Tue, Aug 2, 2016 at 9:28 PM Andriy Redko <drr...@gmail.com> wrote:
>
> >>> Hi John,
>
> >>> Thanks a lot for your fixes, much appreciated and of great value for
> CDI
> >>> users. To answer a couple of your questions / concerns.
>
>
>
> >>> *JDA> First, its assuming that Weld is the only testable container.
> *This
> >>> is very true. The reason for that is Weld was the only one implementing
> >>> CDI 1.2 at the moment the CXF/CDI integration was done. OpenWebBeans
> were
> >>> behind but there is no obstacles or objects to have a test suite(s)
> >>> against
> >>> it as well, it's been a while OpenWebBeans implements 1.2.
>
>
> >> I just realized that the CDI integration has been around for all of the
> >> 3.x line.  I only found out about it in the last couple of weeks.
>
> >> With that said, I'd like to try to put together a test suite.  I'll send
> >> it over when ready.  If you guys like it, its yours.
>
> >> I created https://issues.apache.org/jira/browse/CXF-6988
>
>
>
>
>
> >>> *JDA> Second, its always doing classpath scanning.   *This is also
> true,
> >>> as there was an intention to test exactly the way it is
> >>> going to be used. The suite also tests against Tomcat and Jetty,
> embedded
> >>> and
> >>> WAR based deployments. With that being said, if Arquillian allows to
> >>> simplify
> >>> the test structure while opening more opportuties to test different
> >>> scenarios
> >>> (including the ones we already have), it would be great in my opinion.
>
>
> >> Sounds good.  Some of the things I'd like to make sure are proved out:
>
> >> - Testing both Weld and OWB
> >> - Running different parts of the test per deployment.
> >> - Ensuring the various tests with Jetty/Jetty Embedded/Tomcat
>
>
>
> >>> Thanks.
>
> >>> Best Regards,
> >>> Andriy Redko
>
>
>
>
>
>
>
>
>
>
>
> >>> *JDA> Hi, JDA> Long time user, first time contributor to CXF.  Though
> I'm
> >>> no stranger to JDA> the ASF by any long shot. JDA> I was looking at
> putting
> >>> in some fixes for issues I reported.  First one JDA> was a non-problem.
> >>> However, when trying to figure out how to add tests to JDA> ensure that
> >>> empty application class applications work fine (CXF-6986), I JDA>
> realized
> >>> that the current testing structure in systest wouldn't work. *JDA>
> >>>
> https://github.com/apache/cxf

Re: CDI testing module

[John D. Ament]

So I'm running into an interesting issue.  I'm not sure if I found a bug,
or if I've gone way far into the deep end here.

I'm getting this exception: https://paste.apache.org/8WEp

You can see my changes here:
https://github.com/johnament/cxf/tree/arquillian

I suspect what's happening is that CXF is being initialized twice.  Now
that I've enabled CDI, the static initialization and the CDI initialization
are both being triggered.  Not sure if you have any ideas.

John

On Tue, Aug 2, 2016 at 9:46 PM John D. Ament <johndam...@apache.org> wrote:

> Hi Andriy,
>
> Thanks for the prompt reply.
>
> On Tue, Aug 2, 2016 at 9:28 PM Andriy Redko <drr...@gmail.com> wrote:
>
>> Hi John,
>>
>> Thanks a lot for your fixes, much appreciated and of great value for CDI
>> users. To answer a couple of your questions / concerns.
>>
>>
>>
>> *JDA> First, its assuming that Weld is the only testable container. *This
>> is very true. The reason for that is Weld was the only one implementing
>> CDI 1.2 at the moment the CXF/CDI integration was done. OpenWebBeans were
>> behind but there is no obstacles or objects to have a test suite(s)
>> against
>> it as well, it's been a while OpenWebBeans implements 1.2.
>>
>
> I just realized that the CDI integration has been around for all of the
> 3.x line.  I only found out about it in the last couple of weeks.
>
> With that said, I'd like to try to put together a test suite.  I'll send
> it over when ready.  If you guys like it, its yours.
>
> I created https://issues.apache.org/jira/browse/CXF-6988
>
>
>>
>>
>>
>> *JDA> Second, its always doing classpath scanning.   *This is also true,
>> as there was an intention to test exactly the way it is
>> going to be used. The suite also tests against Tomcat and Jetty, embedded
>> and
>> WAR based deployments. With that being said, if Arquillian allows to
>> simplify
>> the test structure while opening more opportuties to test different
>> scenarios
>> (including the ones we already have), it would be great in my opinion.
>>
>
> Sounds good.  Some of the things I'd like to make sure are proved out:
>
> - Testing both Weld and OWB
> - Running different parts of the test per deployment.
> - Ensuring the various tests with Jetty/Jetty Embedded/Tomcat
>
>
>>
>> Thanks.
>>
>> Best Regards,
>> Andriy Redko
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *JDA> Hi, JDA> Long time user, first time contributor to CXF.  Though I'm
>> no stranger to JDA> the ASF by any long shot. JDA> I was looking at putting
>> in some fixes for issues I reported.  First one JDA> was a non-problem.
>> However, when trying to figure out how to add tests to JDA> ensure that
>> empty application class applications work fine (CXF-6986), I JDA> realized
>> that the current testing structure in systest wouldn't work. *JDA>
>> https://github.com/apache/cxf/blob/master/systests/cdi/src/test/java/org/apache/cxf/systest/jaxrs/cdi/AbstractCDITest.java
>> <https://github.com/apache/cxf/blob/master/systests/cdi/src/test/java/org/apache/cxf/systest/jaxrs/cdi/AbstractCDITest.java>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *JDA> It looks like this test code is doing a few odd things.  First, its
>> JDA> assuming that Weld is the only testable container.  The ASF actually
>> hosts JDA> the other CDI impl, OpenWebBeans.  Second, its always doing
>> classpath JDA> scanning.  This strategy would mean I need a separate module
>> to test my JDA> feature, which is a little odd. JDA> I was wondering if
>> there was any interest in converting this to an JDA> arquillian based
>> test?  The test code could be platform inspecific, JDA> allowing tests to
>> be created for both CDI impls, improving compatibility. JDA> WDYT? JDA> in
>> case it helps understand the problem, my proposed changes can be seen JDA>
>> here: *https://github.com/apache/cxf/pull/150
>>
>>
>>
>> *JDA> - John *
>>
>

Re: CDI testing module

[John D. Ament]

Hi Andriy,

Thanks for the prompt reply.

On Tue, Aug 2, 2016 at 9:28 PM Andriy Redko  wrote:

> Hi John,
>
> Thanks a lot for your fixes, much appreciated and of great value for CDI
> users. To answer a couple of your questions / concerns.
>
>
>
> *JDA> First, its assuming that Weld is the only testable container. *This
> is very true. The reason for that is Weld was the only one implementing
> CDI 1.2 at the moment the CXF/CDI integration was done. OpenWebBeans were
> behind but there is no obstacles or objects to have a test suite(s) against
> it as well, it's been a while OpenWebBeans implements 1.2.
>

I just realized that the CDI integration has been around for all of the 3.x
line.  I only found out about it in the last couple of weeks.

With that said, I'd like to try to put together a test suite.  I'll send it
over when ready.  If you guys like it, its yours.

I created https://issues.apache.org/jira/browse/CXF-6988


>
>
>
> *JDA> Second, its always doing classpath scanning.   *This is also true,
> as there was an intention to test exactly the way it is
> going to be used. The suite also tests against Tomcat and Jetty, embedded
> and
> WAR based deployments. With that being said, if Arquillian allows to
> simplify
> the test structure while opening more opportuties to test different
> scenarios
> (including the ones we already have), it would be great in my opinion.
>

Sounds good.  Some of the things I'd like to make sure are proved out:

- Testing both Weld and OWB
- Running different parts of the test per deployment.
- Ensuring the various tests with Jetty/Jetty Embedded/Tomcat


>
> Thanks.
>
> Best Regards,
> Andriy Redko
>
>
>
>
>
>
>
>
>
>
>
> *JDA> Hi, JDA> Long time user, first time contributor to CXF.  Though I'm
> no stranger to JDA> the ASF by any long shot. JDA> I was looking at putting
> in some fixes for issues I reported.  First one JDA> was a non-problem.
> However, when trying to figure out how to add tests to JDA> ensure that
> empty application class applications work fine (CXF-6986), I JDA> realized
> that the current testing structure in systest wouldn't work. *JDA>
> https://github.com/apache/cxf/blob/master/systests/cdi/src/test/java/org/apache/cxf/systest/jaxrs/cdi/AbstractCDITest.java
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
> *JDA> It looks like this test code is doing a few odd things.  First, its
> JDA> assuming that Weld is the only testable container.  The ASF actually
> hosts JDA> the other CDI impl, OpenWebBeans.  Second, its always doing
> classpath JDA> scanning.  This strategy would mean I need a separate module
> to test my JDA> feature, which is a little odd. JDA> I was wondering if
> there was any interest in converting this to an JDA> arquillian based
> test?  The test code could be platform inspecific, JDA> allowing tests to
> be created for both CDI impls, improving compatibility. JDA> WDYT? JDA> in
> case it helps understand the problem, my proposed changes can be seen JDA>
> here: *https://github.com/apache/cxf/pull/150
>
>
>
> *JDA> - John *
>

CDI testing module

[John D. Ament]

Hi,

Long time user, first time contributor to CXF.  Though I'm no stranger to
the ASF by any long shot.

I was looking at putting in some fixes for issues I reported.  First one
was a non-problem.  However, when trying to figure out how to add tests to
ensure that empty application class applications work fine (CXF-6986), I
realized that the current testing structure in systest wouldn't work.

https://github.com/apache/cxf/blob/master/systests/cdi/src/test/java/org/apache/cxf/systest/jaxrs/cdi/AbstractCDITest.java

It looks like this test code is doing a few odd things.  First, its
assuming that Weld is the only testable container.  The ASF actually hosts
the other CDI impl, OpenWebBeans.  Second, its always doing classpath
scanning.  This strategy would mean I need a separate module to test my
feature, which is a little odd.

I was wondering if there was any interest in converting this to an
arquillian based test?  The test code could be platform inspecific,
allowing tests to be created for both CDI impls, improving compatibility.

WDYT?
in case it helps understand the problem, my proposed changes can be seen
here: https://github.com/apache/cxf/pull/150

- John