My first thought is to talk to the app schema module maintainer ... but
Rini is away. Victor and Lingbo have both been in recent communication
about build failures and may be in position to help.
My second thought is to ask for a bug report :)
A couple of random ideas:
- Fixing DuplicateFilterVisitor will not help (it is doing the right thing
PropertyName is just a data structure and should not be subclassed).
- It looks like NestedAttributeExpression is an optimization (parsing the
PropertyName into a data structure, and possibly returning a list of values
if the XPath selects more than one value). We actually have an API for this
called PropertyAccessor - so I would ask the App Schema team to fix this
(and match the geotools design). TLDR: Move the NestedAttributeExpression
functionality to a PropertyAccessor.
- If you want to try an evil workaround override the
NestedAttributeExpression accepts method to "do the right thing" when it
accepts a DuplicatingFilterVisitor.
Aside: Your evil workaround of visiting NestedAttributeExpression does not
work for two technical reasons:
- NestedAttributeExpression is declared "downstream" so
DuplicatingFilterVisitor cannot depend on app-schema and see that class
- Java dispatch for FilterVisitor occurs at the interface level, and will
match visit( PropertyName, Object )
--
Jody Garnett
On 9 January 2015 at 12:01, Torben Barsballe <tbarsba...@boundlessgeo.com>
wrote:
> I have managed to track down the cause of the error. Our
> propertyNameResolving visitor (extending DuplicatingFilterVisitor) from
> ContentFeatureSource.resolveProperty names ends up converting the
> NestedAttributeExpression in our filter to an AttributeExpressionImpl by
> way of the FilterFactoryImpl.property call - see DuplicatingFilterVisitor,
> line 362:
>
> return getFactory(extraData).property(expression.getPropertyName(),
> expression.getNamespaceContext());
>
> And FilterFactoryImpl.property():
>
> public PropertyName property( String name, NamespaceSupport
> namespaceContext ) {
> if (namespaceContext == null) {
> return property(name);
> }
> return new AttributeExpressionImpl(name, namespaceContext );
> }
>
> This seems to be an error with DuplicatingFilterVisitor, which appears to
> turn any PropertyName expression into an AttributeExpressionImpl,
> regardless of the origional implementation.
>
> The only fix I can think of is adding an additional
> visit(NestedAttributeExpression expression, Object extraData) method to
> DuplicatingFilterVisitor, and a nestedProperty( String name,
> NamespaceSupport namespaceContext ) method to FilterFactoryImpl
>
> Thoughts?
>
> Torben
>
> On Thu, Jan 8, 2015 at 8:44 PM, Jody Garnett <jody.garn...@gmail.com>
> wrote:
>
>> Hi Torben:
>>
>> Ben was our usual contact for app schema stuff. Perhaps we can step
>> through the same test with the original property datastore implementation
>> and see how it was working (I won't claim to know how it was supposed to
>> work).
>>
>> Jody
>>
>> --
>> Jody Garnett
>>
>> On 8 January 2015 at 15:51, Torben Barsballe <tbarsba...@boundlessgeo.com
>> > wrote:
>>
>>> While migrating the new property-ng implementation to be used by
>>> geotools, I ran into a new test failure in gt-app-schema
>>>
>>> On line 133
>>> <https://github.com/geotools/geotools/blob/master/modules/extension/app-schema/app-schema/src/test/java/org/geotools/data/complex/PolymorphicChainingTest.java#L113>
>>> of PolymorphicChainingTest, the test fails. I have tracked the issue down
>>> to the artifactSource mapping, which only contains the
>>> PropertyFeatureSource corresponding to the Artifact featuteType, so that
>>> when it goes to read through the FeatureSource, it only finds Artifact
>>> features, not the StringAttribute it is looking for. This appears to occur
>>> because the artifactSource is passed in the Artifact feature type when it
>>> is created.
>>>
>>> I am curious how this test was supposed to work? I assume it was
>>> intended to get all of the features, not just the one type?
>>>
>>> I have verified that all the expected feature source mappings (Artifact,
>>> GeoAttribute, StringAttribute, NumberAttribute) are contained in the
>>> AppSchemaDataAccess class at runtime.
>>>
>>> Torben Barsballe
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Dive into the World of Parallel Programming! The Go Parallel Website,
>>> sponsored by Intel and developed in partnership with Slashdot Media, is
>>> your
>>> hub for all things parallel software development, from weekly thought
>>> leadership blogs to news, videos, case studies, tutorials and more. Take
>>> a
>>> look and join the conversation now. http://goparallel.sourceforge.net
>>> _______________________________________________
>>> GeoTools-Devel mailing list
>>> GeoTools-Devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>>>
>>
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
