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 ra
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
> hi,
> thanks all for the information.
>
> Is this issue about the manager instance that is c
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 need
On Jul 4, 2013, at 5:33 AM, Jason Pell 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 (though obviously no
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" wrote:
> IMHO, it would make sense to support a newer version of ehcache for
> 2.7/2.6 as service implementations usually re
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 excep
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 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.
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
+1.
Colm.
On Thu, Jul 4, 2013 at 3:54 AM, Dennis Sosnoski 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
>> suggest
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: d
10 matches
Mail list logo
