Results 1 to 7 of 7

Thread: ConversationContainer protected?

  1. #1

    Default ConversationContainer protected?

    I was looking at doing a custom implementation of the ConversationManager. When I went to implement the methods I discovered that ConversationManager is default protected, so I had to have my class in the same package structure to use it. Just wondering if this was done on purpose or should be opened as a JIRA?

    I am only trying to override the private getConversationContainer method to not save ConversationContainer to the HttpSession.

  2. #2

    Default

    I did a bit more research and I am starting to think my original question probably isn't valid (or doesn't matter to much for what I want to do).

    I really don't want to tie my flow executions to the HttpSession so that they don't expire when the HttpSession expires. So I though I would write my own ConversationManager to go to a backing cache to get the ConversationContainer. But this doesn't seem right. The ConversationContainer looks like it should be 1 to 1 with the user session. Also after it gets the conversation it doesn't look like it is doing a put back into the Container ever, it is all by reference. That won't work if I am using a cache that potentially serializes between request.

    So I guess my real question is how do I go about getting the Conversations off the HttpSession so they don't share the same expiration policy? I know Erwin said he had a DB backed version of ConversationManager but I haven't been able to find any source code for that.

  3. #3
    Join Date
    Sep 2004
    Location
    Leuven, Belgium
    Posts
    1,853

    Default

    Just wondering if this was done on purpose or should be opened as a JIRA?
    This is by design. The ConversationContainer and ContainedConversation are internal implementation artifacts of the SessionBindingConversationManager. They're not part of the public API and not intended for direct use.

    So I guess my real question is how do I go about getting the Conversations off the HttpSession so they don't share the same expiration policy?
    You'll have to implement a ConversationManager from scratch.

    I know Erwin said he had a DB backed version of ConversationManager but I haven't been able to find any source code for that.
    That's normal, the source is not yet publicly available. The DaoConversationManager will be an example in my upcoming SWF book.

    Erwin

  4. #4

    Default

    Without getting into your implementation to much, how do you put the updated conversation into the DB? From the looks of the ConversationManager interface there are only hooks to get the conversation but not to put the updated conversation back.

  5. #5
    Join Date
    Sep 2004
    Location
    Leuven, Belgium
    Posts
    1,853

    Default

    The ConversationManager API guarantees that unlock will always be called, so you can use that for those kinds of purposes. Check the JavaDoc for ConversationManager and Conversation for more details.

    Erwin

  6. #6

    Default

    Great suggestion. I had just finished writing my own impl for Conversation and ConversationManager when I read this. The unlock looks like it will do exactly what I want to do. Guess I should have kept reading before I posted

    I am still very curious to see your DB impl. Can't wait for the book

  7. #7
    Join Date
    Oct 2011
    Posts
    3

    Default

    Hi,

    I'm interested in using Erwin's DaoConversationManager with SWF 2.2.1 - is there an updated version?

    It appears from the 2.0 XSD that registering a customised ConversationManager is not possible but is supported in the 2.3 XSD. I'm guessing then that if there is an updated version of DaoConversationManager I will also need to use it with SWF 2.3 and not 2.2.1?

    Regards,
    Matt

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •