Web Beans Public Review Draft released

Discussions

News: Web Beans Public Review Draft released

  1. Web Beans Public Review Draft released (56 messages)

    Web Beans defines a set of services for the Java EE environment that makes applications much easier to develop. Web Beans layers an enhanced lifecycle and interaction model over existing Java component types including JavaBeans and Enterprise Java Beans. As a complement to the traditional Java EE programming model, the Web Beans services provide:
    • an improved lifecycle for stateful components, bound to well-defined contexts,
    • a typesafe approach to dependency injection,
    • interaction via an event notification facility, and
    • a better approach to binding interceptors to components, along with a new kind of interceptor, called a decorator, that is more appropriate for use in solving business problems.
    Web Beans is especially useful in the context of web applications, but is applicable to many different kinds of applications and may even be used in the Java SE context, in conjunction with an embeddable EJB Lite container, as defined in the EJB 3.1 specification. The Web Beans public draft is available in PDF or HTML format at: or from: Please send feedback on the public draft to:
    • jsr-299-comments at jcp dot org
    An even easier way to learn about Web Beans is the Introduction to Web Beans guide available in PDF or HTML format here: This is a great time to get involved!

    Threaded Messages (56)

  2. Great work[ Go to top ]

    Great work Gavin and Team. Very excited to see this in Public Draft, and even more to already see some good examples about how to use Web Beans already. Thanks again, I think this will fill a very needed hole in JEE development.
  3. Cast your vote![ Go to top ]

    It's fitting that the Web Beans spec was released on this US Election Day because it's equally as important for the future of Java EE as the presentational choice is for the future of the US. I say that not because Web Beans is a good spec, though I do believe it is, but because it touches on every part of Java EE that a majority of us use each and every day. Please take the time to study it and provide feedback if there is something that concerns you or give it your approval if you think it's solid. It's important! If you haven't looked into Web Beans yet, I encourage you to start by reading the Web Beans Book (i.e., guide) at http://seamframework.org/WebBeans. It's written for a developer, so it's easy to read and paints the big picture, whereas the specification is...well, a specification. The specification has to cover the fine-grained details, which can make it hard to see the big picture for newcomers. Of course, if you are interested in all the technical aspects of Web Beans, then I encourage you to graduate to that document.
  4. Overall, I believe this is a good spec. However, I and many other folks in the EG believe more work needs to be done around proper integration with Java EE before this can make it into Java EE 6 (some of these concerns are addressed in the spec, but not all by far). In a way, this is not surprising given the very high impact nature of the changes. It is important that this is a "seam" rather than a "tear in the fabric" :-). The other concern I have is the lack of availability of multiple implementations since that's an important value proposition for any standards based technology. In particular, I was hoping for a Google and/or Sun implementation in addition to the one from JBoss, but such support does not appear to be forthcoming right now... Cheers, Reza
  5. Congratulations to the hard work Gavin has put in this spec, this is a key spec for the future of EE.
    The other concern I have is the lack of availability of multiple implementations since that's an important value proposition for any standards based technology. In particular, I was hoping for a Google and/or Sun implementation in addition to the one from JBoss, but such support does not appear to be forthcoming right now...

    Cheers,
    Reza
    You are welcome to contribute to the WebBeans RI at JBoss.org. Cheers, Sacha JBoss, a division of Red Hat
  6. Alternate implementations[ Go to top ]

    The other concern I have is the lack of availability of multiple implementations since that's an important value proposition for any standards based technology. In particular, I was hoping for a Google and/or Sun implementation in addition to the one from JBoss, but such support does not appear to be forthcoming right now...

    Cheers,
    Reza

    You are welcome to contribute to the WebBeans RI at JBoss.org.

    Cheers,
    Sacha
    I would even go further to say that we have entered a new age of software development where it makes more sense to focus our energy on an implementation out in the open rather than try to copy off of one another and have a bunch of half-baked implementations. Sure, in the long run you might want alternatives that focus on different areas of performance, optimization, or extension, but let's work together to make a good implementation of the idea first. Alternatives for the sake of alternatives is not productive.
  7. Re: Alternate implementations[ Go to top ]

    Dan, This is certainly not a new argument. I respect the viewpoint, but I beg to differ. I see competing but compatible implementations as essential to a healthy marketplace that's not just a monopoly in "nicer" packaging. That just leads to the same problems that monopolies have in the long run - higher "cost" and lower quality. The other end of the spectrum is hyper-competition and constant churn - not exactly desirable qualities especially if the churn doesn't actually produce very useful stuff and is more "marketing" than true innovation. Cheers, Reza
  8. Re: Alternate implementations[ Go to top ]

    I would even go further to say that we have entered a new age of software development where it makes more sense to focus our energy on an implementation out in the open rather than try to copy off of one another and have a bunch of half-baked implementations. Sure, in the long run you might want alternatives that focus on different areas of performance, optimization, or extension, but let's work together to make a good implementation of the idea first. Alternatives for the sake of alternatives is not productive.
    I strongly disagree with this view. One of the main reasons for defining a specification through a standards body is to enable multiple competing, compatible implementations. I believe that there is great value in this, and I'm looking forward to seeing multiple implementations of Web Beans. Currently I know that JBoss and Apache are both working on implementing Web Beans, and I'm also aware that Caucho were working on an implementation of the EDR at one stage (not sure what the current status of that effort is). I want to stress that the public draft went public *today*, and so I don't think it's worth worrying about a lack of implementations just yet ;-)
  9. Re: Alternate implementations[ Go to top ]

    Gavin,
    I would even go further to say that we have entered a new age of software development where it makes more sense to focus our energy on an implementation out in the open rather than try to copy off of one another and have a bunch of half-baked implementations.
    I strongly disagree with this view.
    I had a feeling you would say this :-). This is part of the reason why I have said here and on the EG groups that WebBeans is fundamentally a good thing! However, I feel I must repeat that it can be significantly improved to have better organization, support and positioning via collaborative work between different people in the EG most of whom I believe have valid concerns that should be seriously addressed. I and others are very glad to see that you have already taken some steps to this end and seem to have a genuine desire to listen. This is a fundamental strength of the standards process and should be respected. I do hope that a healthy debate ensues, I certainly would be honored to be a part of it. I believe an "eminently complementary" WebBeans spec as one person in the EG labeled it, is very possible. I also hope for many good implementations of the WebBeans spec, just as EJB 3.1 is widely supported. Cheers, Reza
  10. Re: Alternate implementations[ Go to top ]

    Currently I know that JBoss and Apache are both working on implementing Web Beans, and I'm also aware that Caucho were working on an implementation of the EDR at one stage (not sure what the current status of that effort is).
    Ah, after a quick peek at the Caucho blog and at the latest Resin docs, it appears that this effort is very much alive and well and that they've been doing some interesting stuff with integrating Web Beans and OSGi. :-)
  11. Re: Alternate implementations[ Go to top ]

    From their blog:
    Resin 4.0 is organized around WebBeans, OSGi, and BAM to provide a foundation for application services. WebBeans is the cleanest technology so far for the service contract and discovery requirements. OSGi improves encapsulation and reusability by cleaning-up version management of libraries and services, using JVM classloader capabilities to improve the loose-coupling of services. BAM extends the foundation of WebBeans and OSGi to a distributed and clustered deployment, helping service architectures scale as demand grows. * In 3.2, Resin’s web-apps are OSGi bundles, so you can define an OSGi service in the resin-web.xml. * Resin’s OSGi/WebBeans integration lets you configure OSGi services in the resin-web.xml or web-beans.xml. * The OSGi/WebBeans integration publishes OSGi services to WebBeans, letting service consumers inject directly.
    Not quite sure what all that means, but it sounds interesting ;-)
  12. Re: Alternate implementations[ Go to top ]

    Ah, after a quick peek at the Caucho blog and at the latest Resin docs, it appears that this effort is very much alive and well and that they've been doing some interesting stuff with integrating Web Beans and OSGi. :-)
    Yep, we're working hard on getting the new WebBeans changes into Resin now. I like the draft changes, especially the XML redesign.
  13. Sacha, Thanks for the invitation. I will surely consider it. Cheers, Reza
  14. Apache has one brewing[ Go to top ]

    There is one incubating over at Apache: http://wiki.apache.org/incubator/OpenWebBeansProposal
  15. Re: Apache has one brewing[ Go to top ]

    Nicklas, Didn't know about the potential Apache implementation, so thanks for that. It is definitely a relief to some degree. It always makes me nervous to have stuff in Java EE that seems unilateral - nothing against any particular vendor....JBoss certainly has a good track record so far. Cheers, Reza
  16. What are some of the concerns about how Web Beans integrates with the rest of Java EE 6? Thanks, Adam
  17. Issues[ Go to top ]

    For a quick overview, open the specs and search for "Open issue" ;-)
  18. Biting the bullet[ Go to top ]

    My personal opinion is that it is time to scrap the JSF managed bean container and hook JSF directly into Web Beans. One of the main points of Seam was to provide an alternative to managed beans and I thought that the advent of Web Beans would have finished them off. However, it appears that we are moving forward with two conflicting containers, as the JSF spec is proposing annotations for declaring managed beans. I really don't think it is too late to solve this issue either. Note that I am not involved in the Web Beans spec and have only been working with the JSF spec for a couple of weeks now, so these are just opinions/observations.
  19. Re: Biting the bullet[ Go to top ]

    My personal opinion is that it is time to scrap the JSF managed bean container and hook JSF directly into Web Beans. One of the main points of Seam was to provide an alternative to managed beans and I thought that the advent of Web Beans would have finished them off. However, it appears that we are moving forward with two conflicting containers, as the JSF spec is proposing annotations for declaring managed beans.
    For JSF 2 the EG has discssed only very limited upgrades to managed beans, with the idea that they are deprecated in favour of Web Beans.
  20. Re: Biting the bullet[ Go to top ]

    My personal opinion is that it is time to scrap the JSF managed bean container and hook JSF directly into Web Beans. One of the main points of Seam was to provide an alternative to managed beans and I thought that the advent of Web Beans would have finished them off. However, it appears that we are moving forward with two conflicting containers, as the JSF spec is proposing annotations for declaring managed beans.


    For JSF 2 the EG has discssed only very limited upgrades to managed beans, with the idea that they are deprecated in favour of Web Beans.
    I dont think that extending the current jsf facilities is that bad. After all JSF already has certain extension points where you can remove the managed bean facilities, this is already done by frameworks like spring and seam! After all one of the goals of JSF2 was zero conf, so adding those annotations to the existing bean mechanism made sense in the context that JSF also should be able to survive without any extra framework just on top the servlet API.
  21. Adam, I am trying to avoid getting into the details of this to much. It's much too early in how these concerns were expressed and how they will eventually play out, so you'll forgive me for being terse for now... The first and foremost from my personal perspective is how the Java Beans integration use case fits with the EJB integration use case. It's important to have clear guidance points on what's what. That appears to be missing in the spec. The primae facie mandate for WB was supposed to be JSF/EJB 3 integration so the current form is a bit of a surprise from that standpoint. The other issue that seems apparent is that significant effort was not put into sharing WB concerns to the EJB 3.1 and Java EE 6 EGs beyond just the spec leads, leaving most of us in the dark to give timely feedback! A related concern is that it treads too much ground - JSF/EJB integration, context management, DI and AOP. That's a pretty big spec that was very sparsely participated in as well as being potentially unmanageable now and going forward as clearly separated concerns that belong in separate JSRs. I know I'm struggling to get my head around the sheer number of features and all their implications. Pretty dangerous given the importance WB has by all accounts...it's not even just Seam or just Guice or just Spring! Some features appear to be in none of these pre-existing technologies and I am just catching up to it. Hope this sheds a bit more light. As I said, personally, these are not major problems and can be sorted out in a timely fashion with proper cooperation and teamwork. Cheers, Reza
  22. I would like to caution everyone on this thread that what was released today is a *public review draft*, released for the purpose of *public review*. :-) This is *not* a proposed final draft, and we are expecting, and hoping for, a lively debate about the specification and Java EE integration issues. The agreement we had with Sun going back a couple of years is that we would initially work on nailing down the basic Web Beans programming model, get the public draft out, and then focus more directly on the relationship of Web Beans to other platform technologies, working more directly with the other EE expert groups. We started on that second phase a couple of weeks ago, and we've already identified a number of directions to explore in terms of platform integration. I intend to blog about the issues we've identified over the next week, in the hope that we can have a more public discussion of the issues.
  23. Web Beans is not enterprise ready[ Go to top ]

    Web Beans still do not support - remote EJBs as enterprise Web Beans - context propagation across remote method invocations To my opinion Web Beans must support remote EJBs to be named "enterprise". Local EJBs are only a special case and in a real world enterprise remote EJBs just exist (it is not just a chapter in the JEE spec). As soon as the "remote" feature is supported, the Web Beans will be the most important spec for enterprise java developer since 1998. Alain.
  24. Re: Web Beans is not enterprise ready[ Go to top ]

    Alain, WB *does* support remote EJBs in that remote EJBs can be injected, etc. You are right this is an important spec, which is why it needs to be carefully considered, well-integrated, well positioned and well-supported. My personal opinion is that none of those conditions have been met at this point, putting this in much shakier footing than it really ought to be accomplish its mission. I hope we can sort all that out quickly and effectively within the folks contributing to the JCP... Cheers, Reza
  25. Re: Web Beans is not enterprise ready[ Go to top ]

    WB *does* support remote EJBs in that remote EJBs can be injected, etc.
    Just to be clear, this is not correct.
  26. Re: Web Beans is not enterprise ready[ Go to top ]

    Gavin,
    WB *does* support remote EJBs in that remote EJBs can be injected, etc.
    Just to be clear, this is not correct.
    This is a good illustration of the kind of valid concerns many people have about WB. My reading of the draft was that @EJB is fully supported...now you are saying this is not accurate... Cheers, Reza
  27. Re: Web Beans is not enterprise ready[ Go to top ]

    Gavin,

    WB *does* support remote EJBs in that remote EJBs can be injected, etc.
    Just to be clear, this is not correct.


    This is a good illustration of the kind of valid concerns many people have about WB. My reading of the draft was that @EJB is fully supported...now you are saying this is not accurate...

    Cheers,
    Reza
    Injection of remote EJBs via @EJB is "supported" - but this is the responsibility of the Java EE container, not of Web Beans. Injection of remote EJBs via Web Beans injection is not supported, out-of-the-box, at least not in the public draft. Of course, what Alain was looking for was injection of remote EJBs via use of Web Beans injection.
  28. Re: Web Beans is not enterprise ready[ Go to top ]

    Injection of remote EJBs via @EJB is "supported" - but this is the responsibility of the Java EE container, not of Web Beans. Injection of remote EJBs via Web Beans injection is not supported, out-of-the-box, at least not in the public draft. Of course, what Alain was looking for was injection of remote EJBs via use of Web Beans injection.
    Why do we need two different injections for the same thing? Don't you think this would add confusion to the platform? IMO, Java already has enough DI implementations and it's time for JCP to unify/standardize them instead of adding a new one! Are we repeating the same old story of "Entity Beans > JDO > JPA"?
  29. Re: Web Beans is not enterprise ready[ Go to top ]

    The end goal is definitely to have a powerful, unified injection mechanism for all the kinds of things you might want to inject. We're not quite there yet, but we're working on it. To achieve this goal, we need to take the model defined by the Web Beans public draft and add support for the other existing Java EE resource types (JDBC connections, connectors, persistence contexts, remote EJBs, web services, etc). This requires a bunch of collaboration with the platform expert group, which is why it was appropriate to leave it until after the release of the public draft. Eventually, if we want to do so, the existing injection annotations like @EJB, @Resource and @PeristenceContext could be re-characterized as Web Beans binding types, but this isn't something we will do in the Java EE 6 timeframe.
  30. Re: Web Beans is not enterprise ready[ Go to top ]

    Web Beans still do not support
    - remote EJBs as enterprise Web Beans
    - context propagation across remote method invocations

    To my opinion Web Beans must support remote EJBs to be named "enterprise". Local EJBs are only a special case and in a real world enterprise remote EJBs just exist (it is not just a chapter in the JEE spec).

    As soon as the "remote" feature is supported, the Web Beans will be the most important spec for enterprise java developer since 1998.

    Alain.
    Alain, I respect this, and I hope you'll send feedback to the comments alias on this issue. In some earlier drafts of the spec I had a proposal for "remote Web Beans", but it got cut from the public draft because I felt that it didn't rise to the level of elegance of the rest of the programming model, and because it had not been adequately discussed and iterated by the EG. However, it is likely that support for injection of remote EJBs will be added, as part of an effort to support generic injection of all Java EE resource types via Web Beans mechanisms - as has been requested by some of the Java EE experts. With respect to the public draft: * Support for injection of remote EJBs, it is not supported as an out-of-the-box feature of Web Beans, however, it quite easy to add support for this via a portable extension based upon the Bean interface. * Support for context propagation across remote method invocations could also be supported by an extension based upon the Context interface. However, this extension would not be portable between application servers, because the necessary (standard) hooks do not exist in the RMI layer. I hope that helps :)
  31. Re: Web Beans is not enterprise ready[ Go to top ]

    Hi Gavin I must admit that you proposed "remote Web Beans" in earlier drafts. I was very exited about it. I talked to Christian Bauer about it and it seems to me that it would be "available soon" in JBoss Seam. I can understand that a "remote" programming model may not be that elegant, but on the other side, as many other consultants like me, we loose interest on this spec because the lack of this remote feature. *Support for injection of remote EJB* Why not deliver the extension (based upon the Bean interface) as part of the spec? *Support for context propagation*. To be honest, since 10 years (since Jim Waldo did the wrong design of RMI in 1997 while hiding the correctly designed IIOP context propagation standard) I spend my time by customers, hooking any kind of interceptors in app servers for propagating the context. Although the customers paid a lot, I get bored and still hope for a spec. BTW Jim Waldo accepted my critic but the version 1.0 was out and he was absorbed by its new "baby" (the Jini project). So to me the real issue is this "remote context propagation". Why not specify that the app server vendor has to implement it? They have to implement IIOP, so they already have remote context propagation. Ergo it's not a big deal to specify that the Context interface has to support "remote propagation". I'm sure that "remote context propagation" will come some day. I was telling EJB experts since the EJB 1.0 in 1998 that the EJB spec need interceptors. They finally put the interceptors in EJB 3.0, after 7-8 years. For me Seams (or Web Beans) is the long awaited missing link. And a big "THANK YOU" to you for that. However the dozen big companies I do consulting for won't use it because it doesn't fit in their distributed environment. Cheers Alain
  32. Re: Web Beans is not enterprise ready[ Go to top ]

    I must admit that you proposed "remote Web Beans" in earlier drafts. I was very exited about it. I talked to Christian Bauer about it and it seems to me that it would be "available soon" in JBoss Seam. I can understand that a "remote" programming model may not be that elegant, but on the other side, as many other consultants like me, we loose interest on this spec because the lack of this remote feature.
    I'm not saying that it *can't* be elegant, only that what we had in the Web Beans draft wasn't satisfying. I would much rather cut a feature than do it wrong.
    *Support for injection of remote EJB* Why not deliver the extension (based upon the Bean interface) as part of the spec?
    I do think we will end up with support for injection of remote EJBs, but I'm not sure if it will be contextual (i.e. perhaps all remote references will have scope @Dependent).
    *Support for context propagation*. To be honest, since 10 years (since Jim Waldo did the wrong design of RMI in 1997 while hiding the correctly designed IIOP context propagation standard) I spend my time by customers, hooking any kind of interceptors in app servers for propagating the context. Although the customers paid a lot, I get bored and still hope for a spec. Why not specify that the app server vendor has to implement it?
    Look, I totally agree. CORBA had this problem licked 10 years ago, but it has still not been adequately addressed in Java EE. But this problem is *far* out of the scope of JSR-299! You'll need to send this feedback to the Java EE EG.
    For me Seams (or Web Beans) is the long awaited missing link. And a big "THANK YOU" to you for that. However the dozen big companies I do consulting for won't use it because it doesn't fit in their distributed environment
    Web Beans can still fit into the distributed environment - but only as the model used *internally* in the application. When you cross process boundaries, you'll need to pass everything as parameters. Or, like I said before: you *can* develop a distributed context, based on vendor-specific APIs. In JBoss, at least, this is not very difficult, since our whole RMI layer is based upon an interceptor stack.
  33. I am using Seam since 1.0BETA. I can say this experience has been very open and productive. The leaders and community are extremely good and responsive. I use Seam to take maximum benefits from Java EE. From my point of view, WebBeans is taking the technology and knowledge developed in this project and others to a broader audience and more contribution. The benefits brought by WebBeans is much more important then some issues. I support this spec and I think that this can turn Java EE developent to a great deal for small or large or simple or enterprise projects. Great job Gavin, WebBeans EG, Seam and JBoss. Congratulations and keep pushing! Thanks,
  34. Does Google have a roadmap?[ Go to top ]

    Since Bob Lee worked on the spec, I'd think there would be a plan to triangulate this with Guice & GWT.
  35. Firstly, congrualations to Gavin King and EG members for doing huge efforts that results appearing this smart piceces of the Java EE. In short, WebBeans defines the "Component Model" of the future Java EE. It defines and manages the loosely-coupled, type-safe, easy configurable , easy unit tested, and contextual components otherwise the developer has to struggle with all of these stuffs in every day enterprise programming. It perfectly alignes with the other Java EE specifications/standarts. Currently EJB, JMS, Servlet and JSF are supported. But as Gavin expressed, integration of other Java EE standarts with WebBeans is on the board. WebBeans is also extensible. You can define your own component models and register it with the WebBeans runtime. Do not look at the WebBeans standart as an another DI, or IOC. It really provides more than this. Its great time to look at the spec. In the mean time, as Niclas expressed, we are at Apache Incubator, implementing the WebBeans specification, it is called OpenWebBeans. First alpha version of the implementation is on the road and released in a near time. Also I will start a introduction to WebBeans articles in my blog. Gurkan Erdogdu Free and Open Source Software http://gurkanerdogdu.blogspot.com
  36. In the mean time, as Niclas expressed, we are at Apache Incubator, implementing the WebBeans specification, it is called OpenWebBeans.
    Cheers, mate, and good luck! I had a quick browse around your repo and it looks like your implementation is significantly more advanced than the RI right now. ;-)
  37. URL[ Go to top ]

    I got a 404 from the https://svn.apache.org/repos/asf/incubator/openwebbeans and couldn't see it one level up either.
  38. Re: URL[ Go to top ]

    I got a 404 from the https://svn.apache.org/repos/asf/incubator/openwebbeans and couldn't see it one level up either.
    Nicklas, project setup is going on on the incubator side. Until that, the source code is at the location in sourceforge; http://bigfaces.svn.sourceforge.net/viewvc/bigfaces/webbeansimpl/
  39. In the mean time, as Niclas expressed, we are at Apache Incubator, implementing the WebBeans specification, it is called OpenWebBeans.


    Cheers, mate, and good luck! I had a quick browse around your repo and it looks like your implementation is significantly more advanced than the RI right now. ;-)
    Thanks Gavin, and congrulations again :)
  40. Gavin,
    In short, WebBeans defines the "Component Model" of the future Java EE.
    ' This is another good illustration of why more work needs to be done around WB integration in Java EE. For one, this sends a seriously mixed message and risks undermining all the hard work numerous people have done around bringing EJB 3 back from the brink and finally making it into something people enjoy developing with. In my opinion, doing so is plainly unjustified and irresponsible. This is exactly what I and others refer to as cause of a serious rift instead of a cleanly complementary technology that has a real potential to unify the platform. This does not need to happen. Let's put in sincere work to solve it. It can be done. Cheers, Reza
  41. In my opinion, doing so is plainly unjustified and irresponsible
    Reza, I think you understand my assertion wrongly. In an IT environment, I am sure you know that "Component" means lots of definition in the different contexts. For example, SOA Components in SOA context, DB Component in DB Context, JMS Component in Messaging Context, EJB component in EJB Context etc. I did not want to declare that WebBeans will be replacement of the EJBs related stuffs anyway. WebBeans just uses it as its one of the component model. Others are Java Beans, JMS or anything else you can define. I think, EJB has its own place in the Java EE, it defines its own component model and its container and its services. And it done its job great. On the other hand, WebBeans defines its own component model(or bean model) (using other component models) and its container and its services. I think that Java EE 6.0 specification/standart will greatly simplify the development of the enterprise projects using Java EE with its several different specification parts that completes the puzzle together. Cheers;
  42. Gurkan,
    I think you understand my assertion wrongly.
    That might be the case and I apologize for casting this is such an absolutist manner. What you say makes a lot of sense, but it needs to be better crystallized in WebBeans, Java EE and elsewhere. It particular, WebBeans is a Java EE spec, so the essential first step is to make sure that Java EE integration is well defined before leaping too far outward. Otherwise, I suspect my reaction will be all too common. In the worst case scenario, WebBeans can be hijacked to fragment Java EE from the inside out. A close second risk is adding more bloat to Java EE by duplicating what's already there and does what it is designed to do just fine, as you say. Cheers, Reza
  43. Return of the Manager[ Go to top ]

    One wonders how the completely generic interface name "Manager" was deduced. Must have been an interesting meeting.
  44. Can some one shed some light how Web Beans are different from the stateful session beans?
  45. Can some one shed some light how Web Beans are different from the stateful session beans?
    Web Beans is a set of services. Stateful session beans are one kind of "thing" that these services apply to. The first service is contextual lifecycle management. This service lets stateful session beans have a lifecycle that is automatically managed, instead of explicitly demarcated by the application creating and destroying the bean. The lifecycle is determined by the web beans scope: request scoped, session scoped, application scoped, or conversation scoped. The second service is dependency injection. This service lets (a) the stateful session bean inject other scoped objects with managed lifecycles, and (b) lets the stateful session bean be injected into clients. (This is a *much* more sophisticated form of dependency injection than is provided by @EJB.) Finally, the stateful session bean can fire and observe events, have decorators, etc. The Web Beans services are generic and can be applied to essentially any kind of "thing". For example, the JAX-RS folks want to re-use Web Beans to provide the same set of services to JAX-RS components. If you want to know more, the "Introduction to Web Beans" guide will make it all very clear :-)
  46. Gavin,
    Can some one shed some light how Web Beans are different from the stateful session beans?


    Web Beans is a set of services. Stateful session beans are one kind of "thing" that these services apply to.

    The first service is contextual lifecycle management. This service lets stateful session beans have a lifecycle that is automatically managed, instead of explicitly demarcated by the application creating and destroying the bean. The lifecycle is determined by the web beans scope: request scoped, session scoped, application scoped, or conversation scoped.

    The second service is dependency injection. This service lets (a) the stateful session bean inject other scoped objects with managed lifecycles, and (b) lets the stateful session bean be injected into clients. (This is a *much* more sophisticated form of dependency injection than is provided by @EJB.)

    Finally, the stateful session bean can fire and observe events, have decorators, etc.

    The Web Beans services are generic and can be applied to essentially any kind of "thing". For example, the JAX-RS folks want to re-use Web Beans to provide the same set of services to JAX-RS components.

    If you want to know more, the "Introduction to Web Beans" guide will make it all very clear :-)
    I am heartened by this explanation. It is indicative of what WebBeans can really become in terms of an "eminently complementary" technology in Java EE. Cheers, Reza
  47. Is webbean to seam like jpa to hibernate?
  48. Is webbean to seam like jpa to hibernate?
    The Web Beans spec is based on ideas that originated in the Seam and Guice projects, together with some original thinking that came out of the convergence of these two approaches, iteration through the expert group, and suggestions from the public. For example: * Seam contributed the context lifecycle model and the idea for the event bus * Guice contributed the typesafe dependency injection based on type+binding types and dependent pseudo scope * the expert group discussions resulted in ideas like deployment types, event binding types, stereotypes and specialization * Matt Drees contributed the initial idea for decorators through the feedback alias
  49. hoping for the best[ Go to top ]

    Hopefully Webbeans RI won't be as bloated and tightly coupled as Seam does.
  50. Nope[ Go to top ]

    There won't be anything thats not in the specs. Bloat is reserved for frameworks built on top...
  51. re: hoping for the best[ Go to top ]

    Hopefully Webbeans RI won't be as bloated and tightly coupled as Seam does.
    Sounds like flamebait - but toss out your best example and you might be taken seriously.
  52. Re: re: hoping for the best[ Go to top ]

    Hopefully Webbeans RI won't be as bloated and tightly coupled as Seam does.


    Sounds like flamebait - but toss out your best example and you might be taken seriously.
    I already made one of my opinion here about Seam being tightly coupled to hibernate. There is no abstraction for many different JPA implementation. Also just look how much framework Seam requires to get it up and running. :-) The distribution itself is pretty large for a framework. So I'm not flaming. I'm hoping things would go better.
  53. For all of us Spring users, can someone in 25 words or less explain why we should bother looking at WebBeans. I am not being inflamatory here. I would like the sales pitch that explains what WebBeans delivers on top of, say, Spring + Spring Webflow -- which together provide DI + various scope, incl. conversation. My initial thoughts are "why do I care" and "too little too late", but given the experts involved and total effort seemingly expended building webbeans, what (seriously + respectfully) is the big deal?
  54. perhaps...[ Go to top ]

    Standards. Hmmm. 24 words left ;-) If Spring works for you, no need to switch but if you compare it with the ORM scene you can probably find 30-40 projects that gets the job done for some definition of done. Having JPA means that you can swap out the implementation should you need to. If your favorite proprietary persistence provider suddenly says "hey, we're still open source, we just run it through an obfuscater before committing", you might be in trouble.
  55. Re: perhaps...[ Go to top ]

    Standards.

    Hmmm. 24 words left ;-) If Spring works for you, no need to switch but if you compare it with the ORM scene you can probably find 30-40 projects that gets the job done for some definition of done. Having JPA means that you can swap out the implementation should you need to. If your favorite proprietary persistence provider suddenly says "hey, we're still open source, we just run it through an obfuscater before committing", you might be in trouble.
    OK. Thanks. So to clarify, if I don't mind being non-standard by using Spring there's no compelling reason to look at WebBeans?
  56. Re: perhaps...[ Go to top ]

    Greg, the only way to answer your question is to ask you to read the "Introduction to Web Beans" article. Yes, I know its about 40 pages long, but it will be worth your while. After you've read the article, you'll understand the value of Web Beans. Before that, you won't. :-)
  57. WebBeans vs Spring[ Go to top ]

    Is spring participating in the expert group and making an implementation? If not, it would seem (no pun intended) that a civil war is being set up.