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 Tue, 16 Jul 2013 14:07:09 GMT
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 <elakito@gmail.com> 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 <jason@pellcorp.com>:
> > 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 <elakito@gmail.com> wrote:
> >>
> >> okay. then i'll wait for you.
> >>
> >> 2013/7/7 Jason Pell <jason@pellcorp.com>:
> >> > 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