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.
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.
Regards
Niels
------------------------------------------------------------------------------
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
