JBoss Seam 1.0 released

Discussions

News: JBoss Seam 1.0 released

  1. JBoss Seam 1.0 released (27 messages)

    Gavin King has announced that JBoss Seam 1.0, an application framework for Java EE 5 based on JSF, JMS, EJB3, and some other technologies, has been released.
    Seam integrates Java EE 5 technologies like EJB 3.0, JSF and JMS into a unified programming model and then narrows the semantic gap between the business domain and the Java programming language by deeply integrating technologies like jBPM for business process and user interaction modelling and Drools for management of business rules. Seam Remoting provides an AJAX-based remoting layer for EJB 3.0, allowing client-side JavaScript to call EJB session beans directly. Seam's unique contextual state management architecture makes it easy to build applications with complex, stateful user interactions and helps eliminate a whole class of bugs endemic to browser-based applications. Seam also eliminates the "XML hell" that plagues Java frameworks designed for use with J2EE by leveraging Java 5 annotations for declarative programming.

    Threaded Messages (27)

  2. Re: JBoss Seam 1.0 released[ Go to top ]

    FYI, Seam is also the basis for the new WebBeans JSR. Kito D. Mann Author, JavaServer Faces in Action http://www.virtua.com - JSF/J2EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
  3. Re: JBoss Seam 1.0 released[ Go to top ]

    FYI, Seam is also the basis for the new WebBeans JSR.
    I'm going to troll for a second and ask why this integration JSR is being coined as WebBeans. The whole lot of JSR 29x's are overlapping each other and if the integration model is done correctly from a business standpoint, it should be deployment agnostic-- such that web/jsf/swing can use the metadata, not regulate it. As we begin to blur the lines of thing/fat client applications, why are we still promoting two different programming models in our business layer given the architecture of EJB?
  4. Re: JBoss Seam 1.0 released[ Go to top ]

    FYI, Seam is also the basis for the new WebBeans JSR.


    I'm going to troll for a second and ask why this integration JSR is being coined as WebBeans. The whole lot of JSR 29x's are overlapping each other and if the integration model is done correctly from a business standpoint, it should be deployment agnostic-- such that web/jsf/swing can use the metadata, not regulate it.

    As we begin to blur the lines of thing/fat client applications, why are we still promoting two different programming models in our business layer given the architecture of EJB?
    The JSR is clearly bound to JSF ('a server-side user interface component framework for Java technology-based web applications'). Imho would have been better to make that clear from the naming.
  5. Re: JBoss Seam 1.0 released[ Go to top ]

    I'm going to troll for a second and ask why this integration JSR is being coined as WebBeans. The whole lot of JSR 29x's are overlapping each other and if the integration model is done correctly from a business standpoint, it should be deployment agnostic-- such that web/jsf/swing can use the metadata, not regulate it.

    As we begin to blur the lines of thing/fat client applications, why are we still promoting two different programming models in our business layer given the architecture of EJB?


    The JSR is clearly bound to JSF ('a server-side user interface component framework for Java technology-based web applications'). Imho would have been better to make that clear from the naming. Not really though-- I mean, that's the implementation pitched, but if you look at Seam's annotations, they could apply within Action2 or Wickett for the most part-- the whole stateful injection stuff is just as deployable/integratable as standalone Spring. Why would JBI/EJB integration be specific to JSF unless the spec had UIComponents as a by product?
  6. WebObjects?[ Go to top ]

    FYI, Seam is also the basis for the new WebBeans JSR.


    I'm going to troll for a second and ask why this integration JSR is being coined as WebBeans. I think it is a tip of the hat to Apple's WebObjects (Web + Enterprise Objects). Thus WebBeans (Web + Enterprise Java Beans). Anyone?
  7. Re: JBoss Seam 1.0 released[ Go to top ]

    From the JSR:
    the EJB component model still has some limitations: * EJB components are not aware of the web-tier request, session and application contexts and do not have access to state associated with those contexts. Nor may the lifecycle of a stateful EJB component be scoped to a web-tier context.
    And:
    The goal of this work is to enable EJB 3.0 components to be used as JSF managed beans, unifying the two component models and enabling a considerable simplification to the programming model for web-based applications in Java.
    Now it does go on to state that it is intended to provide constructs that are sophisticated enough to be used outside of web apps. However, that is clearly secondary. This is all about easy web development leveraging the full JavaEE stack. One might say that this is a reaction to Ruby on Rails, or that Ruby on Rails and Seam are both reactions to the same limitations in Java. I think a lot of the RoR fans are Java devs, not PHP or .NET people. Maybe Seam can win some people back.
  8. From the JSR:
    the EJB component model still has some limitations: * EJB components are not aware of the web-tier request, session and application contexts and do not have access to state associated with those contexts. Nor may the lifecycle of a stateful EJB component be scoped to a web-tier context.
    Was not it supposed to be a proper thing that the web tier knows about persistence/model tiers, but the persistence tier does not know about web tier? This page http://jcp.org/en/jsr/detail?id=299 does not specifically mention whether database metadata will be pulled into EJB/web beans to be used as the base for validation/conversion rules. I hope that metadata will get enough attention, Microsoft ADO has been able to use metadata for years. Some other frameworks like PHP Django are able to do it too. Did I mentioned Ruby On Rails ;-) ?
  9. Re: JBoss Seam 1.0 released[ Go to top ]

    JBoss Seam looks really good. But can I run it on WebSphere or Weblogic? Some people are saying no... Will my application become "JBoss-dependent" by using Seam?
  10. Re: JBoss Seam 1.0 released[ Go to top ]

    JBoss Seam looks really good. But can I run it on WebSphere or Weblogic? Some people are saying no...
    Will my application become "JBoss-dependent" by using Seam?
    Well, that might be the reason for making it a JSR.
  11. Two bag things in Seam[ Go to top ]

    Hi, I see in Seam two bag things: 1. Seam as base for a JSR: This a case of premature standard. First Seam must be used for years to create real life applications, and recieve the feedback of developer community. If you try to do the stardard first, you will be create an awkward stardard for us, the programmers. 2. Seam is really a complicate framework: Yes, it's differente from previous ones, and also is more simple that old J2EE, but still is complicate to create a business application with Seam, it still left in the programmer a lot of work to do. 4GL, VB or RPG are still more productive than Seam framework. Javier Paniza
  12. Re: JBoss Seam 1.0 released[ Go to top ]

    JBoss Seam looks really good. But can I run it on WebSphere or Weblogic? Some people are saying no...
    Will my application become "JBoss-dependent" by using Seam?
    Seam targets the standard Java EE 5 platform, and has been tested on both JBoss and Glassfish (the RI). I have not tested on Oracle yet, but I expect Seam to run there too. Neither WebLogic nor WebSphere currently support Java EE 5, but I expect that situation to change.
  13. how about Struts+EJB or Struts+POJO?[ Go to top ]

    Seam is for JSF+EJB, but struts has the biggest customers, how about for Struts+EJB or Struts+POJO? JdonFramework is same as Seam or RoR: https://jdon.dev.java.net
  14. Seam is for JSF+EJB, but struts has the biggest customers, how about for Struts+EJB or Struts+POJO?
    Maybe if Struts is less than convinient it will start to fade away.
  15. I did a detailed interview with Gavin on SEAM 1.0 incase anyone is interested. We covered why SEAM chose JSF as a framework, SEAMs relationship to Java EE, future directions, and the following key differentiators:
    1. A unified component model centered around EJB. 2. Raises the semantic level of development. 3. A new contextual component model / higher level state management over HTTPSession. 4. DRW-style AJAX EJB invocation and the ability to recieve JMS messages in the browser. 5. Support for process-driven applications. 6. Portal integration. 7. Testability.
  16. Re: JBoss Seam 1.0 released[ Go to top ]

    My concern is more along the lines of redundancy in Java in relation to the WebBeans JSR and the following: JSR 295: Bean Bindings JSR 296: Swing Application Framework JSR 227: A Standard Data Binding & Data Access Facility for J2EE I'm not saying that anyone is going to do this better than the others, just that I can see a lot of artifacts being standardized which are just repackaged versions of what the others offered. If they are focusing around annotations/injection/state/binding-- integration-- why can't we do like the common.annotations spec and just provide constructs that frameworks can act as a client of-- such as JSF or swing's application framework, etc.
  17. Re: JBoss Seam 1.0 released[ Go to top ]

    My concern is more along the lines of redundancy in Java in relation to the WebBeans JSR and the following:

    JSR 295: Bean Bindings

    JSR 296: Swing Application Framework

    JSR 227: A Standard Data Binding & Data Access Facility for J2EE

    I'm not saying that anyone is going to do this better than the others, just that I can see a lot of artifacts being standardized which are just repackaged versions of what the others offered. If they are focusing around annotations/injection/state/binding-- integration-- why can't we do like the common.annotations spec and just provide constructs that frameworks can act as a client of-- such as JSF or swing's application framework, etc.
    Totally agreed. I didn't want to be the troll to say that this time, but I've wondered from the start why e.g. JSR 227 wouldn't be sufficient or could at least be the starting point. Then again, I had the surprising experience that when I asked one of Seams core devs about JSR 227 last year (and it's competing JSR, forgot the number...) he wasn't even aware of its' existence.
  18. My concern is more along the lines of redundancy in Java in relation to the WebBeans JSR and the following:

    JSR 295: Bean Bindings

    JSR 296: Swing Application Framework

    JSR 227: A Standard Data Binding & Data Access Facility for J2EE

    I'm not saying that anyone is going to do this better than the others, just that I can see a lot of artifacts being standardized which are just repackaged versions of what the others offered. If they are focusing around annotations/injection/state/binding-- integration-- why can't we do like the common.annotations spec and just provide constructs that frameworks can act as a client of-- such as JSF or swing's application framework, etc.


    Totally agreed. I didn't want to be the troll to say that this time, but I've wondered from the start why e.g. JSR 227 wouldn't be sufficient or could at least be the starting point. Then again, I had the surprising experience that when I asked one of Seams core devs about JSR 227 last year (and it's competing JSR, forgot the number...) he wasn't even aware of its' existence.
    Isn't this the domain of the executive committee to prune and consolidate some of these JSR's. A leaner catalog of standards, especially those that overlap, might mitigate some of the queasiness that people feel when they browse jcp.org. Given the fact that section 2.6 of the Request procedure specifially requires a new spec to "justify it's existness" with respect to other JSRs, I'm surprised that some of these JSRs have been allowed to see the light of day. RE JSR 227: the last activity seems to have been in 2003. I guess the JCP would rather spawn a new JSR than resurrect an old EG.
  19. RE JSR 227: the last activity seems to have been in 2003. I guess the JCP would rather spawn a new JSR than resurrect an old EG.
    Though 'dead' here is relative rather than absolute.
  20. RE JSR 227: the last activity seems to have been in 2003. I guess the JCP would rather spawn a new JSR than resurrect an old EG.


    Though 'dead' here is relative rather than absolute.
    I stand corrected. But even in those threads, Ted Farrell mentions in Dec 2005 'we'll update the status next week' and we'll all see "some public activity early next year['06]. Six months later we're looking at 2003 as last update. So we seem to have the proverbial "the spec is in the mail" apology. Other specs were started well after JSR 227 and they already are in public review stages and are just as comprehensive(I'm guessing since there is no public review of JSR 227). If public updates across the board were more forthcoming, maybe the JSR29x guys would've have built upon other JSRs instead of spawning a new one. Perhaps the JCP should institute a monthly or quarterly "mark and sweep" of all JSR's for status updates so the community can have a better guage on activity of JSR's they may be interested in. As the #25 post on that thread stated, "it's just good project management". Hell, a Wiki model would be better than the inertia of a spec that takes 3 years to come to public review.
  21. JSRs[ Go to top ]

    There has been activity on JSR 227, and I have been in contact with Gavin about this JSR, its scope and how it might work with JSR 227. This is just an example of bad public communication in the JSR process. All that said, I think there is room for both of these JSRs, and I don't think this JSR is about taking SEAM and stamping it as a standard. We need to figure out what makes the most sense to accomplish the goal. The goal, in this case, is to make it easy for the JSF/EJB coder to build apps w/o doing a lot of data marshalling in managed beans. JSR 227 is targeted at a declarative approach and while we have always wanted to extend that for a coding solution as well, we have not had the time. I look forward to participating in this JSR to see if we can't solve some of those problems at the same time. SEAM has some interesting stuff in it and Gavin's background, along with the rest of the EG's should make a strong group to help figure it out. Ted Farrell Oracle Corporation
  22. The goal, in this case, is to make it easy for the JSF/EJB coder to build apps w/o doing a lot of data marshalling in managed beans. JSR 227 is targeted at a declarative approach and while we have always wanted to extend that for a coding solution as well, we have not had the time.
    This seems to be particularly true that managed beans are, at least in my experience, bloated with unnecessary unmarshalling of the core object model to different DataModel etc. objects that the UI components handle. I've always thought this to be an issue that could be resolved better, say with a declarative solution as mentioned. Just expose information on how to interact and unmarshal / marshal with/from the said POJOs or use XML. A situation where this problem culminates is for example a JSF UI tree component. Say we have a hierarchy that is built/mapped using ORM (parent --> set of children x levels of tree), it is a working hierarchy represented by POJOs and collections. Now we still need to transform this into DataModel objects and the like (most likely also the "tiny bits" to something the tree understands). Never saw the point in this, when we could've used "just" the POJOs instead... -I
  23. Re: JBoss Seam 1.0 released[ Go to top ]

    My concern is more along the lines of redundancy in Java in relation to the WebBeans JSR and the following: JSR 295: Bean Bindings JSR 296: Swing Application Framework JSR 227: A Standard Data Binding & Data Access Facility for J2EE
    Totally agreed. I didn't want to be the troll to say that this time, but I've wondered from the start why e.g. JSR 227 wouldn't be sufficient or could at least be the starting point.
    As I understand it, JSR-227 is a UI databinding solution that addresses the problem of mapping between the an application model and the standard model types expected by UI widgets. The Web Beans JSR-299 _does_not_ address this concern at all, and if you check the JSR proposal, it explicitly calls out JSR-227 as a source of databinding functionality:
    * Ensure that the component model can be used with JSR-227 databinding.
    I'm sure Oracle will help us get it right in this area. I have not paid much attention to JSR-295, but I'm sure Sun would have surfaced this if they believed that there was potential overlap. With respect to the idea of trying to support rich clients and web clients in the same JSR, I believe that such a thing would be premature and extremely likely to either go nowhere or produce a horrible mess ;-) Cheers,
  24. Re: JBoss Seam 1.0 released[ Go to top ]

    if you check the JSR proposal, it explicitly calls out JSR-227 as a source of databinding functionality
    I missed that, sorry. I looks like this JSR certainly is going to make life better for JEE developers.
  25. Re: JBoss Seam 1.0 released[ Go to top ]

    With respect to the idea of trying to support rich clients and web clients in the same JSR, I believe that such a thing would be premature and extremely likely to either go nowhere or produce a horrible mess ;-)
    But Gavin-- you can't tell me that state management and IoC aren't a concern of desktop deployments too-- and in reality have nothing to do with the particulars of the GUI implementation per say. These are fundamental concepts from an application standpoint that shouldn't be isolated. If you are modeling after Seam, standardized annotations could be interpreted by any number of frameworks/deployments while guaranteeing a common set of semantics for java developers to use in parallel with EJB 3.
  26. Questions about J2EE future… Does someone know how Shale (Struts evolution) and JBoss Seam will interact? Will interaction be possible between these two "frameworks" ? And what about Spring and JBoss Seam ? Is the Spring team working on a "bridge" to use Seam features? I think these 3 big ones will be major actors on the future months. Shale and Spring should interact together but what about Seam?
  27. Questions about J2EE future…

    Does someone know how Shale (Struts evolution) and JBoss Seam will interact?
    Will interaction be possible between these two "frameworks" ?
    And what about Spring and JBoss Seam ?
    Is the Spring team working on a "bridge" to use Seam features?

    I think these 3 big ones will be major actors on the future months. Shale and Spring should interact together but what about Seam?
    From what I know, Spring and Seam are competitive products (especially with Spring Web Flow and Spring 2.0 scoped beans). So why would you use both?
  28. Google SAP IBM Oracle SUN Hani Suleiman? http://jcp.org/en/jsr/results?id=3865