While porting restconfig to trunk I ran into this issue:
http://jira.codehaus.org/browse/GEOS-3290
Now a simple guard for null fixes the issue, but... i was curious as to
why this was a problem on trunk and not 1.7.x. The reason is because for
this case GeoServerFeatureSource never gets called on 1.7.x.
The reason a GSFS is created to wrap the original FS on trunk is the
attribute list of the FeatureTypeInfo object. If the attribute list
return is empty or null the original FS is returned, otherwise it is
wrapped.
Andrea has brought this issue up a few times now and we never seem to
get anywhere on it because I keep on insisting that
FeatureTypeInfo.getAttributes() is a regular collection based property.
However I have now realized that it is not. It is a derived property
which is defined as:
* If the user provided a schema.xsd file (or mucked with the attribute
list via the ui in future versions) then that list of attributes should
be returned
* otherwise, the attributes from the underlying feature type should be used
Andrea and I discussed this in IRC the other day and came up with the
following:
FeatureType.getAttributes() should go to:
FeatureType.attributes() throws IOException;
The IOException because it has to do IO to potentially load the
underlying feature type to get the list of attributes. So what would the
implementation of attributes() look like:
List<AttributeInfo> attributes() {
attributes = catalog.getResourcePool().getAttributes( this ):
}
(And yes, I know this follows the anti-pattern that Andrea illustrated
before) but this is how FeatureTypeInfo gets its feature type and
feature source so I am following suit.
In ResourcePool the attribute list would possibly be cached. I say
possibly because caching them has a potential drawback in that it will
not be sensitive to changes in the underlying feature type schema.
However I think this is a core issue that we are already susceptible to
because we cache feature types.
Regardless of caching or not caching
ResourcePool.getAttributes(FeatureTypeInfo) would load the feature type,
grab the raw attributes, check them against any schema.xsd file to
modify them or trim them down, and then return the list.
Thoughts and opinions? If people think this is a good path to go down I
will whip up a patch.
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
