Hi Aki, EHCacheManagerHolder has only been moved to WSS4J trunk and so only affects CXF trunk. It still exists in CXF 2.7.x. I think you are probably right, and that we should only upgrade EhCache for CXF trunk and not 2.7.x.
Colm. On Thu, Jul 4, 2013 at 5:48 PM, Aki Yoshida <[email protected]> wrote: > 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 range [2.5.0, 3.0.0). > > Maybe, there are other components that are also using 2.5.1 with this > default 2.5 range and if these rely on the old behavior, they cannot > upgrade to ehcache to 2.5.2 or higher. So maybe it may not be a good idea > to change cxf 2.7.x's ehcache's lower range to 2.5.2. > > @Colm > are you reading this thread? > > thanks. > aki > > > 2013/7/4 Aki Yoshida <[email protected]> > > > 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 <[email protected]> > > > >> 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 needs to be instead called? > >> > >> If that's the case, we should put the code to handle both cases in all > >> code lines. > >> > >> thanks. > >> aki > >> > >> > >> 2013/7/4 Jason Pell <[email protected]> > >> > >>> Sorry guys i never got back to this one. Would be easier i should think > >>> to fix this for 3.0 and no longer support the old version at all thus > no > >>> reflection magic. > >>> On Jul 4, 2013 7:04 AM, "Daniel Kulp" <[email protected]> wrote: > >>> > >>>> Aki, > >>>> > >>>> This was on my todo list to look at, just never have managed to find > >>>> the time. There is an issue logged about it: > >>>> > >>>> https://issues.apache.org/jira/browse/CXF-4577 > >>>> > >>>> If you have time, feel free to grab it and see what you can find out. > >>>> > >>>> Dan > >>>> > >>>> > >>>> > >>>> > >>>> On Jul 3, 2013, at 4:58 PM, Aki Yoshida <[email protected]> wrote: > >>>> > >>>> > cxf's trunk and branches (2.7.x, 2.6.x, etc) all use ehcache 2.5.1 > and > >>>> > create the karaf feature with the corresponding smx's bundle > version. > >>>> But > >>>> > the version range specified in the package imports is set as > >>>> [2.5.0,3.0.0), > >>>> > so we could use a newer version in runtime. > >>>> > > >>>> > As ehcache 2.5.1 is rather old (from 2012-01) and there are newer > >>>> versions > >>>> > such as 2.6.6 (2013-05) and 2.7.2 (2013-07) which is already an > >>>> > osgi-bundle, I was wondering if we can use a newer version for > >>>> trunk's > >>>> > build. There are some disappeared classes and other changes, but the > >>>> usage > >>>> > in cxf seem to be compatible with these versions. I tried both 2.6.6 > >>>> and > >>>> > 2.7.2, and the build itself seems to run without problems. > >>>> > > >>>> > How do you think about upgrading ehcache to ehcache 2.7.2 for trunk > >>>> so that > >>>> > we can test cxf not just against old ehcache 2.5.1? > >>>> > > >>>> > As comparison, camel trunk uses ehcache 2.7.0, while 2.11.x uses > >>>> 2.5.2. > >>>> > > >>>> > regards, aki > >>>> > >>>> -- > >>>> Daniel Kulp > >>>> [email protected] - http://dankulp.com/blog > >>>> Talend Community Coder - http://coders.talend.com > >>>> > >>>> > >> > > > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
