cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: SeachConditionBuilder for CXF JAX-RS clients
Date Mon, 07 Mar 2011 12:44:05 GMT
Hi Andy

> Regarding SimpleSearchCriteria flaw it is rooted in
> SearchCriteria.getCondtition() interface operation that I think must be
> removed from the contract. It suggests possibility of using type T as
> condition data holder which was actually done in SimpleSearchCriteria. And
> this led us to limitation with primitives properties which is the reason of
> our problem now. Anyway, the rework has begun ;)
sorry, I'm not following :-) We have PrimitiveSearchCondition which wraps an
expression like "a==2". The actual condition instance is say Book. Having
getCondition() returning Book is not ideal in this case but
PrimitiveSearchCondition also has getters identifying a particular property
this PrimitiveSearchCondition is centered around.

What is the code which is passed SearchCondition wants to do the match
differently by traversing SearchCondition for the sub-conditions and using
the actual condition instance to make the match against the data which can
not be easily assembled into say List<Book> for SearchCondition.findAll() to
work ?

> Another hint for environment. Being seasonal contributor I faced problems
> with JDK1.5 build. I did not spot problems since I am using JDK1.6 locally
> and generated Eclipse workspace did not force me to use compatibility with
> 1.5. Maybe maven should generate by default code compatibility 1.5 instead
> of latest-greatest; this way we would reduce problems injected by
> contributors regenerating workspace.

cheers, Sergey

> cheers,
> -andy.
> --
> View this message in context:
> Sent from the cxf-dev mailing list archive at

Sergey Beryozkin

Application Integration Division of Talend <>

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