1 2 Previous Next 21 Replies Latest reply on Aug 24, 2006 4:28 PM by wondermike

    Progress

    gavin.king

      I've updated the docs to cover all the new stuff in Seam 1.1.

      This includes stuff like:

      * <s:cache>
      * themes
      * @Redirect / @HttpError
      * major improvements to components.xml
      * @Begin(flushMode=MANUAL)
      * deprecation of @Conversational(ifNotBeginOutcome) in favor of no-conversation-view-id

      For the next week or so I'll be working on our JSF/Ajax story and, when I've got something good enough there, I'll release 1.1.CR1. It would be nice if people who have a spare minute could test out current CVS to see whats broken...

        • 1. Re: Progress
          gus888

          Congratulations! Thank you so much and have a great weekend!

          • 2. Re: Progress

            The support for @Factory methods that return values causes problems for me and my DataBinders.

            I have the following:

             @SelectItems
             private List items;
            
             @Factory("items")
             public List getItems()
             {
             ... static lookup code
             }
            


            Prior to the enhancement this was great. When my EJB clients were accessing the bean they could get the items via the getItems method. When JSF needed the items, Seam resolved the variable, called the factory method that set the instance variable and sent everything through my DataBinder.

            With the latest CVS it seems the DataBinder is called but the List that's eventually exposed to JSF is the one from the @Factory method, which JSF can't process.

            I guess I'd either ask that Seam check for and apply data binders for things created via a @Factory return. Or supply some way to disable the new @Factory logic.

            Thanks,
            Jim

            • 3. Re: Progress
              gavin.king

              I just made a change in CVS. Please try it out and see if that solves your problem.



              • 4. Re: Progress

                Nope. The context object is still the Factory return instead of being the data binder wrapped object. The data binder is still called though. I wonder if there's some sort of outjection race condition or ordering problem. Both the Factory and DataBinder implicitly outject the same component.

                • 5. Re: Progress
                  gavin.king

                  I don't believe you have the latest changes:

                  private static Object handleFactoryMethodResult(String name, Component component, Object result, ScopeType scope)
                   {
                   Object value = Contexts.lookupInStatefulContexts(name); //see if a value was outjected by the factory method
                   if (value==null) //usually a factory method returning a value
                   {
                   if (scope==ScopeType.UNSPECIFIED)
                   {
                   if (component==null)
                   {
                   throw new IllegalArgumentException("no scope specified for factory method defined in components.xml: " + name);
                   }
                   else //an @Factory method defaults to the same scope as the component
                   {
                   scope = component.getScope();
                   }
                   }
                   scope.getContext().set(name, result);
                   }
                   else //usually a factory method with a void return type
                   {
                   if (scope!=ScopeType.UNSPECIFIED)
                   {
                   throw new IllegalArgumentException("factory method with defined scope outjected a value: " + name);
                   }
                   }
                   return result;
                   }


                  Use your debugger to step through this code if you really have it.

                  • 6. Re: Progress
                    robjellinghaus

                    Also Gavin please don't forget the annoying little Log4JLogger issue:
                    http://www.jboss.com/index.html?module=bb&op=viewtopic&t=86058

                    Probably you already fixed it in CVS, but I just got things working with 1.0.1GA, so I'm going to avoid destabilizing my local build with latest CVS for a couple weeks :-)

                    Cheers!
                    Rob

                    • 7. Re: Progress

                      Yes, I appear to have the latest. It looks like you return result, no matter what value is. According to the debugger value is the object I'm looking for.

                      • 8. Re: Progress
                        gavin.king

                        Ooops. Yes, I screwed up. Should now be fixed.

                        • 9. Re: Progress

                          All better now. Thanks.

                          • 10. Re: Progress

                             

                            "gavin.king@jboss.com" wrote:

                            * deprecation of @Conversational(ifNotBeginOutcome) in favor of no-conversation-view-id


                            I just started to use 1.1 in cvs and I am wondering about the reason for deprecating @Conversational. I don't use pages.xml very much and would prefer to have this functionality on my SFSB rather than in a seperate file.

                            I am all for choices; however, I am just curious about the reason for deprecating a choice. I could be missing the bigger picture with respect to pages.xml; It seems like one more place to remember to look in for how a given component works by being forced to use pages.xml.

                            Thanks,
                            Chris....

                            • 11. Re: Progress
                              gavin.king

                              Basically it just didn't work very well ;-)

                              The trouble with @Conversational is that lots of methods of the component can get called before an action method. There may not even be an action method.

                              • 12. Re: Progress

                                 

                                "gavin.king@jboss.com" wrote:
                                Basically it just didn't work very well ;-)

                                The trouble with @Conversational is that lots of methods of the component can get called before an action method. There may not even be an action method.


                                I think I discovered that one my own. It seems like I have some cases where I think it should work but doesn't...

                                Guess I'm back to the design mode. I'm trying to put in a framework that handles exceptions - basically all exceptions should redirect to an error page that displays FacesMessages if present.

                                The specific case I'm working on is:
                                a) user submits a page that throws a BusinessExcpetion
                                b) BusinessException is annotated with @Redirect
                                c) error page is displayed correclty

                                d) user in a different window corrects the error
                                e) user than returns to the original window (still displaying the error message) and hits the back button
                                f) the same page is resubmitted - an ugle error is generated basically saying that a conversation is already started and to use (Begin join=true)
                                - however, the conversation was rolledback and I believe destroyed in #b/c

                                I've read some of the other threads/JIRA about using Servlets / modifying JSF, so I'll think about it some more. Anyway, just curious how other handle generic exceptions rather than showing the ugly app server error messages or generic http messages.

                                Chris....



                                • 13. Re: Progress

                                  An exception shouldn't implicitly kill the conversation. In fact you've proven that it doesn't. You might roll back a transaction on an exception, but conversations aren't the same as transactions and should survive your given use case (although if you wanted to, it wouldn't be hard to end a conversation when you navigate to your error page).

                                  • 14. Re: Progress

                                    Your right. I went back and traced through the logs again and I thought it was being destroyed since I saw some context.destroy messages in the log. I mis-read them as being in the stateful context.....Thanks for putting me on the right path.

                                    I'm really used to stateless frameworks and wrapping my head around a conversation's interactions and subtlies is a bit more than I initial thought it was going to be.

                                    Thanks for the patience.

                                    Chris....

                                    1 2 Previous Next