cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <elak...@gmail.com>
Subject Re: ehcache version used in cxf build
Date Sat, 06 Jul 2013 20:54:02 GMT
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 <jason@pellcorp.com>

> 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" <elakito@gmail.com> 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 <coheigea@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 <elakito@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 <elakito@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 <elakito@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 <jason@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" <dkulp@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 <elakito@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
>>> > >>>> dkulp@apache.org - http://dankulp.com/blog
>>> > >>>> Talend Community Coder - http://coders.talend.com
>>> > >>>>
>>> > >>>>
>>> > >>
>>> > >
>>> >
>>>
>>>
>>>
>>> --
>>> Colm O hEigeartaigh
>>>
>>> Talend Community Coder
>>> http://coders.talend.com
>>>
>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message