[geotk] NullPointerException with WFSFeatureStore

[johann sorel]

That's right, FeatureCollection is not defined in Geoapi, it is defined 
in GeotoolKit only.

On 10/12/2014 14:57, Emmanuel Blondel wrote:
> Thanks, but you confirm that they are only convenient methods, and 
> that there is no more "Featurecollection" (or similar) interface at 
> GeoAPI level, right?
>
> 2014-12-10 13:33 GMT+01:00 johann sorel <johann.sorel at geomatys.com 
> <mailto:johann.sorel at geomatys.com>>:
>
>     When you have a FeatureStore you can use the method createSession().
>
>     The Session object has many more convenient methods including
>     FeatureCollections.
>
>     Johann Sorel
>
>
>
>     On 10/12/2014 13:27, Emmanuel Blondel wrote:
>>     Thanks Martin , it would be great yes. Let me know if something
>>     new appears in snapshot, i will further test with a geoserver WFS
>>     instance.
>>
>>     Related to the use of WFS geotk client, i would have a question
>>     about the way how data can be retrieved:
>>     - I see there is a FeatureReader, that acts as iterator if i'm
>>     not wrong.
>>     - However, nothing to get a feature collection object; looking to
>>     GeoAPI in parallel, i've realized that the GeoAPI is not handling
>>     anymore a FeatureCollection interface, which was available in
>>     previous (old) versions of GeoAPI. Apparently i'm very late :-/ !.
>>     I thought we had in GeoAPI a single interface for representing
>>     the data retrieved for a WFS featureType (what we are actually
>>     looking for in our project), but it seems it belongs to the past,
>>     and the highest representation is the Feature.
>>     Do you confirm that?
>>
>>     Thanks again
>>     Emmanuel
>>
>>     Le 10/12/2014 09:11, Martin Desruisseaux a écrit :
>>>     Le 10/12/14 17:05,emmanuel.blondel1 at gmail.com  <mailto:emmanuel.blondel1 at gmail.com>  a écrit :
>>>>     Ok for a snapshot, i will argue here on the fact we should use first a snapshot until M3 is available, it shouldn't be a problem.
>>>     Thanks
>>>
>>>>     Some questions:
>>>>     - Is it reasonable to make this timeout hardcoded in geotk? Isn't there a way to specify this timeout threshold as client param..?
>>>     Yes it should be a parameter. I'm not familiar with the way
>>>     WFSFeatureStore uses optional parameters. If I find an obvious place
>>>     where to put it, I will do. Otherwise a static constant and a "TODO"
>>>     note gives an opportunity to revisit this question by someone more
>>>     familiar. There is a danger that a "TODO" note is forgot for a long
>>>     time, but it should be no longer than until the code is ported to SIS
>>>     (since we try to resolve pending issue in this process).
>>>
>>>>     - if it is only a time 'warning', ie not an exception, why should i have a null getcapabilities? I would expect a result anyway.
>>>     I agree, this is why I proposed alternatives in my previous email. I
>>>     would prefer an exception to be thrown, and Johann seems to agree. Would
>>>     it be okay for you?
>>>
>>>>       - in case it's'considered as failure, i should have a timeout exception (but it supposes that i can specify the timeout, otherwise it would be very restrictive and will not work for large GetCapabilities docs)
>>>     Yes I agree for the TimeoutException. I will try to find a place for the
>>>     timeout parameter.
>>>
>>>          Martin
>>>
>>
>>
>>
>>     _______________________________________________
>>     Geotoolkit mailing list
>>     Geotoolkit at lists.osgeo.org  <mailto:Geotoolkit at lists.osgeo.org>
>>     http://lists.osgeo.org/mailman/listinfo/geotoolkit
>
>
>     _______________________________________________
>     Geotoolkit mailing list
>     Geotoolkit at lists.osgeo.org <mailto:Geotoolkit at lists.osgeo.org>
>     http://lists.osgeo.org/mailman/listinfo/geotoolkit
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geotoolkit/attachments/20141210/2551937e/attachment.html>