Discussions

News: One gap that Seam should fill in

  1. One gap that Seam should fill in (72 messages)

    Joshua Jackson has written "One gap that Seam should fill in," a blog posting detailing JBoss Seam's dependency on Hibernate. He says that Seam should provide abstractions to other JPA providers - especially after JPA 2 is finalized and released. Basically, Seam uses stateless session beans and Hibernate for persistence (not surprising, as both are JBoss projects led by Gavin King.) Mr. Jackson says that the session bean reliance isn't so critical as it might seem, because Seam can use POJOs in the business layer as well. However, the Hibernate dependency is a little more important. It means that Hibernate must be bundled with the application for deployment in application servers other than JBoss, "my application file size bigger than it should be." There's a workaround in the existence of a PersistenceProvider interface, which currently only supplies a provider implementation for Hibernate - potentially a problem for someone who doesn't know how to implement their own. Mr. Jackson finishes with this:
    I know that this should not only addressed for Seam, because some of it is because of the JPA spec itself being partially complete at some major area. JPA spec still have some missing parts and that way this missing parts is implemented by each persistence provider. And this implementation is implemented differently by each persistence provider. But at this year’s JavaOne, Linda said that this missing parts will be fixed in the next version of JPA. My hope is that Seam developer can work more closely with other JPA implementation developer besides working close with the JCP so Seam could fill in this missing gap to make Seam as a plug and play JEE5 application framework.
    What do you think? Is Seam's current dependency on Hibernate a problem for non-JBoss application servers? Is application file size (mentioned as a factor in the blog post) an issue? Your Humble Editor believes the application deployer should be able to resolve duplication of Hibernate libraries if it's a problem, but is that a realistic solution for you?

    Threaded Messages (72)

  2. Personally I do not think the dependency on a mature product such as Hibernate is an issue. I am looking at Seam nowadays and I have liked whatever I seen thus far (long way to go though). I personally feel that Seam is a good framework and I would love to use it on a project. For too long frameworks (and specs) have concentrated on solving one part well (UI or backend). Seam fills the gap by making us think of development end-2-end.
  3. Why is there a need for that?[ Go to top ]

    Why is there a need for it? Must Seam be everything to everybody? It is a framework with the purpose to make developing EJB3,POJO+Annotations/JSF Apps easier. And it does a brilliant job at doing exactly THIS. We already have a mature, proven "do-it-all" framework and it is called Spring. So why is this truely necessary? As long as I can write apps in a simple yet powerful programming model and still deploy on Tomcat/JBoss/Glassfish/..., why should we focus the constrained (time) JBoss ressources on doing this?
  4. Why is there a need for it? Must Seam be everything to everybody?

    It is a framework with the purpose to make developing EJB3,POJO+Annotations/JSF Apps easier. And it does a brilliant job at doing exactly THIS.


    We already have a mature, proven "do-it-all" framework and it is called Spring.


    So why is this truely necessary? As long as I can write apps in a simple yet powerful programming model and still deploy on Tomcat/JBoss/Glassfish/..., why should we focus the constrained (time) JBoss ressources on doing this?
    :) another Spring fan, so ... welcome to the Spring party! Seriously, Daniel, have you ever tried Seam? If not, could you try it first then come back and say this feature of Seam can be done in Spring in less amount of time, that feature of Seam is obsolete in Spring and Spring has a better one .....? Or if you don't have time to try Seam because you're spending all your precious time working with Spring, Acegi, Spring Web Flow, JSF ...., could you spare just 1 minute to pray for me to have more free time to learn Seam? Then, maybe I might be able to answer a little bit of your question "Why is there a need for that?". To Bill: your post is quite brief. Could you please provide some links to some documentation saying that Seam doesn't depend on Hibernate (or how to replace Hibernate with something else in Seam)? (I hope you won't tell me "That's what I said. If you want to know further, look for it by yourself" :) ).
  5. Re: Why is there a need for that?[ Go to top ]

    Why is there a need for it? Must Seam be everything to everybody?

    It is a framework with the purpose to make developing EJB3,POJO+Annotations/JSF Apps easier. And it does a brilliant job at doing exactly THIS.


    We already have a mature, proven "do-it-all" framework and it is called Spring.


    So why is this truely necessary? As long as I can write apps in a simple yet powerful programming model and still deploy on Tomcat/JBoss/Glassfish/..., why should we focus the constrained (time) JBoss ressources on doing this?

    :) another Spring fan, so ... welcome to the Spring party!
    Seriously, Daniel, have you ever tried Seam? If not, could you try it first then come back and say this feature of Seam can be done in Spring in less amount of time, that feature of Seam is obsolete in Spring and Spring has a better one .....? Or if you don't have time to try Seam because you're spending all your precious time working with Spring, Acegi, Spring Web Flow, JSF ...., could you spare just 1 minute to pray for me to have more free time to learn Seam? Then, maybe I might be able to answer a little bit of your question "Why is there a need for that?".

    To Bill: your post is quite brief. Could you please provide some links to some documentation saying that Seam doesn't depend on Hibernate (or how to replace Hibernate with something else in Seam)? (I hope you won't tell me "That's what I said. If you want to know further, look for it by yourself" :) ).
    Let me answer this. Why should I? Seam needs to attract me from Spring. If Spring solves me problems, then Seam needs to explain why it is more compelling than Seam as Spring explained why it is more compelling than Seam. Daniel as nothing to prove to Seam or you and thus the burden is on Seam to attract Daniel. How about you answering his question instead of taking the rather overuse tact of forcing both the question and answer on the person who has a legit concern? Many big names like Oracle and Bea directly support Spring and answers like yours won't convince them to support Seam.
  6. Re: Why is there a need for that?[ Go to top ]

    Let me answer this. Why should I? Seam needs to attract me from Spring. If Spring solves me problems, then Seam needs to explain why it is more compelling than Seam as Spring explained why it is more compelling than Seam.
    There is no way on earth that anyone is ever going to "discover" the advantages of an application development paradigm without actually trying it out. Seam is definitely not trying to "prove itself" to people who are too lazy to try new things ;-) If you are completely happy with your current level of productivity in Java application development, good for you, keep doing what you are doing. There is of course a possibility that J2EE + Spring + Hibernate3 is The Most Productive Development Environment That Has Ever Been Or Will Ever Be Known To Mankind. But I doubt it. OTOH, if you think that there is some possibility that human technological progress did not in fact come to a complete halt in 2003, then it is worth your while, as a technology professional, to investigate new ideas and new solutions. The heavyweight contenders today are Rails, Grails, Seam. Don't try them out if you don't want to :-)
  7. Re: Why is there a need for that?[ Go to top ]

    Let me answer this. Why should I? Seam needs to attract me from Spring. If Spring solves me problems, then Seam needs to explain why it is more compelling than Seam as Spring explained why it is more compelling than Seam.


    There is no way on earth that anyone is ever going to "discover" the advantages of an application development paradigm without actually trying it out. Seam is definitely not trying to "prove itself" to people who are too lazy to try new things ;-)

    If you are completely happy with your current level of productivity in Java application development, good for you, keep doing what you are doing. There is of course a possibility that J2EE + Spring + Hibernate3 is The Most Productive Development Environment That Has Ever Been Or Will Ever Be Known To Mankind.

    But I doubt it.

    OTOH, if you think that there is some possibility that human technological progress did not in fact come to a complete halt in 2003, then it is worth your while, as a technology professional, to investigate new ideas and new solutions.

    The heavyweight contenders today are Rails, Grails, Seam. Don't try them out if you don't want to :-)
    I'm sure you think that Seam is up there with the contenders, but you have a bit a bias(and clearly attitude). It is utter arrogance to think that because a particular piece of software was released by a company that has definitely proven capable of attracting combative individuals(some of whom have released some good software) can Do No Wrong. If a tool comes out, the best tool in the world, it has the burden of explaining to tool users why their tool is the best, especially given that competing tools are not standing still. I suppose one can try to scare others into trying something because they may "miss out". Look at the current housing problems in America. Know it alls people convinced others that they should jump on board or be left behind. Pass. If Seam is truly a heavyweight, people other than Gavin King will make it so. Instead of a rather weak attempt to insult me into using your IMO, not heavyweight tool, how about trying, instead, to explain why I should risk my job and those of other people on your software sans the attitude? I mean, unless your job is writing frameworks, most of use have to get things done and solve real problems, not indulge our technological sweettooths on the latest software de jour. The software world is littered with such corpses? Hivemind? Picocontainer? Daikatana? MS Bob, anyone? Hailstorm? Pointcast? Plenty of software done by bigger and smarter guys with more attitude who're convinced that their's was the latest coming that ended in a spectacular flameout. When me over on competence, not attitude.
  8. Re: Why is there a need for that?[ Go to top ]

    I'm sure you think that Seam is up there with the contenders, but you have a bit a bias(and clearly attitude).


    It is utter arrogance to think that because a particular piece of software was released by a company that has definitely proven capable of attracting combative individuals(some of whom have released some good software) can Do No Wrong.
    Gavin's pro-Seam response has less 'attitude' in it than your response to him. For what it's worth, I am a converted Spring user - Seam is much better in terms of productivity; so much better in fact that we are well into the process of shifting the architecture of our (internal) applications away from Spring + Hibernate to Seam + EJB3. So let me be someone to say that I've been happy to "risk my job and those of other people" on using Seam as the 'standard' framework for our applications. BTW - using annotations to express resource dependencies directly on the classes and ORM mappings is indeed a far more productive (and saner) experience than dealing with classes + xml mapping files + spring-xml files. Add in Facelets and your favorite JSF component libs and you can really do just about anything very easily now.
  9. Re: Why is there a need for that?[ Go to top ]


    I'm sure you think that Seam is up there with the contenders, but you have a bit a bias(and clearly attitude).


    It is utter arrogance to think that because a particular piece of software was released by a company that has definitely proven capable of attracting combative individuals(some of whom have released some good software) can Do No Wrong.

    Gavin's pro-Seam response has less 'attitude' in it than your response to him. For what it's worth, I am a converted Spring user - Seam is much better in terms of productivity; so much better in fact that we are well into the process of shifting the architecture of our (internal) applications away from Spring + Hibernate to Seam + EJB3. So let me be someone to say that I've been happy to "risk my job and those of other people" on using Seam as the 'standard' framework for our applications.

    BTW - using annotations to express resource dependencies directly on the classes and ORM mappings is indeed a far more productive (and saner) experience than dealing with classes + xml mapping files + spring-xml files. Add in Facelets and your favorite JSF component libs and you can really do just about anything very easily now.
    First, I haven't generated a hibernate XML file in sometime, do the persistence portions of the XML don't affect me. Second, we don't agree with the Spring XML config items at all. I like it. I think it is quite productive and don't think that annotating my code would be more productive, but the opposite. There are things that I've done and needed to do that runs contrary to having such information tied to code. But that is why choice is important. Third, I don't use JSF. Maybe, *maybe* I would find Seam better for me, than JSF, but I've picked a different direction. I am currently using GWT and after that, my next project will be using DWR. So, you have JSF, Seam, and Facelets. I prefer GWT/Spring/Hibernate and I can also do just about anything very easily. Regardless, you've stumbled upon the value I still attribute to this site and how I personally cope with the volume of frameworks out there. I cannot hope to personally test each and every tool. I don't want to. However, one metric I use is when someone likes a tool, what are the reasons? The annotation item you listed is not an advantage to me so this doesn't translate as a good reason to use a tool...to me. Spring is hardly the end-all. I used something before Spring and I'll use something after it. Ditto for Hibernate. But just as Spring had to *prove* that it was a better solution, so does Seam. Its proud heritage doesn't absolve it of this responsibility. And Spring never claimed to be a heavyweight. Lightweight, yes...
  10. Re: Why is there a need for that?[ Go to top ]

    Third, I don't use JSF. I am currently using GWT
    Same is here.
    and after that, my next project will be using DWR.
    Why? I found GWT superior in many ways. --Mark.
  11. Re: Why is there a need for that?[ Go to top ]


    Third, I don't use JSF. I am currently using GWT

    Same is here.


    and after that, my next project will be using DWR.

    Why? I found GWT superior in many ways.

    --Mark.
    That's what they are using. I've had a great experience with GWT. At the very least, I'll be in a position to compare DWR and GWT. I agree that the component coding of GWT is excellent. Easy, easy, easy. GWT really nails things like that, styling(via CSS), modularizing your app, back-end integration, ease of dev and debugging. The tool is great. Heck, we even using Spring to inject resources into our services. I'm not quite at the point where I want to expose our business objects, which currently get injected into services, as services, but I'm close.
  12. GWT over JSF if you[ Go to top ]

    IMHO DWR is good if you want to add AJAX spices to Struts or JSF application. If you start a new project GWT is right choice. PS What do you use to expose spring beans to GWT services? GWT Server Library or something else? --Mark
  13. Re: GWT over JSF if you[ Go to top ]

    IMHO DWR is good if you want to add AJAX spices to Struts or JSF application. If you start a new project GWT is right choice.

    PS What do you use to expose spring beans to GWT services?
    GWT Server Library or something else?

    --Mark
    You got it! I spent a few days with the that library and currently use the GWT Handler/Spring DispatcherServlet combination. I'm not fully certain I've considered all the ramifications of exposing the beans directly, so I went the GWTHandler route, with a couple of threadlocals to hold the request and response.
  14. The software world is littered with such corpses? Hivemind? Picocontainer?
    Don't want to get into an argument or something, but imho those calling Hivemind and picocontainer failures is not fair. They seem to do the job alright, and they have some community around them. I think too often people are focussed on frameworks that have the largest market share rather than whether they are just OK projects that do the job.
  15. The software world is littered with such corpses? Hivemind? Picocontainer?


    Don't want to get into an argument or something, but imho those calling Hivemind and picocontainer failures is not fair. They seem to do the job alright, and they have some community around them. I think too often people are focussed on frameworks that have the largest market share rather than whether they are just OK projects that do the job.
    I don't disagree, but marketshare does matter. I've recently been checking out the job market and no one has asked if I had Picocontainer experience. Marketshare drives demand and demand is what puts money in our pockets. The best situation is when that demand is driven by excellence. Regardless, this is business, not personal and business isn't fair. There were some great pieces of software that bought it and it wasn't fair. But remember, the creator of Hivemind and Tapestry dropped Hivemind in Tapestry 5 for some internal IOC container. How fair was that for those who jumped on the Tapestry 4 and Hivemind bandwagon?
  16. I've recently been checking out the job market and no one has asked if I had Picocontainer experience. Marketshare drives demand and demand is what puts money in our pockets. The best situation is when that demand is driven by excellence.

    Regardless, this is business, not personal and business isn't fair. There were some great pieces of software that bought it and it wasn't fair.
    All I'm saying is that I don't care about whether a framework is in demand or not. I just want it to do the job well. Listings on job sites are overrated anyway if you ask me. I mean, spend an hour toying around and you know how picocontainer/ spring/ hivemind works. Spend a few days, read a book and browse the sources, and you're well on your way being an expert. :)
  17. I've recently been checking out the job market and no one has asked if I had Picocontainer experience.
    Marketshare drives demand and demand is what puts money in our pockets. The best situation is when that demand is driven by excellence.

    Regardless, this is business, not personal and business isn't fair. There were some great pieces of software that bought it and it wasn't fair.


    All I'm saying is that I don't care about whether a framework is in demand or not. I just want it to do the job well. Listings on job sites are overrated anyway if you ask me. I mean, spend an hour toying around and you know how picocontainer/ spring/ hivemind works. Spend a few days, read a book and browse the sources, and you're well on your way being an expert. :)
    You didn't read what I said. I said "I've recently been checking out the job market and no one has asked if I had Picocontainer experience." I didn't say anything about any job listing site, did I? You may not care whether something is in demand or not, but I'd believe, perhaps erroneously, that demand drives compensation. Not only have I had success using frameworks, but the demand for that experience has directly translated into demand for me. Now, demand for me may not be important to you, but it is pretty critical for...well, me.
  18. Seam looks compelling to me[ Go to top ]

    The one object model on both web and persistence tiers is compelling - makes handling it all mentally easier. Having the web/JSF beans, the EJB facade beans, and JPA beans all using the same object model, and annotations, makes the whole thing easier to understand. Annotations is much more attractive to me than reams of XML configuration. For one, annotations are easier to read, and more pleasant on the eye than noisy, ugly XML. Two, annotations make the Java classes more self documenting/descriptive of what they are doing, and how they fit with the larger project picture. Having separate XML config files make understanding/debugging/writing the Java classes, and fitting them with other Java classes, harder (for me). True, you have to put the proper annotations in all the classes, and in a large project that could be hundreds (as opposed to a single, or a handful of, XML config file(s). But you have to go look at every class anyway, in order to make sure the XML configuration is correct. To me, that process is extremely tedious and error prone (and harder to debug). For me, using annotations is a cleaner, easier, more elegant solution than XML config. Frankly, I always hated XML config for big Enterprise Java apps. I always found it messy, ugly, tedious, complex, and error prone. That said, the latest releases of Spring apparently support annotations as well, so that's a good thing. Seam also does a good job of state management, especially when it comes to Ajax enabled applications.
  19. Re: Why is there a need for that?[ Go to top ]

    It is utter arrogance to think that because a particular piece of software was released by a company that has definitely proven capable of attracting combative individuals(some of whom have released some good software) can Do No Wrong.
    Ahem. Where did I say or imply that? Quote?
    If a tool comes out, the best tool in the world, it has the burden of explaining to tool users why their tool is the best, especially given that competing tools are not standing still.
    I have written many pages of documentation explaining all that, and written many example applications to demonstrate it. In addition, there are several very readable articles about Seam available on the web. Those who are interested, and motivated to investigate further, have plenty to work from. I don't think there is a need to reiterate the advantages of Seam in every single TSS thread.
    I suppose one can try to scare others into trying something because they may "miss out".
    Where did I try to scare people? Quote?
    Look at the current housing problems in America. Know it alls people convinced others that they should jump on board or be left behind.
    How is that relevant? Where did I imply that anyone was being "left behind"?
    If Seam is truly a heavyweight, people other than Gavin King will make it so.
    Undoubtedly true. Open source projects live and die by their community. Seam has a very large, active, enthusiastic user community, which we're very thankful for.
    Instead of a rather weak attempt to insult me into using your IMO, not heavyweight tool, how about trying, instead, to explain why I should risk my job and those of other people on your software sans the attitude?
    Where did I insult you? Quote? Dude, I'm not trying to convince you to use Seam. I honestly don't care what you use. Use what works for you. I was merely replying to your fairly aggressive assertion that Seam was somehow at fault for not selling itself hard enough to you. All I said is "it is worth your while, as a technology professional, to investigate new ideas and new solutions". All I'm saying is that good stuff can sometimes take some effort to fully appreciate. It's completely up to you which frameworks you choose to spend time on.
    I mean, unless your job is writing frameworks, most of use have to get things done and solve real problems, not indulge our technological sweettooths on the latest software de jour. The software world is littered with such corpses? Hivemind? Picocontainer?
    You're right. Just look at such "technological sweettooths" as Hibernate? Spring? Lucene? JPA? Oh, wait...
    Daikatana? MS Bob, anyone? Hailstorm? Pointcast? Plenty of software done by bigger and smarter guys with more attitude who're convinced that their's was the latest coming that ended in a spectacular flameout.
    I object in the strongest terms to your assertion that the creators of these failed products have more attitude than me. My attitude is the biggest and the shiniest and the hardest.
    When me over on competence, not attitude.
    Seriously, my attitude is really, really big - you should use Seam for that reason alone.
  20. Re: A suggestion[ Go to top ]

    Just another topic, I think the “Component” should add an extensible mechanism, or to say the “Component” should be configurable. The idea comes with my recent project, when I use the "@Restrict" attribute, I want also check the method's params, like whether it's current user's id. I changed the SecurityInterceptor to achieve that, but a better way may be that to replace the SecurityInterceptor with your customized one, and of course it can be done with an xml configure file. But seam doesn’t support that currently. And sometimes we also need to add our own annotations to the component and to support the customized Interceptors or any other features (not only Interceptors). I think it will be more flexible and fit our needs better. Sorry for my poor English. Hope I have made myself clear.
  21. Re: Why is there a need for that?[ Go to top ]

    Well, you've got a pretty big attitude(and reason for it), but John Romero was going to make all of us his b*tch. However, I disagree that Seam or any framework doesn't have to sell itself. Rod made Spring's case and I don't think it is unreasonable to think that Gavin should make Seam's. I didn't say that it had to be Gavin doing it for every post. I did challenge the assertion that that (Daniel?), necessarily had to try it the way the other poster declared. I think that it is the framework's job to convince me. Struts did. Hibernate did. Spring did. There are far to many tools to give each and everyone a test drive so, to me, a site like TSS is the place to go to find out if something is worth trying. Thai's suggestion, IMO, should have been to go to one of those resource sites you mentioned and if you can accept the philosophy of Seam, then move on to the next step of trying it out.
  22. Re: Why is there a need for that?[ Go to top ]

    The heavyweight contenders today are Rails, Grails, Seam.
    Spring is promoted by developers(read customers) while Seam is promoted by it's lead (read producer) Will you believe to producer or to customer? From my personal experience Seam is nothing but advertisement.
    Advertisement N1 JBoss Seam is a powerful new application framework for building next generation Web 2.0 applications
    Let's have a look what Seam provides for Web2.0. -JSF is the answer. Is JSF is good for Web2.0? -No is the answer (who thinks different try to implement hierarchical grid or any component you don't have in you JSF lib in GWT and in JSF manually). Seam claims it has support for GWT but it is less than minimal. You can't even start a transaction on start of GWT service. In other words Seam is only for JSF, while JSF doesn't work well for AJAX. Look GWT,Echo2 or at least at DWR to find out how a real Web2.0 framework looks like. Let's look on other ads.
    Advertisement N2 A revolutionary approach to state management
    Guys invented statefull beans ;-)
    Advertisement N3 Easy integration testing
    Guys have a look at Spring test classes and compare it with what seam provides ;-) At least Seam guys didn't bring anything new.
    Advertisement N4 Premium Subscription: 1 business hour response time.
    Fact - response time often more that 3 days. PS Guys (from Red Hat/JBoss/ JHAT or what ever you call yourself today) please spend more time on making your product better, and you won't have to spend so much on advertisement. --Mark
  23. Re: Why is there a need for that?[ Go to top ]

    From my personal experience Seam is nothing but advertisement.
    From my personal experience, Seam is one of the most elegant, cleanest framework designs i have ever seen. The unified component model, pervasive use of EL, etc. It's just brilliant. However, for the next platform, i still chose Spring based stack (Spring, Spring Web Flow, Acegi). The functionality is pretty much equal, but Spring has much wider knowledge base and really shines when it comes to stable, well-documented, realistic, no-hype solutions and support, without attitude. /Henri Karapuu

  24. Advertisement N4
    Premium Subscription: 1 business hour response time.


    Fact - response time often more that 3 days.

    PS
    Guys (from Red Hat/JBoss/ JHAT or what ever you call yourself today) please spend more time on making your product better, and you won't have to spend so much on advertisement.
    Indeed. The support goes with HUGE delays. And the quality of support isn't impressing. E.g. When we found out the bug in Hibernate 3.x second level cache management it took them 4 days to answer the question. And the answer was - yes it is a bug. Next we asked for at least JIRA ticket id. 2 days later was next response. Despite it hibernate seems getting better. IMHO JBoss saved it's ass when they bought this project. As for SEAM – they backed the wrong horse - jsf and ejb. Probably it is a candy for those who have to use jsf and ejb. IMHO jsf and ejb(even these days) are too heavy, slow, and have HUGE problems with portability. I recommend GWT & Spring & Hibernate. Regards, Vitaliy S
  25. Re: Why is there a need for that?[ Go to top ]

    Is JSF is good for Web2.0?-No is the answer (who thinks >different try to implement hierarchical grid or any >component you don't have in you JSF lib in GWT and in JSF >manually).
    It's very simple instead. There are tons of components out there, and if you don't find the one for you, you can implement the new component. Don't want to implement a new one? Ok go on with ui:repeat tag and so on as you would do in JSP.
    Seam claims it has support for GWT but it is less than minimal.
    No It claims an *experimental* GWT support. Be honest please!
    In other words Seam is only for JSF, while JSF doesn't work
    well for AJAX. That's absolutely wrong. There are tons of ajax component library. there are also many library that add very transparently ajax to JSF (ajax4jsf, dynafaces for example). It's very simple to use Ajax in JSF.
  26. Re: Why is there a need for that?[ Go to top ]

    In other words Seam is only for JSF, while JSF doesn't work well for AJAX. That's absolutely wrong. There are tons of ajax component library. there are also many library that add very transparently ajax to JSF (ajax4jsf, dynafaces for example). It's very simple to use Ajax in JSF.
    I've seen enough of JSF projects with NetAdvantage and IceFaces and each of this project a lot of javaScript code. Be honest with yourself JSF was invented without AJAX in mind. It is hard to perform client side rendering with JSF. Have a look on IceFaces or NetAdvantage demo with Firefox. Bugs bugs bugs... and support at least for NetAdvantage work same way as JBoss. Delays... Delays.... (We didn't try IceFaces support) JSF components are not customizable enough. It is hard to use these components as blocks. Because JSF is made of Components not of Classes. You can not inherit from Component. By the way how do you like JSF Compoments "interoperability"? - try to use IceFaces with NetAdvantage ;-) Oops doesn't work. Ok try to use NetAdvanate with Seam. Oops... last NA supports Seam. But what does it mean? You can't just place any JSF component in Seam? WHY? I hope you know the answer. Do you? Ok, you'll have time to think, lets continue... Want to have troubles with integration of your Ajax application into JSR 168 Portal. Try JSF. If you don't - try GWT since it uses client side rendering.
    Seam claims it has support for GWT but it is less than minimal. No It claims an *experimental* GWT support. Be honest please!
    I'm honest - the support is less than minimal. PS You didn't try GWT or even Spring don't you? ;-) Have a look and we will talk later.
  27. Re: Why is there a need for that?[ Go to top ]

    I've seen enough of JSF projects with NetAdvantage and IceFaces and each of this project a lot of javaScript code.
    So give a look at Ajax4JSF, DynaFaces, RichFaces, Woodstock.
    Be honest with yourself JSF was invented without AJAX in mind.
    It has invented with pluggability in mind, and it is almost enough for ajax too.
    It is hard to perform client side rendering with JSF.Have a look on IceFaces or NetAdvantage demo with Firefox.Bugs bugs bugs... and support at least for NetAdvantage work same way as JBoss. Delays...
    I see you are focusing only on 2 component library. I have nevert tried them. I tried happly many other component library instead. As I said, give a look at RichFaces, Ajax4jsf for example. No need for javascript coding, and you can still compose a very rich client interface.
    Because JSF is made of Components not of Classes. You can not inherit from Component.
    Uh? You can subclass the component. You can also customize/override the renderer.
    By the way how do you like JSF Compoments "interoperability"? - try to use IceFaces with NetAdvantage ;-) Oops doesn't work.
    This is the only ajax - jsf issue. This gap will be filled in the release I think, standardizing the ajax lifecycle. But this issue come from also the great number of component library in the JSF world, something that other framework can't see.
    I'm honest - the support is less than minimal.
    I wouldn't count on an experimental support. I don't know what you want to say. It is experimental, it is there to be improved not to be used.
    PS You didn't try GWT or even Spring don't you?
    GWT no, Spring yes.
  28. Re: Why is there a need for that?[ Go to top ]


    I've seen enough of JSF projects with NetAdvantage and IceFaces and each of this project a lot of javaScript code.


    So give a look at Ajax4JSF, DynaFaces, RichFaces, Woodstock.
    I tried Ajax4JSF as well and RichFaces (but not in production). Ajax4JSF doesn't have rich components combining this fact that JSF ajax libs have problems with «interoperobility» and developing own component in JSF is very tidios and error prone (yet another problem of JSF it is hard to develop own components) we have a conclusion – JSF don't feet well for AJAX .

    Be honest with yourself JSF was invented without AJAX in mind.
    It has invented with pluggability in mind, and it is almost enough for ajax too.
    Almost? ;-) JSP was invented with pluggability in mind too. I'm not sure JSP is not good for AJAX dispite you can do AJAX soulutions with JSP.

    It is hard to perform client side rendering with JSF.Have a look on IceFaces or NetAdvantage demo with Firefox.Bugs bugs bugs... and support at least for NetAdvantage work same way as JBoss. Delays...


    I see you are focusing only on 2 component library.
    Wrong, I just mention the most reach libraries. You see you try to defend technology without trying others? You didn't try DWR, you didn't try GWT, but you belive that JSF is good for AJAX. Comparing with what? With Ruby on Crutches?

    Because JSF is made of Components not of Classes. You can not inherit from Component.


    Uh? You can subclass the component. You can also customize/override the renderer.

    You forgot to mention xml files. How many JSF components you extended? How many your own JSF components did you create? Didn't you find it that it is extremely hard to create new ajax JSF component?

    By the way how do you like JSF Compoments "interoperability"? - try to use IceFaces with NetAdvantage ;-) Oops doesn't work.
    This is the only ajax - jsf issue. May I add several more the only issues? You can't debug your AJAX rendering. You can not easy write unit tests for it. You can't extend you AJAX components.
    This gap will be filled in the release I think, standardizing the ajax lifecycle. But this issue come from also the great number of component library in the JSF world, something that other framework can't see.
    PS You didn't try GWT or even Spring don't you? GWT no, Spring yes.
    You didn't try other frameworks and say others don't have such libraries? FYI: GWT has more compoments than each of JSF library has. There are many open source GWT based libs and they are compatible with each other. PS I suggest to continue conversation when you evaluate GWT,ECHO2 and DWR and after that you'll tell me does JSF fits for AJAX or not.
  29. Re: Why is there a need for that?[ Go to top ]

    I don't believe that GWT has more components than say, Icefaces. However, I do think that GWT makes it easier to craft your own components. I think GWT exceeds the usability of even a facelets-enabled JSF when combined with something like GWT Designer. However, I'm still getting a feel for things such as display large(say several thousands rows) of data in GWT. I don't have an ultimate answer. How do you handled such a thing in a table?
  30. I don't believe that GWT has more components than say, Icefaces.
    GWT 1.4 has more components than Icefaces and also you should count the amount of free components that are available to a project. With GWT you can use GWT window manager, GWT DND and many others. With JSF you stick to one AJAX vendor solution.
    However, I do think that GWT makes it easier to craft your own components.

    I think GWT exceeds the usability of even a facelets-enabled JSF when combined with something like GWT Designer.
    I've never tried GWT Designer, does it worth tring?
    However, I'm still getting a feel for things such as display large(say several thousands rows) of data in GWT. I don't have an ultimate answer. How do you handled such a thing in a table?
    These are my solutions: 1. Server side rendering. Draw rows on server and post to client. 2. Use paging. 3. use IncrementalCommand() to prevent browser not responding messages. Regards, Vitaliy S
  31. I think that the GWT is definitely worth trying. For putting together front-ends, it is fantastic. You will, of course, have to refactor and clean the code it generates, but you can prototype screens very quickly.
  32. I don't believe that GWT has more components than say, Icefaces. However, I do think that GWT makes it easier to craft your own components.
    And that is a major advantage. Personally, I much prefer a framework that makes it easy to create exactly what I need than a framework that doesn't but ships with a load of components that all *almost* do what I want.
  33. Even GWT is not the silver bullet[ Go to top ]

    PS You didn't try GWT or even Spring don't you? ;-)
    Have a look and we will talk later.
    GWT must be nice to work with, and has a fantastic design, but it is not perfect (not technology is). It is great if you need to develop an applet-like web app, where an initial big load is acceptable, bookmarkability and searchability is not a primary concern, you're ok with a disconnected datamodel, you're ok with it working with layout managers and if don't have to support a non-ajax UI. If not, there are better choices.
  34. PS You didn't try GWT or even Spring don't you? ;-)
    Have a look and we will talk later.


    GWT must be nice to work with, and has a fantastic design, but it is not perfect (not technology is). It is great if you need to develop an applet-like web app, where an initial big load is acceptable, bookmarkability and searchability is not a primary concern, you're ok with a disconnected datamodel, you're ok with it working with layout managers and if don't have to support a non-ajax UI. If not, there are better choices.
    Wrong. First, the load isn't necessarily that big. It depends on a slew of factors. Also, you can bookmark GWT pages. I've done it. I'm sure what you mean by applet-like web app.
  35. PS You didn't try GWT or even Spring don't you? ;-)
    Have a look and we will talk later.


    GWT must be nice to work with, and has a fantastic design, but it is not perfect (not technology is). It is great if you need to develop an applet-like web app, where an initial big load is acceptable, bookmarkability and searchability is not a primary concern, you're ok with a disconnected datamodel, you're ok with it working with layout managers and if don't have to support a non-ajax UI. If not, there are better choices.



    Wrong. First, the load isn't necessarily that big. It depends on a slew of factors. Also, you can bookmark GWT pages. I've done it.

    I'm sure what you mean by applet-like web app.
    I think you misunderstood what I said. I am not saying any of these things aren't possible with GWT, but rather I'm saying that there are better choices (imho that is) than GWT if these things are a primary concern in your applications. With applet-like development I mean what many people nowadays call a single page approach.
  36. Re: Why is there a need for that?[ Go to top ]

    The heavyweight contenders today are Rails, Grails, Seam.
    Yes, and this indisputable fact is also supported by i.e. job statistics: http://www.indeed.com/jobtrends?q=java+spring%2C+java+ejb%2C+java+seam%2C+java+grails&l= Indeed, it is a rare sight to see a major bank these days that does not solely rely on Groovy in their core logic. Meaning: what the heck are you talking about. Heavyweight in what sense? Certainly not a current market penetration. /Henri Karapuu
  37. Re: Why is there a need for that?[ Go to top ]

    The heavyweight contenders today are Rails, Grails, Seam.


    Yes, and this indisputable fact is also supported by i.e. job statistics: http://www.indeed.com/jobtrends?q=java+spring%2C+java+ejb%2C+java+seam%2C+java+grails&l=

    Indeed, it is a rare sight to see a major bank these days that does not solely rely on Groovy in their core logic.

    Meaning: what the heck are you talking about. Heavyweight in what sense? Certainly not a current market penetration.

    /Henri Karapuu
    Job statistics reflect the success of previous or current generation technologies (of course). The full-stack web frameworks I listed represent the next generation. Did you even drill into the job statistics for Seam to see this interesting curve? http://www.indeed.com/jobtrends?q=jboss+seam&l= :-)
  38. Re: Why is there a need for that?[ Go to top ]

    Job statistics reflect the success of previous or current generation technologies (of course). The full-stack web frameworks I listed represent the next generation.
    Well, you said "the heavyweight contenders today", which is entirely different thing than "the most promising contenders for tomorrow" .. Seam is a great framework and i see a very bright future for it, but lets not jump ahead of things. /Henri Karapuu
  39. interesting stats[ Go to top ]

    Did you even drill into the job statistics for Seam to see this interesting curve?

    http://www.indeed.com/jobtrends?q=jboss+seam&l=

    :-)
    It's only going to take a handful of people getting jboss + seam jobs to make the jboss+seam curve move in any sort of upwards, as opposed to zero and sideways direction. 0.15 % of jobs (java/spring) divided by 0.001 % of jobs (jboss/seam) is roughly a 150x difference in the number of jobs. I use Spring/Spring Webflow/JBoss/Hibernate at the moment, have tried to read up on Seam. It looks interesting but haven't used it whatsoever.
  40. Re: interesting stats[ Go to top ]

    It's only going to take a handful of people getting jboss + seam jobs to make the jboss+seam curve move in any sort of upwards, as opposed to zero and sideways direction. 0.15 % of jobs (java/spring) divided by 0.001 % of jobs (jboss/seam) is roughly a 150x difference in the number of jobs.
    Thanks for this hint.
  41. i USE seam ;)[ Go to top ]

    Seriously, Daniel, have you ever tried Seam? If not, could you try it first then come back and say this feature of Seam can be done in Spring in less amount of time, that feature of Seam is obsolete in Spring and Spring has a better one .....?
    It is quite funny to read that. I use Seam right now in a project I am developing on. Not only that but I contributed my first experiences of Red Hat Developer Studio Beta 1 to the JBoss Forums to help them get this beast stable and solid (it already looks insanely great). But please, under any circumstances, never underestimate what Spring has done for J2EE in the past years.
  42. Why is there a need for it? Must Seam be everything to everybody?
    Of course it does. The whole point of JPA is that you can plug-and-play any JPA provider to your application as long as your code adhere to the JPA API. That's the whole point why they formed JCP. But if you can only use Hibernate as the JPA provider in Seam, what's the whole point? You might as well use Hibernate API instead of JPA API then.
  43. Why not use GWT[ Go to top ]

    I might be confused but why not use a true fat client development tool like GWT instead of a hack like JSF ? Sure the widgets arent there yet but there are many addons for GWT that are making it a player today and a player tomorrow.
  44. Re: Why not use GWT[ Go to top ]

    I might be confused but why not use a true fat client development tool like GWT instead of a hack like JSF ?

    Sure the widgets arent there yet but there are many addons for GWT that are making it a player today and a player tomorrow.
    I've been enjoying my GWT experience. I think, for example, that GWT "got it right" in terms of component creation. Combined with a tool such as GWT Designer, an Eclipse plugin, has made for an awesome development experience.
  45. Re: Why is there a need for that?[ Go to top ]

    Why is there a need for it? Must Seam be everything to everybody?

    Of course it does. The whole point of JPA is that you can plug-and-play any JPA provider to your application as long as your code adhere to the JPA API. That's the whole point why they formed JCP. But if you can only use Hibernate as the JPA provider in Seam, what's the whole point? You might as well use Hibernate API instead of JPA API then.
    You can use any JPA provider with Seam. If you want to use some "special" features of Hibernate (atomic persistence contexts, filters) you need to use Hibernate.
  46. It is an issue[ Go to top ]

    At jbilling, we are in the process of migrating from entity beans to JPA. We rather not have a dependency on Hibernate, even if it is a great and mature product. Even if we end up with Hibernate dependencies, we'll minimize this as much as possible. Seam is an option in the future for us, but it would help us adopt it earlier if its dependency was on JPA, rather than Hibernate. Paul Casal Sr Developer jbilling.com The Enterprise Open Source Billing System
  47. Seam isn't Hibernate dependent.
  48. Get it right[ Go to top ]

    Seam isn't Hibernate dependent.
    Neither is it dependent on EJBs.
  49. Re: Get it right[ Go to top ]

    Seam isn't Hibernate dependent.


    Neither is it dependent on EJBs.
    This is true partly. It does depend on hibernate validator, which is in principle can work with any other JPA provider (in theory, I am not sure if someone got it working with non-hibernate JPA provider). But in general yes, it's supposed to work with any JPA provider - not only hibernate.
  50. Re: Get it right[ Go to top ]

    This is true partly. It does depend on hibernate validator, which is in principle can work with any other JPA provider (in theory, I am not sure if someone got it working with non-hibernate JPA provider).

    But in general yes, it's supposed to work with any JPA provider - not only hibernate.
    It is my understanding that that is only true if you want to do validations. If you don't want to use 'em for whatever reason, you don't need any Hibernate jars at all.
  51. no dependency on hibernate[ Go to top ]

    Seam doesn't depend on hibernate validations, it allows the use of them if you want to use them. In any event, I'm fairly sure the use of hibernate validations does not require the full use of hibernate, but I've not looked closely enough. Seam has NO hard dependency on Hibernate. When using JPA, any persistence provider can be used. I recall reading blogs from the sun guys on how to use toplink with Seam. There are some features like FlushMode.MANUAL which are not supported by JPA, which Seam can make use of if your persistence provider is Hibernate. We've been very public about our willingness to support other persistence vendors extensions for these things too, but I don't think you can fault Seam much for not being super-aggressive about hounding other JPA providers to improve their functionality. When not using JPA, Seam can use Hibernate directly. The code is abstract enough that it would be very easy to add direct support for another persistence provider. The hooks are there, and the code required is very minimal. We have a large community and if there were any real interest in it, I am very sure that someone in the community would have already stepped up. However, it's clear that the overwhelming majority of users are very happy using Hibernate and don't find adding a couple of hibernate JARs to their app to be an issue.
  52. >Seam has NO hard dependency on Hibernate.
    I worked on Wicket-Seam integration, and have a very simple example project here: http://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-seam-test That project does not use persistency in any way, but if I remove Hibernate and start it up, it will try to autostart a component that depends on Hibernate validators and will throw a NoClassDefFoundError (org/hibernate/validator/ClassValidator). Besides that, it needs dependencies such as EL and JSF and quite a bunch of others to just get started. Imho, there's definitively something to improve here.
  53. Re: no dependency on hibernate[ Go to top ]

    >Seam has NO hard dependency on Hibernate.


    I worked on Wicket-Seam integration, and have a very simple example project here: http://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-seam-test

    That project does not use persistency in any way, but if I remove Hibernate and start it up, it will try to autostart a component that depends on Hibernate validators and will throw a NoClassDefFoundError (org/hibernate/validator/ClassValidator).

    Besides that, it needs dependencies such as EL and JSF and quite a bunch of others to just get started. Imho, there's definitively something to improve here.
    Yes, Hibernate Validator is required for the model-based validation stuff. Hibernate Validator is not the same thing requiring Hibernate as the persistence provider.
  54. Re: no dependency on hibernate[ Go to top ]

    Yes, Hibernate Validator is required for the model-based validation stuff. Hibernate Validator is not the same thing requiring Hibernate as the persistence provider.
    Yeah, I got that. However, the thing that I missed was that hibernate-validator has a separate release. I changed the project to include just that, and that works fine.
  55. Re: Get it right[ Go to top ]

    You've got it partially right there Bill. Seam is not dependent on EJB3, you've got this right. But if you use POJO as the business layer in Seam, it is definitely dependent on Hibernate even if you use JPA as the persistence layer because Seam only provides HibernatePersistenceProvider :)
  56. Re: Get it right[ Go to top ]

    Joshua, PersistenceProvider is the general class that can handle any JPA compliant provider. From it's javadocs: "Abstraction layer for persistence providers (JPA implementations). This class provides a *working base implementation* that can be optimized for performance and non-standardized features by extending." Notice the "working base implementation" in there ? HibernatePersistenceProvider is the implementation that allows you to use hibernate specific features. If you move to another JPA provider you will of course not have access to these - so use the PersistenceProvider. So no - Seam is not dependent on Hibernate.
  57. Re: Get it right[ Go to top ]

    You've got it partially right there Bill. Seam is not dependent on EJB3, you've got this right. But if you use POJO as the business layer in Seam, it is definitely dependent on Hibernate even if you use JPA as the persistence layer because Seam only provides HibernatePersistenceProvider :)
    You have misunderstood the reason for the PersistenceProvider interface. For PeristenceProvider abstracts certain features of Hibernate that were not standardized by EJB 3.0, allowing Seam to use them without a hard dependency upon Hibernate. If some other JPA provider provides an equivalent of FlushMode.MANUAL, for example, you could implement MyPersistenceProvider and get atomic persistence contexts with that provider, just like you can get them with Hibernate. However, the base PersistenceProvider implementation works with *all* JPA implemenentations and supports 90% of the functionality of Seam. Basically, the only major feature you miss out upon by choosing TopLink over Hibernate (for example) is atomic persistence contexts. Once TopLink provides an equivalent of FlushMode.MANUAL, we can support that via a TopLinkPersistenceProvider. So this is a mechanism for supporting *extra*, non-standard, features of the JPA provider. Going forward, my expectation is that all the operations of PersistenceProvider will be rolled into JPA 2.0 and we will no longer need this extra abstraction.
  58. Re: Get it right[ Go to top ]

    the only major feature you miss out upon by choosing TopLink over Hibernate (for example) is atomic persistence contexts. Once TopLink provides an equivalent of FlushMode.MANUAL
    Wouldn't it be possible to achieve the same in toplink by not binding the PersistenceContext to transaction until you want the changes flushed to DB? /Henri Karapuu
  59. Re: Get it right[ Go to top ]

    the only major feature you miss out upon by choosing TopLink over Hibernate (for example) is atomic persistence contexts. Once TopLink provides an equivalent of FlushMode.MANUAL


    Wouldn't it be possible to achieve the same in toplink by not binding the PersistenceContext to transaction until you want the changes flushed to DB?

    /Henri Karapuu
    Yeah, I have not completely thought through all the implications of that, but that is probably a reasonable way to support atomic persistence contexts for JPA providers other than Hibernate. I'll look into it more closely: http://jira.jboss.org/jira/browse/JBSEAM-1837
  60. Re: Get it right[ Go to top ]

    the only major feature you miss out upon by choosing TopLink over Hibernate (for example) is atomic persistence contexts. Once TopLink provides an equivalent of FlushMode.MANUAL


    Wouldn't it be possible to achieve the same in toplink by not binding the PersistenceContext to transaction until you want the changes flushed to DB?

    /Henri Karapuu


    Yeah, I have not completely thought through all the implications of that, but that is probably a reasonable way to support atomic persistence contexts for JPA providers other than Hibernate.

    I'll look into it more closely:

    http://jira.jboss.org/jira/browse/JBSEAM-1837
    Unfortunately this approach does not really work out, since we don't usually know that the PC is atomic when we create it / inject it / first call it. :-(
  61. Re: Get it right[ Go to top ]

    Unfortunately this approach does not really work out, since we don't usually know that the PC is atomic when we create it / inject it / first call it. :-(
    Perhaps you can delay binding PC to transaction until first actual call. If @Begin(FlushMode=MANUAL) appears before the first call then the first call would still not bind pc to tx, that would be done only when em.flush() is called. I'm using the 'pc without tx' style with Spring Web Flows, and it seems to work well enough in practice, although i have not yet fully tested it (i.e. what is the exact impact to tx isolation levels). /Henri Karapuu
  62. Re: Get it right[ Go to top ]

    Going forward, my expectation is that all the operations of PersistenceProvider will be rolled into JPA 2.0 and we will no longer need this extra abstraction.
    Great. I'm looking forward too for the revised version of JPA 2.0. Keep up the good work :)
  63. The premise of the original post is incorrect. (1) Seam can work with any JPA implementation, as demonstrated in the example application that deploys to GlassFish/TopLink (2) Hibernate Validator can work with any JPA implementation As an *alternative* to the above, you can use Hibernate3 APIs instead of JPA APIs, but this is your choice.
  64. The premise of the original post is incorrect.

    I think that is because you didn't get the whole idea of my article :)
    (1) Seam can work with any JPA implementation, as demonstrated in the example application that deploys to GlassFish/TopLink

    C'mon the Glassfish examples that is in jee5 examples requires EJB3. This is not what I have problem about. What I said is that Seam is not compatible with other JPA implementation other than Hibernate if you use POJO as the business layer because the PersistenceProvider abstraction class is only extended by HibernatePersistenceProvider.
    (2) Hibernate Validator can work with any JPA implementation

    As an *alternative* to the above, you can use Hibernate3 APIs instead of JPA APIs, but this is your choice.
    True. But what's the point having tight integration with Hibernate validator if I don't intend to use it?
  65. The premise of the original post is incorrect.


    I think that is because you didn't get the whole idea of my article :)

    (1) Seam can work with any JPA implementation, as demonstrated in the example application that deploys to GlassFish/TopLink


    C'mon the Glassfish examples that is in jee5 examples requires EJB3. This is not what I have problem about. What I said is that Seam is not compatible with other JPA implementation other than Hibernate if you use POJO as the business layer because the PersistenceProvider abstraction class is only extended by HibernatePersistenceProvider.
    Completely wrong. We can just as easily use TopLink as a JPA provider with a POJO business layer. The PersistenceProvider class is not abstract and will work with any JPA implementation.
    (2) Hibernate Validator can work with any JPA implementation

    As an *alternative* to the above, you can use Hibernate3 APIs instead of JPA APIs, but this is your choice.

    True. But what's the point having tight integration with Hibernate validator if I don't intend to use it?
    So how do you propose to do model-based validation then? (There is no current standard in this area, though Jason and Emmanuel and the rest of the Validation EG are working on creating one for the next rev of Java EE.)
  66. Completely wrong. We can just as easily use TopLink as a JPA provider with a POJO business layer. The PersistenceProvider class is not abstract and will work with any JPA implementation.
    It doesn't work with Toplink, simply because Toplink doesn't have transaction_manager_lookup unlike Hibernate. And it doesn't work if you use RESOURCE_LOCAL either because the joinTransaction won't work if you use RESOURCE_LOCAL.
    So how do you propose to do model-based validation then? (There is no current standard in this area, though Jason and Emmanuel and the rest of the Validation EG are working on creating one for the next rev of Java EE.)
    Correct. That's why I said some of this missing pieces is because of the incomplete features of JPA spec. I'm looking forward for the revised version of JPA 2.0 :)
  67. Completely wrong. We can just as easily use TopLink as a JPA provider with a POJO business layer.

    The PersistenceProvider class is not abstract and will work with any JPA implementation.


    It doesn't work with Toplink, simply because Toplink doesn't have transaction_manager_lookup unlike Hibernate. And it doesn't work if you use RESOURCE_LOCAL either because the joinTransaction won't work if you use RESOURCE_LOCAL.

    I'm certain that TopLink must have *some* kind of transaction_manager_lookup, otherwise TopLink would not be usable at all in J2EE environments. It will work with RESOURCE_LOCAL if you configure Seam to use transaction:entity-transaction in components.xml.
  68. Re: One gap that Seam should fill in[ Go to top ]

    Ack!
    Completely wrong. We can just as easily use TopLink as a JPA provider with a POJO business layer.

    The PersistenceProvider class is not abstract and will work with any JPA implementation.


    It doesn't work with Toplink, simply because Toplink doesn't have transaction_manager_lookup unlike Hibernate. And it doesn't work if you use RESOURCE_LOCAL either because the joinTransaction won't work if you use RESOURCE_LOCAL.

    I'm certain that TopLink must have *some* kind of transaction_manager_lookup, otherwise TopLink would not be usable at all in J2EE environments. It will work with RESOURCE_LOCAL if you configure Seam to use transaction:entity-transaction in components.xml.
  69. I'm certain that TopLink must have *some* kind of transaction_manager_lookup, otherwise TopLink would not be usable at all in J2EE environments. I couldn't find this configuration settings in Toplink's docs.
    It will work with RESOURCE_LOCAL if you configure Seam to use transaction:entity-transaction in components.xml.
    joinTransaction does not work with RESOURCE_LOCAL if you use Toplink as JPA provider.
  70. Rails vs Grails vs Seam[ Go to top ]

    The heavyweight contenders today are Rails, Grails, Seam. Don't try them out if you don't want to :-)
    This was actually the decision we were confronted with. Rails was thrown out because Ruby in itself not a first-class citizen on the JVM and we did not like the idea starting all over again in a different language with new idioms (although I think we could have been productive with it after a few weeks). So it became a Grails vs Seam thing. It is absolutely amazing to see what Grails can do, it will solve 98 % of all problems a regular web-app will be confronted with. Plus you have goodies like lower environment requirements (Tomcat) with hot deployment included. Seam can do that as well, but it cannot replicate things like closures/dynamic finder methods of groovy/grails. But a disadvantage of that is the fact that with Grails you sometimes get a huuuuge stacktrace of reflection errors and you cant tell what the hell just went wrong. If you are working with a bigger team on that project this can become a problem that wastes a lot of time.Seam definetly scores in this area. Plus you get proven ajax-capable JSF components and dont have to do the same with javascript in Grails.
  71. guys stop squabbling over nothing here. Within the Java community we are lucky to have all this innovation and frameworks to choose from. Use what fits your needs and at least be aware of the other frameworks. I am hoping for an opportunity to use Seam in the near future. My headache is trying to convince large clients that moving away from old struts is in their interest (not that i am a struts basher....so do not reply on that).
  72. guys stop squabbling over nothing here. Within the Java community we are lucky to have all this innovation and frameworks to choose from. Use what fits your needs and at least be aware of the other frameworks.
    If you don't like squabbling, then you better leave TSS ;-)
  73. i must confess...my life is devoid of any technical-squabbling-type-entertainment... i come to tss to get some...i just need this squabble to end and another to start....any pointers to other recent good 'squabbles' will be appreciated.