thaaat's what I call a satisfactory answer :)
Rini, see how FeatureTypeCache is used in WFSConfiguration.configureContext
As Justin suggested, the same way you can register a new instance of,
say, IdLookUp in GMLConfiguration.configureContext and have
AbstractFeatureTypeBinding take an extra constructor argument of type
IdLookUp (if my understanding is correct the picocontainer will take
care of passing over the constructor argument as long as it's registered
by GMLConfiguration)
Then IdLookUp might be something like:
class IdLookUp{
...
boolean idExists(String gmlId){...}
void add(String gmlId){...}
}
May you have time to do that so we fix the perf penalty?
(Justin please confirm my above suggestion is correct)
Cheers,
Gabriel
Justin Deoliveira wrote:
> 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
>>>
>>>
>>
>>
>
>
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
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
