Re: Dealing with Attachments in CXF JAX-WS Clients

the > code that tests things, that would be > systests/jaxws/src/test/java/org/apache/cxf/systest/swa/ClientServerSwaTest.java. > > Dan > > > > > On Mar 29, 2019, at 2:37 PM, John D. Ament wrote: > > > > Hi, > > > > I'm looking to integrate wi

Re: Dealing with Attachments in CXF JAX-WS Clients

the message (which we can see is coming correctly). Thanks, John On 2019/03/29 18:37:38, "John D. Ament" wrote: > Hi, > > I'm looking to integrate with an existing webservice that uses attachments > for its handling of binary content. I've enabled mtom on my client.

Dealing with Attachments in CXF JAX-WS Clients

Hi, I'm looking to integrate with an existing webservice that uses attachments for its handling of binary content. I've enabled mtom on my client. I've tested the service using SoapUI and I can see that it properly handles the attachment when using the attachment option in SoapUI. When I try

Re: RE: Memory usage while working with SOAP Client Proxies

().put("thread.local.request.context", > "true"); > > Take a look into > http://cxf.apache.org/faq.html#FAQ-AreJAX-WSclientproxiesthreadsafe? For the > further details. > > Regards, > Andrei. > > > -Original Message- > >

Memory usage while working with SOAP Client Proxies

I'm using CXF 3.2.7 to communicate with SOAP services. I generate client stubs using wsdl2java. My applicates run on Kubernetes and we use pretty small deployments. We recently saw that at times we run out of metaspace and can see higher memory usage after a few invocations of the soap client.

Re: CXF 3.2.3 Regression

in client stuff, because I’m using client > proxies. I ended up using a custom reader @Provider for the rx types. > > On Wed, Mar 21, 2018 at 6:38 PM John D. Ament <johndam...@apache.org> > wrote: > > > Unfortunately, yes. > > > > There was an issue with depend

Re: CXF 3.2.3 Regression

Unfortunately, yes. There was an issue with dependency tress in 3.2.2 with the reactive modules. TL;DR but you need to depend on rx2 module instead of rx module (but good news it brings in everything it needs transitively and you can use an extension to setup the server). I still need to update

Re: Remove obsolete RxJava code and keep RxJava2 only one

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,

Re: JAX-RS 2.1 SSE transport - SseTransportCustomizationExtension is not CDI autodiscoverable

BTW you can find the open PR here: https://github.com/apache/cxf/pull/369 And to be clear, no, the class shouldn't have a CDI scope as we don't want a hard dependency on CDI in this module. John On Mon, Feb 5, 2018 at 9:12 AM John D. Ament <johndam...@apache.org> wrote: > Hi Aaron

Re: JAX-RS 2.1 SSE transport - SseTransportCustomizationExtension is not CDI autodiscoverable

Hi Aaron, Yes, already aware of this limitation. It's probably because the bean discovery mode is ignored in these JARs. Can you try adding it as a scanned JAR in meecrowave? For CXF 3.2.3 (didn't have enough time to finish in 3.2.2) the default discovery mechanism will move from being CDI to

Re: Reactive Services & CDI

d as far as I know the AsyncResponse approach is the more spec appropriate way. > In the servlet container you may need to enable the async (via the > standard servlet param). > haha, that was it. Thanks! > > Cheers, Sergey > > On 04/02/18 17:59, John D. Ament wrote: > >

Re: Reactive Services & CDI

lass); > } > > Not sure why Continuation is not init-ed though, something to do with > the servlet setup > Anything you can suggest to debug through? I'm following the async example I wrote, but within a servlet container (I'm assuming the systests are running a jetty instance).

Re: Reactive Services & CDI

BTW, sample project can be found @ https://github.com/johnament/cxf-demo-reactive-cdi On Sun, Feb 4, 2018 at 11:13 AM John D. Ament <johndam...@apache.org> wrote: > I built a simple webapp (WAR file, deploying to Tomcat) that depends on > the CXF 3.2.2 libraries + Weld 3.0.2. I d

Reactive Services & CDI

I built a simple webapp (WAR file, deploying to Tomcat) that depends on the CXF 3.2.2 libraries + Weld 3.0.2. I don't believe CDI has anything to do with my problem though. I registered a feature/server customizer that can deal with the invoker logic required, and provided a rest controller that

Re: Remove obsolete RxJava code and keep RxJava2 only one

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

Re: Does SSE + CDI work?

On Mon, Sep 18, 2017 at 7:01 AM John D. Ament <johndam...@apache.org> wrote: > On Mon, Sep 18, 2017 at 6:27 AM Sergey Beryozkin <sberyoz...@gmail.com> > wrote: > >> On 18/09/17 11:14, John D. Ament wrote: >> > I'm assuming you mean >> > >> htt

Re: Does SSE + CDI work?

On Mon, Sep 18, 2017 at 6:27 AM Sergey Beryozkin <sberyoz...@gmail.com> wrote: > On 18/09/17 11:14, John D. Ament wrote: > > I'm assuming you mean > > > https://github.com/apache/cxf/blob/master/distribution/src/main/release/samples/jax_rs/sse_cdi/src/

Re: CDI & Class Metadata Parsing

; > Thanks, Sergey > > > On 18/09/17 11:08, John D. Ament wrote: > > Would you be in favor of having one checked in and used by default if > > you're using CDI integration? > > > > On Mon, Sep 18, 2017 at 4:41 AM Sergey Beryozkin <sberyoz...@gmail.com> > >

Re: Does SSE + CDI work?

id, by default CXF assumes it is 'plain' HTTP, so it > needs a hint. > > What did you mean with 1) ? > > Sergey > > On 18/09/17 00:57, John D. Ament wrote: > > Ok, i was able to work a bit deeper into this. > > > > 1. the integration works, but firing async events doe

Re: CDI & Class Metadata Parsing

. > > Sergey > On 17/09/17 23:27, John D. Ament wrote: > > On Sun, Sep 17, 2017 at 5:09 PM Sergey Beryozkin <sberyoz...@gmail.com> > > wrote: > > > >> Hi > >> On 17/09/17 15:37, John D. Ament wrote: > >>> Hey > >>> > >&g

Re: Does SSE + CDI work?

to customize the transport id. It would be good if this was automatic. John On Sun, Sep 17, 2017 at 4:21 PM John D. Ament <johndam...@apache.org> wrote: > I'm trying to create a very basic example of using SSE + CDI events. To > do that, I created a basic endpoint based on a CXF sy

Re: CDI & Class Metadata Parsing

On Sun, Sep 17, 2017 at 5:09 PM Sergey Beryozkin <sberyoz...@gmail.com> wrote: > Hi > On 17/09/17 15:37, John D. Ament wrote: > > Hey > > > > So I just ran into an issue where ExceptionMappers weren't being > processed > > in CXF when they had a CDI nor

Does SSE + CDI work?

I'm trying to create a very basic example of using SSE + CDI events. To do that, I created a basic endpoint based on a CXF systest that I found, but tried to adapt it to work with CDI. @Path("/sse") @RequestScoped public class SseEventEndpoint { @Inject private Event event; @Context

CDI & Class Metadata Parsing

Hey So I just ran into an issue where ExceptionMappers weren't being processed in CXF when they had a CDI normal scope. Switching to a pseudo scope (@Dependent) fixes it. A similar issue to what I saw recently with Weld and Generic Type being lost, except this was happening for both OWB and

Re: sources of cxf-2.6.2.jar?

You should be able to browse all of the source code on github if you're unable to locate it - https://github.com/apache/cxf/tree/cxf-2.6.2 On Wed, May 10, 2017 at 3:48 AM Sigmund God wrote: > We had a old project which have dependency on a jar called cxf-2.6.2.jar. >

Re: CXF Spring Boot integration tests with BeanValidation - ValidationException occurs after successful call

Can you share the implementation of HelloApi? On Oct 24, 2016 07:36, "Johannes Fiala" wrote: > Hi there, > > cxf-spring-boot-starter-jaxrs: 3.1.7 > > I tried using Spring Boot CXF in combination with Spring Boot integration > tests (running as a Spring Boot application

Re: ParamCoverter, List, CSV query parameters

Hi, So just a thought. Why can't this be accomplished today with a ParamConverter and a custom annotation? Looking at the samples repo - https://github.com/javaee-samples/javaee7-samples/blob/master/jaxrs/paramconverter/src/main/java/org/javaee7/jaxrs/paramconverter/MyConverterProvider.java#L18

Re: JDK 8 and CXF

I'm using CXF and Java 8 without any issues. John On Mon, Aug 22, 2016 at 6:55 PM Jeff Coronado wrote: > Hi, > It appears that only JDK 7 is certified for the latest CXF versions. > However, there is a mention that JDK 8 may work. I'm wondering if the > latest v3.1.7

Deploying in an Uber JAR with CXF CDI

I'm using CXF 3.1.6, Weld 2.3.5 and Jetty latest. When starting my app, I get the following stacktrace. The only dependency I added was for the CDI module in CXF, everything else looked transitive. I create a shaded JAR, and everything is getting packed in there properly. John

Re: Test Fail when Exception implements Serializable

Just wondering. Your definition uses long serialVersionUID = 9179138257757325575L; This is an implicit type cast from Long to long. Have you tried using a primitive long in the value, e.g. long serialVersionUID = 9179138257757325575l; On Thu, Jan 28, 2016 at 7:20 AM José Manuel Prieto <

Equivalent of Message.setContextProperty

Hi, I'm upgrading an app to be based on CXF 3.1 (from 3.0.5). In 3.0.5, I could do message.setContextualProperty(SecurityConstants.USERNAME_TOKEN_VALIDATOR,tokenValidator); from within an AbstractPhaseInterceptor. This method no longer exists. Is there an equivalent? John

Re: Problem with optional @PathParam

Realistically in REST, path params are never optional. What you're trying to do is bind the same service to two different URIs. This might be a reason why you want to use sub resources to do the implementation. Assuming you have some wrapper level around this, adding these two methods should

Migrating to CXF 3.0.5 - Without Spring

Hi, I have an app, doesn't leverage spring presently. I'd like to keep it that way. In CXF 2.7.x, I used to use Endpoint.publish(path,implementor) to create my endpoints. It seems that now in CXF 3.0.x, that same call has some internal dependencies on Spring. Namely ServerFactoryBean [1] is

Keep tmp files around

Hi all I'm currently debugging an issue w/ CXF where fields are coming in wrong to our webservice (CXF is the client). I have debug logging turned on but the payloads are too large so I can only see the first 64kb of the message. Is it possible to have CXF keep the files that it creates rather

Re: Keep tmp files around

operation of this caching to leave the files undeleted after processing. If you just want to look at the message content, isn't it easier to activate the logging feature? regards, aki 2013/5/21 John D. Ament john.d.am...@gmail.com Hi all I'm currently debugging an issue w/ CXF where

Re: Keep tmp files around

, at 1:11 PM, John D. Ament john.d.am...@gmail.com wrote: aki In my case, the request body is too large to show in the debug logging. That limits it to 64kb. Actually, I think the debug logging defaults to 100K, not 64K. This is for an outbound web service call we're making using CXF

Re: Keep tmp files around

21, 2013 at 1:52 PM, Daniel Kulp dk...@apache.org wrote: On May 21, 2013, at 1:41 PM, John D. Ament john.d.am...@gmail.com wrote: Currently, I use the JVM option org.apache.cxf.logging.enabled and I see this output: Message (saved to tmp file): Filename: /tmp/cxf-tmp-609897

Re: Keep tmp files around

...@apache.org wrote: On May 21, 2013, at 1:58 PM, John D. Ament john.d.am...@gmail.com wrote: Hmmm Looking at http://cxf.apache.org/docs/debugging-and-logging.html I don't see any option to specify the limit. I do see in the code the alternate constructors, but since I'm using JBoss AS 7

Re: Keep tmp files around

, 2013, at 2:35 PM, John D. Ament john.d.am...@gmail.com wrote: Daniel, Thanks. I added @org.apache.cxf.annotations.Logging(limit = Integer.MAX_VALUE,inLocation= file:///tmp/cxf/in.txt,outLocation=file:///tmp/cxf/out.txt) To my interface (AppPortType.class). Is there somewhere else it should