On Mon, Dec 22, 2008 at 2:50 PM, Jordan Zimmerman <[email protected]> wrote: > I've been using Java Shindig for a few weeks now and there are some > things I'd like to see changed. > > * J2EE vs Plain Java * > The major change should be a refactoring to make Shindig a code library > as opposed to an application. Shindig makes deep assumptions about the > environment it is running in. In particular, it assumes a J2EE compliant > container. It then runs in that container as a standalone application. > Developers must plug in to the Shindig application. I suggest a > refactoring into two libraries: Shindig J2EE and a Shindig Engine. I > don't see why Shindig has to be released as a set of servlets. For > example, ProxyServlet is a thin wrapper around ProxyHandler. So, the > engine is actually already there.
I think, as you say, that this is already present to a large extent. It's just not explicitly called out, or architecturally enforced. In general, the gadgets code is already in this shape, and does not make such "deep assumptions about the environment". This isn't nearly as true for the social-api code, which puts non-trivial logic in Servlet implementations. +1 for resolving that. > > * Dependency Injection is awful * > DI is an implementation detail that should be left to users of Shindig. > Shindig's use of Guice serves to obfuscate the internals of Shindig > without a lot of benefit that I can see. I've been able to get Shindig > up and running without using any of the DI. If I can do that, then it > seems unnecessary. Leave this in the J2EE layer (which should be a > separate library as I said above). I strongly agree that you should be able to build Shindig objects without using DI - the few cases where this isn't so (the use of static injection into HttpResponse) are known hacks that go against good Guice design, and interferes with testability. On the other hand, I'd be strongly against removing the use of @Inject, etc., in Shindig, and couldn't disagree more with the face value of a statement like "Dependency Injection is awful". Forcing developers to manually hook up objects is awful. Hard-coded dependencies in a large code base is incredibly awful. Dependency injection has a learning curve. > * Documentation is not hard to write * > I can't understand why there isn't minimal documentation. Take a few > hours and document the main classes, how they work together and how an > implementer might use them. Further, there are lots of hard coded values > in the JS files (e.g. %js%) that aren't documented anywhere that I can > see. > > It's wonderful that Shindig exists. But, so far, it's been very > frustrating trying to get it to work in my environment. My comments > above are a few of the reasons why it's so frustrating. > > > Jordan Zimmerman > Principal Software Architect > 831.647.4712 > 831.214.2990 (cell) > [email protected] > > SHOP*COMTM > All your favorite stores. > OneCart(r) convenience. > www.shop.com > > This message (including any attachments) is intended only for > the use of the individual or entity to which it is addressed and > may contain information that is non-public, proprietary, > privileged, confidential, and exempt from disclosure under > applicable law or may constitute as attorney work product. > If you are not the intended recipient, you are hereby notified > that any use, dissemination, distribution, or copying of this > communication is strictly prohibited. If you have received this > communication in error, notify us immediately by telephone and > (i) destroy this message if a facsimile or (ii) delete this > message > immediately if this is an electronic communication. FWIW: this is not an especially welcoming signature on messages to an Apache mailing list. -- Adam Winer > Thank you. >
