> > 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. Yeah, the case for datastore is a little hard to sell proxies. However for regular java beans its like the classes in the new configuration model its a little bit easier to sell. You can put in some generic logic based on get/set method naming conventions. For instance the code in LayerGroupInfo that thats the collections of layers and wraps them in read only layers. There is code in ModificationProxy that does this exact same thing.
So the short of it is I think we could save some code by using proxies, and break out full blown decorators when need be... like with DataStore. However as you say programming with proxies is a level of indirection as all calls you make are reflective calls. The only thing I fear with the pure decorator approach as that we are following down the same road as with DTO's and the config... where modifying one class does not mean modifying one class. > >> 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? Correct, I meant that the objects themselves, not the proxy implement equals in terms of the interface. > >> 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 > > !DSPAM:4007,4848fa04213634901796417! > -- 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
