Justin Deoliveira wrote:
Well, I'm to blame as well, since though I wasn't initially consulted on the change, I insisted that if the change was to be done it be done right, which was more substantial work on a stable branch. Probably should have insisted that the new way of doing things was just a switch that wasn't on by default. That may be the best way forward? I think it may be in just DefaultSQLBuilder and some small other place where it makes the split (or that may be actually be done in the sqlbuilder).Hi all, Some recent development on geotools 2.2.x has caused filter encoding to go bad and as a result is making geoserver cite tests fail, which means we cant release. After three hours of bug hunting i have found the following bugs: 1. FilterCapabilties being wiped out by a negative bit mask (Filter.ALL), so datastores can receive "pre" filters to encode that they cannot handle. 2. The filter splitter changes the filter of an incoming Query object to only be the preFilter. This is a bad assumption to make that the datastore can change the query object passed into it, this makes it so it cant be reused by the calling application. The pre vs post filter processing (used to be SQLUnpacker) appears to have been totally rewritten. This is annoying for two reasons: 1. The postgis module maintainers (chris and I) were not consulted before hand. 2. 2.2.x is supposed to be "stable" which means just bug fixes. This goes far beyond that. I am not trying to point fingers, I am as much to blame as anyone as I have not been keeping up with what is going on apparently.
I'm also a bit scared of the GEOS and non-GEOS postgis merge. Not because it doesn't need to be done, but because it has the possibility of introducing some hard to find bugs. 'nice to have' changes on things that are already working well and tested should _not_ be done right before we're about to make a .0 release. And I'd put the filter capabilities stuff in the same category - we had a stable way of doing things, if uDig requires a major change then they should be on the next version. And if we actually are able to get the api to calm down we could theoretically just use a 2.3 jar for postgis with 2.2 for the rest.
Chris
I cant really spend much more time hunting these bugs down. Also since its radically different i am not confident I will make the appropriate changes properly. So I am in a position where my only option is to roll geoserver back to an earlier 2.2.x version. -Justin
-- Chris Holmes The Open Planning Project http://topp.openplans.org
begin:vcard fn:Chris Holmes n:Holmes;Chris org:The Open Planning Project adr:;;377 Broadway, 11th Floor;New York;NY;10013;USA email;internet:[EMAIL PROTECTED] title:VP, Strategic Development x-mozilla-html:FALSE url:http://topp.openplans.org version:2.1 end:vcard
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
