Fred Many thanks, that is really helpful - what you describe is not a case we have had yet ... but I am sure we will.
On Sep 4, 4:09 pm, Fred Faber <[email protected]> wrote: > David, > > I agree a FAQ would be useful. I'll need to queue it up as a TODO after the > long weekend. > > As a brief summary, static injection implies static state, which generally > complicates component / functional testing. This is especially true when > more than one instance of a class needs to reference the same static state, > but with a different value thereof. If the static state is effectively a > stateless block of logic, then this is not so much of an issue. > > Consider a quick example: > > class RpcClientThatIsInjectedStatically { > @Inject static ServerAddress serverAddress; > > @Inject RpcClientThatIsInjectedStatically(...) { } > > RpcResponse makeRpcRequest(RpcRequest rpcRequest) { > RpcStub rpcStub = getStubForServer(serverAddress); > ... > return rpcStub.call(rpcRequest); > } > > } > > If I have two instances of this class in the same process, then I can't have > more than one ServerAddress. Naturally I might have several instances of > this class in a real application. > > Even if you expect only one instance of such a class in an application, you > might want to create an in-process integration test with two different > applications running in the same process. You're then faced with the issue > of not being able to distinguish the ServerAddress used in one application > from the ServerAddress used in the other. > > This problem also manifests itself at a simpler level, which is running > tests in the same process. If you set static state on a class in one test > and don't tear it down appropriately, then you might break other tests in a > nonobvious way. Yes, it's ideal to think that all tests clean up after > themselves nicely, but we know in practice what really happens. Also, > you're now precluded from running tests in parallel within the same process, > insofar as the static state is referenced from two different tests running > concurrently. > > Fred > > On Wed, Aug 31, 2011 at 1:17 PM, David Sowerby > <[email protected]>wrote: > > > > > > > > > Fred > > > Thanks for the thoughtful response. > > > First, could I suggest an FAQ on this subject? Static injection is > > documented, but not in the context of serialisation as I recall - and > > I don't remember seeing anything on the options you have put forward > > here. > > > Your answer made me think - what really are my objections to static > > injection, as it seems to work? The testing has been limited, but > > serialization / de-serialization returns correctly set up objects. > > > Ok, I lose the ability to make the member final - and it is static. > > That is not ideal, but now I really think about it I am trying to work > > out why it seemed so bad! (As opposed to spending time putting in > > place one of your suggested alternatives) > > > I can unit test well enough, and the integration testing we have done > > so far (not a great deal admittedly) with static injection (using > > Mycila) has caused no problems. > > > So at the moment, I am of the opinion that I should have thought about > > it more before posting the question - and leave it as static > > injection, unless I find it causes other issues somewhere. > > Thanks again for the response. > > > On Aug 25, 6:30 pm, Fred Faber <[email protected]> wrote: > > > The best solution will depend on how you can hook the serialization code. > > > > If you can hook the objects that you want serialized by adding a > > > writeReplace() method, then you can use a serializable > > > proxy< > >http://books.google.com/books?id=ka2VUBqHiWkC&lpg=PP1&pg=PA312#v=onep.. > > .>to > > > ship each over the wire. The proxy would contain the Key > > > corresponding > > > to the binding of the object. The trick here is establishing the reverse > > > mapping from { object => key }, but it's possible through use of either > > the > > > provision API or plain java code (I've done the latter myself). > > > > The proxy would have a readResolve() method that can find a handle to the > > > injector on the JVM (several options exist for how to do this), and then > > it > > > would return "injector.getInstance(key)." This solution would allow you > > to > > > have non-serializable types as "private final transient" instance vars on > > a > > > serializable object. Looks strange, but it's possible. > > > > As another solution, if you could only hook the deserialization code, you > > > could then declare the non-serializable types as non-final and use member > > > injection when types are deserialized (via > > > "injector.injectMembers(deserializedObject)"). > > > > We could also brainstorm different ways if you provide specific problem > > > constraints. > > > > Fred > > > > On Wed, Aug 24, 2011 at 5:56 PM, David Sowerby <[email protected] > > >wrote: > > > > > I probably should have been a bit clearer - static injection clearly > > > > works (except when I get it wrong!), but I am curious whether this > > > > approach is still the recommended "best practice" as a way of handling > > > > non-serializable objects. It does seem to negate some of the > > > > advantages of Guice. > > > > > On Aug 24, 6:29 pm, David Sowerby <[email protected]> wrote: > > > > > I have read the post athttp:// > > > > groups.google.com/group/google-guice/browse_thread/thread/4799... > > > > > but I am still confused by this issue (and it may have changed since > > > > > then, it was 4 years ago) > > > > > > The problem is the same - serialising session state in a web app > > which > > > > > has injections of Injector and of Providers - neither of which are > > > > > serializable. > > > > > > In the previous thread, Bob Lee says this is why he introduced static > > > > > injection - but I must be missing something, as I cannot get it to > > > > > work. If that is the answer, or for that matter whatever the answer, > > > > > could someone post a simple example? > > > > > -- > > > > 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. > > > -- > > 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. -- 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.
