Talking about real applications helps a lot: The simplest example of handling a connection life cycle is inside the scope of a web request.
In that scenario you will need a @RequestScoped provider and a normal web filter: The provider's is used mostly as a "holder" for the later-to-be-opened connection, but can do useful work as well like initializing / starting / collecting the connection from a pool. Then, injected with the provider, I use the filter to close the connection at the end of the scope (request). It can also start it, if you prefer to have all the life cycle code in one place. Throughout your code you inject the provider and call get() to obtain an open connection where you need it (Like Mr. Kumar wrote earlier). The only downside of this is that you need to make sure your filter is the last (and therefor the first also) to handle requests that require an open connection, but this is not really a big downside IMO. To me, this example illustrate something important: Guice is used for what it was meant for, which is DI and the rest of the solution to the problem is provided by tools that rely on DI but are better suited to handle the life cycle task in its "real app" context, the web filter in our case. I would also like to refer you to this thread: http://code.google.com/p/google-guice/issues/detail?id=62 Which has a very interesting discussion about Guice and Life cycle. Additionally, you can take a look on a project called RoboGuice<http://code.google.com/p/roboguice/>(Guice 4 Android) and how they implemented injection of UI Instances (@InjectView) And finally you can see a real example of the connection in request scope scenario here: http://blog.yanivkessler.com/2010/06/lightweight-jdo-persistence-filter.html Hope this helps Yaniv Kessler On Mon, Jul 5, 2010 at 1:27 AM, Jason Winnebeck <[email protected]> wrote: > Well I didn't want to focus too much on DataSource specifically, but if a > pooling data source (like apache-commons dbcp) has a close method, because > after you get/close a connection it stays open in the pool. Of course for > apache-commons dbcp specifically you can start up an idle reaper (I assume > it starts a thread) that will eventually close those connections, but it > would be nice if you were done with that stage of the program if you could > close it certainly. And there are other resources out there that aren't so > "automatic"... Would one ever use Guice to inject things like Swing frames? > I suppose yes if the goal is to eliminate "new" entirely. So a swing frame > has to be disposed. > > Maybe I should just try it in a real app and maybe it's not a problem. In a > Swing app you can dispose on close... with an "FTP resource" someone is > going to "get" it and then "close" it... for things like pooling JDBC > sources they have features to automatically clean up. I can't think of a > good example of a shared resource like DataSource that doesn't implicitly > clean itself up. > > I've been realizing to start up a "subtask" I don't really need a child > injector. If I have a class like FtpUploader and it takes FtpConnection > which takes a Socket or something, if I ask for an FtpUploader Guice will > instantiate a new FtpConnection and Socket for it. And whatever uses the > FtpUploader will eventually cause it to close the connection, so it will be > cleaned up in the end. And of course I can create as many FtpUploader as I > want. I just don't know immediately how I would parametrize that (I would > want FtpUploader for site.example.com because the user typed that in), > without creating a new injector though. I'll have to figure that out. Maybe > the intention is that construction doesn't take the parameters but I have > set/connect methods instead. > > Jason > > > On 7/4/2010 3:32 PM, Kartik Kumar wrote: > >> You only have to shut down a connection generated from DataSource. You >> can inject a DataSource binding into a Provider<Connection> >> implementation and implement get() method to return a Connection to be >> injected. >> > > -- > You received this message because you are subscribed to the Google Groups > "google-guice" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-guice%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-guice?hl=en. > > -- You received this message because you are subscribed to the Google Groups "google-guice" group. 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.
