cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrei Shakirin <>
Subject RE: Thoughts about a 2.8 release (or not)…
Date Mon, 15 Apr 2013 10:17:48 GMT

One idea for 3.0 in security area is supporting of XKMS 2.0 standard (was already announced
in dev list in the past).
XKMS will be one more service (like STS) providing standardized access to central key infrastructure
(PKI) including lookup, validation, registration, reissuing, revocation of different types
of keys.
XKMS will help users to manage their certificates centrally instead storing them in local
keystores, that IMO very useful in middle/large service landscapes.
Additionally XKMS provides functionality to revoke keys as soon as they become compromised.
It can be used for SOAP as well as with Rest services.
I tried to explain the use case of XKMS in the blog:

>From my perspective it could be useful extension of current CXF security.


> -----Original Message-----
> From: Daniel Kulp []
> Sent: Donnerstag, 11. April 2013 17:17
> To:
> Subject: Re: Thoughts about a 2.8 release (or not)…
> I never really did follow up on this.
> Looking at the responses, I think we're in something close to an agreement
> that a 2.8 cannot be done right now (or it doesn't make sense to do so) and
> moving toward 3.0 make sense.
> Thus, I'd like to go ahead an make trunk to be targeting 3.0.   The main chunks
> of work right now for it involve the JAX-RS 2.0 work and the WSS4J 2.0 work.
> The WSS4J stuff is on a branch right now, but I'd like to see a little more
> stability there before merging to trunk.  Maybe a couple weeks away.
> Once we start targeting a 3.0, I'd definitely like to open it up for other ideas.
> My immediate plan is to pull the WSDL4J requirements out of the transports
> somehow to allow a pure jaxrs app to not need any WSDL things.   I'm
> thinking about also pulling the wsdlmanager, ws-addressing stuff, various
> soap specific things, etc…  out of api/core to reduce the size of those for JAX-
> RS apps.  Not quite sure what that would look like yet, but it certainly would
> make sense to do for a 3.0 version.
> I'd definitely recommend folks to update:
> and
> (both of which are horribly outdated)
> Please add any ideas or thought or other things that have bugged you.
> Dan
> On Mar 25, 2013, at 2:19 PM, Daniel Kulp <> wrote:
> >
> > We're getting close to April which normally would be the next release (2.8).
> However, looking things over, I'm not sure it makes sense at this time.
> Looking at trunk, the only major change (which is admittedly a big one), is
> updating the JAX-RS 2.0 stuff from m10  to the RC level.   However, it's not
> complete yet.   Almost everything else has been back ported to 2.7.x.   The
> other major chunk of work that is happening is on the wss4j2 branch, but
> that isn't ready for for release yet either.   (and has some backwards compat
> issues to resolve if it would go on a 2.x line)
> >
> > According to the agreements Apache has with Oracle, we really cannot
> "release" code that doesn't pass the TCK (which the 2.0 works would not).
> Technically, we should not have released 2.7.0 as a release.  We can release
> things like "tech previews" or "beta" or similar, but not a full release.   Since
> we are working on trying to renew the agreements, Oracle is paying
> attention to us pretty closely right now.
> >
> > So, what am I getting at?   In order to release 2.8 in a few weeks, we'd
> either need to back out all the JAX-RS 2.0 stuff to 1.1 level OR everyone jump
> in full force and get it to pass the TCK.   I really don't see either happening.
> Backing out to 1.1 would be silly and the 2.0 TCK stuff is a ton of work.   Thus,
> my suggestion would be to skip a big release this April and concentrate on
> bigger things for our Oct/Nov release.  Possibly make that a CXF 3.0 release
> instead of 2.8 where we can clean up some stuff, break a few things (like
> change the couple API's that currently force WSDL4J on JAX-RS users), etc…
> We can incorporate the WSS4J2 changes as part of this as well.    If we go this
> route, we could likely start a series of "beta" releases or similar in June or so
> to get people looking at it and testing with it.
> >
> > Any thoughts?
> >
> > --
> > Daniel Kulp
> > - Talend Community Coder -
> >
> >
> --
> Daniel Kulp
> - Talend Community Coder -

View raw message