Re: [cxf] branch master updated: [CXF-7934]Add cache for ProxyClassLoader

This commit has a bunch of problems. At no point is anything removed from these caches until the cache fills. Thus, would definitely be considered a memory leak of some sort. Also, because the class loader is held onto strongly, the classes are locked and not able to be garbage collected.

[GitHub] amarkevich opened a new pull request #488: maven-surefire-plugin: replace deprecated forkMode with forkCount

amarkevich opened a new pull request #488: maven-surefire-plugin: replace deprecated forkMode with forkCount URL: https://github.com/apache/cxf/pull/488 according to [1] replace forkMode (default 'once') with forkCount (default '1') some tests updated to run with

Re: 3.3.0 soon?

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

[GitHub] rmannibucau opened a new pull request #487: Ensure JAXB and javax.activation are not required for JAX-RS

rmannibucau opened a new pull request #487: Ensure JAXB and javax.activation are not required for JAX-RS URL: https://github.com/apache/cxf/pull/487 Goal is to ensure default java11 experience is still good when not needing JAXB/activation (which is pretty much often these days with

cxf-services-ws-discovery-api

Hi all, Is this test failing for anyone else? It's recently started failing for me on Ubuntu. Perhaps we need to just disable it by default, as it already doesn't run on RHEL. Colm. -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com

Re: CxfTypeSafeClientBuilderTest failing on JDK9+

Yes, and we build against JDK12-ea builds, so I think we could ignore it for now. Best Regards, Andriy Redko RMB> Guess the hack on modifiers can be ignored, it is not deterministic anyway RMB> - it can lead to a noop since java 8. While in unamed modules RMB> unreflectSpecial will be

Re: 3.3.0 soon?

Hey guys, I also noticed that some of our integrations, like fe Swagger / OpenApi do explicitly depend on JAXB APIs artifacts. I think we should be careful here and at least add exclusions, avoiding classpath collisions. There could be more examples like that. Thanks. Best Regards, Andriy

Re: 3.3.0 soon?

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

Re: 3.3.0 soon?

Hi, On Fri, Dec 21, 2018 at 10:24 AM Dennis Kieselhorst wrote: > > > think we should definitely integrate the JakartaEE dependencies > (groupId/ > > artifactId change as announced earlier). According to schedule they will > be > > release next Friday (14.12.2018). > > > > +1. > > Unfortunately

Re: 3.3.0 soon?

> > think we should definitely integrate the JakartaEE dependencies (groupId/ > artifactId change as announced earlier). According to schedule they will be > release next Friday (14.12.2018). > > +1. Unfortunately the JAXB and JAX-WS releases are still not available on central. Haven't found an

Re: CxfTypeSafeClientBuilderTest failing on JDK9+

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

Re: CxfTypeSafeClientBuilderTest failing on JDK9+

Thanks Andriy, looks good for 8-11 now, but 12 is now failing with: Caused by: java.lang.NoSuchFieldException: allowedModes at org.apache.cxf.microprofile.client.CxfTypeSafeClientBuilderTest.testCanInvokeDefaultInterfaceMethods(CxfTypeSafeClientBuilderTest.java:173)