Hi Jason, I wanted to have a patched snapshot sometime next week. But I am not around in the beginning of the next week, so I was wondering if you wanted to work on it in the next few days :-). But if you can't find time next week, I can look at it next week then.
regards, aki 2013/7/5 Jason Pell <[email protected]> > It depends when you need it done :-) > > Its been on my list of todos for a long time and i am flat out on my day > job with other stuff. Might be able to look at it in a few weeks. > On Jul 5, 2013 10:46 PM, "Aki Yoshida" <[email protected]> wrote: > >> Hi Colm, all, >> >> My mind has been going back and forth :-( >> >> I think we should make cxf 2.7.x, et al use a reflection based method so >> that we can use either ehcache 2.5.1 or a higher version at runtime. If we >> don't do this and either stick to the current 2.5.1 usage or switch to the >> new 2.5.2 usage, we will have to set its ehcache range to either >> [2.5.0,2.5.1] or [2.5.2,3.0.0), and that will look sad. >> >> For cxf trunk, we can update its compile time dependency to ehcache 2.7.2 >> and since the code change has to go into 2.7,x, we can also include this >> change for rt/rs/security/sso/saml that uses the create method. And we need >> an equivalent change in wss4j trunk to be consistent. >> >> @Jason, >> Will you be doing the change for cxf or shall I do it or help you some >> part? Let me know. >> >> thanks. >> aki >> >> >> >> >> 2013/7/5 Colm O hEigeartaigh <[email protected]> >> >>> 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 >>> >> >>
