maybe you can try to use Onami Lifecycle Dispose support [1] or Lifecycle Management in Governator [2]
hth, jordi [1] http://onami.apache.org/lifecycle/org.apache.onami.lifecycle.standard/dispose.html [2] https://github.com/Netflix/governator/wiki/Lifecycle-Management On Wed, Sep 4, 2013 at 7:06 PM, <jon.mi...@gmail.com> wrote: > Thanks. Yeah that makes sense, I don't mind adding guice functionality or > utilities if it simplifies the actual end code I write. What I want to > avoid is writing some code then having to write more custom code just to > get it bound properly and reusable. Seems that is what you have achieved > with your child injectors + some generic management of them. > > Think I have some good ideas to play with now, thanks. > > > On Tuesday, September 3, 2013 8:18:04 PM UTC+1, Nate Bauernfeind wrote: > >> In this kind of situation I would try to put my non-reusable code behind >> [well-thought] interfaces as much as possible. Think about all the [known] >> use-cases and really try and separate the common logic from the custom >> logic. If you can hide the state behind a logical interface that has always >> been a huge win in my experiences. >> >> Also keep in mind the scope of the re-usability .. if you expect others >> to use it in non-guice scenarios, try hard to separate the needed Guice >> dependency into a separate maven/project module (basically a Guice >> convenience package). If the re-use is from within a single application, >> then assisted inject factories are the easiest way to go (easier than child >> injectors). >> >> If you choose to create a separate GuiceModule that brings all of the >> components together then be explicit about what things should be externally >> available (i.e. any implementation of your interfaces should be defined in >> a different GuiceModule (parent or sibling of your re-usable component)). >> Consider using interfaces for as many of the internal classes as makes >> sense ... because if someone doesn't like the default implementation then >> they can still easily create an override. >> >> I have previously used child injectors to create large object graphs that >> were configured by a couple of minor fields. I was able to reduce all sorts >> of awkward overhead by doing this. For example, I created a multi-bound >> list of tags that could be injected at any point in the graph to attach the >> tags to any metrics. There was a system that was in charge of constructing >> a new child injector, starting up the Managed classes and for shutting them >> down when they were no longer needed. It may have been what you're calling >> boiler plate, but I was extremely satisfied with the end result. I'm >> actually currently planning on going back to introduce a handful of >> interfaces (which I didn't originally think of doing) with the goal of >> making that part of that application easily plugin-able (which I'm >> anticipating will make it a lot friendlier for open sourcing). >> >> Nate >> >> On Tue, Aug 27, 2013 at 4:07 AM, <jon....@gmail.com> wrote: >> >>> Hi, >>> >>> Guice has had a big impact with the things I code, particular in >>> developing and bringing together a modular system + then the testing that >>> goes with it. >>> >>> However, I am struggling to find a nice way to do reusable components >>> and in part is due to my inexperience with all of this. >>> >>> Examples of reusable components may be tabs in a browser or say in an >>> IDE having drop in components like an n number of editors. >>> >>> So with the editors you have many classes that work together to make it >>> happen and you need to it reusable / many concurrent uses some unique >>> state. And when you close the editor, you may need to invoke the release of >>> services / files they handle. >>> >>> I see three ways: >>> 1. Factory / bioler plate code. >>> 2. Child injectors, still requires a factory + bioler plate for the >>> lifecycle. >>> 3. A custom scope but have to manage the scope + entry/exit >>> >>> I dislike the first option, too much boiler plate. The second seems to >>> work well and is probably the avenue I'm going down at the moment. The 3rd >>> is what I am most confused about, everywhere I read says custom scopes are >>> bad yet the Session and Request scope of servlets seem very handy and given >>> I essentially need to manage state it seems like it is the answer. >>> >>> Any help would be great thanks. >>> >>> Thanks, >>> Jon >>> >>> >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "google-guice" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to google-guice...@**googlegroups.com. >>> To post to this group, send email to google...@googlegroups.com. >>> >>> Visit this group at >>> http://groups.google.com/**group/google-guice<http://groups.google.com/group/google-guice> >>> . >>> For more options, visit >>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>> . >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "google-guice" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-guice+unsubscr...@googlegroups.com. > To post to this group, send email to google-guice@googlegroups.com. > Visit this group at http://groups.google.com/group/google-guice. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "google-guice" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-guice+unsubscr...@googlegroups.com. To post to this group, send email to google-guice@googlegroups.com. Visit this group at http://groups.google.com/group/google-guice. For more options, visit https://groups.google.com/groups/opt_out.
