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. 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. So perhaps the two ideas line up? Not sure, just wanted to give my 2c. -Justin Andrea Aime wrote: > Hi, > in the security implementation work I have to create a ton of wrappers. > These classes are needed in order to make the current user do only > what he's supposed to do, that is, if the current user can only read > a feature type, the wrappers make sure the service really see a read > only object, be it a FeatureTypeInfo, a FeatureSource, DataStore, > FeatureCollection and whatnot (man, too many ways to get a write > enabled object!). > > On the outbound this works fine, but it might happen some of these > object to come back and be used to query, before passing them > to the actual catalog, unwrapping is needed (since the catalog is > working on object identity comparisons, we have no real "keys" > around). > > The java.sql.Wrapper interface is an inspiration, but there are > a couple of gotchas: > (http://java.sun.com/javase/6/docs/api/java/sql/Wrapper.html) > * it is in the wrong package (what I'm doing has nothing to do > with sql) > * it is in the wrong JDK (1.6 onwards) > > What about implementing it in GeoTools instead? We could benefit > from using it in the many wrappers we have around (it would > make it possible to walk them for example). > > The Wrapper javadoc is also lacking about best practices on > how to implement the wrappers: > * what about equality, when are two wrappers equal? When > they have the same delegate? Or when unwrap(targetClass) > returns the same object (deep or shallow equality?) > * what about hashcodes, shall we use the one of the delegate > or create a new one? > > Also wrapper creation is not trivial when two objects > candidate for wrapping point one to the other, like > FeatureSource and DataStore. By using just constructors > to create the wrappers, new wrappers can be created each > time a certain object, say a DataStore, is required, and > that _might_ break some code. > Should we use a factory and a canonicalizer (a weak > hash map using the delegate as the key) to avoid that? > Or I'm just thinking too much? ;) (probably so!). > > 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 > > !DSPAM:4007,4847fa2b39291096210785! > -- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
