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.
