It is usually hard to manage scopes that aren't dependent on threads.  Non
thread-based scopes usually require a "only one context is active at a
time" mode, and you can just switch between the contexts.  If that applies
to you, then that's doable -- you'll just need some static external state
somewhere that defines that active context and will have to map what
objects are live in that context (using something like a Map<ContextId,
Map<Key, Object>>).

sam


On Tue, Aug 27, 2013 at 5:07 AM, <[email protected]> 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 [email protected].
> To post to this group, send email to [email protected].
> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to