Hi Gabriel; I am continuing to test FeatureEvents using ArcSDE as a guide post. You can see ArcSDEFeatureStore.testFeatureEventsAndTransactionIndependence to see where we are at.
It is proving hard to provide a FeatureStore as the "source" of the FeatureEvent; as such I am letting the feature writer (or whatever) act as the source; and the existing FeatureEvent.getFeatureSource() method will return the feature source that the listener registered with (ie the one used by FeatureSource.addFeatureListener). The events are now broadcasting a Filter; that in the case of add / update / remove contains an Id filter indicating the modifed feature(s). The next step is to break out a BatchEvent for the duration of a transaction that can be used to hold this info in order to get a good commit event. We are starting to get a growing number of "stuff" associated with a "typeName" + Transaction; I may end up making a single Transaction.State "Context" rather rather than having three our for Transaction.State entries floating around. All the best and enjoyed the weekend. Jody ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
