The problem here is XStream081Configuration, not ImplementedBy. On Wed, Dec 3, 2008 at 10:08 AM, Henning P. Schmiedehausen < [EMAIL PROTECTED]> wrote:
> So we are integrating Shindig into our own code base. Which is large, > complex and I try to keep a few personal guidelines that go against > the "current industry trends" but 25 years of computer programming > should be good for something. :-) One of them is "everything that > happens automatically is bound to break". Always. > > What we want to do is provide our own implementations of some > opensocial model classes. There is a reason for this, mainly because > we have more fields in compliance with > > http://www.opensocial.org/Technical-Resources/opensocial-spec-v081#TOC-Compliance > using <prefix>.specialField. Which are represented by additional > fields in our objects. > > (Which BTW leads the whole idea of using getter/setter based bean > classes for Shindig ad absurdum. The current model classes clamp down > exactly what is in the spec without allowing the dynamic extension > mechanisms shown there. Using Enums is equally bad, because extending > these leads to necessary Shindig code modifications. But let's not go > there). > > And it breaks. It breaks in a very puzzling way. Because at some > point, the PersonImpl classes started to bleed into our code, even > though our custom GuiceModule contains > > bind(Person.class).to(MyCustomPerson.class); > > The reason for this is the following piece of code in > InterfaceClassMapper. A class that can only be replaced by ripping out > the whole XStream081Configuration class, because it is hard coded in > there. > > --- cut --- > private Class<?> getImplementation(Class<?> clazz) { > // get the guice default implementation on the class. > // we might use the injector to discover this > Class<?> cl = clazz; > ImplementedBy implementedBy = clazz.getAnnotation(ImplementedBy.class); > if (implementedBy != null) { > Class<?> c = implementedBy.value(); > if (log.isDebugEnabled()) { > log.debug("===================Class " + clazz + " is implemented by " > + c); > } > cl = c; > } else { > if (log.isDebugEnabled()) { > log.debug("===================Class " + clazz > + " no implementation, assume concrete "); > } > } > return cl; > } > --- cut --- > > This method *TIES* the @ImplementedBy implementations of the model > interfaces to the interfaces. And you can not override this without > recompiling Shindig. So why use IoC at all? And argueing that this > *helps* implementors to understand how Shindig works is simply > wrong. This is error-prone, difficult to read and understand and the > current code structure makes it *harder* for implementors to > understand where they can and must tweak the code base for integrating > it into their project. > > So I beg to differ to Ian: @ImplementedBy makes the code base harder > to read and understand. Because there is no centralized point of entry > where the parts are tied together. Which was (up until now) my > understanding why people are using IoC containers in the first place. > > Why you have Modules in Guice and config files in Spring. But that is > just me. > > Ciao > Henning > > -- > Henning P. Schmiedehausen - Palo Alto, California, U.S.A. > [EMAIL PROTECTED] "We're Germans and we use Unix. > [EMAIL PROTECTED] That's a combination of two demographic groups > known to have no sense of humour whatsoever." > -- Hanno Mueller, de.comp.os.unix.programming >
