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.