3.0.0 release timeframe?

2013-07-04 Thread Dennis Sosnoski
Any idea when we're going to have a 3.0.0 release off trunk? I've implemented WS-RMP 1.2 support and I'm now working on cleaning up the WS-RM 1.2 operation. Could backport to 2.7.x (with some work - there are a lot of changes), but there are probably going to be some minor API changes so just

RE: ehcache version used in cxf build

2013-07-04 Thread Oliver Wulff
IMHO, it would make sense to support a newer version of ehcache for 2.7/2.6 as service implementations usually rely on other 3rd parties which use ehcache as well (hibernate). Thanks Oli From: Daniel Kulp [dk...@apache.org] Sent: 04 July 2013 00:54 To:

Re: [DISCUSS] api+rt-core - core

2013-07-04 Thread Colm O hEigeartaigh
+1. Colm. On Thu, Jul 4, 2013 at 3:54 AM, Dennis Sosnoski d...@sosnoski.com wrote: +1 - Dennis On 07/04/2013 06:39 AM, Daniel Kulp wrote: For 3.0, I'd like to combine both cxf-api and cxf-rt-core into a single jar/bundle. I'd likely just call it cxf-core, but I'm open to other

Re: [DISCUSS] api+rt-core - core

2013-07-04 Thread Alessio Soldano
Generally speaking I agree on this. The api jar has always been actually quite fat for an api thing. One question that pops up in mind though is how we're going to deal with api changes in micro releases in the future. My understanding is that so far, any non backward compatible change to the

Re: [DISCUSS] api+rt-core - core

2013-07-04 Thread Sergey Beryozkin
Hi Sounds good Thanks, Sergey On 04/07/13 10:52, Colm O hEigeartaigh wrote: +1. Colm. On Thu, Jul 4, 2013 at 3:54 AM, Dennis Sosnoski d...@sosnoski.com wrote: +1 - Dennis On 07/04/2013 06:39 AM, Daniel Kulp wrote: For 3.0, I'd like to combine both cxf-api and cxf-rt-core into a

Re: DOSGi 1.5.0 systests failing inconsistently

2013-07-04 Thread A. Rothman
Christian, This doesn't look like it's only about reusing ports (though I added socket.setReuseAddress in getFreePort() for what it's worth if you feel like tinkering). I opened https://issues.apache.org/jira/browse/DOSGI-199 and https://issues.apache.org/jira/browse/DOSGI-200 with two

RE: ehcache version used in cxf build

2013-07-04 Thread Jason Pell
If we don't need to support 2.5.1 as well then the changes would be simpler just need to use new api methods to avoid the 4577 issue. On Jul 4, 2013 6:23 PM, Oliver Wulff owu...@talend.com wrote: IMHO, it would make sense to support a newer version of ehcache for 2.7/2.6 as service

Re: ehcache version used in cxf build

2013-07-04 Thread Daniel Kulp
On Jul 4, 2013, at 5:33 AM, Jason Pell ja...@pellcorp.com wrote: If we don't need to support 2.5.1 as well then the changes would be simpler just need to use new api methods to avoid the 4577 issue. I'd be OK making 2.5.2 a minimum if that helps. That's a patch release via it's number

Re: ehcache version used in cxf build

2013-07-04 Thread Aki Yoshida
hi, thanks all for the information. Is this issue about the manager instance that is created using the create method in the newer version (eg., 2.5.2 and also 2.6.6, etc) being a singleton? In other words, in the newer version to have the same behavior, the newly introduced method newInstance

Re: ehcache version used in cxf build

2013-07-04 Thread Aki Yoshida
maybe I should revert my opinion. if we can change the cxf 2.7.x et al branches to require ehcache 2.5.2, that will be probably better than putting more effort to support 2.5.1. 2013/7/4 Aki Yoshida elak...@gmail.com hi, thanks all for the information. Is this issue about the manager

Re: ehcache version used in cxf build

2013-07-04 Thread Aki Yoshida
I just noticed that EHCacheManagerHolder used in cxf trunk has been moved to wss4j-ws-security-common''s org.apache.wss4j.common.cache. So this handling needs to be done there. This component currently has the same setting like in cxf's 2.7.x (i.e, compiles with 2.5.1, uses create() and sets the