|Version 12 (modified by heikki, 2 years ago)|
- Architecture discussion
- [heikki] XML binding: In the ebRIM branch, and in the Nordic Security code (not public yet), JiBX is used for Java <--> XML binding. It is highly useful to have such a binding, as it can be invoked automatically on Web Service communications and leads to a much cleaner dealing with objects in Java than when DOM/JDOM is used. One disadvantage of JiBX is that this binding needs to be written manually, which is a bit of a pain in the neck. Another disadvantage is that it is not a Java standard. JAXB on the other hand *is* the standard and comes with a binding-generator that takes a schema and produces the bound Java classes.
However, I've tried running it on the ISO19139 schema and it does not work :
~/jaxb-ri-20110115/bin$ xjc -p testpackagename ~/source/ogc/ogc-schemas/trunk/iso/19139/20070417/schema/src/main/resources/iso/19139/20070417/gmd/gmd.xsd The result is : parsing a schema... [ERROR] Property "Rows" is already defined. Use <jaxb:property> to resolve this conflict. line 648 of file: ~/source/ogc/ogc-schemas/trunk/iso/19139/20070417/schema/src/main/resources/gml/3.2.1/geometryPrimitives.xsd [ERROR] The following location is relevant to the above error line 680 of file: ~/source/ogc/ogc-schemas/trunk/iso/19139/20070417/schema/src/main/resources/gml/3.2.1/geometryPrimitives.xsd Failed to parse a schema.
This is because of peculiarities in the schemas that we cannot control. I have asked firstname.lastname@example.org if it is possible to do this at all, but I'd be surprised.
Question remains: if we cannot use JAXB to generate a binding for ISO19139, is it still desired to use JAXB for situations where we *can* use it, instead of using JiBX ?
Generated classes representing the OGC schemas are available, after all (see http://confluence.highsource.org/display/OGCS/Reference).
So the new question is: do we like to replace DM/JDOM code with these ?
- DB / Mckoi to H2 or HSQL or derby ? See #475
Search and Lucene index
- Merge LQB and lucene XSLTs
- Add any search criteria
- Search param is one value or an array value
- Thread for indexing ?
- IndexWriter alert IndexReader about status
- Merge LQB and lucene XSLTs
[heikki] Don't think this is necessary in Geonetwork code; code should already use only 1 IndexReader that should re-open itself only when necessary.
- Return JSON
- Using only stored field from the index
- StandardAnalyzer & GeoNetworkAnalyzer :
- Removed character like (';,)} at the end/start of tokens
- Chinese was not tokenized by GeoNetworkAnalyzer
- StandardAnalyzer? keep accent, do not keep negative number, split dates after hour
[heikki] Improvements to GeoNetworkAnalyzer so it has all the goodies of StandardAnalyzer, e.g. does tokenize Chinese and does not keep brackets and commas at the end of tokens, without breaking wildcard search and has added accented-character-abstraction, see http://trac.osgeo.org/geonetwork/ticket/476
- SettingManager (lock, default value),
- root/gui/localized - only current session language ? - faster XSL
- DB queries
- Maven : version settings