Hmmm... well one possibility might be to use a similar solution as FeatureTypeCache. Each time the encoder stats, the container context gets a FeatureTypeCache instance which basically serves as a cache for feature type objects, used while parsing features to avoid creating the feature type over and over again.
A similar class could be used ot track ids during encoding. GMLConfiguration.configureContext could register it, and then whatever binding (AbstractFeatureTypeBinding or whatever) could declare a dependency on it, grab the instnace and check for or update the set with encoded ids. The downside being that for huge feature collections the set could get quite large... but i guess its better than the current solution of building up a document full of ids. Gabriel Roldan wrote: > Hey Justin, > > when you have a chance please take a look at the comments in > <http://jira.codehaus.org/browse/GEOT-2627>, as > GML3EncodingUtils.idExists() is making the gml encoding process almost > twice slower and I would love you opinion on the proposed workaround > > Cheers, > Gabriel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
