cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: [DISCUSS] Short term plans/branching....
Date Mon, 19 May 2014 19:26:51 GMT

On May 19, 2014, at 2:54 PM, Andriy Redko <> wrote:

> Hi Dan,
> Excellent plan! One question though: following recent discussions on the list,
> there is strong interest in Java 8 support but we know some issues have to be resolved.
> Do you think we can at least investigate Java 8 support and be ready as much as we can?

I know Willem and I have both been doing a bunch of experiments with Java8.  The main blocker
we have right now is all the JIBX related stuff as the JIBX plugin cannot work with Java8.
 It’s pretty much out of our hands (and not really even in the JIBX’s folks hands) as
it would require a release of BCEL from the Apache Commons folks first.   I *think* if a BCEL
release was made, we could at least build CXF with Java8.   That would leave a couple remaining

CXF’s use of JAXB - we pull in the jaxb-impl and jaxb-xjc from Maven central.   Those versions
have problem with the secure parsers.   There are two options:  1) wait for Oracle to release
new versions to maven central, or 2) Update to use the ‘internal’ versions from the JDK.
 (or (3), set the system property, but that sucks)   There might be another option of doing
DOM parsing ourself with Woodstox and just return DOM’s, but I haven’t looked enough into
JAXB to know if that really would work.   Anyway, #3 on my list was partially to help with
the Java8 issues.   (note:  this can also be “fixed” by throwing xercesImpl onto the classpath,
but I’m kind of loathe to mandate that as well)

Other third party things:  I’m not sure what the Java8 status is for things like the version
of Spring we use, the version of Jetty, etc….   Definitely a testing effort.

I’m pretty sure most of our tests pass OK with Java8 right now.   It’s mostly just the
build time issues and likely the DynamicClient (due to invoking JAXB), and any tests that
parse/process schemas (wsdl2java, wadl2java, etc…) that would have issue.


> Thanks.
> Best Regards,
>    Andriy Redko
> DK> Just wanted to throw out a quick discussion about how to manage the git repo for
the short term.
> DK> With the last 2.6.x release, we announced there would be one more release of that
branch.  Thus, we need to keep
> DK> that branch around.   To avoid having to merge to 3 fixes branches, I’d like
to keep master on 3.0.1 until 2.6.15 is
> DK> released.   At that point, we can create the 3.0.x-fixes branch and set master
for 3.1.    Is there any problems
> DK> with that?  Anything needed for 3.1 that needs to be put on master immediately?
> DK> With 3.0.0 out, I expect a bit higher uptake of it and a possible influx of issues.
  Thus, I’d like a relatively
> DK> quick turnaround for 3.0.1.  Maybe 4-6 weeks.   At that point, we could do 3.0.1/2.7.12/2.6.15
releases at once and be done with 2.6.x.      Would that work for everyone?
> DK> Once we start 3.1, I’d like to do a couple things:
> DK> 1) Update to require Java7
> DK> 2) Remove all the Jaxws 2.1 support stuff.   With being Java 7, we don’t need
the various 2.2/2.1 profiles and differences and such.
> DK> 3) *possibly* change the tooling to use the in-JDK JAXB XJC.   With recent versions
of the JDK, the in-JDK versions
> DK> are actually more up to date than the versions available in central.   Plus, this
would fix some of the issues on
> DK> Java8.   This MAY cause issue on IBM JDK’s.  Will need to investigate.  Possible
wrap the impl via reflect calls
> DK> like we do in the runtime.  In any case, this would drop a few dependencies as
> DK> 4) Start investigating Jetty9 support.   This may be hard without breaking Jetty8.
> DK> 5) With Java7, start using some of the new interfaces, the AutoClosable one being
the main “nice to have”.
> DK> Anyway, open for discussion.  :-)

Daniel Kulp -
Talend Community Coder -

View raw message