1 2 Previous Next 26 Replies Latest reply on Feb 12, 2008 5:41 PM by maxandersen

    Web Beans Sneak Peek

    gavin.king

      I'm writing a series of articles about Web Beans (which is taking up most of my time right now). The first installment is up:

      http://in.relation.to/Bloggers/WebBeansSneakPeekPartIIntroducingWebBeans

        • 1. Re: Web Beans Sneak Peak
          matt.drees

          Cool stuff! I'm looking forward to the rest.

          • 2. Re: Web Beans Sneak Peak
            gavin.king
            • 3. Re: Web Beans Sneak Peak
              gavin.king
              • 4. Re: Web Beans Sneak Peak
                gavin.king
                • 5. Re: Web Beans Sneak Peek
                  christian.bauer

                  These were renamed, find the whole series here:

                  http://in.relation.to/Bloggers/Gavin

                  • 6. Re: Web Beans Sneak Peek

                    Hi,

                    I don't know if this is the palce but after reading all 4 parts of the sneak peak of Web Beans, here's a couple of comments/questions I would like share.

                    @Named annotation
                    I know that this has also been raise about Seam but would it be possible to remove that annotation and use the value() of the @Component annotation or add a "name" attribute to it instead? I found it would be more meaningful this way. Or maybe the @Named attribute has other uses which requires it to be separate?

                    Injection on resolver method
                    In the example that you give in part 4 about how to use injection in resolver method, wouldn't it be better to instantiate the component through the Web Beans API instead of having the container inject 3 values and in the end only using one of them? Something like:

                    @Resolves @Preferred @ApplicationScoped
                    public PaymentStrategy getPaymentStrategy() {
                     switch (paymentStrategy) {
                     case CREDIT_CARD: return container.methodToInjectBean("whatevertheparamshouldbe");
                     case CHEQUE: container.methodToInjectBean("whatevertheparamshouldbe");
                     case PAYPAL: container.methodToInjectBean("whatevertheparamshouldbe");
                     default: return null;
                     }
                    }
                    

                    Again, I understand it was maybe only to showcase the possibility and not necessarily the only work around to this problem but I was just curious if it would be the preferred way to address this situation.

                    Integreation in Seam
                    It probably is too soon to discuss this but are there any plans to replace Seam's component model with Web Beans? I know that some features/behaviour of the Seam component model might be missing from the Web Beans specification but is the ultimate goal the one day use it in Seam?

                    Thanks for sharing this preview of the specification with us.

                    • 7. Re: Web Beans Sneak Peek
                      gavin.king

                       

                      I know that this has also been raise about Seam but would it be possible to remove that annotation and use the value() of the @Component annotation or add a "name" attribute to it instead? I found it would be more meaningful this way. Or maybe the @Named attribute has other uses which requires it to be separate?


                      There are many component type annotations (@Component, @Standard, and all the user-defined component types). It doesn't make sense to re-declare the name attribute each time we create a new component type.

                      And please compare:

                      @Component(name="foo")
                      @Component @Name("foo")


                      The only difference is a single space.

                      In the example that you give in part 4 about how to use injection in resolver method, wouldn't it be better to instantiate the component through the Web Beans API instead of having the container inject 3 values and in the end only using one of them?


                      You can do that if you like. It will look like:

                      Component<Foo> comp = container.resolveByType(Foo.class);
                      Foo foo = container.getContext(comp.getScope()).get(comp)


                      It probably is too soon to discuss this but are there any plans to replace Seam's component model with Web Beans? I know that some features/behaviour of the Seam component model might be missing from the Web Beans specification but is the ultimate goal the one day use it in Seam?


                      The current Seam codebase will evolve into the Web Beans RI. Then non-standardized features of Seam will be layered over the Web Beans standard.

                      • 8. Re: Web Beans Sneak Peek

                        My argument against the @Named annotation wasn't about the number of extra key strokes (as you pointed out, there is only one!) I was merely saying that to me, if you say that a component has a name, it would make more sense that it has a "name" attribute, not a separate annotation. Are you saying that because many annotations have to share common attributes that those common attributes should be turned into individual annotations just so you don't have to repeat them on each one? Take the @Stateless and @Stateful annotation. Are you saying that the EJB 3 spec is wrong in having duplicated the set of attributes they have in them? I can understand that when it comes to extending the framework and developing your own custom annotations it makes it a little bit easier because you don't have to carry over that attribute, but for clarity's sake and because I find it semantically more accurate, I like my idea better. It wouldn't be that much to ask that component annotations must define a name attribute. Then again, who am I to decide, right? Sorry for busting your balls, but I like to argument. And what's wrong with argumenting anyways? Isn't it how things get better?

                        • 9. Re: Web Beans Sneak Peek
                          lisaanm

                          Hi,
                          Web Beans pre-review sounds good.

                          But what about the core EJB functionality: Distribution (Remote, RMI etc.,). I'm excited to know little more about this.

                          Thanks

                          • 10. Re: Web Beans Sneak Peek
                            mnrz

                            Thanks Gavin, I found it really nice and useful document :)

                            • 11. Re: Web Beans Sneak Peek
                              nickarls

                              And the early draft now seems to be available (as seen on TSS):

                              http://in.relation.to/Bloggers/JSR299WebBeansEarlyDraft

                              • 12. Re: Web Beans Sneak Peek
                                gavin.king

                                 

                                But what about the core EJB functionality: Distribution (Remote, RMI etc.,). I'm excited to know little more about this.


                                Well, yeah, I need to write another installment covering that ... but, all you need to know is: you can use it all :-) And remember, EJB 3.1 will introduce a bunch of new stuff: singletons, bean-class local views, much improved timer service, etc.

                                Actually its pretty exciting what's going on in EJB 3.1.

                                • 13. Re: Web Beans Sneak Peek
                                  gavin.king

                                   

                                  My argument against the @Named annotation wasn't about the number of extra key strokes (as you pointed out, there is only one!) I was merely saying that to me, if you say that a component has a name, it would make more sense that it has a "name" attribute, not a separate annotation. Are you saying that because many annotations have to share common attributes that those common attributes should be turned into individual annotations just so you don't have to repeat them on each one? Take the @Stateless and @Stateful annotation. Are you saying that the EJB 3 spec is wrong in having duplicated the set of attributes they have in them?


                                  Yes, I think that was a mistake. If I'm writing code that needs to discover the name of an EJB, it would be *much* better if there was just one annotation to look for. If annotation inheritance was supported, it would not be a problem, we could have @Stateless and @Stateful both extend @EJBComponent, and it might be OK.

                                  It's even worse in Web Beans, where component types can be defined by the user.

                                  When people see annotations, they start to forget all their OO modeling knowledge, for some reason. Try to think in terms of modeling and typesafety.

                                  • 14. Re: Web Beans Sneak Peek
                                    ar.mohseni

                                     

                                    "mnrz" wrote:
                                    Thanks Gavin, I found it really nice and useful document :)




                                    hi mr. nourozi

                                    please contact me.

                                    apc.mohseni@gmail.com

                                    tanx

                                    1 2 Previous Next