Integrating with Guice

[Josh]

Is there a way to integrate Gson with Guice such that deserialized objects will be instantiated by Guice? This is important since certain objects need to be instrumented, which means Guice needs to construct them. I am aware of InstanceCreator, but it doesn't look like that can be used to construct ALL objects. Any solution?

Thanks,

Josh

[Jesse Wilson]

I don't know what your application looks like, but in general it's a
bad idea for value objects to participate in dependency injection.

In my apps I have value objects that hold data, and service objects
that do stuff:
• Value objects never depend on anything but other value objects. For
example, Customer might depend on String and Address, but never on
Database. In exchange for their limited dependencies, these objects
are trivial to serialize with Gson (or protocol buffers or whatever).
• Service objects are allowed to depend on anything. Typically this
includes network services, and the file system. These dependencies
require these objects to be constructed by a DI framework like Guice.
And they prevent the objects from participating in serialization &
deserialization.

It's possible to have objects that both represent data and have
nontrivial dependencies. But Gson is not designed for this case
(because it doesn't know about dependencies) and neither is Guice
(because it doesn't know about data). If you go this route you're on
your own.

[Josh]

Thanks for the response.

What you say is true, for the most part, but doesn't hold well for the specific category of objects I'm trying to serialize and deserialize at the moment, basically, persistent message driven workflows. A good example is NServiceBus's sagas:

http://www.nservicebus.com/Sagas.aspx

NServiceBus actually separates the state of the saga (saga data) from the saga implementation, but I believe the reason for that is to ease object relational mapping of the saga data, which I'm not interested in. I just want to serialize the thing to JSON. This works fine as long as your service related dependencies are transient. Though I'm open to splitting the saga data out to a separate class, it seems like an extra hoop to make our users jump through as things have worked fine as they are so far.

As for re-hydrating a saga, you can either let gson create the object and inject any remaining members with Guice, or in my cause, what I'd like to do is construct the object with Guice (so that it can be instrumented) and populate state data via Gson. It looks like this would only work if Gson supported a global InstanceCreator, or an InstanceCreator that created instances assignable from some registered type (such as Object.class).

Anyways, given the specific use case I'm working with here, any change in thought?

Cheers,

Josh

[Josh]

One more thought:

I don't think it's fair to say that only value objects should be populatable by Gson. Entities certainly could be serialized to Gson and possibly require additional dependencies be injected.

Cheers,

Josh

[Josh]

One more comment (sorry) :)

Keeping the state and behavior that operates on that state in one object makes sense since neither the state or the behavior in this case is useful without the other. We'd be doing it just to satisfy some technical hurdle related to persistence or serialization.

Cheers,

Josh