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. > > +1 cheers, Sergey > cheers, > -andy. > > -- > View this message in context: > http://cxf.547215.n5.nabble.com/SeachConditionBuilder-for-CXF-JAX-RS-clients-tp3357826p3412343.html > Sent from the cxf-dev mailing list archive at Nabble.com. > -- Sergey Beryozkin Application Integration Division of Talend <http://www.talend.com> http://sberyozkin.blogspot.com
