Re: [JPP-Devel] question about getUltimateWrappee()
This code has always been wrapped in a mystery to me.
Larry
On Wed, Sep 8, 2010 at 6:57 PM, Stefan Steiniger sst...@geo.uzh.ch wrote:
me neither
I think you need to ask Jon Aquino or Martin Davis about this ;)
stefan
Michaël Michaud wrote:
Hi Kevin,
The FeatureCollectionWrapper.getUltimateWrappee() looks like this:
public FeatureCollection getUltimateWrappee() {
FeatureCollection currentWrappee = fc;
while (currentWrappee instanceof FeatureCollectionWrapper) {
currentWrappee = ((FeatureCollectionWrapper) currentWrappee).fc;
}
return currentWrappee;
}
Is there a reason line 66 references .fc directly instead of
.getWrappee() ?
I have no idea. Did you try to find calls to this method in the whole
source tree ?
Maybe also worthwhile to check in WFS plugin or other plugins which
could use caching if this method is called.
Michaël
For me this currently returns the wrong answer. In the case of a
CachingFeatureCollection, there are actually two FeatureCollections: the
actual wrapped FC and a cached FC (a potentially small subset of the
wrapped FC). So, in this case, .fc references the cached FC, which is
not the FC I'm actually after.
I've overridden CachingFeatureCollection.getWrappee() in a custom
variant to return the actual wrapped FC, which in my case is a custom
DataStoreFeatureCollection that mimics a database table, not the cached
FC subset.
-- Kevin
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] question about getUltimateWrappee()
me neither
I think you need to ask Jon Aquino or Martin Davis about this ;)
stefan
Michaël Michaud wrote:
Hi Kevin,
The FeatureCollectionWrapper.getUltimateWrappee() looks like this:
public FeatureCollection getUltimateWrappee() {
FeatureCollection currentWrappee = fc;
while (currentWrappee instanceof FeatureCollectionWrapper) {
currentWrappee = ((FeatureCollectionWrapper) currentWrappee).fc;
}
return currentWrappee;
}
Is there a reason line 66 references .fc directly instead of .getWrappee() ?
I have no idea. Did you try to find calls to this method in the whole
source tree ?
Maybe also worthwhile to check in WFS plugin or other plugins which
could use caching if this method is called.
Michaël
For me this currently returns the wrong answer. In the case of a
CachingFeatureCollection, there are actually two FeatureCollections: the
actual wrapped FC and a cached FC (a potentially small subset of the
wrapped FC). So, in this case, .fc references the cached FC, which is
not the FC I'm actually after.
I've overridden CachingFeatureCollection.getWrappee() in a custom
variant to return the actual wrapped FC, which in my case is a custom
DataStoreFeatureCollection that mimics a database table, not the cached
FC subset.
-- Kevin
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] question about getUltimateWrappee()
Hi Kevin,
The FeatureCollectionWrapper.getUltimateWrappee() looks like this:
public FeatureCollection getUltimateWrappee() {
FeatureCollection currentWrappee = fc;
while (currentWrappee instanceof FeatureCollectionWrapper) {
currentWrappee = ((FeatureCollectionWrapper) currentWrappee).fc;
}
return currentWrappee;
}
Is there a reason line 66 references .fc directly instead of .getWrappee() ?
I have no idea. Did you try to find calls to this method in the whole
source tree ?
Maybe also worthwhile to check in WFS plugin or other plugins which
could use caching if this method is called.
Michaël
For me this currently returns the wrong answer. In the case of a
CachingFeatureCollection, there are actually two FeatureCollections: the
actual wrapped FC and a cached FC (a potentially small subset of the
wrapped FC). So, in this case, .fc references the cached FC, which is
not the FC I'm actually after.
I've overridden CachingFeatureCollection.getWrappee() in a custom
variant to return the actual wrapped FC, which in my case is a custom
DataStoreFeatureCollection that mimics a database table, not the cached
FC subset.
-- Kevin
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] question about getUltimateWrappee()
The FeatureCollectionWrapper.getUltimateWrappee() looks like this:
public FeatureCollection getUltimateWrappee() {
FeatureCollection currentWrappee = fc;
while (currentWrappee instanceof FeatureCollectionWrapper) {
currentWrappee = ((FeatureCollectionWrapper) currentWrappee).fc;
}
return currentWrappee;
}
http://jump-pilot.svn.sourceforge.net/viewvc/jump-pilot/core/trunk/src/com/vividsolutions/jump/feature/FeatureCollectionWrapper.java?revision=859view=markup#l66
Is there a reason line 66 references .fc directly instead of .getWrappee() ?
For me this currently returns the wrong answer. In the case of a
CachingFeatureCollection, there are actually two FeatureCollections: the
actual wrapped FC and a cached FC (a potentially small subset of the
wrapped FC). So, in this case, .fc references the cached FC, which is
not the FC I'm actually after.
I've overridden CachingFeatureCollection.getWrappee() in a custom
variant to return the actual wrapped FC, which in my case is a custom
DataStoreFeatureCollection that mimics a database table, not the cached
FC subset.
-- Kevin
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
