Re: ehcache version used in cxf build
Hi, No sorry have not had a chance to look at this at all. My day job is keeping me really busy, now on java 7 upgrade and all the fun that comes with it. I had a look at the patch. It's unfortunate that we have to use reflection, but I was pleased to see this all in the EHCacheUtils class, so not really that big of a deal. Thanks for taking the time to do it, and apologies that I had not done it myself, it was quite low on my list of priorities as ehcache 2.5.1 was working fine for my day job. Cheers Jason On Tue, Jul 16, 2013 at 9:04 PM, Aki Yoshida wrote: > Hi Jason, > I suppose you haven't had time for this. > > Since I see Dan preparing for the 2.7.x release today, I would like to > include this ehcache fix in the release if we still got time so that > we can use cxf 2.7.6 with a newer ehcache. I made a local change for > trunk (not updating the ehcache version in pom yet there but changed > the code to use reflection to pick up the right method). I can > integrate the corresponding changes into 2.7.x and add them to the > ticket. Please take a look. > Thanks. > > regards, aki > > 2013/7/12 Jason Pell : > > Hi, > > > > I did not get to this this week. I have been in xtext hell all week, and > > performance problems with xtext have continued with no resolution. I > hope > > to resolve them in the next day or so. > > > > > > On Thu, Jul 11, 2013 at 1:46 AM, Aki Yoshida wrote: > >> > >> okay. then i'll wait for you. > >> > >> 2013/7/7 Jason Pell : > >> > I might have time end of next week so leave with me for the moment. > >> > > >> > On Jul 7, 2013 6:54 AM, "Aki Yoshida" wrote: > >> >> > >> >> 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 > >> >>> > >> >>> 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" 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 > >> > > >> > 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 > >> > 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 > >> > > > >> > > > maybe I s
Re: ehcache version used in cxf build
Hi Jason, I suppose you haven't had time for this. Since I see Dan preparing for the 2.7.x release today, I would like to include this ehcache fix in the release if we still got time so that we can use cxf 2.7.6 with a newer ehcache. I made a local change for trunk (not updating the ehcache version in pom yet there but changed the code to use reflection to pick up the right method). I can integrate the corresponding changes into 2.7.x and add them to the ticket. Please take a look. Thanks. regards, aki 2013/7/12 Jason Pell : > Hi, > > I did not get to this this week. I have been in xtext hell all week, and > performance problems with xtext have continued with no resolution. I hope > to resolve them in the next day or so. > > > On Thu, Jul 11, 2013 at 1:46 AM, Aki Yoshida wrote: >> >> okay. then i'll wait for you. >> >> 2013/7/7 Jason Pell : >> > I might have time end of next week so leave with me for the moment. >> > >> > On Jul 7, 2013 6:54 AM, "Aki Yoshida" wrote: >> >> >> >> 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 >> >>> >> >>> 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" 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 >> > >> > 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 >> > 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 >> > > >> > > > 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 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? >> > > >> >
Re: ehcache version used in cxf build
Hi, I did not get to this this week. I have been in xtext hell all week, and performance problems with xtext have continued with no resolution. I hope to resolve them in the next day or so. On Thu, Jul 11, 2013 at 1:46 AM, Aki Yoshida wrote: > okay. then i'll wait for you. > > 2013/7/7 Jason Pell : > > I might have time end of next week so leave with me for the moment. > > > > On Jul 7, 2013 6:54 AM, "Aki Yoshida" wrote: > >> > >> 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 > >>> > >>> 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" 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 > > > > 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 > 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 > > > > > > > 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 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 > > > >> > > > >>> 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" > 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://issu
Re: ehcache version used in cxf build
okay. then i'll wait for you. 2013/7/7 Jason Pell : > I might have time end of next week so leave with me for the moment. > > On Jul 7, 2013 6:54 AM, "Aki Yoshida" wrote: >> >> 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 >>> >>> 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" 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 > > 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 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 > > > > > 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 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 > > >> > > >>> 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" 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 > > 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
Re: ehcache version used in cxf build
I might have time end of next week so leave with me for the moment. On Jul 7, 2013 6:54 AM, "Aki Yoshida" wrote: > 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 > >> 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" 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 >>> 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 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 > > > 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 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 > >> > >>> 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" 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 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
Re: ehcache version used in cxf build
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 > 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" 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 >> >>> 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 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 >>> > >>> > > 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 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 >>> > >> >>> > >>> 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" 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 >>> 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 versi
Re: ehcache version used in cxf build
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" 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 > >> 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 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 >> > >> > > 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 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 >> > >> >> > >>> 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" 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 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 >> > >> > -- >> > >>>
Re: ehcache version used in cxf build
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 > 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 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 > > > > > 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 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 > > >> > > >>> 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" 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 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 > > dk...@apache.org - http://dankulp.com/blog > > Talend Community Coder - http://coders.talend.com > > > > > > >> > > > > > > > > > -- > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com >
Re: ehcache version used in cxf build
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 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 > > > 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 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 > >> > >>> 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" 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 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 > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > > > >> > > > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
Re: ehcache version used in cxf build
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 > 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 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 >> >>> 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" 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 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 dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com >> >
Re: ehcache version used in cxf build
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 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 > >> 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" 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 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 >>> dk...@apache.org - http://dankulp.com/blog >>> Talend Community Coder - http://coders.talend.com >>> >>> >
Re: ehcache version used in cxf build
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 > 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" 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 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 >> dk...@apache.org - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >>
Re: ehcache version used in cxf build
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 not). Dan > 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 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: dev@cxf.apache.org >> Cc: Aki Yoshida >> Subject: Re: ehcache version used in cxf build >> >> On Jul 3, 2013, at 6:01 PM, Jason Pell wrote: >> >>> 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. >> >> Well, I'd LIKE to still be able to run 2.7/2.6 with the newer versions of >> ehcache if at all possible.But yes, for 3.0, we could just go with the >> newest as a minimum. >> >> Dan >> >> >> >>> On Jul 4, 2013 7:04 AM, "Daniel Kulp" 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 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 >>>> dk...@apache.org - http://dankulp.com/blog >>>> Talend Community Coder - http://coders.talend.com >>>> >>>> >> >> -- >> Daniel Kulp >> dk...@apache.org - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >> -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
RE: ehcache version used in cxf build
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 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: dev@cxf.apache.org > Cc: Aki Yoshida > Subject: Re: ehcache version used in cxf build > > On Jul 3, 2013, at 6:01 PM, Jason Pell wrote: > > > 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. > > Well, I'd LIKE to still be able to run 2.7/2.6 with the newer versions of > ehcache if at all possible.But yes, for 3.0, we could just go with the > newest as a minimum. > > Dan > > > > > On Jul 4, 2013 7:04 AM, "Daniel Kulp" 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 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 > >> dk...@apache.org - http://dankulp.com/blog > >> Talend Community Coder - http://coders.talend.com > >> > >> > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > >
RE: ehcache version used in cxf build
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: dev@cxf.apache.org Cc: Aki Yoshida Subject: Re: ehcache version used in cxf build On Jul 3, 2013, at 6:01 PM, Jason Pell wrote: > 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. Well, I'd LIKE to still be able to run 2.7/2.6 with the newer versions of ehcache if at all possible.But yes, for 3.0, we could just go with the newest as a minimum. Dan > On Jul 4, 2013 7:04 AM, "Daniel Kulp" 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 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 >> dk...@apache.org - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >> -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: ehcache version used in cxf build
On Jul 3, 2013, at 6:01 PM, Jason Pell wrote: > 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. Well, I'd LIKE to still be able to run 2.7/2.6 with the newer versions of ehcache if at all possible.But yes, for 3.0, we could just go with the newest as a minimum. Dan > On Jul 4, 2013 7:04 AM, "Daniel Kulp" 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 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 >> dk...@apache.org - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >> -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: ehcache version used in cxf build
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" 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 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 > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > >
Re: ehcache version used in cxf build
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 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 dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
