Even though the Configuration object is a singleton in geoserver (hopefully fix that someday), the binding context is not stored as a member of it, it is created by the encoder and passed into Configuration.configureContext(). So as long as two processes are not storing the same encoder instance as state there should be no problem.
Gabriel Roldan wrote: > That'd be a good solution to provide a context to the gml encoding > process, my open question is now how to ensure that context is not > shared between encoding processes, as the list of ids is to be checked > independently for each one. My understanding is FeatureTypeCache is > shared and that's ok, but this one may require a per process "context". > What do you think? > > Justin Deoliveira wrote: >> 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
