cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Pell <ja...@pellcorp.com>
Subject Re: ehcache version used in cxf build
Date Sat, 06 Jul 2013 22:51:37 GMT
I might have time end of next week so leave with me for the moment.
On Jul 7, 2013 6:54 AM, "Aki Yoshida" <elakito@gmail.com> 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 <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