Discussions

News: JBoss 'Seam', app framework for JEE 5, released in beta

  1. Seam is an application framework for Java EE 5 which unifies the component models of JSF and EJB 3.0, providing a streamlined programming model for web-based enterprise applications. Seam lets you bind your EJB components directly to JSF pages, eliminating noisy glue code.

    Seam introduces the notion of declarative application state management for POJO components. Seam components are stateful and contextual, with a well-defined container-managed lifecycle. This approach helps solve a whole class of bugs and performance problems that plague web applications with non-linear or multi-window navigation. Seam components may take advantage of "subversion of control", a generalization of dependency injection which applies to stateful components as well as stateless services. The programming model is declarative; Seam extends the annotations defined by EJB 3.0 with a new set of annotations for declarative state management, state validation and declarative context demarcation, eliminating much of the XML required by plain JSF.

    Seam also makes business process management a first class construct, by deeply integrating JBoss jBPM into this state management architecture.

    Finally, Seam makes it easy to test Java EE 5 applications in unit test frameworks, leveraging the JBoss Embeddable EJB3 container.

    Seam is compatible with any application server that supports the EJB 3.0 public draft, and with any JSF 1.1 implementation.

    Even if you're not ready to plunge into Java EE 5 and EJB 3 today (after all, EE 5 is not quite final), you can still take advantage of Seam's unique approach to state management by using Seam with Hibernate 3 and the JBoss Microcontainer.

    What do you think of the notion of binding EJBs directly into the JSF layer like this?

    Threaded Messages (71)

  2. Needs Eclipse[ Go to top ]

    Still doesn't look that simple to me. I think what is needed is Eclipse to hide this low level complexity.
  3. I'm interested in the Embeddable EJB3 container of JBoss Seam. Will this be able to provide the same degree of testability we get from Spring???
  4. I'm interested in the Embeddable EJB3 container of JBoss Seam. Will this be able to provide the same degree of testability we get from Spring???

    Yep, the release includes unit testing support. It's quite cool to be able to create a POJO bean with a couple annotations and *immediately* test with an in memory DB and zero SQL work.

    In addition, there are 'Scripts' you can run to test the coordination of your business objects with JSF.
  5. Annotations[ Go to top ]

    I don't buy into that annotations stuff. Trying to figure out problems by scanning getter headers for stuff like "@Id @NotNull @Length(min=5, max=15)" makes no good for our projects. Any annotation-fans can please try to list some valid points why this seems to be a clever idea?
  6. Annotations[ Go to top ]

    I don't buy into that annotations stuff. Trying to figure out problems by scanning getter headers for stuff like "@Id @NotNull @Length(min=5, max=15)" makes no good for our projects. Any annotation-fans can please try to list some valid points why this seems to be a clever idea?

    http://www.onjava.com/pub/a/onjava/2005/01/19/metadata_validation.html
  7. Annotations - conflicts?[ Go to top ]

    Am I off base wondering if all these different systems using annotations are not going to start colliding on the tags? One of the things that XML provides is a context for the tag names. That is, different subject contexts may use the same tag names because they are encapsulated within the context.

    The way everyone and their brother is using annotations, I think we will quickly get to some form of encapsulation marking to avoid conflicts. For example:

    @EJB 3.0
    @Stateful
    @!EJB 3.0
    @Seam
    @In
    @NotNull
    @!Seam
    @Hibernate
    @NotNull
    @one-to-many ...
    @!Hibernate
  8. Annotations - conflicts?[ Go to top ]

    Am I off base wondering if all these different systems using annotations are not going to start colliding on the tags?

    Annotations exist in a package, and may be qualified by the package name. :-)
  9. Annotations - conflicts?[ Go to top ]

    Am I off base wondering if all these different systems using annotations are not going to start colliding on the tags? One of the things that XML provides is a context for the tag names. That is, different subject contexts may use the same tag names because they are encapsulated within the context. The way everyone and their brother is using annotations, I think we will quickly get to some form of encapsulation marking to avoid conflicts. For example:@EJB 3.0@Stateful@!EJB 3.0@Seam@In@NotNull@!Seam@Hibernate@NotNull@one-to-many ...@!Hibernate
    Yes I'd like to see something like
    with org.domain
    {
      @NotNull
    }
  10. Needs Eclipse[ Go to top ]

    Still doesn't look that simple to me. I think what is needed is Eclipse to hide this low level complexity.

    agree, maybe it is my age ;-( but i am getting really tired lately of learning frameworks. When I can click around first and then dive deeper it is fine (given the fact that it works!)
  11. Needs Eclipse[ Go to top ]

    Still doesn't look that simple to me. I think what is needed is Eclipse to hide this low level complexity.
    agree, maybe it is my age ;-( but i am getting really tired lately of learning frameworks. When I can click around first and then dive deeper it is fine (given the fact that it works!)

    That's an excellent point. Seam promotes the idea of 'one kind of stuff'-- beans. No lengthy XML configuration files or complex APIs, just drop annotations on your beans and everything is taken care of. It's somewhat of a 'reverse' framework. Instead of requiring your code to dive into multiple frameworks, the framework dives into your code. It's not AOP, it's just metadata that allows you to scale to different layers as you see fit.
  12. Complexity[ Go to top ]

    If you are concerned out complexity, check out this demo application:

    http://seam.demo.jboss.com/

    And then go download Seam and see just how little code it took to write this app.

    One of the (several) goals of Seam is to bring Ruby On Rails style productivity to the Java EE platform, which means we had to be incredibly economical with "framework" constructs. The idea of the programming model in Seam is that you don't have create any "extra things" to make your frameworks happy. You express your business model in entity beans, application logic in session beans, and then you're able to bind those directly to the JSP/Facelets page. Any extra layering or patterns are up to you, Seam doesn't force that on you.

    Complexity is the opposite of what Seam is about :-)

    (And no, it most certainly doesn't need tools!)
  13. Complexity[ Go to top ]

    Is demo application source code available online ?
  14. RE: Complexity.... Sean Vs. RoR[ Go to top ]

    Gavin Says:
    One of the (several) goals of Seam is to bring Ruby On Rails style productivity to the Java EE platform, which means we had to be incredibly economical with "framework" constructs.

    This seems like a worthy goal. I think the Java community needs an answer RoR that is standards based. It is nice to see an answer to RoR that includes JSF. I'll check it out.
  15. Looks really interesting[ Go to top ]

    Just a minor question, does it really make things easier?
    I checked out the examples, I have not figured them out fully. but having 4 annotations in a class, and several per important method is that really easier than having one central config file to handle those issues.

    Dont get me wrong, I love annotations like the next one for instance

    @Transactional or @Webmethod can save lots of coding
    but the way the annotations are used there, do they make things that much easier, instead of pushing everything into a config file it seems to me that all the config entries are pushed into the annotations without really simplifying that much more.

    This is maybe an area which things have to be worked upon.
    It is definitely not rails ease of use yet, due to the fact that rails does not even need those, but relies as much as possible on introspection and only goes into the configuration layer if absoluteley needed.
  16. Re: Looks really interesting[ Go to top ]

    First you must understand that's it's not all about annotations. It is not about putting information in descriptors or annotations, even though we decided to use annotations. The point of Seam is about "contextual components", you can read the documentation about this.

    Now about annotations, why not putting those info like validation right into the definition of a POJO ? Why would i define my object attributes then go edit some XML descriptor where i will have to specify again the name of my attribute ? What when you change the name of the attibute or the class, you need to go change it in the descriptor as well. It leads to lot of mistakes.

    Isn't:
    package org.jboss;
    public class Thing {
      @NotNull
      public String myString;
    }

    simpler than:

    package org.jboss;
    public class Thing {
      public String myString;
    }
    public String myString
    with an xml file that would look like this:
    <class-name>org.jboss.Thing</class-name>
    <attribute>
      <attribute-name>myString</attribute-name>
      <not-null />
    </attribute>

    That said, that's really not where Seam is a good framework, using annotations is a tool not the goal, think about the plumbing code to write to do as simple as persisting data from an HTML page, Seam let you do this very easily (with few annotations).
  17. JBoss versus Spring[ Go to top ]

    So this must be the JBoss answer to Spring. I'm not too surprised given this recent discussion.

    This will be interesting to watch. I personally hate annotations and prefer declarative stuff in XML. The dependency on Java 5.0 and JSF is a bit steep in my opinion. Looks like a equivalent to Spring Web Flow is also in the works based on jBPM.
  18. Not really[ Go to top ]

    So this must be the JBoss answer to Spring.

    Well, actually, no. In a Seam architecture, EJB3 fills the role of the Spring-style component layer, and JSF forms the web layer.

    So don't think of Seam as being "IoC with annotations", or you'll miss the whole point ;-)

    The role of Seam in the architecture, (apart from pure integration of the two layers), is *state management*, which is something that IoC containers don't usually bother with.

    As a couple of illustrations of the difference:

    (1) Seam components are very often stateful, and hold conversational state across multiple requests to the server; it's left to the application to manage state manually, and clean up state at the end of a conversation, which results in many bugs and memory leaks, especially if the application allows multi-window operation.

    (2) Users of O/R mapping layers like Hibernate are often troubled by LazyInitializationExceptions or NonUniqueObjectExceptions when they try to implement conversations that span multiple requests; Seam applications are by nature not vulnerable to these exceptions, since entities *stay managed* for the entire conversation (conversation scoped persistence context).

    It's going to be difficult for me to really "explain" this stuff in forum posts (though I'll try my best). To grok the difference, you need to take a look at the examples.

    How we came to this was really from the perspective of trying to understand how data, and more generally *state* is used in a system.
  19. Not really[ Go to top ]

    Ooops! I meant to write:


    (1) Seam components are very often stateful, and hold conversational state across multiple requests to the server; ****In IoC containers like Spring*** it's left to the application to manage state manually, and clean up state at the end of a conversation, which results in many bugs and memory leaks, especially if the application allows multi-window operation.

    The point is that Seam controls clean up and isolation of conversational state. You don't have to do it manually.

    Ugh. Way too early in the morning for me, but I'm excited about the release :-)
  20. Not really[ Go to top ]

    Ooops! I meant to write:(1) Seam components are very often stateful, and hold conversational state across multiple requests to the server;
    I am looking at "Example 1.2" in documentation, I see controler is implemented as Stateless EJB and it stores "EntityManager" and "User" as instance fields. Doe's "SeamInterceptor" inject this stuff and calls "register" in "synchronized" block or it just a mistake in example ?
  21. mistakes ... impossible![ Go to top ]

    Ooops! I meant to write:(1) Seam components are very often stateful, and hold conversational state across multiple requests to the server;
    I am looking at "Example 1.2" in documentation, I see controler is implemented as Stateless EJB and it stores "EntityManager" and "User" as instance fields. Doe's "SeamInterceptor" inject this stuff and calls "register" in "synchronized" block or it just a mistake in example ?

    There is no mistake in the example. Session beans are single threaded ;-) No synchronized block. Also, EntityManager is injected by the EJB container, not by Seam.

    Yes, injection/outjection is done synchronously with the invocation, hence the "dynamic" part of "dynamic, contextual, and bidirectional". It's different to what you're used to, huh?

    (By the way, Example 1.2 is not the fullest illustration of what Seam is all about, since it doesn't show an actual conversation, also look at 1.9.)
  22. mistakes ... impossible![ Go to top ]

    There is no mistake in the example. Session beans are single threaded ;-) No synchronized block. Also, EntityManager is injected by the EJB container, not by Seam.Yes, injection/outjection is done synchronously with the invocation, hence the "dynamic" part of "dynamic, contextual, and bidirectional". It's different to what you're used to, huh?
    Yes, I always thought stateless session beans can be shared by container implementation (they have no state) and statefull beans can not be used to store http session data (they are used to propagate client thread state)
    (By the way, Example 1.2 is not the fullest illustration of what Seam is all about, since it doesn't show an actual conversation, also look at 1.9.)
    Yes, it is interesting. JBPM stuff is very interesting, I think it is a good idea to use this kind of state management for single http session data too.
  23. mistakes ... impossible![ Go to top ]

    Yes, I always thought stateless session beans can be shared by container implementation (they have no state) and statefull beans can not be used to store http session data (they are used to propagate client thread state)

    The example is somewhat misleading... you only have one method that you are invoking with registration, not a series of them on the public contract.

    -- Jacob (JSF EG)
  24. Answer to Spring?[ Go to top ]

    The role of Seam in the architecture is *state management*, which is something that IoC containers don't usually bother with.

    Gavin,

    Yes, IoC containers don't usually bother with managing conversational state. However, state management is most definitely something *Spring Web Flow* (SWF) bothers with, and Peter's point there was spot on.

    Just to be clear: Spring is positioned in the market as a modular, full-stack application framework, not just a IoC container. Spring Web Flow is one component of that full stack focused on the definition and management of web conversations for orchestrating application transactions that typically span multiple requests into the server.

    Given that position, what the Spring community offers with Web Flow is a mature solution in this space, grown from over five years of research between the founders and most recently out of use in several large production applications for Fortune 500 clients. Today, SWF is nearing a complete 1.0 final release, and runs on JDK 1.3 or >.

    From my cursory glance at what SEAM can do, I do see considerable overlap with SWF, but I also see gaps where SEAM currently falls short. Both products address state management, but SEAM does not yet address the problem of modeling user interactions (page flow), at least not at the level Spring Web Flow does today. From what I gathered in te FAQ, I presume that gap will be eventually be served by JBPM.

    Spring Web Flow, like SEAM, also offers the ability to store and restore conversational state in an automatic fashion. A major difference between Web Flow's core architecture is it is *not* tied first-class to JSF or EJB 3.0: SWF can manage the state of arbitrary POJOs on existing infrastructure, and work with any web framework--as an open component, in the true spirit of the word.

    For specific information about our architectural approach to this problem, see http://www.jroller.com/page/kdonald?entry=significant_new_spring_web_flow

    Cheers,

    Keith
  25. Answer to Spring?[ Go to top ]

    The role of Seam in the architecture is *state management*, which is something that IoC containers don't usually bother with.
    Gavin,Yes, IoC containers don't usually bother with managing conversational state. However, state management is most definitely something *Spring Web Flow* (SWF) bothers with.

    I'm not very familiar with Spring Web Flow, but from what I know, it is not comparable to the uniform, declarative state management architecture of Seam. I just downloaded SWF, and checked the code examples and they do not look remotely similar to what we are talking about here. Your blog entry seems to describe something that is almost halfway along the way to being Seamy, but not quite there yet.

    Seam is about writing contextual components bound to context variables with full dynamic bijection between various scopes from REQUEST all the way up to the long-running multi-user business PROCESS. It's not just about having conversation state.

    Again, I recommend people download the code examples, read the docs properly, and get familiar with what Seam code really looks like before drawing conclusions.
  26. Answer to Spring?[ Go to top ]

    I'm not very familiar with Spring Web Flow, but from what I know it is not comparable ... I just downloaded SWF, and checked the code examples and they do not look remotely similar to what we are talking about here.

    Hmmm, SEAM and SWF look comparable to me. I just played around with your demo application and they definitely look comparable to me.

    A Spring Web Flow definition models a user interaction with the application, typically an interaction that drives a business process that takes place over a series of steps.

    Once such an interaction is modeled, independently running "executions" of it can be launched at runtime. Conversational state associated with each execution is managed for you. In addition, a snapshot of each execution can be saved and restored at any point, to support resumable long running flows and proper browser navigational button use.

    To make this a bit more concrete, the SWF "sellitem" sample demonstrates how to implement a multi-step wizard as a webflow. To do this, you first create a flow definition to describe the complete wizard interaction, modeling the various steps and the possible paths from one step to another.

    At application use time, when the user wants to sell an item, SWF launches a new *execution* of this "sellitem" flow. This execution maintains the state of that one user's interaction. The execution pauses when user input is needed, resumes to process signaled user input events, and terminates when the flow ends. Contextual data from flow scope moves into the hands of worker business objects for processing--seamlessly.
    Seam is about writing contextual components bound to context variables with full dynamic bijection between various scopes from REQUEST all the way up to the long-running multi-user business PROCESS.

    That's a lot of words to digest, but again SWF sounds comparable. The presentation I am giving on SWF in your back yard at the Atlanta JUG in October even uses a booking system as an example!

    In any case, it IS good to see further recognition that traditional approaches to building web applications today lack a key abstraction--the notion of a web conversation. As your demo application captions say, welcome to 2005. :-)

    Keith
  27. Answer to Spring?[ Go to top ]

    Hmmm, SEAM and SWF look comparable to me. I just played around with your demo application and they definitely look comparable to me.

    A Spring Web Flow definition models a user interaction with the application, typically an interaction that drives a business process that takes place over a series of steps.

    Once such an interaction is modeled, independently running "executions" of it can be launched at runtime. Conversational state associated with each execution is managed for you. In addition, a snapshot of each execution can be saved and restored at any point, to support resumable long running flows and proper browser navigational button use.

    I don't like to repeat myself but, again, Seam is not just about conversations. Really, there's more here than you guys will fully grok in one morning of playing and trying hard to convince yourselves that there's nothing you didn't think of before. ;-)

    Support for conversations is one important piece of what Seam offers, of course.

    By the way, I'll be talking about Seam at JBoss World in Barcelona in a few weeks time :-)
  28. Ouch![ Go to top ]

    Really, there's more here than you guys will fully grok in one morning of playing and trying hard to convince yourselves that there's nothing you didn't think of before. ;-)

    Really guys!? You are being over critical. Take your time, dig for a couple of months. Just define a continuation at this point in time. Save the state of the process right here. And resume only after you armed yourselfs with really good argumets.


    Regards,
    Horia Muntean
  29. Answer to Spring?[ Go to top ]

    Hmmm, SEAM and SWF look comparable to me. I just played around with your demo application and they definitely look comparable to me.A Spring Web Flow definition models a user interaction with the application, typically an interaction that drives a business process that takes place over a series of steps.Once such an interaction is modeled, independently running "executions" of it can be launched at runtime. Conversational state associated with each execution is managed for you. In addition, a snapshot of each execution can be saved and restored at any point, to support resumable long running flows and proper browser navigational button use.
    I don't like to repeat myself but, again, Seam is not just about conversations. Really, there's more here than you guys will fully grok in one morning of playing and trying hard to convince yourselves that there's nothing you didn't think of before. ;-)Support for conversations is one important piece of what Seam offers, of course.By the way, I'll be talking about Seam at JBoss World in Barcelona in a few weeks time :-)

    I must be missing something. Can you be more specific? What does SEAM give you that WebFlow + Spring doesn't? To me, SEAM looks to be solving two-way DI plus flow with annotations, no?
  30. Answer to Spring?[ Go to top ]

    I must be missing something. Can you be more specific? What does SEAM give you that WebFlow + Spring doesn't?

    I think it's a RoR style "magic" when based on a lot's of assumptions things just link to each other and work.
    So you end up wrinting much less code, and create applications much faster.
  31. OT: Spring Web Flow question[ Go to top ]

    Offtopic but is the Spring Web Flow built off a more generalized workflow design like Microsoft's upcoming Windows Workflow Foundation (WWF)? If not, why not?

    http://msdn.microsoft.com/windowsvista/building/workflow/default.aspx
  32. Not really[ Go to top ]

    The role of Seam in the architecture, (apart from pure integration of the two layers), is *state management*, which is something that IoC containers don't usually bother with.
    Support for transparent injection of scoped services is already on the roadmap for Spring 1.3, which will no doubt be final well before Seam (and of course doesn't require Java 5). This has been a feature that one of our customers asked for, and which we've already given them prototype support for. (A household name worldwide, they're migrating from Dynamo to Spring. Dynamo has a form of DI and has some scoping features.) However, it's not something our users have been pressing for in general, and when I've mentioned it as a new feature (for example in a presentation in Cork two weeks ago), there hasn't been a stampede of users desperate for it...

    Rgds
    Rod
  33. Not really[ Go to top ]

    I guess you really have to take a look at things from the opposite direction with how users interact with data/state from an OO standpoint. For example, the UI within JSF and Tapestry push a contextual OO model for managing state with user interactions. When the common annotations spec hits, there were a lot of issues because it wasn't handling 'real' injection requirements in true OO applications.

    I guess, if you can find a framework that does wonderful things like this, proper, contextual IoC isn't so much of an issue for your users.
  34. Feedback on Seam[ Go to top ]

    Full disclosure: as the author of Stripes, a new web application framework, I'm not entirely unbiased when it comes to this subject.

    First off, I really like the fact that someone else is trying to create a framework starting from the premise that things should just be easier! Developing in Java these days is often too much of a drudge. That said, I read through some of the Seam documentation this morning, and I'm a little disappointed. There are a number of things that I just couldn't figure out a solution to, that I consider pretty core pieces of a web application these days.

    When I released Stripes, one of the major points raised was that since validation was in annotations it was hard to vary with context. Since Stripes has you declare the validations in actions, and projects them over domain objects, there is a way to vary them. With Seam it looks like I have to decorate my persistent entities. What happens when I want to have multiple sets of validation per entity, based on the context?

    Also, I couldn't figure out from the documentation how to do basic web application things like execute custom validation logic, supply error messages and render them on to the page. I expect that the sample application must do some of this - but I don't really want to have to download a whole load of stuff just to see how basic stuff works.

    How would the authors of Seam suggest implementing an Ajax application with Seam? From the examples it looks like my action/controller methods have to return a String token identifying a view to go to next. How would I render an XML or JSON fragment to the browser? Would I have to use a facelet (or other view component) to do it?

    Like I say, I'm actually really happy that Seam is trying to make JEE development easier. Hopefully these things are possible, and it's just the documentation that is a bit lack-lustre at this point.
  35. Feedback on Seam[ Go to top ]

    When I released Stripes, one of the major points raised was that since validation was in annotations it was hard to vary with context. Since Stripes has you declare the validations in actions, and projects them over domain objects, there is a way to vary them. With Seam it looks like I have to decorate my persistent entities. What happens when I want to have multiple sets of validation per entity, based on the context?

    There are three kinds of validation available:

    (1) Standard JSF form validation in the JSP/Facelets page
    (2) Validation in action listener code
    (3) Business model validation

    IMO, only the third kind truly belongs in annotations, and it truly belongs on the domain model, since it needs to be enforced in three layers of the application simultaneously: (a) at data-entry time, (b) before writing to the database (c) when generating DDL. This is actually the *common case* for validation. For the somewhat less common case, you can then customize and add extra "contextual" validation in your action listener or JSP form. This is more than sufficient flexibility.
    Also, I couldn't figure out from the documentation how to do basic web application things like execute custom validation logic, supply error messages and render them on to the page.

    This is shown in the tutorial, in fact.
    How would the authors of Seam suggest implementing an Ajax application with Seam?

    This is not really a question for Seam, rather it is a question for JSF. Some JSF implementations are starting to support Ajax components, in which case it will work Just Great with Seam. I know Jacob Hookom, among others, is doing a lot of thinking about this stuff right now. The declarative state management model of Seam is applicable to all kinds of applications. (Seam-WS is on the horizon.) Certainly, making sure Seam works well with Ajax is a major priority for us.

    By the way, Seam is not a web application framework, and in future we -may- support other Java web frameworks apart from JSF (Tapestry is a likely candidate). We would warmly welcome contributions of integration code for other frameworks.
    Hopefully these things are possible, and it's just the documentation that is a bit lack-lustre at this point.

    Well, I dunno, I think 48 pages of docs in HTML and PDF is a pretty good effort for a first release. ;-) Obviously, that will only improve over time, however, for this release we deliberately emphasized building example applications, since our experience with Hibernate has taught us that most people learn more quickly by looking at examples.
  36. Feedback on Seam[ Go to top ]

    Also, I couldn't figure out from the documentation how to do basic web application things like execute custom validation logic, supply error messages and render them on to the page.
    This is shown in the tutorial, in fact.

    D'oh! Apologies. I re-read the tutorial, and did spot it this time. I'm not a huge fan of JSF, am not familiar with some of the details, and overlooked that.
    Well, I dunno, I think 48 pages of docs in HTML and PDF is a pretty good effort for a first release. ;-) Obviously, that will only improve over time, however, for this release we deliberately emphasized building example applications, since our experience with Hibernate has taught us that most people learn more quickly by looking at examples.

    Come now, if documentation quality was measured by size... Examples are great, but I think they need to be well structured and focused around acheiving a specific goal. That way, when a user needs to solve some problem, they can find documentation and examples relevant to the problem easily. Anyway, I'm sure the documentation will improve with subsequent releases (btw. I'm a huge fan of the hibernate documentation, it's some of the best documentation I've ever seen in an OSS project).

    I gathered that Seam is not a web framework...but I think it does try to tackle some of the problems that many web frameworks attempt to tackle. Notably seamless (ahem) integration with the domain model etc.

    You mention Tapestry as another possible integration. With both JSF and Tapestry falling into the component-oriented camp, have you thought about how Seam might integrate with more action-oriented frameworks like WebWork or (ugh) Struts?
  37. Feeback on Seam[ Go to top ]

    have you thought about how Seam might integrate with more action-oriented frameworks like WebWork or (ugh) Struts?

    I have not put a great deal of thought into it, but my initial intuition is that that two models simply don't make sense together.
  38. Feedback on Seam[ Go to top ]

    Tim,

    Gavin would probably be better to comment on contextual validation, but from a UI standpoint, it's all automatically wired from your Bean's annotations via implicit naming. The public booking demo includes an example of this.

    Pertaining to AJAX, that's a concern of JSF, not of Seam specifically. Since JSF maintains view state, and in this case, conversational state for Seam, maintaining AJAX requests in proper component/model separation shouldn't be an issue. I blogged a bit on Seam and AJAX on Java.net.

    -- Jacob (Facelets)
  39. Feedback on Seam[ Go to top ]

    Yes, I don't understand the assertion that JSF and AJAX don't mix. That's like saying Tapestry and AJAX don't mix, and I don't hear anyone saying that. I also blogged about JSF and AJAX in my response to Rick Hightower's blog a while ago.

    http://weblogs.java.net/blog/edburns/archive/2005/09/clearing_up_jsf.html

    With Shale and now Seam as frameworks choosing to build on top of JSF, I think the value of having a web UI framework as part of the standard enterprise Java platform is starting to become evident. It's very exciting to see such innovation in this area, and I look forward to learning more about Seam. As a leading question, where is Seam with respect to RoR's much vaunted zero deployment time?

    Ed (JSF Spec co-lead)
  40. Feedback on Seam[ Go to top ]

    As a leading question, where is Seam with respect to RoR's much vaunted zero deployment time?Ed (JSF Spec co-lead)

    Please define zero deployment time.
  41. Feedback on Seam[ Go to top ]

    As a leading question, where is Seam with respect to RoR's much vaunted zero deployment time?Ed (JSF Spec co-lead)
    Please define zero deployment time.

    "zero deployment time" is the mercy of dynamic languages. As it is put on http://www.rubyonrails.com: "it means no compilation phase: Make a change, see it work.". So this may come down to the two sides of the "dynamic vs. static typed languages discussion". Indeed: At least in development mode in rubyonrails you'll make a change on your model, controller or view, do a browser refresh and see immediatly what's happening. Without having looked at Seam: How is Seam coping with the fact, that many people find the development cycle of Java and JEE in particular exhausting?
    In detail:
    - Do you have to start a JBoss-Server for development in Seam?
    - What would be it's smallest startup-time in it's most minimal configuration compared to webbrick (development server for rubyonrails) that comes up in "no time"?
    - How long would be a compiling and deployment cycle for something like your demo booking application, even if you combine the necessary steps in a ant configuration (you won't need compiling and deployment in rubyonrails)?
    - Is there a way of working with the pojos directly in a exploded archive in the jboss deployment folder that would come near to "zero deployment time" and needs only the change and a browser refresh as in rubyonrails?
    - Is this way described in the documentation?

    Please note: This isn't meant as a start for another ror vs. java battle, but just as constructive questions on an interesting problem many developers find painful in JEE. As Seam is trying to take some 'easyness' of ror to java - which is in my opinion is a very, very, very important goal - this should be adressed by seam and in it's documentation. Maybe it already is... as I said I hadn't got the time to have a look into Seam.

    best regards
    Jan Prill
  42. Feedback on Seam[ Go to top ]

    It won't fully satisfy you, but on the view part you can make modifications in the exploded directory and see your changes right after a web browser refresh. This is very useful since that's where we lose lot of time (moving stuff around and see what it gives in x y and z browsers).
    You can also change your JSF EL if you made a mistake.

    Now regarding class modification this is something we could look into and have a development mode to listen and compile classes on the fly and put them in the good classloader (like for JSPs).

    Thanks for the feedback Jan.
  43. ror[ Go to top ]

    Do you have to start a JBoss-Server for development in Seam?

    Absolutely not. You can write TestNG integration tests that test all the Java code (but not the facelets/jsp page) running on Seam, inside your IDE. Seam is designed for efficient Test Driven Development.

    If you're not doing TDD, you should be.
    What would be it's smallest startup-time in it's most minimal configuration compared to webbrick (development server for rubyonrails) that comes up in "no time"?

    The startup-time for hot redeploy of a war on Tomcat or ear on JBoss. But I don't have to start the ear/war to run my tests.
    How long would be a compiling and deployment cycle for something like your demo booking application, even if you combine the necessary steps in a ant configuration (you won't need compiling and deployment in rubyonrails)?

    With hot deploy on JBoss, a handful of seconds. But personally, I rarely deploy to the server to test my Java code, I do that in a unit or integration test.

    Testing the facelets or JSP page *is* something I do by deploying to the server, but that's where your next case comes into it:
  44. tss is so broken I had to split the post[ Go to top ]

    Is there a way of working with the pojos directly in a exploded archive in the jboss deployment folder that would come near to "zero deployment time" and needs only the change and a browser refresh as in rubyonrails?

    Certainly, you can work with an exploded archive in JBoss.

    Certainly, with facelets, editing the webpage in the deploy directory and seeing changes immediately is possible.

    Now, scripting languages have a basic advantage over Java in that I can reload classes individually. The JVM won't let me do this. If I want to reload a Java class, I have to kill the classloader and redeploy all of them. This is a pain, and a limitation of current JVM implementations. But, speaking for myself, I don't usually see the need to edit Java code in this way. If I want to develop Java, I *always* do it in the context of a unit or integration test, and in this case hot replace is possible to a certain extent, and "restart" time is negligable.

    So, yes, I'll grant you that the scripting language has the advantage that scripting languages have, and perhaps saves some development time there. OTOH, Java has the productivity advantages that typesafe languages have: compile time checking, IDE autocomplete, wonderful refactoring tools. For me, this actually saves more time.

    I'm a former SmallTalk guy. I loved SmallTalk, and I like Ruby, since Ruby is basically SmallTalk-with-a-different-syntax-but-the-same-class-libraries. But Java is, for me, a *much* more productive environment. You simply cannot, conceptually, implement the same kind of refactoring tools and IDE integration in a language like SmallTalk or Ruby that you can implement in Java. No rename method, even! Yes, think about that for a second. No rename method. It cannot, conceptually, be implemented. If you want to automatically rename a method, you have to rename all methods with the same name! Nor can you really have proper method name autocompletion.

    There are many productivity problems affecting Java at this time, but they are almost all the result of bad infrastructure design, not problems with the core language.
  45. tss is so broken I had to split the post[ Go to top ]

    Indeed. I've just tried about 10x to post, and I'm going to have one more go before I give up.
  46. tss is so broken I had to split the post[ Go to top ]

    Hi Gavin,

    thanks for the detailed answer and kudos for your effort in Seam, Hibernate and EJB3. I'm sharing your thoughts about refactoring and IDE-support in general. I'm not so sure that ruby - and a ruby-written IDE - won't be able to implement refactoring support anyway, but there is no doubt that refactoring has grown to a strength of the great java IDEs available. I'm sure that the dynamic languages guys will make progress in this sector (http://freeride.rubyforge.org/wiki/wiki.pl?RefactoringDynamicLanguages) and since I'm one of the millions of developers without the skills of the GoF I'm stoked that java is keeping up on the sector of easy development in JEE. Dynamic and static typed evolving and learning from each other seems a good thing to me...

    regards
    Jan Prill
  47. Feedback on Seam[ Go to top ]

    Yes, I don't understand the assertion that JSF and AJAX don't mix. That's like saying Tapestry and AJAX don't mix, and I don't hear anyone saying that. I also blogged about JSF and AJAX in my response to Rick Hightower's blog a while ago.http://weblogs.java.net/blog/edburns/archive/2005/09/clearing_up_jsf.htmlWith Shale and now Seam as frameworks choosing to build on top of JSF, I think the value of having a web UI framework as part of the standard enterprise Java platform is starting to become evident. It's very exciting to see such innovation in this area, and I look forward to learning more about Seam. As a leading question, where is Seam with respect to RoR's much vaunted zero deployment time?Ed (JSF Spec co-lead)

    I'd like to point out that I agree with Ed.

    The only disagreement we have is which JSF is the better implementation. I felt that MyFaces RI surpassed the JSF RI. It does not seem to have as many bugs. At one point, the JSF RI seemed a lot less buggy than MyFaces RI, then MyFaces RI seemed more stable than the JSF RI. MyFaces seems to have a lot more frequent releases. This impression is shared by quite a few JSF developers that I worked with.

    Based on Ed's blog... There seems to be a lot of work happening on the JSF RI.

    Ed I just noticed your blog response to my blog and your subsequent comments. Thanks for the clarifications.

    http://jroller.com/page/RickHigh?entry=confusion_about_jsf_1_2

    JSF has a synergistic relationship with AJAX as the JSF components make a good abstraction to deliver AJAX support as Web Gallileo and other frameworks have shown.
  48. Seem seems good, but I love XML[ Go to top ]

    The idea of put all needed things to create a J2EE application in only one place and make it in a declarative way is good.

    But, why use Java (in the old XDocLet style) for declarative programming?
    Why not use XML? XML is perfect to declare things, better than annotations.

    The problem is not XML, the problem are the frameworks that need huge amounts of XML and Java in order to develop something simple.

    But you can just drop Java, and use only XML, in a simple way.

    See OpenXava as an example of this.
  49. Seem seems good, but I love XML[ Go to top ]

    The idea of put all needed things to create a J2EE application in only one place and make it in a declarative way is good.But, why use Java (in the old XDocLet style) for declarative programming?Why not use XML? XML is perfect to declare things, better than annotations.The problem is not XML, the problem are the frameworks that need huge amounts of XML and Java in order to develop something simple.But you can just drop Java, and use only XML, in a simple way.See OpenXava as an example of this.

    I think it is a common misconception that once you start with annotations you are stuck with them. At least in JEE there are XML equivalents to all annotations, so you can RAD with annotations, and switch to XML later if you need, or even have partial XML DDs that override the annotations you need overriding.

    That being said, IMO, it is far easier, less verbose, and more maintainable to express class/method/field/constructor/parameter metadfata using annotations than it is with XML.
  50. Seem seems good, but I love XML[ Go to top ]

    That being said, IMO, it is far easier, less verbose, and more maintainable to express class/method/field/constructor/parameter metadfata using annotations than it is with XML.

    With XML (in OpenXava) you can write something like this:

    <component name="Teacher">

        <entity>
            <property name="id" type="String" key="true"
                size="5" required="true"/>
            <property name="name" type="String"
                size="40" required="true"/>
            <collection name="pupils">
                <reference model="Pupil"/>
            </collection>
        </entity>
                           
        <entity-mapping table="MYSCHOOL@separator@TEACHER">
            <property-mapping property="id" column="ID"/>
            <property-mapping property="name" column="NAME"/>
        </entity-mapping>
                   
    </component>

    And in this elegant way you can obtain a J2EE application with CRUD, Report Generation in PDF, export to Excel, list customization, searching, ordering, etc.

    How many lines of code do you need to obtain this with annotations or Seems?

    Do you see the above XML so ugly?
  51. Re: Seem seems good, but I love XML[ Go to top ]

    One of the problems with externalizing metadata in XML is that it adds a parallel location for information that is already in your entity object. Your example "links" additional metadata to code, but to do it you have to duplicate the structure of that object. Every property, already defined in the object is reproduced, with the additional information.

    When it comes time to maintain this, its another location that you have to worry about keeping in sync. I'm not saying that everything should be squished together, seperation of concerns is still helpful, but those aren't really separate concerns. OpenXava has nice XML, but its still externalized metadata about other objects that already exist. With annotations, if I decide to change the name of a property, I don't have to go search for the XML location and change it there too.
  52. Re: Seem seems good, but I love XML[ Go to top ]

    OpenXava has nice XML, but its still externalized metadata about other objects that already exist. With annotations, if I decide to change the name of a property, I don't have to go search for the XML location and change it there too.

    In the concrete case of OpenXava this is not true, because OpenXava generates the Java code from XML specification, hence if you change the name of a property you only need make the change in XML, not in Java. The essence is: more XML less Java.
  53. Does Seam rely on the EJB tier being passed (and working directly with) the JSF context? If so, what are the pros and cons of such a decision?

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Transactional Caching
  54. Does Seam rely on the EJB tier being passed (and working directly with) the JSF context? If so, what are the pros and cons of such a decision?

    Well, in Seam it doesn't quite make sense to talk of "the EJB tier" as such. The "top" layer of a Seam application is usually a layer of local stateless and stateful session beans (if you are using Seam's client-side conversation state saving, some of them might need remote interfaces, but that's an irrelevant technicality). This top layer is using the web request context, but need not necessarily have any hard code dependencies to artifacts like FacesContext (that is mediated by Seam).

    Now, obviously, the web request context can't be propagated across a remote method call, so if you want to have the flexibility to deploy some components remotely, those components would need to *not* be trying to inject stuff that is bound to any of the contexts associated with the web request (EVENT, CONVERSATION, SESSION). They can still get stuff from the other contexts, I suppose.

    So, if you want this kind of physical deployment, you might still need to layer your application in something that looks more like a traditional J2EE architecture, with the difference that both tiers might very well be implemented using EJBs.

    I don't see any "hard" pros or cons there, its really up to you to worry about what kind of things you want your architecture to support.
  55. Does Seam rely on the EJB tier being passed (and working directly with) the JSF context? If so, what are the pros and cons of such a decision?

    Surely, this approach will allow to combine the advantages of extremely successful EJB technology with very promising and upcoming JSF component model...

    --
    Igor Zavialov
    Factoreal Financial Data and Technical Analysis solutions.
  56. Does Seam rely on the EJB tier being passed (and working directly with) the JSF context? If so, what are the pros and cons of such a decision?
    Surely, this approach will allow to combine the advantages of extremely successful EJB technology with very promising and upcoming JSF component model...

    :-) Well said...

    Nikita.
    GridGain Systems.
  57. Comments[ Go to top ]

    As the JBoss Seam project leader I am really willing to make of Seam the perfect framework for most of the developers.
    That said, there are out there many great frameworks that are only great when they are well used by skilled and careful programmers. One of Seam's goal is really to make everything easier and more robust, where a senior developer and a junior developer would make scalable, readable and reusable applications easily.
    If there was nothing to be done in the Java world we wouldn't have make it, we made it because it worths it.

    Think of Seam as a framework to reduce your development time (and go to the beach once your client's requirements are met) by producing *scalable*, *robust* and *"users and the weird stuff they do"'s proof* applications.

    Now, in this really long thread (45 comments and counting !) where i stayed quiet, there are some constructive comments, while i don't think any specific tool is really necessary for Seam, Neil Turner thinks he needs one, and i am curious to hear about his ideas to make the usage of Seam even simpler.
    Now i am not willing to read pathetic stuff about unrelated and unknown frameworks linked here for the only purpose of publicity/spam, neither ignorant and noisy messages (i don't blame them for being ignorant but for being noisy)

    Please, read our documentation and try out the examples (looking at the code) then comment and let's make Seam answer everybody's needs.

    I am really glad to have feedback and i thank you all for your interest in JBoss Seam. You are more than welcome to leave more constructive comments here, in our forum or by personal email at theute at jboss dot org.

    Gavin and I will present JBoss Seam at the JBoss World Barcelona event on October 10-12th, i will be glad to answer your questions there and meet you all (let me know if you are coming). Yes that was my shameless part of advertisement.
  58. Comments[ Go to top ]

    I have been told by people who know me that my post sounds aggressive that was really not my goal.

    I did let myself go in one sentence, i apologize for that. We are all passionate developers.

    What i really want is feedback (positive and negative), i just want people to try it out before making their own judgement and let you know that i have my ears open to you.

    Sorry if i offended some of you.
  59. Comments[ Go to top ]

    Now i am not willing to read pathetic stuff about unrelated and unknown frameworks linked here for the only purpose of publicity/spam, neither ignorant and noisy messages (i don't blame them for being ignorant but for being noisy)

    Um ... why is Seam posted here if not for publicity? Also, prior to this article SEAM was unknown to many ... so why would we want to read about your "unknown" framework?

    -Adam
  60. Isn't there a standard way of doing it (what happened to JSR 227 ?).
    Is Seam not a vendor lock-in ?
  61. Is Seam not a vendor lock-in ?

    Seam is using POJOs, standard JSF and EJB3 (any EJB3 implementation would work)

    You can use Seam inside JBoss, in any EJB3 container and you will be able to use it in standalone Tomcat.
  62. Is Seam not a vendor lock-in ?
    Seam is using POJOs, standard JSF and EJB3 (any EJB3 implementation would work)You can use Seam inside JBoss, in any EJB3 container and you will be able to use it in standalone Tomcat.

    Our EJB3 container is already embeddable within Tomcat and probably other app servers although I haven't fully tested yet with WLS or Websphere yet. Seam, JBoss, JBoss EJB3 are all open source.

    That being said:

    Isn't Spring vendor lock-in? Spring is a vendor too.

    Bill
  63. That being said:Isn't Spring vendor lock-in? Spring is a vendor too.

    Selecting Spring can be just as much "lock in" as selecting any product. Spring is less intrusive than most approaches, choosing to make the the developer externally declare injection points into pre-existing components, instead of forcing developers to modify the components around the framework.

    I've only taken a brief look at Seam, so I can't judge its invasiveness or lack thereof. I am glad to see efforts being made to find simpler approaches to building applications, though .. RoR is a good wake-up call for overly-complex J2EE web apps.

    I see a lot of Spring+Hibernate+(webframework) .. any comments on whether and where Seam is designed to fit into that stack, or is it intended to replace part of it? e.g. is it being positioned as a Spring replacement?

    Peace,

    Cameron Purdy
    Tangosol Coherence: High-Scale and HA for HTTP Session Management
  64. transparency[ Go to top ]

    I've only taken a brief look at Seam, so I can't judge its invasiveness or lack thereof

    It's very, very transparent, unless you consider annotations non-transparent. Actually, you have probably never seen a an application framework this transparent.

    >> I see a lot of Spring+Hibernate+(webframework) .. any comments on whether and where Seam is designed to fit into that stack, or is it intended to replace part of it?

    Yes, it can fit in there. (Though it is not the main scenario we are pushing.) We will probably soon support spring beans as a variety of STATELESS components.
  65. Isn't Spring vendor lock-in? Spring is a vendor too.
    Interesting Freudian slip, Bill. The other poster didn't mention Spring, yet for some reason, Spring seems to bother JBoss folk greatly.

    One of the aims of Spring is to minimize the impact of the framework on your code. And I think we do a pretty good job of it. Btw, in Oslo last week, Keith Donald gave an example of a Spring Web Flow application (similar in complexity to the Seam example from your tutorial from what I have seen) that contained no Spring Web Flow specific Java code, but could work with an existing POJO that knew nothing about web presentation, Spring in general or the Spring web stack in particular.

    And we are committed to continuing to have Spring work well on all application servers and outside an application server. If users find an issue with Spring on Tomcat, WebLogic, WebSphere (or JBoss) we will take it seriously. And we have no vested interested in trying to favour one application server platform over another. So Spring is neutral to the application server vendor.
  66. tsk[ Go to top ]

    Interesting Freudian slip, Bill. The other poster didn't mention Spring, yet for some reason, Spring seems to bother JBoss folk greatly.

    Well, actually, the second and eighth posters in this thread brought up Spring, and then two employees of interface21, including yourself, used this thread to promote your product, all before anyone before anyone from JBoss mentioned it. If you guys wouldn't have been so noisy in a thread that had nothing to do with you, I'm sure Bill would not have seen the need to mention you.
  67. yawn[ Go to top ]

    One of the aims of Spring is to minimize the impact of the framework on your code. And I think we do a pretty good job of it. Btw, in Oslo last week, Keith Donald gave an example of a Spring Web Flow application (similar in complexity to the Seam example from your tutorial from what I have seen) that contained no Spring Web Flow specific Java code, but could work with an existing POJO that knew nothing about web presentation, Spring in general or the Spring web stack in particular. And we are committed to continuing to have Spring work well on all application servers and outside an application server. If users find an issue with Spring on Tomcat, WebLogic, WebSphere (or JBoss) we will take it seriously. And we have no vested interested in trying to favour one application server platform over another. So Spring is neutral to the application server vendor.

    By the way, I'm committed to not letting this thread turn into a pissing contest, so I'm not going to respond to any of this kind of marketing guff. I'm confident that people will check out Seam and see the value of what it has to offer, and how it is different to other existing frameworks (already over 1000 people tried out the booking demo).
  68. yawn[ Go to top ]

    Gavin

    You took that quote out of context. I was refuting some FUD from Bill. If he hadn't made a gratuitous
    negative comment about Spring, I would not have posted again to this
    thread.

    Rgds
    Rod
  69. Gavin I am really wowed over you JBoss seam framework. I am big fan yours. I would like to ask you one question. When we use @startup, how seam able to lunch at time of deployment. I looked into code; specifically I am referring to ComponentScanner. Is Jboss seam you parse all the .class files in the class path and find out where @startup annotation given and then execute it? If that the case, it’s a serious performance hit in large enterprise application and will take lots of time in deployment and eat up memory. Please help me understand you framework better.
  70. Hi, I am reading quite a lot about Seam. My perception is it cant decouple the two layers. I need to use Seam for my application for integration reasons with ICEFaces. But I am not quite sure how can I decouple the two. Will I get similar performance using a business delegate?
  71. Hi,
    I am reading quite a lot about Seam. My perception is it cant decouple the two layers(presentation and business). I need to use Seam for my application for integration reasons with ICEFaces. But I am not quite sure how can I decouple the two layers. Will I get similar performance using a business delegate?
  72. Seam... has issues[ Go to top ]

    come on guys, Seam is not a bad frame. that said I wrote this article about it today, most of it is basic but it outlines my main issue with seam... which is Jboss :) read it criticize it ;) http://www.ideadex.com/?q=node/6