On Thu, Mar 24, 2011 at 8:22 PM, Niels <[email protected]> wrote:
>
> Not sure I follow. Those preventer adapters should now allow the same
> element or schema to be added more than once... so I am curious as to how
> the back references are accumulating. So while maybe right away the objects
> won't be deferenced but eventually hey should be. Although if you are
> building up multiple different schemas I can see how this could be an issue.
>
>
>
> Well, what I meant to say is that even if the preventers were working, it
> wouldn't be enough. Say for example that an app-schema test builds a schema
> for a "blahblah" namespace, the preventers wouldn't remove it until another
> "blahblah" schema is built. However, I want it to be gone at the end of the
> test, no matter what, there is no point in keeping it around forever. That's
> why I concluded I should follow the path of active disposal of schema's
> rather than just preventing duplicates.
>
> Ok right, makes sense.
>
>> The consequences for App-schema are big though. In the current setup, you
>> specify your schema's for each datastore (for each mapping). So even in one
>> single test, multiple versions of the GSML schema are alive. All of them
>> accumulate to multiple references in the substitution groups of GML for the
>> same element. It just does not make any possible sense to link multiple
>> versions of the GSML schema to one single GML schema in memory! Because of
>> the backwards links and substitution groups it becomes one big clutter.
>>
> Right... but is that not the problem that the preventers "prevent" :). I am
> curious as to why they are not working on this case.
>
>
>> My solution is to keep a registry that maps schema locations to schema's
>> and reuse schema's that have already been built. Performance and memory
>> improvement at the same time.
>>
>> In that case, the only way there could still be cluttering in the XSD
>> schema's in memory, if for some reason someone is using the same schema in
>> different file locations, or different versions of the same schema, in
>> different datastores of the same instance of app-schema. I don't see a way
>> to avoid that.
>>
>
> Another possible solution would be to create some sort of wrapper, or a
> registry in which every time client code builds a schema they should
> register it. And when the schema object is not required any longer there is
> some dispose method called. When that occurs the schema removes itself from
> any schemas that it imported or referenced via substitution group.
>
>>
>>
>>
> I think what you are saying is basically what I am doing.
>
> Cool, I look forward to the results.
>
> Regards
> Niels
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
