Hi,
As all of you who carefully read commit-messages may have seen (:-),
yesterday I committed the ability to call
Conversation.bind(instance)
so that later calls to any method on that instance will run within the
context of the specified conversation (including its associated
persistence context if any) [1].
This is useful functionality and I don't think anyone will object. There
is one question about the actual implementation, though, that I thought
people might have an opinion on.
The current approach adds interface ConversationBinder, and a setter
method has been added to the Conversation class. Each
dependency-injection-specific layer then provides a different
implementation of this (eg SpringConversationBinder) when creating
Conversation instances.
An alternative would be for each dependency-framework to instead return
a subclass of Conversation, then the binder interface would not be
needed. This approach would potentially be more extensible in future
(any future new features requiring tight couplings between conversation
and dependency-injection-framework can just be added transparently
without new interfaces) but would make the Conversation class a little
harder to understand IMO.
Both seem reasonable to me; anyone got arguments about preferring one
over the other? Or any other issues about those patches in general?
[1] Mario came up with this idea, and did an initial prototype.
Regards,
Smion
