>> May be we can make SearchConditionBuilder an abstract class? Have an >> > internal FiqlSearchConditionBuilder as the default instance ... >> >> Yeap, you have just verbalized what I wanted to do. > > Sorry about it Andy, can't help it, not a great habit :-)
Quite opposite, it is good habit, it decreases misunderstanding; it was just my confirmation we are on the same page. 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 ;) 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, -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.
