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 <cohei...@apache.org>

> 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 <elak...@gmail.com> 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 <elak...@gmail.com>
> >
> > > 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 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 <ja...@pellcorp.com>
> > >>
> > >>> 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" <dk...@apache.org> 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 <elak...@gmail.com> 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
>

Reply via email to