Details

    • Type: Feature Request Feature Request
    • Status: Open Open (View Workflow)
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.0
    • Fix Version/s: TBD
    • Component/s: Contexts
    • Labels:
      None
    • Similar Issues:
      Show 10 results 

      Description

      Add management API for built in contexts allowing them to be reused as needed.

        Issue Links

          Activity

          Hide
          Pete Muir
          added a comment - - edited

          Weld used the following interface, which has also been approved by Mark Struberg representing OpenWebBeans and by Reza Rahman
          representing CanDI and I hope it can be used for the basis of discussions on this topic:

          public interface ConversationManager
          {
             /**
              * Checks the state of the conversation context
              * 
              * @return true if the conversation context is active, false otherwise
              */
             public abstract boolean isContextActive();
             
             /**
              * Sets up and activates the conversation context
              * 
              * @return The conversation manager
              * 
              * @throws IllegalStateException if the context is already active
              */   
             public abstract ConversationManager setupContext();
             
             /**
              * Destroys the conversations and deactivates the conversation context
              * 
              * @return The conversation manager
              * 
              * @throws IllegalStateException if the context is already deactive
              */   
             public abstract ConversationManager teardownContext();
          
             /**
              * Resumes a long running conversation. If the cid is null, nothing is done and the current
              * transient conversation is resumed
              * 
              * 
              * @param cid The conversation id to restore
              * @return The conversation manager
              * @throws NonexistentConversationException If the non-transient conversation is not known
              * @throws BusyConversationException If the conversation is locked and not released while waiting 
              * @throws IllegalStateException if the conversation context is not active
              */
             
             public abstract ConversationManager setupConversation(String cid);
             
             /**
              * Destroys the current conversation if it's transient. Stores it for conversation 
              * propagation if it's non-transient
              * 
              * @return The conversation manager
              * @throws IllegalStateException if the conversation context is not active
              */
             public abstract ConversationManager teardownConversation();
             
             /**
              * Gets the current non-transient conversations
              * 
              * @return The conversations, mapped by id
              * @throws IllegalStateException if the conversation context is not active
              */
             public abstract Map<String, Conversation> getConversations();
          
             /**
              * Returns a new, session-unique conversation ID
              * 
              * @return The conversation id
              * @throws IllegalStateException if the conversation context is not active
              */   
             public abstract String generateConversationId();
           
          }
          

          Subsequently we replaced this with a set of general purpose APIs for managing all built in contexts including conversations.

          Show
          Pete Muir
          added a comment - - edited Weld used the following interface, which has also been approved by Mark Struberg representing OpenWebBeans and by Reza Rahman representing CanDI and I hope it can be used for the basis of discussions on this topic: public interface ConversationManager { /** * Checks the state of the conversation context * * @ return true if the conversation context is active, false otherwise */ public abstract boolean isContextActive(); /** * Sets up and activates the conversation context * * @ return The conversation manager * * @ throws IllegalStateException if the context is already active */ public abstract ConversationManager setupContext(); /** * Destroys the conversations and deactivates the conversation context * * @ return The conversation manager * * @ throws IllegalStateException if the context is already deactive */ public abstract ConversationManager teardownContext(); /** * Resumes a long running conversation. If the cid is null , nothing is done and the current * transient conversation is resumed * * * @param cid The conversation id to restore * @ return The conversation manager * @ throws NonexistentConversationException If the non- transient conversation is not known * @ throws BusyConversationException If the conversation is locked and not released while waiting * @ throws IllegalStateException if the conversation context is not active */ public abstract ConversationManager setupConversation( String cid); /** * Destroys the current conversation if it's transient . Stores it for conversation * propagation if it's non- transient * * @ return The conversation manager * @ throws IllegalStateException if the conversation context is not active */ public abstract ConversationManager teardownConversation(); /** * Gets the current non- transient conversations * * @ return The conversations, mapped by id * @ throws IllegalStateException if the conversation context is not active */ public abstract Map< String , Conversation> getConversations(); /** * Returns a new , session-unique conversation ID * * @ return The conversation id * @ throws IllegalStateException if the conversation context is not active */ public abstract String generateConversationId(); } Subsequently we replaced this with a set of general purpose APIs for managing all built in contexts including conversations.
          Hide
          Richard Hightower
          added a comment -

          you might want to link to a wiki or a github gist or use the format commands of Jira which are {{{ }}}. I can't read your code.

          Show
          Richard Hightower
          added a comment - you might want to link to a wiki or a github gist or use the format commands of Jira which are {{{ }}}. I can't read your code.
          Hide
          Pete Muir
          added a comment -

          Actually the proposal here is quite out of date, will update it in a bit.

          Show
          Pete Muir
          added a comment - Actually the proposal here is quite out of date, will update it in a bit.
          Hide
          Mark Struberg
          added a comment -

          hmm not sure if we really should add this.

          This was certainly a good thing back at the time when we discussed this. But from trying to use CDI's own @ConversationScoped in a real world JSF project I must say - it doesn't work out. Reason is that our CDI Conversation is lazy-starting which is way too late for JSF applications. Because what happens if you have a mandatory field not set or any other JSR-303 or JSF validation issue? In this case your action - which would make the conversation long-running - just doesn't get invoked! So you end up with a standard @RequestScoped behaviour and your bean will over and over get created again with each view hit.

          Also: CDI conversations doesn't prevent opening an action link in a new window or tab, which makes them unusable for multi windowed applications.

          I guess the same reasons apply why CODI introduced an own ConversationScoped and why Seam3 also introduced an own one, right?

          So, since the CDI @ConversationScoped is kind of naturally restricted, I'm not sure if it's really worth adding a complex management SPI for it.

          Show
          Mark Struberg
          added a comment - hmm not sure if we really should add this. This was certainly a good thing back at the time when we discussed this. But from trying to use CDI's own @ConversationScoped in a real world JSF project I must say - it doesn't work out. Reason is that our CDI Conversation is lazy-starting which is way too late for JSF applications. Because what happens if you have a mandatory field not set or any other JSR-303 or JSF validation issue? In this case your action - which would make the conversation long-running - just doesn't get invoked! So you end up with a standard @RequestScoped behaviour and your bean will over and over get created again with each view hit. Also: CDI conversations doesn't prevent opening an action link in a new window or tab, which makes them unusable for multi windowed applications. I guess the same reasons apply why CODI introduced an own ConversationScoped and why Seam3 also introduced an own one, right? So, since the CDI @ConversationScoped is kind of naturally restricted, I'm not sure if it's really worth adding a complex management SPI for it.
          Hide
          Pete Muir
          added a comment -

          Mark, can we spin out your issues with CDI conversations to a new issue, as these are definitely something we should address.

          Regarding this issue around managing contexts, what I believe is useful here is to introduce a much more powerful, regular SPI that can manage all the built in contexts in a consistent fashion (unlike the proposal above which is just for conversations and very special case). This would also give people building their own contexts a "blueprint" to build their lifecycle management from which would introduce more uniformity for users. I will happily drive this issue, but I need a couple of weeks to write up a full proposal

          Show
          Pete Muir
          added a comment - Mark, can we spin out your issues with CDI conversations to a new issue, as these are definitely something we should address. Regarding this issue around managing contexts, what I believe is useful here is to introduce a much more powerful, regular SPI that can manage all the built in contexts in a consistent fashion (unlike the proposal above which is just for conversations and very special case). This would also give people building their own contexts a "blueprint" to build their lifecycle management from which would introduce more uniformity for users. I will happily drive this issue, but I need a couple of weeks to write up a full proposal
          Hide
          Mark Struberg
          added a comment -

          sure, go on. The question is though how broad CDI-1.1 should be finally. If it will only be a 'bugfix and consistency' release, then I'd say we move this to a later version. If it is more a CDI-2, then we should cleanup the conversations too.

          Show
          Mark Struberg
          added a comment - sure, go on. The question is though how broad CDI-1 .1 should be finally. If it will only be a 'bugfix and consistency' release, then I'd say we move this to a later version. If it is more a CDI-2 , then we should cleanup the conversations too.
          Hide
          Pete Muir
          added a comment -

          Ok, we will cover scope at the phone call next week and come up with a statement.

          Show
          Pete Muir
          added a comment - Ok, we will cover scope at the phone call next week and come up with a statement.
          Hide
          Shane Bryzak
          added a comment -

          There is no @ConversationScoped annotation in Seam 3 that I'm aware of. We need the management API to be able to support conversation management within view technologies other than JSF. Currently, we need to use a non-portable solution to achieve this, however it should have really been part of the CDI 1.0 specification and in my opinion it was an oversight that it was not included.

          Show
          Shane Bryzak
          added a comment - There is no @ConversationScoped annotation in Seam 3 that I'm aware of. We need the management API to be able to support conversation management within view technologies other than JSF. Currently, we need to use a non-portable solution to achieve this, however it should have really been part of the CDI 1.0 specification and in my opinion it was an oversight that it was not included.
          Hide
          Pete Muir
          added a comment -

          Slipping Java SE related issues.

          Show
          Pete Muir
          added a comment - Slipping Java SE related issues.

            People

            • Assignee:
              Unassigned
              Reporter:
              Nicklas Karlsson
            • Votes:
              2 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated: