> > I have a large Java desktop application and I want 3rd party developers to > be able to create plugins for it. And I am exploring whether Guice might > help with the API. > I expect 3rd party developers to create plugins as jars and deploy them > into a specified dir. > At runtime I plan to pick up plugin classes using annotations (much like > EJBs in an EE container). I am investigating whether Guice will be suitable > for injecting important components into the plugins. > > A plugin annotation that decorates a plugin class: >
> I've just thrown this together to see if I can do what I envisage. But the > injection of ImportantClass is not occuring into the instance of > MyImportantClassUser. > Is that because I have not instantiated MyImportantClassUser via the > injector? > Yup. The good news is, you can just make MyImportantClassUser a constructor parameter, and instantiate it all with Guice. One of the things Guice is really good for is eliminating special initialization phases and methods of things - which is generally as a good thing. Think of a constructor as an instance method that the language guarantees may only be called once per instance (that's what it really is) - if you have initialization that should happen before anything sees your object, and you want to guarantee it cannot be initialized twice, then a constructor is the natural place to do it. > I don't want my users (3rd party developers) to have to instantiate every > class via the injector. So is there a way to globally inject things in this > manner? Am I misunderstanding or trying to abuse the purpose of Guice? A little. There are quite a few injection frameworks more geared around desktop applications, which might save you some coding and trouble - I'd recommend http://platform.netbeans.org as a possible starting point, but I'm biased since I wrote some of it :-) GUI apps tend to want more just-in-time binding of things, to accomplish lazy initialization and improve startup performance; so, the service locator pattern is often more appropriate there (say you have a class that in some exceptional circumstance may want to show an error dialog - you probably don't *really* want one instantiated every time and passed to your constructor just in case). At the least, I wouldn't want to do that classpath scanning stuff while a user is staring at a splash-screen. If you want to create a simple plugin registration mechanism, you can write an annotation processor that writes a flat file of whatever form you like, which gets bundled into the JAR, at compile time. Then just find and read all such files on the classpath, and load up and initialize whatever was recorded there. That way, you get your dynamic plugin discovery, but you just read a few flat files on startup, rather than load and scan the entire universe, which is much more suited to server-side apps. If writing an annotation processor sounds hard, here's a starting point: http://bit.ly/RJQ1L7 and http://bit.ly/NveK2Z -Tim -- You received this message because you are subscribed to the Google Groups "google-guice" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-guice/-/QsjD5ZWj0bYJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
