Justin Deoliveira ha scritto: > Hi Andrea, > > I recently ran into some of the same concerns with the new catalog > implementation. As you know there is currently no real DTO layer, which > means that changes made via the UI or wherever else are instantly made > live. Now.. this if course has issues with synchronization, beign able > to revert changes, etc... etc.. > > So to solve this I used a dynamic proxy, not quite the same as but > similar to the wrapper idea.
Yeah, I was tempted by this approach as well, that would have spared me quite some pure forwarding delegation calls... but at the same time it would have made the decorated calls handling a a bit cumbersome, since I have no generic rule for decoration. See for example: http://svn.codehaus.org/geoserver/trunk/geoserver/main/src/main/java/org/geoserver/security/decorators/ReadOnlyDataStore.java http://svn.codehaus.org/geoserver/trunk/geoserver/main/src/main/java/org/geoserver/security/decorators/DecoratingDataStore.java It would be nice to be able and just say class DecoratingDataStore extends MySmartProxy<DataStore> implements DataStore { public DecoratingDataStore(DataStore delegate) { super(delegate); } } and then leave ReadOnlyDataStore as is, but I don't see how this can be implemented using the java dynamic proxies. > However I too ran into the question of how > to deal with equals and hashcode. And the answer was to have the objects > being proxied to define equality based on interface, not on implementation. I lost you there. I looked into the ModificationProxy class: http://svn.codehaus.org/geoserver/trunk/geoserver/main/src/main/java/org/geoserver/catalog/impl/ModificationProxy.java and found it has no overrides for equals/hashcode, so the contract defined by the java Proxy class applies: "An invocation of the hashCode, equals, or toString methods declared in java.lang.Object on a proxy instance will be encoded and dispatched to the invocation handler's invoke method in the same manner as interface method invocations are encoded and dispatched, as described above. The declaring class of the Method object passed to invoke will be java.lang.Object. Other public methods of a proxy instance inherited from java.lang.Object are not overridden by a proxy class, so invocations of those methods behave like they do for instances of java.lang.Object. " Looked into the implementations of objects being proxies, and it seems equals and hashcode have been generated by Eclipse. For example: http://svn.codehaus.org/geoserver/trunk/geoserver/main/src/main/java/org/geoserver/catalog/impl/StyleInfoImpl.java Ah, but in the equals method you cast to StyleInfo, not to StyleInfoImpl, that's what you mean by interface based equality, right? > So perhaps the two ideas line up? Not sure, just wanted to give my 2c. Yes, I mean, they forcefully line up as long as the catalog objects are concerned, since the equality used is the same, they do not when it comes to the gt2 objects I wrapped (FeatureSource, FeatureCollection, DataStore) because there the equality concept is not the same. Anyways, I got enough information to: * define a Wrapper interface that mimics the java.sql.Wrapper one, which could be used by ModificationProxy too, since the unwrap method is bit by bit compatible * define a generic decorator superclass that implements Wrapper and consistently delegates equals and hascode to the wrapped object * unfortunately, unless someone has a bright idea, keep the DecoratingXXX objects around as they are (but extending the generic decorator class) Cheers Andrea ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
