Discussions

News: Seam 1.1.5: Security, Email, PDF and more

  1. Seam 1.1.5: Security, Email, PDF and more (87 messages)

    JBoss Seam 1.1.5 has been released. Despite the strange version number, it includes exciting new functionality including:
    • Seam/Security - integrated JAAS-based authentication and unique EL and Drools-based authorization engine
    • Facelets-based email templating - define emails using JSF tags in a Facelets template
    • Facelets-based PDF templating - create iText PDF pages using JSF tags and Facelets
    • WebSphere support - examples now tested and deployable on WebSphere 6.1 (along with JBoss, WebLogic and GlassFish)
    • J2EE support for seam-gen - quickly generate a Seam application that deploys to a WAR on any J2EE 1.4 application server
    • New JSF controls including a file upload component
    • New examples and documentation enhancements
    Seam 1.1.5 takes JSF where it has never been before: you can use Facelets with Seam's new JSF tag libraries to define PDF documents, and even email templates! It's now super-easy to generate reports and send emails from a Seam application. A future version of Seam will even include JSF tags for generating charts in the PDF document - soon you'll be able to use Seam for problems which you previously would have needed a specialized reporting engine for. Until today, Security was the most requested feature in the Seam forums. Seam/Security offers an innovative authorization model based around Unified EL and JBoss Rules. The model was designed to allow elegant solution of complex cases such as row-level security and ACL-based permissioning. Right now, Seam/Security lacks some bells and whistles, but the hard work is done and we can now concentrate on executing our aggressive roadmap of new features. Seam has now been tested on all the mainstream Java EE application servers, and JBoss is now preparing to offer Seam support on platforms other than JBoss AS (at first, the list of supported platforms will include WebLogic, WebSphere, GlassFish and possibly Tomcat). This release was a team effort by Shane Bryzak (Seam/Security, file uploads), Norman Richards (PDF controls), Pete Muir (Email, select list control), Michael Yuan (WebSphere support) and definitely not by Gavin King (vacation, influenza, girlfriend birthday). Full changelog: http://jira.jboss.org/jira/secure/ReleaseNote.jspa?projectId=10071&styleName=Html&version=12311059 Download page: http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=163777&release_id=482792 Seam/Security documentation: http://docs.jboss.com/seam/1.1.5.GA/reference/en/html/security.html Seam PDF documentation: http://docs.jboss.com/seam/1.1.5.GA/reference/en/html/itext.html Seam email documentation: http://docs.jboss.com/seam/1.1.5.GA/reference/en/html/mail.html

    Threaded Messages (87)

  2. Spring support?[ Go to top ]

    I'd love to see Spring support in Seam. Once it's in, we'll take it for a testdrive and possibly switch to it pretty soon if all the praise I've heard and read still stands. On the other side, pushing other JBoss products is a definite drawback (at least for us) in the way of adaptation. The ability to stay vendor-independent seems to be more important than ever these days..
  3. Vendor independenc?[ Go to top ]

    On the other side, pushing other JBoss products is a definite drawback (at least for us) in the way of adaptation. The ability to stay vendor-independent seems to be more important than ever these days..
    Seam works in many different environments other than JBoss AS. Spring is also a vendor, so what's the problem with pushing yet another app-server-neutral framework? Just curious... thanks, bill
  4. Re: Vendor independenc?[ Go to top ]

    Hmm strange you bring that up, never thought of that this way. I think the difference is that somehow they managed to avoid looking like a vendor. They *do* feel neutral, but that's getting slightly offtopic. My original point was that I'm not that much sold on the EJB component model (for that very reason I'm less excited about the Web Beans JSR). If Seam allows me going the POJO way (I know it does), does not tie me to any proprietary framework or environment and I can easily integrate to the rest of my stack, I'm buying in.
  5. yes[ Go to top ]

    If Seam allows me going the POJO way (I know it does), does not tie me to any proprietary framework or environment and I can easily integrate to the rest of my stack, I'm buying in.
    It does support POJO+hibernate 'mode' if that's what you ask?
  6. Re: Vendor independenc?[ Go to top ]

    Hmm strange you bring that up, never thought of that this way. I think the difference is that somehow they managed to avoid looking like a vendor. They *do* feel neutral, but that's getting slightly offtopic.
    That is probably true in the early days of Spring. Havn't heard there will be another Expert One on One J2EE Development in the pipeline (what a pity!), an indication that Rod and Co no longer intends to appear a non vendor?
  7. Re: Vendor independenc?[ Go to top ]

    That is probably true in the early days of Spring. Havn't heard there will be another Expert One on One J2EE Development in the pipeline (what a pity!), an indication that Rod and Co no longer intends to appear a non vendor?
    I and other Interface21 folk have written quite a few books in the last couple of years. More are coming out this year (not merely on Spring). I would love to do another edition of E1:1 (I've had many requests), but that book took me 9 months full time to write. I have two small kids and too many other commitments right now (including working on Spring itself). But I will definitely write another book on architecture at some point...
  8. Re: Spring support?[ Go to top ]

    ...On the other side, pushing other JBoss products is a definite drawback (at least for us) in the way of adaptation. The ability to stay vendor-independent seems to be more important than ever these days..
    Note that Seam has been proposed as the basis for a JSR, JSR-299, the Web Beans JSR. As such, I think it's fair to say that improvements in Seam are likely to feed into the JSR's features (or, at the very least, participants in the JSR are likely to provide equivalents) so stuff like this isn't quite as vendor-dependent as one might think. Plus, Gavin & co. have always done a pretty good job of not tying you to a specific vendor, outside of the library itself.
  9. Re: Spring support?[ Go to top ]

    We don't try to couple Seam with any other JBoss technologies. In fact, we have the annoying habit of rejecting opportunities to couple more tightly with JBoss things when it would reduce the choices available to the users. But, we aren't afraid to flat out use a technology when it is the right thing. The business process technology is JBPM and rules are handled by Drools. (JBoss Rules) For those technologies standards don't exist (at least not in a way that is useful to us) and so have chosen them for now. For a counter-example, look at the JPA support. The final JPA spec had a few glaring omissions that severely limit the possibilities of a pure-JPA application. We could have easily forced everyone using Seam to use Hibernate so that you would have access to those critical features. But, rather than forcing people to use "our" persistence, we also support pure JPA access for those applications that happen not to need those things. If there is any JBoss technology you'd think the Seam team wants to promote the use of, wouldn't it be Hibernate? So, I hope you can see that we've tried very hard not to tie you down to specific technologies. We've worked hard to make sure Seam runs on non-JBoss platforms using non-JBoss technologies where possible.
  10. It is vendor independent[ Go to top ]

    I'd love to see Spring support in Seam. Once it's in, we'll take it for a testdrive and possibly switch to it pretty soon if all the praise I've heard and read still stands.
    I am not sure if Seam needs spring to be supported but that's another discussion of course.
    On the other side, pushing other JBoss products is a definite drawback (at least for us) in the way of adaptation. The ability to stay vendor-independent seems to be more important than ever these days..
    If you knew Seam a little bit closer you would know that Seam IS vendor independent. JBoss extending support for Seam for other application servers and (may be) even just servlet containers such as Tomcat.
  11. Re: It is vendor independent[ Go to top ]

    I am not sure if Seam needs spring to be supported but that's another discussion of course.
    From purely a tech perspective I would agree. Spring has little to offer in a Seam environment. I think we've created something that is both simpler and more powerful. However, there are many applications out there that are written with Spring in mind, and there are many developers out there who understand the technology. There's a lot of value in providing a path for those developers to leverage existing code and existing knowledge.
  12. Re: It is vendor independent[ Go to top ]

    I am not sure if Seam needs spring to be supported but that's another discussion of course.
    From purely a tech perspective I would agree. Spring has little to offer in a Seam environment. I think we've created something that is both simpler and more powerful. However, there are many applications out there that are written with Spring in mind, and there are many developers out there who understand the technology. There's a lot of value in providing a path for those developers to leverage existing code and existing knowledge.
  13. Re: It is vendor independent[ Go to top ]

    I am not sure if Seam needs spring to be supported but that's another discussion of course.


    From purely a tech perspective I would agree. Spring has little to offer in a Seam environment. I think we've created something that is both simpler and more powerful. However, there are many applications out there that are written with Spring in mind, and there are many developers out there who understand the technology. There's a lot of value in providing a path for those developers to leverage existing code and existing knowledge.
    While I'm not personally a fan of the Spring Way, and I believe that we offer a programming model that lets you get your job done *much* faster and more elegantly than Spring, the reality is that there are millions of lines of Spring code out there in the world, and the projects that are migrating to Seam will need to re-use that code. It's not reasonable to ask them to rewrite everything from scratch. Meanwhile, there are probably some diehards who don't share my view of Spring, and we want let them continue using the things they like about Spring, without missing out on the benefits of Seam.
  14. looks good.[ Go to top ]

    I'm excited about where Steam is going. I'm finally getting ready to jump ship on using Struts, and have been looking into and reading up on JSF. I think it might be worth my while to give Steam a shot at the same time. Maybe I was misunderstood, but I thought that Gavin was talking about coming out with a new security model that (at some point) was going to be build into Steam. Did I just misunderstand this or is this still in the works? I'm interested in this as I'm not terribly fond of JAAS.
  15. Re: looks good.[ Go to top ]

    The rule-based security framework is in the 1.1.5 release. It is so much better and more powerful than the standard JEE security model ... Check it out (see the doc links in the news post).
  16. JAAS[ Go to top ]

    Maybe I was misunderstood, but I thought that Gavin was talking about coming out with a new security model that (at some point) was going to be build into Steam. Did I just misunderstand this or is this still in the works? I'm interested in this as I'm not terribly fond of JAAS.
    To clarify, we use JAAS for *authentication*, where it is actually quite a reasonable model. But don't worry, you won't actually need to directly interact with JAAS APIs unless you start to need to customize stuff. What this does mean is that you can re-use existing JAAS authentication providers with Seam/Security. In the initial release, Seam/Security is more about authorization than authentication. We don't use the JAAS authorization APIs at all.
  17. Re: JAAS[ Go to top ]

    To clarify, we use JAAS for *authentication*, where it is actually quite a reasonable model. But don't worry, you won't actually need to directly interact with JAAS APIs unless you start to need to customize stuff. What this does mean is that you can re-use existing JAAS authentication providers with Seam/Security.

    In the initial release, Seam/Security is more about authorization than authentication. We don't use the JAAS authorization APIs at all.
    This makes sense, yes of course I would like to be able to continue to use JAAS providers, and your right my issue was more specifically with the authorization aspects JAAS. This is possibly a big +1 for me to switch. Thanks again for all the contributions you and team have made over the last few years.
  18. Spring support[ Go to top ]

    I'd love to see Spring support in Seam.
    Norman and Ales have already started work on this, and it will come in less than two months, I expect.
    pushing other JBoss products is a definite drawback
    Seam integrates JCP-standard technologies with several non-standards-blessed technologies interesting technologies into a consistent, unified, programming model. These include: The standards include: * JSF * EJB3/JPA * JAAS authentication * JSP * Unified EL * JavaMail * Portlet The non-standards include: * Facelets * jBPM * Hibernate * iText * Drools * JCaptcha (coming soon) * Ajax4JSF * ICEFaces * Trinidad (coming as soon as Trinidad actually gets released) Of the non-standards, 3 are JBoss projects, 6 are not. In each case, the nonstandard technology was chosen for being the best thing in its category, without regard for the vendor. jBPM, Hibernate and Drools are there because they are damn good, not because they are JBoss. Cheers :-)
  19. Re: Spring support?[ Go to top ]

    I'd love to see Spring support in Seam. Once it's in, we'll take it for a testdrive and possibly switch to it pretty soon if all the praise
    Your wish resembles me the following: I'd like to see Java SE as a part of .Net Framework. I've designed and developed several projects based on Spring + (Wicket/Pure Servlets+DWR/Prototype.js/...) architecture and I see these vivid products as a natural replacement for JSF/EJB X bloatware. Regards, ejboy
  20. Re: Spring support?[ Go to top ]

    I'd love to see Spring support in Seam. Once it's in, we'll take it for a testdrive and possibly switch to it pretty soon if all the praise

    Your wish resembles me the following:
    I'd like to see Java SE as a part of .Net Framework.

    I've designed and developed several projects based on Spring + (Wicket/Pure Servlets+DWR/Prototype.js/...) architecture and I see these vivid products as a natural replacement for JSF/EJB X bloatware.

    Regards,
    ejboy
    Just curious... Why is EJB 3.0 bloatware when with 2 annotations (@Stateless/@PersistenceContext) you get "REQUIRED" transaction demarcation as well as automatic JPA session propagation and management. And you don't have to write any XML. public interface MyLocal { public void doit(); } @Stateless public class MyBean implements MyLocal @PersistenceContext EntityManager em; public void doit() { do something } } Compile those 2 files, jar them. Thats it. Your doit() method automatically implicitly defines a transaction boundary. EntityManager is automatically created/associated/destroyed with the transaction. Add the Seam @In/@Out annotations and you get automatic integration with your HTTP Session. Add the webflow annotations, etc... Bill
  21. Re: Spring support?[ Go to top ]

    Hello Bill,
    Why is EJB 3.0 bloatware when with 2 annotations (@Stateless/@PersistenceContext) you get "REQUIRED" transaction demarcation as well as automatic JPA session propagation and management. And you don't have to write any XML.
    ...And to make it work outside JBoss (for testing or other purposes) you have to put on classpath just a 10Mb of jars ;)... All that you've mentioned was available in Spring for years, of course without annotations, but Spring supported annotations before EJB3. Spring is a proven and a solid technology, but I cannot find REAL applications/examples of EJB3 PROFESSIONAL usage. And please do not tell me that @Stateless class MyFirstBean {} is a professional programming, it's great for demo applications and prototyping, but makes no much sense for long term projects. Anyway you can code everything in Ruby even faster, but what about maintainability. I'm sick and tired with EJB 2.0 (JBoss+Weblogic) and use EJB 3.0 only to show our customers that we have expertise in all areas. P.S. I've understood the power of Spring only when we've finished the project similar to Google Calendar. With support for annotations Spring is as productive as EJB, but much easier to integrate with other technologies. Regards, ejboy
  22. Re: Spring support?[ Go to top ]

    And please do not tell me that
    @Stateless class MyFirstBean {}
    is a professional programming, it's great for demo applications and prototyping, but makes no much sense for long term projects.
    What the... Why doesn't it make sense for long term projects? What's wrong with it? If the default case works for your project, then it works. I know in our case, it works great. The annotations let you manage by exception. That's the whole point. And what's "Professional Programming"? We have 3 systems done already, and are working a fourth using EJB 3. Sales reporting system, a credit card management system, and an asset tracking and software delpoyment system for the server farms. We have a fourth we're just starting, and these apps are rolling out fast. So far we're quite happy with EJB 3, it hasn't betrayed us yet.
  23. Re: Spring support?[ Go to top ]

    We have 3 systems done already, and are working a fourth using EJB 3.
    We also had several systems done using EJB 2.0. And where is this technology now? Spring is natural and evolutionary - EJB 3 is an artificial snapshot of current trends. The EJB authors continue to ignore other projects and reinvent the wheel, e.g. EJB Interceptors is AOP for dummies. I do not want to offend anybody, moreover I make my money mostly because development in Java is too complex comparing to other platforms ;)
  24. for dummies[ Go to top ]

    The EJB authors continue to ignore other projects and reinvent the wheel, e.g. EJB Interceptors is AOP for dummies.
    Spring AOP used to be "AOP for dummies" as well. Wasn't that much richer than the EJB 3.0 model. I remember the Spring guys stating that it was "good enough" for the majority of projects and "simpler to learn" than "true" AOP. Adrian Coyler comes along and joins Spring and their tune changes. Its a common tact that people use when their technology is inferior. I try not to do that myself and hope people will send a nasty email to me if I ever have/will done it. Also, I'll say that the Spring founders ignore standardizations efforts in order to retain vendor control. It would be cool to standardize IoC under something like OSGi so IoC isn't dominated by one vendor. Bill
  25. Re: for dummies[ Go to top ]

    The EJB authors continue to ignore other projects and reinvent the wheel, e.g. EJB Interceptors is AOP for dummies.


    Spring AOP used to be "AOP for dummies" as well. Wasn't that much richer than the EJB 3.0 model. I remember the Spring guys stating that it was "good enough" for the majority of projects and "simpler to learn" than "true" AOP. Adrian Coyler comes along and joins Spring and their tune changes. Its a common tact that people use when their technology is inferior. I try not to do that myself and hope people will send a nasty email to me if I ever have/will done it.

    Also, I'll say that the Spring founders ignore standardizations efforts in order to retain vendor control. It would be cool to standardize IoC under something like OSGi so IoC isn't dominated by one vendor.

    Bill
    Especially if that vendor isn't JBoss, right? So not the Spring guys ignore standards? How so? And how has their tune changed? I mean, I've been using Spring AOP from the beginning? How is it different? Your tune hasn't changed, that's for sure. Same old song...
  26. Re: for dummies[ Go to top ]

    Bill
    Spring AOP used to be "AOP for dummies" as well. Wasn't that much richer than the EJB 3.0 model. I remember the Spring guys stating that it was "good enough" for the majority of projects and "simpler to learn" than "true" AOP. Adrian Coyler comes along and joins Spring and their tune changes.
    Bill, I find the suggestion that I and the rest of the Spring team are shills offensive. If you look at what I've been saying for the last few years, it's been consistent. E.g. I was talking about what would now be called "POJO" programming back in 2001-2002, when you and your colleagues were singing the praises of EJB 2. I have been talking about the importance of AOP for years; it was natural that when we could get at the powerful, elegant pointcut expression language from AspectJ we would do so. AspectJ 5 was a big step forward, with the merger of features from AspectWerkz. We looked at it and decided the integration would benefit our users. Your technical point is also plain wrong. Spring AOP has always had true pointcuts. This makes it radically different to the EJB 3.0 model, which lacks this central concept, making it hard to apply advice without modifying code in multiple places to add @Interceptor annotations. Because Spring AOP has always been true AOP, the AspectJ integration in Spring 2.0 sits on top of the existing runtime: the fundamental concepts of AOP were already there to enable it. Our overall technical direction came before Interface21 even existed. Spring is our attempt to progressively realise the vision we have had for enterprise development for several years. We brought Adrian onboard because we felt that AspectJ 5 was the right direction for AOP programming models; if we hadn't believed AspectJ was important we wouldn't have sought Adrian out. In other words, our company has executed what we thought was technically right; we have not changed our views for commercial gain. I prefer to keep discussions technical. However I can't avoid pointing out that obviously JBoss has a huge vested interest in EJB 3.0 being seen as relevant, so you are hardly impartial. And when it comes to personal credibility and integrity, I find the idea of you calling me and the Spring team shills frankly hilarious. I think it's pretty clear that you have a record of being motivated by commercial interests. By contrast, I have always expressed my honest technical opinion; I have never attempted to mislead the community via astroturfing...
    It would be cool to standardize IoC under something like OSGi so IoC isn't dominated by one vendor.
    As another poster pointed out, it was the EJB 3.0 group that ignored prior art and a huge amount of experience, in both the IoC and especially the AOP space. EJB 3.0 attempted to "standardize" IoC without representation not just from Spring, but from any of the other IoC containers out there. EJB 3.0 attempted to "standardize" AOP lite without any representation from any leading AOP expert, and ignoring the years of experience in AspectJ, and the fact that AspectJ was a de facto standard that was compatible with J2EE. No wonder that the result is strange and unproven, lacking basic concepts. We were not invited onto the EJB 3.0 expert group. In fact, when my name was suggested by one member, it was made pretty clear that I was not welcome. Obviously, the EJB 3.0 group should have signed up people like me, Aslak Hellesoy and Howard Lewis Ship on day one, and people like Adrian Colyer and Jonas Boner on the AOP side. No attempt was made to do so.
    It would be cool to standardize IoC under something like OSGi so IoC isn't dominated by one vendor.
    I'm pleased to see that you mention OSGi. I guess JBoss will be following Interface21's lead in this area? Adrian has been doing a great job, with help from Costin (I21) and Oracle and BEA folk. (I note from the JBoss forums that your guys are looking at imitating what we've done with Spring OSGi integration.) We have been working for many months very closely with the OSGi consortium, along with IBM, BEA and Oracle. We embrace OSGi and look forward to moving towards standardizing the beautiful complementary relationship between Spring and OSGi. Many OSGi leaders are also enthusiastic about this. We embrace OSGi as the right path forward for dynamic modularization. JBoss, by contrast, seems to be the only vendor sticking with a proprietary "microkernel" architecture. It's fascinating that of all vendors in the Java EE space, JBoss seems to be the only one on a crusade against Spring. BEA, Oracle, IBM and Sun seem to be happy to listen to customers who want to use Spring and don't seem to feel the need to spread FUD. Many other projects and companies, such as MuleSource, Iona, LogicBlaze and several Apache projects are adopting Spring with real benefits to their functionality and users--as recently did the Jax-WS RI. The people who lose when you as a Red Hat / JBoss spokesperson spread FUD is customers using JBoss and Spring. Rgds Rod
  27. OSGi + Spring[ Go to top ]

    I guess JBoss will be following Interface21's lead in this area? Adrian has been doing a great job, with help from Costin (I21) and Oracle and BEA folk. (I note from the JBoss forums that your guys are looking at imitating what we've done with Spring OSGi integration.)

    We have been working for many months very closely with the OSGi consortium, along with IBM, BEA and Oracle. We embrace OSGi and look forward to moving towards standardizing the beautiful complementary relationship between Spring and OSGi. Many OSGi leaders are also enthusiastic about this. We embrace OSGi as the right path forward for dynamic modularization. JBoss, by contrast, seems to be the only vendor sticking with a proprietary "microkernel" architecture.
    Imitating? What's so special that you have done with it? It's a simple (natural) lookup and/or registration of services. Ok, you were there first, but with a lot of help from OSGi people. And as such, I don't really see what would be our purpose to go and create another schema with the help of OSGi people. Would they get some new ideas on how to wire pojos? I don't think so. And just to mention how funny it is to call a simple pojo wiring inside OSGi EG a 'OSGi and Spring' workgroup. You seem to be up to date with all that bother's you with JBoss, but you don't have a clue about new pojo oriented Microcontainer - which happens to ba a lot more than your simple IoC container. And to spread how hostile we are with JBoss + Spring, is really funny, since we've done anything possible to integrate the two - EJB3 (JBoss AOP) + Spring, Seam + Spring, MC + Spring, ... If you just stopped at your first line - and changed it to - 'I guess JBoss will be joining Interface21's lead in this area?' it would really make you look better, as in that you really want some interaction with us, not just constantly complaining.
  28. Re: OSGi + Spring[ Go to top ]

    <What's so special that you have done with it? It's a simple (natural) lookup and/or registration of services.
    OSGi describes itself as the "dynamic module system for Java". The "dynamic" part of that turns out to be pretty important. It's what gives you the ability to add/remove/update modules on the fly in a running system (in process). A consequence of this is that both modules and the services they export (and you might be using!) can go away (and possibly come back) at any time. If you think about it, this is true of any SOA-based system (and OSGi essentially promotes an SOA-based approach to application development - I don't mean web services here of course, I'm talking about the architectural approach). The difference with OSGi is that it forces you to face those demons directly rather than as an afterthought. We've now been able to talk with a lot of people using OSGi in a variety of different ways - one thing in common is that the dynamic nature of the platform is very much both a blessing and a curse. So Spring's OSGi support does a number of things: * it lets you write OSGi-based applications without depending on any OSGi APIs (your code will run outside of the container) * it provides support for integration testing in an OSGi environment * it manages the internal content of your bundle (as an application context), and the references between bundles (via the OSGi service registry backbone) * it provides what I call "damping". So yes, there's a simple way to export beans as services and to inject references to OSGi services. But behind this is a degree of sophistication to manage the dynamics. OSGi lets you update a bundle on the fly. But can you actually do this without clients seeing transient failures? Not if don't design things carefully you can't... What if a service goes away and comes back? (Remember in OSGi-land that 'service' is as likely to be a bluetooth device someone was wearing when they walked out of range as it is a FundsManagementService in an enterprise app.). Spring-OSGi can manage that transparently for you. What if a *stateful* service goes away and comes back? How do you re-establish any state? Spring-OSGi provides a solution to that problem too. It also provides easy support for the "whiteboard" pattern (a superior approach to the classic observer / listener patttern for SOA-based systems). What if when your bundle is started, it's mandatory dependencies aren't satisfied? Spring-OSGi will defer creation of the app context until all dependencies are met (I think of it a bit like a petri-net). And there are more examples like this. So what I mean by "damping" is that yes, this is a dynamic system and it's not possible to make that transparent, but you can do a lot to make the programmer's life easier and to avoid wild 'bouncing' of availability (a problem with the OSGi Declarative Services support for example). * Spring-OSGi also supports property injection from the OSGi config admin service (with updates if values are changed via the admin console). * We're tackling pragmatic issues concerning using existing enterprise libraries under OSGi (like how to manage assumptions about the context class loader etc.) * ... and more besides. There's more to be done of course, like support for building and deploying web apps that are based out of OSGi bundles. The Spring OSGi project is working on that too. Interface21 has joined the OSGi Alliance and is working within the Enterprise Expert Group to help make OSGi a reality for Enterprise Java. It's a shame that JBoss couldn't make the kick-off meeting in Dublin last week (I know the intent was that you would be there). I look forward to collaborating with JBoss at future meetings.
  29. Re: OSGi + Spring[ Go to top ]


    So Spring's OSGi support does a number of things:
    * it lets you write OSGi-based applications without depending on any OSGi APIs (your code will run outside of the container)
    * it provides support for integration testing in an OSGi environment
    * it manages the internal content of your bundle (as an application context), and the references between bundles (via the OSGi service registry backbone)
    * it provides what I call "damping". So yes, there's a simple way to export beans as services and to inject references to OSGi services. But behind this is a degree of sophistication to manage the dynamics. OSGi lets you update a bundle on the fly. But can you actually do this without clients seeing transient failures? Not if don't design things carefully you can't... What if a service goes away and comes back? (Remember in OSGi-land that 'service' is as likely to be a bluetooth device someone was wearing when they walked out of range as it is a FundsManagementService in an enterprise app.). Spring-OSGi can manage that transparently for you. What if a *stateful* service goes away and comes back? How do you re-establish any state? Spring-OSGi provides a solution to that problem too. It also provides easy support for the "whiteboard" pattern (a superior approach to the classic observer / listener patttern for SOA-based systems). What if when your bundle is started, it's mandatory dependencies aren't satisfied? Spring-OSGi will defer creation of the app context until all dependencies are met (I think of it a bit like a petri-net). And there are more examples like this. So what I mean by "damping" is that yes, this is a dynamic system and it's not possible to make that transparent, but you can do a lot to make the programmer's life easier and to avoid wild 'bouncing' of availability (a problem with the OSGi Declarative Services support for example).
    * Spring-OSGi also supports property injection from the OSGi config admin service (with updates if values are changed via the admin console).
    * We're tackling pragmatic issues concerning using existing enterprise libraries under OSGi (like how to manage assumptions about the context class loader etc.)
    Ok, the first three are a *must*, otherwise it is useless to use or write something on top of current OSGi architecture. About tracking property injection, I have doubts, on how well can one handle changes - sometimes simple change causes the whole app to redeploy, which can trigger something else, etc. Zero turnaround ... uf. Regarding other points, I think (no offense meant) you are missing proper architecture to do this easier - better state handling and higher classloading architecture. The last time I checked there was a loop that waited for service to appear, or you rewrote that part?

    Interface21 has joined the OSGi Alliance and is working within the Enterprise Expert Group to help make OSGi a reality for Enterprise Java. It's a shame that JBoss couldn't make the kick-off meeting in Dublin last week (I know the intent was that you would be there). I look forward to collaborating with JBoss at future meetings.
    Yes, unfortunately I wasn't able to made it. I'm always in for a good discussion. You are at the EclipseCon, right?
  30. Re: for dummies[ Go to top ]

    **Corrected blockquote** Bill
    Spring AOP used to be "AOP for dummies" as well. Wasn't that much richer than the EJB 3.0 model. I remember the Spring guys stating that it was "good enough" for the majority of projects and "simpler to learn" than "true" AOP. Adrian Coyler comes along and joins Spring and their tune changes.
    Bill, I find the suggestion that I and the rest of the Spring team are shills offensive. If you look at what I've been saying for the last few years, it's been consistent. E.g. I was talking about what would now be called "POJO" programming back in 2001-2002, when you and your colleagues were singing the praises of EJB 2. I have been talking about the importance of AOP for years; it was natural that when we could get at the powerful, elegant pointcut expression language from AspectJ we would do so. AspectJ 5 was a big step forward, with the merger of features from AspectWerkz. We looked at it and decided the integration would benefit our users. Your technical point is also plain wrong. Spring AOP has always had true pointcuts. This makes it radically different to the EJB 3.0 model, which lacks this central concept, making it hard to apply advice without modifying code in multiple places to add @Interceptor annotations. Because Spring AOP has always been true AOP, the AspectJ integration in Spring 2.0 sits on top of the existing runtime: the fundamental concepts of AOP were already there to enable it. Our overall technical direction came before Interface21 even existed. Spring is our attempt to progressively realise the vision we have had for enterprise development for several years. We brought Adrian onboard because we felt that AspectJ 5 was the right direction for AOP programming models; if we hadn't believed AspectJ was important we wouldn't have sought Adrian out. In other words, our company has executed what we thought was technically right; we have not changed our views for commercial gain. I prefer to keep discussions technical. However I can't avoid pointing out that obviously JBoss has a huge vested interest in EJB 3.0 being seen as relevant, so you are hardly impartial. And when it comes to personal credibility and integrity, I find the idea of you calling me and the Spring team shills frankly hilarious. I think it's pretty clear that you have a record of being motivated by commercial interests. By contrast, I have always expressed my honest technical opinion; I have never attempted to mislead the community via astroturfing...
    Also, I'll say that the Spring founders ignore standardizations efforts in order to retain vendor control.
    As another poster pointed out, it was the EJB 3.0 group that ignored prior art and a huge amount of experience, in both the IoC and especially the AOP space. EJB 3.0 attempted to "standardize" IoC without representation not just from Spring, but from any of the other IoC containers out there. EJB 3.0 attempted to "standardize" AOP lite without any representation from any leading AOP expert, and ignoring the years of experience in AspectJ, and the fact that AspectJ was a de facto standard that was compatible with J2EE. No wonder that the result is strange and unproven, lacking basic concepts. We were not invited onto the EJB 3.0 expert group. In fact, when my name was suggested by one member, it was made pretty clear that I was not welcome. Obviously, the EJB 3.0 group should have signed up people like me, Aslak Hellesoy and Howard Lewis Ship on day one, and people like Adrian Colyer and Jonas Boner on the AOP side. No attempt was made to do so.
    It would be cool to standardize IoC under something like OSGi so IoC isn't dominated by one vendor.
    I'm pleased to see that you mention OSGi. I guess JBoss will be following Interface21's lead in this area? Adrian has been doing a great job, with help from Costin (I21) and Oracle and BEA folk. (I note from the JBoss forums that your guys are looking at imitating what we've done with Spring OSGi integration.) We have been working for many months very closely with the OSGi consortium, along with IBM, BEA and Oracle. We embrace OSGi and look forward to moving towards standardizing the beautiful complementary relationship between Spring and OSGi. Many OSGi leaders are also enthusiastic about this. We embrace OSGi as the right path forward for dynamic modularization. JBoss, by contrast, seems to be the only vendor sticking with a proprietary "microkernel" architecture. It's fascinating that of all vendors in the Java EE space, JBoss seems to be the only one on a crusade against Spring. BEA, Oracle, IBM and Sun seem to be happy to listen to customers who want to use Spring and don't seem to feel the need to spread FUD. Many other projects and companies, such as MuleSource, Iona, LogicBlaze and several Apache projects are adopting Spring with real benefits to their functionality and users--as recently did the Jax-WS RI. The people who lose when you as a Red Hat / JBoss spokesperson spread FUD is customers using JBoss and Spring. Rgds Rod
  31. Re: for dummies[ Go to top ]

    Bill, I find the suggestion that I and the rest of the Spring team are shills offensive. If you look at what I've been saying for the last few years, it's been consistent. E.g. I was talking about what would now be called "POJO" programming back in 2001-2002, when you and your colleagues were singing the praises of EJB 2.
    toot, toot. <blockquote. I have been talking about the importance of AOP for years; it was natural that when we could get at the powerful, elegant pointcut expression language from AspectJ we would do so. AspectJ 5 was a big step forward, with the merger of features from AspectWerkz. We looked at it and decided the integration would benefit our users.</blockquote> What a bunch of crap Rod. Go back to your 2002 or 2003 TSS presentation (don't remember which one) where you present Spring AOP against other AOP frameworks and how you stated that proxies are such a better/safer/good enough approach than weaving.
    As another poster pointed out, it was the EJB 3.0 group that ignored prior art and a huge amount of experience, in both the IoC and especially the AOP space.
    Believe me. I would have gotten more AOP features into EJB if it had been possible...Especially considering we have our own "prior art". We did make sure that the metadata hooks where there to allow vendors to innovate so that we can expand things of future versions of the specifications. But, EJB interceptors are "safer" than true AOP and "good enough" for most usecases. ;-) (sarcasm)
    EJB 3.0 attempted to "standardize" IoC without representation not just from Spring, but from any of the other IoC containers out there.
    Incorrect. IoC was standardized by the Java EE expert group, not EJB 3.0. (For some reason, I thought you were on JSR 244? Don't see your name posted there though.) A few of us were complaining about the incompleteness of Java EE IoC. A complete reworking of the XML format was required, but if you know the JCP, there are a few significant obstacles in the way of such things. Anyways, I thought a good job was done on the injection annotations. Its the XML that was left hanging.
    I prefer to keep discussions technical. However I can't avoid pointing out that obviously JBoss has a huge vested interest in EJB 3.0 being seen as relevant, so you are hardly impartial.
    I have a huge vested interested in EJB 3.0, true. JBoss though? Have you been to our website lately? Is EJB a product? Yeah, its important, but EJB is such a small small part of what we do.
    We embrace OSGi as the right path forward for dynamic modularization. JBoss, by contrast, seems to be the only vendor sticking with a proprietary "microkernel" architecture.
    As you've noticed from OSGi, a kernel is responsible for a bit more than just plain vanilla IoC. Since, OSGi isn't mainstream yet we would be foolish to make it the central spine of all our products. Furthermore, as all specs, it may/may not fit all our requirements. That's why we see OSGi as a personality of our new kernel. We're also excited about OSGi though. Developing a kernel is what Java EE should have done in the first place as it would have been a much easier way to mix and match Java EE a la carte from different vendors.
    It's fascinating that of all vendors in the Java EE space, JBoss seems to be the only one on a crusade against Spring. BEA, Oracle, IBM and Sun seem to be happy to listen to customers who want to use Spring and don't seem to feel the need to spread FUD. Many other projects and companies, such as MuleSource, Iona, LogicBlaze and several Apache projects are adopting Spring with real benefits to their functionality and users--as recently did the Jax-WS RI. The people who lose when you as a Red Hat / JBoss spokesperson spread FUD is customers using JBoss and Spring.
    What it boils down to is that it personally irritates me that you portray yourself as vendor neutral, when you are a vendor just like us, the difference being that you're pushing proprietary APIs. This is not FUD, its the truth. When I see comments on this thread stating that somebody doesn't want to be locked into Seam because it comes from one vendor(and use Spring instead) I get even more irritated, because with Spring its even worse. There is only one vendor, and you're not standardizing anything, where Seam is trying to bring its technology to the JCP. (Just like we did with Hibernate). Believe me...We were quite nervous business-wise about bringing Hibernate under JPA, but it actually increased our market share and download numbers. If you guys do the same, I bet the same will happen to you. Really though, you think too much of yourself. Spring-like functionality is such a small trivial part of what we do, we really don't care whether our users use it or not. We've had the Spring integration we feel is appropriate for a few years now. Sure, I personally care for people to take a look at EJB over Spring, but well, I'm biased as I've been working on it for a few years. Bill
  32. Re: for dummies[ Go to top ]

    Bill
    What a bunch of crap Rod. Go back to your 2002 or 2003 TSS presentation (don't remember which one) where you present Spring AOP against other AOP frameworks and how you stated that proxies are such a better/safer/good enough approach than weaving.
    Thanks for saving me a bunch of time by reminding me why it's not worth "debating" with you. My points stand. There was no TSS in 2002, so I guess you must mean 2003. Anyway, as I mentioned, I've been pretty consistent in what I said: - I believe that proxy based AOP approaches are a great solution to many requirements, especially middleware requirements. - I have never spread FUD about weaving. Just pointed out that proxy approaches are easier to adopt for most projects. This is demonstrably true, and the fact that Spring AOP is by far the most widely used AOP runtime proves it in practice. - I have been extremely positive about AspectJ since AspectJ 5 was announced. That was long before we hired Adrian. AspectJ 5 was a big step forward, bringing the AspectWerkz functionality in, making AspectJ much easier to adopt, and also splitting out the pointcut parser so that it was possible to get at the AspectJ programming moel without necessarily using AspectJ to actually weave. - The whole proxy/weaving debate is largely irrelevant today, as with Spring 2.0 we have a unique ability to use the same programming model and AspectJ pointcut expression language in Spring AOP's proxy based runtime as well as with the AspectJ compiler or load time weaver. The AOP world was different in 2003, and what I said then was obviously in the context of what was out there then. What I'm saying today is actually not radically different. Maybe I should have realised the full importance of AspectJ earlier. However, you're again arguing that I was shaping my message for commercial reasons, and that is simply untrue and offensive.
    Believe me. I would have gotten more AOP features into EJB if it had been possible...Especially considering we have our own "prior art".
    Yes, I know this is true.
    We did make sure that the metadata hooks where there to allow vendors to innovate so that we can expand things of future versions of the specifications. But, EJB interceptors are "safer" than true AOP and "good enough" for most usecases. ;-) (sarcasm)
    See above. And as far as the technical points go: - The metadata hooks are primitive and insufficient to implement true AOP efficiently. (I am qualified to comment, as I have implemented the interception API in Pitchfork. Doing so was pretty trivial on top of Spring AOP.) - EJB interceptors are potentially extremely unsafe compared to the Spring 2.0/AspectJ 5 model as, at least with the annotation style, it's not possible to limit the application of interceptors based on method signatures--for example using argument binding. The examples on page 25 of the "Simplified Programming Model" spec make this obvious--a recipe for ArrayIndexOutOfBoundsException and class casts. - EJB interceptors are not "good enough" even for most simple cases in that, as I pointed out in my previous post, they lack pointcuts. Spring AOP and every other proxy based AOP implementation around since 2002 had a pointcut concept, so is simply not comparable. I think the real question is what happened with JBoss and AOP. Now that was a change of message. All those semi-coherent presentations from Marc and marginally more coherent ones from you, about how AOP was going to revolutionize middleware. Strange silence these days. Perhaps because JBoss AOP looks a dead end project, since the merger of AspectJ and AspectWerkz and because of the convergence between the Spring 2.0 AOP and AspectJ programming models? Or because if you are tied to the simplistic EJB 3.0 interception model you had better keep quiet about true AOP?
    Incorrect. IoC was standardized by the Java EE expert group, not EJB 3.0
    As you know, most of the work was done in the EJB group before it was pulled out into JSR-250. My points stand.
    For some reason, I thought you were on JSR 244? Don't see your name posted there though.)
    You mean JSR-250, "Common Annotations for the Java Platform". I applied to be on the JSR immediately it was announced, but my application was not accepted. So much for us not engaging with the JCP...
    I have a huge vested interested in EJB 3.0, true. JBoss though? Have you been to our website lately? Is EJB a product? Yeah, its important, but EJB is such a small small part of what we do.
    Great. I think the sooner JBoss gets over its obsession with EJB the more successful it will be. However, the fact is that most people out there think of JBG as an app server vendor, and the very name was "EJBoss" until Sun objected, so EJB is core to your heritage.
    Really though, you think too much of yourself. Spring-like functionality is such a small trivial part of what we do, we really don't care whether our users use it or not.
    Why do you think I posted in this thread? Because you spread FUD about Spring. I did not bring the topic up, and I will be very very happy to make my point and leave folk to talk about Seam. It's crystal clear from this site, from the JBoss forums, from blogs and comments on other peoples' blogs that you and many of your colleagues feel very worked up about Spring. Clearly you know that Spring is a big deal, which is why it has been embraced in a huge number of applications across all industries. Obviously you habitually insult every other vendor, project and individual you mention--that's just you, so we're not special in that regard (I loved your recent recent exchange with your ex-colleague Andy Oliver). But clearly something about Spring has you particularly worked up. Saying that Spring's functionality is "trivial" is absurd. Spring's scope is broad, not to mention sister projects like Acegi Security. Many users have found that Spring transforms their experience of enterprise Java development. I really do not want to get into a slanging match. I and my colleagues at Interface21 and in the Spring team would love to have a constructive relationship with Red Hat/JBoss, like we do with nearly every other vendor in enterprise Java. It would be good for our many joint users who see value in using our technology together. It's very simple. It starts with you ceasing to attack us at every opportunity.
  33. Re: Spring support?[ Go to top ]

    moreover I make my money mostly because development in Java is too complex comparing to other platforms ;)
    True, my current Java assignment pays more than 20% more than my last .NET assignment (in the largest non-government .NET project in Australia). And EJB is such an important part of the job...
  34. If you want slightly more details on the new features without diving into the full docs, you might be interested in my blog: http://www.michaelyuan.com/blog/2007/02/01/new-features-in-seam-115/ cheers Michael
  35. awful wikitext[ Go to top ]

    The addition of s:formattedText seems like a goofy hack and kind of a boondoggle. I'm definitely not a fan of the wiki text, or in fact any kind of wikitext markup. Is there any plan to genericize the text formatting? I'd like to see it as a container tag that transforms its children, allows for addition and modification of text transformers with f:facet or similar, and including something like s:sanitizedHTML perhaps? As nice as facelets is, it's hard to compete with some of the perl toolkits where I can just "pipe a block" through an arbitrary transform. Oh yeah and I'd like a pony :) Perhaps it's time to split the Seam UI components like this one that are really just "extra" into a separate jar and taglib? En passant: I hear Spring support is in fact coming. I doubt it could support all of spring, such as AOP (and certainly not Spring MVC), but it should at least be able to inject Spring Beans into the Stateless scope.
  36. Re: awful wikitext[ Go to top ]

    Oh yeah and I'd like a pony :)
    No promises, but if you open a JIRA issue, we'll see what we can do. :)
  37. Re: awful wikitext[ Go to top ]

    Oh yeah and I'd like a pony :)


    No promises, but if you open a JIRA issue, we'll see what we can do. :)
    I am -1 on the pony. What about a donkey?
  38. Re: awful wikitext[ Go to top ]

    The addition of s:formattedText seems like a goofy hack and kind of a boondoggle. I'm definitely not a fan of the wiki text, or in fact any kind of wikitext markup.
    If you don't like wikitext, don't use it ;-) But seriously, collaboration software (forums, blogs, wikis) needs this stuff, and environments like RoR come with it basically builtin. Yeah, wikitext is always less than elegant, but trying to type markup into a textarea is close to impossible.
    Is there any plan to genericize the text formatting?
    C'mon, its like one class and an ANTLR grammer! If you want something else, just use something else :-)
    I doubt it could support all of spring, such as AOP (and certainly not Spring MVC), but it should at least be able to inject Spring Beans into the Stateless scope.
    I don't see any problem with supporting AOP on Spring components. Why should that be a problem?
  39. Spring support[ Go to top ]

    I've been following Seam development fairly closely for the past few months, and plan to build my next significant application with Seam. I'm definitely impressed with what they've produced. Seam tackles developmental issues I've not seen other open source frameworks address, such as managing "conversational" state across business processes simply and elegantly (provided you're using JBPM). The new security functionality is the cleanest I've seen - compared to Acegi it's very straightforward, and covers entitlement. I'd also like to see Seam be a bit more proactive on addressing Spring integration. There is significant overlap no doubt, but Spring has significant mindshare and is generally another top notch tool. Seam would only benefit from showing how and where integration would make sense. Incidentally, they already do to some extent. Check out http://wiki.jboss.org/wiki/Wiki.jsp?page=SpringAndSeamIntegration to see how you can inject Spring beans into any Seam component. Very simple, and I think covers a significant number of integration points as is.
  40. seam tooling support?[ Go to top ]

    I for one am very excited about Seam. Does anyone know if vendors such as Oracle are planning tooling support for this? Oracle already provides excellent support for EJB3 and JSF; hopefully they will do the same for Seam.
  41. Re: seam tooling support?[ Go to top ]

    I for one am very excited about Seam. Does anyone know if vendors such as Oracle are planning tooling support for this? Oracle already provides excellent support for EJB3 and JSF; hopefully they will do the same for Seam.
    The netbeans guys have been very supportive of Seam in their tools. I think you'll see much more tooling as JSR 299 matures and we see this technology making part of the standard Java EE stack.
  42. Re: seam tooling support?[ Go to top ]

    If you generate your Seam project from the Seam-Gen tool, you can open the generated project in both NetBeans and Eclipse. The project can then be built, deployed, debugged from the IDE. See below for an example. http://www.michaelyuan.com/blog/2006/11/16/rapid-seam-development-with-netbeans/
  43. Seam without EJB3 question[ Go to top ]

    Since the introduction of the EntityHome and the EntityQuery objects, there is no need to use session beans anymore with JSF. So my question is what are the benefits of using session beans if I am only building a web application using JSF, Seam and JBoss? (Besides the obvious fact that if I don't use session beans, I can run it on any non-j2ee container) Is there a preference of which to use (POJO vs session bean)?
  44. read here[ Go to top ]

    Since the introduction of the EntityHome and the EntityQuery objects, there is no need to use session beans anymore with JSF. So my question is what are the benefits of using session beans if I am only building a web application using JSF, Seam and JBoss? (Besides the obvious fact that if I don't use session beans, I can run it on any non-j2ee container) Is there a preference of which to use (POJO vs session bean)?
    http://labs.jboss.com/portal/jbossseam/j2ee/part02.html
    However, POJOs also have less features than EJB3 components since POJOs cannot get EJB3 container services. Examples of EJB3 services you lose in non-EJB3 Seam POJOs include the following. * The @PersistenceContext injection no longer works in POJOs. In order to obtain an EntityManager in a Seam POJO, you have to initialize the EntityManager in Seam configuration file and then use the Seam @In annotation to inject it into the POJO. * There is no support for declarative method-level transaction in POJOs. Instead, you can configure Seam to demarcate a database transaction from when the web request is received until the response page is rendered. * Seam POJOs cannot be message-driven components. * No support for @Asynchronous methods. * No support for container managed security. * No transaction or component level persistence contexts. All persistence contexts in Seam POJOs are "extended" and stays valid over the entire conversation. * No integration into the container's management architecture (ie. JMX console services). * No Java remoting (RMI) into Seam POJO methods. * Seam POJOs cannot be @WebService components. * No JCA integration. So, if you do not have the need for the above services (most small to middle size web applications do not), you are can assemble your applications with pure Seam POJOs.
  45. Re: read here[ Go to top ]

    However, POJOs also have less features than EJB3 components since POJOs cannot get EJB3 container services. Examples of EJB3 services you lose in non-EJB3 Seam POJOs include the following.

    * The @PersistenceContext injection no longer works in POJOs. In order to obtain an EntityManager in a Seam POJO, you have to initialize the EntityManager in Seam configuration file and then use the Seam @In annotation to inject it into the POJO.
    * There is no support for declarative method-level transaction in POJOs. Instead, you can configure Seam to demarcate a database transaction from when the web request is received until the response page is rendered.
    * Seam POJOs cannot be message-driven components.
    * No support for @Asynchronous methods.
    * No support for container managed security.
    * No transaction or component level persistence contexts. All persistence contexts in Seam POJOs are "extended" and stays valid over the entire conversation.
    * No integration into the container's management architecture (ie. JMX console services).
    * No Java remoting (RMI) into Seam POJO methods.
    * Seam POJOs cannot be @WebService components.
    * No JCA integration.

    So, if you do not have the need for the above services (most small to middle size web applications do not), you are can assemble your applications with pure Seam POJOs.
    Oh, that's an earlier list I wrote ;-) I need to revise that list a little: * Seam JavaBean components can now do some limited declarative transaction demarcation. * The "no support for container-managed security" is no longer an issue now that Seam/Security is here :)
  46. Re: Seam without EJB3 question[ Go to top ]

    Since the introduction of the EntityHome and the EntityQuery objects, there is no need to use session beans anymore with JSF. So my question is what are the benefits of using session beans if I am only building a web application using JSF, Seam and JBoss? (Besides the obvious fact that if I don't use session beans, I can run it on any non-j2ee container) Is there a preference of which to use (POJO vs session bean)?
    IMO, session beans still have some unique advantages. First, even though I did a bunch of work to ensure that stateful JavaBean components can be efficiently clustered in Seam, my implementation is still not as efficient as the SFSB implementation in JBoss (I can't speak for other appservers) which can do stuff like attribute-level dirty checking and replication. Second, session beans integrate nicely with the container's management/monitoring/deployment infrastructure. Especially the monitoring stuff is very useful. Third, Seam JavaBean components don't support REQUIRES_NEW transaction propagation or transaction-scoped persistence contexts. (You don't need this stuff for basic web-apps, but people do use it for some complex cases.) EJB gives you the timer service, which is what we build Seam async methods and async events on top of. Finally, EJB supports remoting via @Remote or @WebService. I have zero intention of reproducing this stuff for JavaBean components. This will be a very important distinction once Seam/WS is ready ;-) Finally, we are going to work hard in the Web Beans and EJB specs to make EJB even better in the next version of Java EE. Really, if your environment supports EJB3, there is no really good reason to not use them. Well, one, perhaps: we screwed up in EJB3 by requiring the local interface. We should have ditched that, it's a PIA. I'm sure it will be optional in the next rev of EJB.
  47. Re: Seam without EJB3 question[ Go to top ]

    Since the introduction of the EntityHome and the EntityQuery objects, there is no need to use session beans anymore with JSF.
    I think that's a little extreme. Once you start using things like IceFace's sortable columns, or just want to do something like change the sort order programmatically youself, you find EntityQuery won't do it and you need code instead. Similar goes for EntityHome, though in that case I can get a good head start by subclassing it. Something using the Hibernate Criteria API would be more useful to me, but the Seam folks are more focused on JPA than Hibernate, so I'll be doing it myself. But it should be painless what with the @DataModel annotation and all :) As for EJBs vs POJOs, I'd say stick with what you started with. Chances are if you were using POJOs, you didn't need any of the extra services you get with EJBs anyway (I use EJBs because I ocasionally need the global @PersistenceContext that's independent of the conversation-scoped EntityManager)
  48. I think Seam has done an excellent job of filling in some of JSF's holes, and also providing a unified programming model for Java EE. Some of Seam's features, however, are useful in standard JSF apps. Gavin, Michael, Norman, and co: it possible to use the Email and PDF components outside of Seam? --- Kito D. Mann - Author, JavaServer Faces in Action http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info * Sign up for the JSF Central newsletter! http://oi.vresp.com/?fid=ac048d0e17 *
  49. it possible to use the Email and PDF components outside of Seam?
    In theory yes, but it wouldn't work out of the box. These modules rely on Seam for managing the internal components. (Seam can automatically load the application components with no XML or other configuration hooks) You'd have to create that that and provide implementations for any core Seam components they use. It isn't something I'm inclined to work on, but if someone else has that itch, they are more than welcome to give it a go.
  50. Let me add to that by saying that I think this would be a much more feasible in a WebBeans world. If Java EE can provide that extra infrastructure, it would be much easier to write fully featured modules (application components + UI components) like these that can work independently of Seam.
  51. Selling Spring users on JBoss[ Go to top ]

    Every time I go to this site and see a post about JBoss, I go to that post first. I've found that over the past few years, every new product announcement contains links to some really good documentation. That always makes me eager to learn what JBoss has to offer, and I think it contributes to a sense that JBoss is offering some really good software as well. But every time I come to this site and read threads about JBoss, I end up reading some posts from JBoss folks that are arrogant and childish. Most of these posts are from Bill Burke. I've been a Spring user for the past few years, and Bill's posts on this thread - as is the case on most threads where Bill posts - make me think, "Why would I want to use JBoss software at all and deal with someone like this?" In fact, much as the quality of JBoss's software and documentation sets them apart from other vendors, I also think this arrogance sets them apart - far apart. I don't think there's even a close second since Ward Mullins stopped posting here. If I worked for JBoss, I'd be trying to move users from Spring's app framework to what JBoss provides. Knowing that I have excellent products with excellent support, I'd let the products and documentation speak for themselves. And I'd do whatever I needed to do to make sure Bill Burke never posts anything in public, because much of what he says is counterproductive to my goal. I would like to say that I found the comments from Gavin King and Norman Richards to be helpful and productive. When they say things like "We don't think Spring can offer much in a Seam environment, but we realize that many people will want to reuse what they've built on Spring" - it makes me think, "That sounds good, here are some people that think they have a better product, and they're finding a way for me to use some of the features of that product without having to dump what I've already done". One last thought - Gavin, you comment that there are "diehards" who probably don't share your view of Spring. I'd guess that 99.9% users of Spring don't share your view - otherwise they wouldn't use it! But I'd also guess that not all of these folks are "diehards". Most are probably using it because they found it to be useful, that's all. It helps them do their job, and they're not zealots, they just like things that help them. So instead of painting people who don't share your thoughts on the "Spring Way" as "diehards", I think it'd be more appealing to say something like "We realize Spring users find that it makes their work easier, but we believe that Seam can do even more for you". That's the kind of pitch - minus all the childish attacks from Bill Burke - that I think would be really appealing to Spring users. Rob
  52. diehard[ Go to top ]

    ...and they're not zealots, they just like things that help them.
    I find this statement kind of contradictory. Don't people often promote and sell on tools/products that have helped them tremendously? I'm not sure whether this categorize them as "zealots" or "diehards" but there is some truth in that a lot of Spring users just love to recommend Spring everywhere and for everything. And you'll always find users that says "well, I ain't going to take look at product x until it has spring support", which is fine, and I understand where they are coming from but you got to wonder if they would ever cry if Spring ceases to exist one day. I consider myself once a "diehard" Spring user, but recently have evaluated Seam and love the evolutionary ideas that it has to offer. Spring is a fantastic product, but it doesn't solve some of my problems elegantly like Seam does so hence I slowly detach myself from relying on Spring. I think if Spring users actually download Seam, run the examples, peruse the source code, and reflect on what they have learned during the entire process, they may find Seam can offer much more help in some areas that Spring could not.
  53. Move it into Java EE[ Go to top ]

    I think both Jboss and Spring have a lot to offer the community. However, it would be nice to work on projects that use BEA, Oracle, IBM or Jboss in some sort of consistent fashion (EJB3 is definitely a move in the right direction). Its kind of frustrating moving from vendor to vendor and trying to figure out how things are accomplished on their platform. I see Spring and Seam as frameworks that have been created for features that should be in the platform already. Eventually, it would be nice to see the best of Spring and Seam features eventually moved into Java EE.
  54. Re: Move it into Java EE[ Go to top ]

    Eventually, it would be nice to see the best of Spring and Seam features eventually moved into Java EE.
    Here's where I probably start sounding like Bill, but... Only the people behind one of those two technologies has mad any move towards getting their ideas into the standards and improving life for all developers. The creators of another technology have thumbed their noses at the contributing to the standards process. Only those using their proprietary technology can benefit. I don't proprietary as an insult here; I'm simply trying to express my frustration at a technology that intentionally pulled away from the mainstream Java community and, despite having some very interesting ideas about how to do things, has not seen fit to try and contribute their ideas back and make a difference. And, it's not like the JCP has been unwilling to change. Look at Java EE 5. Perhaps some people might not thing it is the greatest thing out there, but it shows that Java standards are able to adapt and do better things. It wasn't as easy as it should have been, and Java EE 5 doesn't go nearly as far as it should have. Had their been more voices contributing, I can guarantee java EE 5 would be even better. Hopefully that didn't offend anyone. I'm not saying we've been perfect about this at JBoss either, because we've dropped the ball and standardization a few times. However, we really have made some serious contributions to the Java community in terms of advancing the state of the art beyond our little proprietary world.
  55. Re: Move it into Java EE[ Go to top ]

    Norman
    Here's where I probably start sounding like Bill, but... Only the people behind one of those two technologies has mad any move towards getting their ideas into the standards and improving life for all developers. The creators of another technology have thumbed their noses at the contributing to the standards process.
    Yes, you do sound rather sadly like Bill. Or alternatively you are both doing a good job of mouthing the present Red Hat marketing line on Spring. Please re-read my posts. I described two significant interactions where we have not had the opportunity to participate in JCP expert groups grappling with problems for which we had demonstrated a high quality, popular solution. So it's disappointing that you are simply repeating your current line to FUD Spring.
    I'm simply trying to express my frustration at a technology that intentionally pulled away from the mainstream Java community and, despite having some very interesting ideas about how to do things, has not seen fit to try and contribute their ideas back and make a difference.
    Again, clearly you didn't read my posts. "Intentionally pulled away from the mainstream Java community": Pure FUD. "Pulls away from the mainstream"? When Spring plays nice in every Java environment out there including all app servers? When Spring integrates with nearly every mainstream server-side Java technology, including various JBoss products? When Spring integrates with many technologies from the JCP including JMX, JCA, JPA, JTA, EJB, JMS... When Spring is used widely across every industry, including strategic use in most of the world's top banks? When just about every major app server vendor (besides JBoss) is positive about their users using Spring? When many other vendors and projects (such as Mule, ServiceMix, Tangosol Coherence, Terracotta, GigaSpaces, Apache JetSpeed, ActiveMQ to take just a few) embrace Spring and derive benefit from doing so? The one thing that Spring could be said to "pull away" from was EJB 2.x. (Note that we embrace JPA.) Pulling away from things that are grossly flawed is a good thing. I think tens of thousands of happy Spring users are grateful that we did, and I can't imagine that EJB 3.0 would look the same otherwise either. Really, I would be more than happy for this to be a Seam thread. So ceasing to repeat FUD about Spring would be a great idea and I'll go away :-) Rgds Rod
  56. Rewriting history[ Go to top ]

    Rod, I've been keeping quiet here because I just hate these TSS trainwreck threads. FTR, frankly, I mostly agree with what you're saying, and mostly disagree with what Bill's saying, but I think there's something to be said on both sides - though you are clearly doing a better job of saying your side than Bill is of saying his. I think Bill is totally wrong to attack you for changing your position on AOP between 2003 and 2007. People's views evolve and that's perfectly normal and perfectly healthy. So you are right on that and Bill is out of line. Of course, my own opinion (not that of my employer) is that you were right then, and you're wrong now. But whatever. History will judge. That's not what I want to argue about. The unpleasant thing I have to say is this: I'm afraid I simply can't let you represent yourself as having tried to engage with the EJB3 group when you did not. That's simply so inaccurate as to border on willfully dishonest. I remember right before we announced EJB3 at a TSS conference, walking up excitedly to Juergen, telling him he had to come to Linda's talk, and saying that "you guys are going to love this". At that moment I had every expectation that Spring folks would soon be represented on the EJB group, and that we would be able to all work together to really give the Java world a new set of standards that embodied the best in the open source world at the time. I remain extremely sad and disappointed that this is not how events played out. You guys never even tried to even speak in person or email or phone to any of the EJB3 group to see where our heads were at, and if you would be welcome on the group (you would have been). You certainly knew my email address and phone number at the time. What really happened was that right there, at the conference, you totally lost the plot, fumed about the EJB group, quote, "stealing" your ideas (a ridiculous notion in technology) and spent the next year or two on a crusade against EJB3, where you attacked EJB3 every time you spoke in public. This is all ancient history now, but the fact is that the combined FUD campaign of the Spring folks and JDO folks was *incredibly* disruptive to the work of the expert group, delayed the release of EJB3, and meant that we missed out on doing some things in EJB3 that we probably could have done, since some of us, and especially the spec lead, were wasting valuable time fighting political battles instead of sitting down and creating the best possible spec. I'm not aware of you ever applying to join the EJB3 group, and so assume that you did not - and it is difficult to see how you could really have been a constructive member when you were attacking EJB3 in public - but if you *would* have chosen to get constructively involved in the EJB spec, that would have been extremely welcome. For example, when Patrick Linskey eventually decided to get on board with JPA, he made a very useful positive contribution. I have no doubt, that if you had wanted to, you could have chosen to go down the same route. Now, frankly, that is your call. There is absolutely nothing wrong with believing that you have a better solution and that the best future for that solution is as a proprietary technology, rather than going through all the politics and compromises that go along with taking it through the standards process. But don't try to pretend that you tried and failed to work with the JCP when you did not in fact try. If you would have tried, I would have loved to have had you there. That's all.
  57. Re: Rewriting history[ Go to top ]

    Gavin
    Rod, I've been keeping quiet here because I just hate these TSS trainwreck threads.
    +1. However, with your last post, this feels like a constructive discussion...
    The unpleasant thing I have to say is this: I'm afraid I simply can't let you represent yourself as having tried to engage with the EJB3 group when you did not. That's simply so inaccurate as to border on willfully dishonest.
    What I said in this thread is completely true. I would have been willing to engage with the EJB3 group had that group been prepared to have me onboard, and showed openness to input after it went public at TSS 2004. It was not. As I mentioned, one new joiner to the JSR-220 group fairly early on suggested my name. That member received a clear response from inside the group that I was not welcome. I am not going to breach confidence and put people in a difficult situation by naming the individuals involved. I hope you don't choose to continue to believe I'm lying, because I'm not. I guess you were unaware of this, and that's a pity, because maybe you would have tried to change the situation had you known. But what's done is done. Regarding my rejected application to join JSR-250 (Common Annotations for the Java Platform), again it's not for me to publish details of stuff that is in confidence, but I'd be happy to share with you personally my emails concerning it. So, the view from the outside: EJB3 was announced as virtually a fait accomplis at TSS 2004. 6 months or more of work had gone on in private before we or anyone else knew about the aims or proposed technical direction. Any technical or other criticism of it was immediately condemned vociferously by certain members of the expert group. Which was a great pity as certain things could have been done differently to give EJB 3.0 more chance of reviving the EJB brand and more chance of evolving well in future. (Some of the problems in my mind are big, like backward compatibility being a requirement rather than a differentiator for vendors, but there are certainly a bunch of other smaller things, especially concerning interception, that could have been fixed). Imagine how frustrating it was to be outside it looking at what I considered to be some pretty bad decisions, in areas where I/we had a lot of experience, yet being unable to put any feedback up without being considered the enemy. Note that I am not talking about the persistence (JPA) side. I have been publically supportive of that all along, because I think it's a good idea and a great start for a 1.0 spec. And I have found several EG members--most notably Mike Keith and Patrick Linskey--to be extremely open to comments.
    You guys never even tried to even speak in person or email or phone to any of the EJB3 group to see where our heads were at, and if you would be welcome on the group (you would have been). You certainly knew my email address and phone number at the time.
    I have a good relationship with several members of the EG. Gavin, I don't think I've ever had your phone number, but, sure, I had your email address. However, you were not the EJB expert group--just one individual. Furthermore, my and Juergen's impression was that you became hostile to us around the time of the TSS 2004. You were pretty public about that hostility, too. But I would love if we can move on.
    What really happened was that right there, at the conference, you totally lost the plot, fumed about the EJB group, quote, "stealing" your ideas (a ridiculous notion in technology) and spent the next year or two on a crusade against EJB3, where you attacked EJB3 every time you spoke in public.
    I never said that EJB3 "stole" "my" ideas. I do not attack EJB3 every time I speak in public--as they say, if you can't say something nice, often it's best to say nothing. (Maybe you don't know how often I speak in public?) Most often when I speak I don't mention EJB--and I usually find that in Q&A sessions developers don't bring it up, either. I'm sorry, I genuinely don't think EJB 3 (except for JPA) is a good technology, I don't think it adds anything to the art, especially now it's 2007, and I don't think that it offers the best course for users looking to solve tomorrow's problems as well as today's. In fact, if you look at the presentation I gave at TSS 2004 (where you claim I lost the plot) you will see that I mentioned a number of technical problems in the spec that could (and should) have been addressed in the past 2 years. Btw one of the the things I was most bitterly attacked for saying back then, was that EJB 3.0 would not be available in the real world until 2006. As it turned out, I was wrong; I didn't warn people strongly enough around the timelines. As of February 2007, implementations are still not GA from most leading vendors (including JBG AFAIK). IBM--by many measures the market leader--is publically talking about availability sometime in 2008. And then the average large WebSphere shop takes 6-12 months to upgrade their server version. Rather than me "losing the plot," I would argue that a lot of what I said back then has been borne out. Also, it's worth bearing in mind that the broader reaction to that talk was positive. I was specifically invited to give it at other high profile conferences; those sessions were packed. Hardly what would have happened if I'd been losing the plot. I'm sorry if what I had to say offended some members of the EG; like you, I have a record of speaking my mind.
    This is all ancient history now, but the fact is that the combined FUD campaign of the Spring folks and JDO folks was *incredibly* disruptive to the work of the expert group, delayed the release of EJB3, and meant that we missed out on doing some things in EJB3 that we probably could have done, since some of us, and especially the spec lead, were wasting valuable time fighting political battles instead of sitting down and creating the best possible spec.
    I think the JDO/JSR-220 story was pretty sorry on both sides and it's time to move on. And I don't think it's fair to blame the Spring team for the deficiencies in EJB 3.0 or the delay. The expert group had plenty of time, and there was plenty of material out there from multiple sources (not just us) about some of the questionable decisions.
    If you would have tried, I would have loved to have had you there.
    Gavin, I am truly sorry that our relationship, and that of the Spring team with the Hibernate team, has deteriorated. I would love the discussion in this thread to help to change that, and get a sense that it can. Spring and Hibernate together have had a huge positive impact on enterprise Java. I remember Juergen, you and and I spending lots of time hanging around at TSS 2003 in Boston, getting on great and coming from a very similar approach to the technology. Our impression was after you joined JBoss with its "us and them" culture, your attitude changed--even before EJB 3.0 was publically announced. Sadly you seemed to buy into the JBoss hostility to us and Spring, which as far as I can remember dated from around the time of Marc's infamous two clowns and a dog attack on TSS in February 2004: well before we, or the world at large, knew anything about EJB 3.0 and had expressed any views on it. Now that Marc seems to be leaving to grow his family and spend his millions, and JBoss has been acquired by a more mature technology company, maybe we can try to start over :-) While I've made no secret of my opinion of Bill's style of interaction, I place you in a completely different category. You are one of the guys who has made a big difference (for the better) to enterprise Java. I know we are both passionate about what we believe in technically and I know there are issues we strongly disagree about, but I would love us to be able to figure out how we can work together more constructively for the benefit of the community. If your email address is still the same, maybe I'll follow up offline... I expect to be in Atlanta in the next month or two, as it happens, so if you're back from vacation and feel like it, I'll buy you a beer. After all, you're a fellow Aussie :-) Rgds Rod
  58. Re: Rewriting history[ Go to top ]

    If your email address is still the same, maybe I'll follow up offline... I expect to be in Atlanta in the next month or two, as it happens, so if you're back from vacation and feel like it, I'll buy you a beer. After all, you're a fellow Aussie :-)
    Yep, got your email. Cheers.
  59. Re: Move it into Java EE[ Go to top ]

    Yes, you do sound rather sadly like Bill. Or alternatively you are both doing a good job of mouthing the present Red Hat marketing line on Spring.
    I'm not sure I fall in line with either of them, but I do stand by comments. I think it is a real shame that you Spring guys have not been more active in shaping the standards. Regardless of whether that was from your lack of interest or whether you were shut out, it's truly a shame that things happened without you guys. We are ALL better off with strong standards-based technologies, and the standards are only as good as the people who are contributing to them. I was quite encouraged to see you reach out to Gavin. I hope that good things come of that, and I look forward to being able work together for the benefit of the whole Java community.
  60. Re: Move it into Java EE[ Go to top ]

    Norman
    I was quite encouraged to see you reach out to Gavin. I hope that good things come of that, and I look forward to being able work together for the benefit of the whole Java community.
    Likewise, I hope we can all engage constructively. Hopefully this thread isn't the usual trainwreck but has the seeds of positive things... Rgds Rod
  61. Re: Move it into Java EE[ Go to top ]

    I'm simply trying to express my frustration at a technology that intentionally pulled away from the mainstream Java community
    Your problem is that Spring is actually the main stream. Most Java job specs thses days have Spring printed on them at the very top of the list. EJB3? Will it have a better fate than JSF?
  62. and so?[ Go to top ]

    Most Java job specs thses days have Spring printed on them at the very top of the list.
    Most java job specs also list Struts at the top of the list as well. And your point is?
  63. Re: and so?[ Go to top ]


    Most Java job specs thses days have Spring printed on them at the very top of the list.

    Most java job specs also list Struts at the top of the list as well. And your point is?
    Yes, Struts has been enjoying main stream status for more than five years, something JSF will never be able to achieve. It will take something like Wicket or Stripes to put Struts into retirement. History will tell.
  64. Re: and so?[ Go to top ]

    It will take something like Wicket or Stripes to put Struts into retirement.
    Probably.
  65. Re: and so?[ Go to top ]

    It will take something like Wicket or Stripes to put Struts into retirement.


    Probably.
    My point is that if JCP blessed JSF cannot replace a mostly inactive project such as Struts (IMHO, Struts2 is not Struts), how can EJB3, which is far less functional than Spring and which still bears all the baggages of EJB1&2, enrode the dominance of Spring.
  66. Re: and so?[ Go to top ]

    My point is that if JCP blessed JSF cannot replace a mostly inactive project such as Struts (IMHO, Struts2 is not Struts), [...]
    I think JSF is becoming fairly well-accepted. We can debate the good and bad of it of a technology (and there is plenty of fodder for both sides of that argument), but it's pretty clear that JSF is doing well and is getting stronger and stronger as people realize that they can better leverage the power of standardization. Just look at the wonderful IDE support and the continual upswing in JSF component libraries. For better or worse, JSF has the greatest momentum.
  67. Re: and so?[ Go to top ]

    I think JSF is becoming fairly well-accepted.
    By the vendors, for sure. By the user community? I am afraid not.
    For better or worse, JSF has the greatest momentum.
    And success stories in real projects are so scarce, I would think it's already dead if not the momentum in the vendor community.
  68. Re: and so?[ Go to top ]

    And success stories in real projects are so scarce, I would think it's already dead if not the momentum in the vendor community.
    Well, I am not sure how you get your samples. If you only look at the blogs or listen to the "consultants", you'd think that there is no successful *Java* project out there, let alone JSF projects -- everything must be RoR. ;) But as a major Java EE vendor, we do see successful JSF projects in the real world all the time. It is true that JSF has its share of inconveniences. But the value of Seam is that it really solves many of those issues. Seam will utimately help the adoption of both JSF and EJB3.
  69. JSF in real life projects[ Go to top ]

    George, My 5 cents regarding success stories in real projects. See http://www.javawebcomponents.com/content/clients/caseStudies.html for details. The only points are what is the JSF tool and what is a level of JSF expertise of a project's developers. Regards. Michael Lyubchenko, WebGalileo Faces guy.
  70. Great work![ Go to top ]

    Great work, I started using seam two weeks ago and really like how it works. I was surprised that it all works so easily. The command-line based generator (which I normally hate working with) actually is very easy to use. Anyway, keep up the good work!
  71. JBoss AOP[ Go to top ]

    Rod,
    I think the real question is what happened with JBoss and AOP. Now that was a change of message.
    JBoss AOP is pretty much alive and well. We've actually done some very interesting integration with our kernel that no other vendors like yourself haven't done yet. And they are features we're going to take advantage of in JBoss 5. Over the years, we evaluate whether or not to fold into AspectJ or not. I've even sent an email or two to Adrian Coyler about the subject, but haven't had much time to follow up. The thing is, like OSGi, our kernel has certain AOP requirements that neither AspectJ nor Spring solve. I've been meaning to write an article on this for some time now. Thanks for the motivation, maybe I'll finally get around to it. As far as "marketing" goes, we don't push AOP much anymore because we found out that people don't care as much about AOP as much as they do the aspects themselves. Although Adrian Coyler has been an incredible evangelist for AOP, we've seen mostly skeptisms and doubt about the approach from our community. We felt that bringing our ideas to the JCP and using standards to push the message was a more effective approach. On the technical side, we also felt that the "fragile pointcut" problem was a very huge problem in AOP land and preferred the triggering of aspects through annotations and/or XML metadata. Annotations + AOP is something that Marc and then myself always pushed really hard. Bill
  72. Re: JBoss AOP[ Go to top ]

    On the technical side, we also felt that the "fragile pointcut" problem was a very huge problem in AOP land and preferred the triggering of aspects through annotations and/or XML metadata. Annotations + AOP is something that Marc and then myself always pushed really hard.

    Bill
    This real issue has been lost in the more emotional arguments unfortunately.
  73. JBoss FUD on Spring[ Go to top ]

    you are both doing a good job of mouthing the present Red Hat marketing line on Spring.
    That's what you don't get. There is no marketing line on Spring. We don't speak about you in blogs, forums, or in the press that I know of. One exception that I can think of. Yes, I do like to point out on TSS your faults as a company and the faults of your message. But that's what TSS is for. P.S. On Andy Oliver...Man was that misinterpreted! I actually pushed real hard for Andy's stuff internally before he left.
  74. Re: JBoss FUD on Spring[ Go to top ]

    Bill
    That's what you don't get. There is no marketing line on Spring. We don't speak about you in blogs, forums, or in the press that I know of. One exception that I can think of.
    Oh dear. It's time to stop digging now. Can't you take a hint from your own colleague, Gavin, that you're just squandering what remains of your credibility? My opinion of you is one thing: reams of evidence that you speak about Spring frequently and stridently is another. Shall we look at the results of 5 mins of googling? Bill Burke: (one of numerous posts on from Jason Carreira's blog): As far as all your other claims of how great your "integration" libraries are, I remain totally unimpressed Yes, the IoC, AOP, WF, is interesting stuff, but the rest? Trivial BS. Otherwise we would have copied you long ago. Btw I love that bit about copying. An interesting window into how you think, perhaps. This is an example of the "Spring is trivial" marketing message, which pops up repeatedly from JBoss folk. Bill Burke: (from TSS in Feb 2004): The "new" Marc may shy away from trashing you, but I won't. Spring, Nanning, PicoContainer are nothing more than cutsy little frameworks implementing low hanging fruit problems. I find it very humerous how you wrap yourselves in cutsy academic language like "Inversion of Control" and expect the rest of us to go oooo, and aahhh! That's right. Nothing but a cutesy little framework. ("Spring is trivial") Strange that JBoss's Chief Architect should devote so much time to it... Marc Fleury himself, from the same thread, replying to a Spring user: here we go again with the gay IoC stuff. Can you guys get over JNDI? oy! it has got to be the BIGGEST EYE CANDY that go the girls excited. Its eye candy. "Spring is trivial" marketing message. From the man himself. And I just love this professional open source. But of course, IoC is good, now IoC 101 is in EJB 3.0, isn't it? Two other incidental things I noted from a glance over this thread: - In his more lucid moments, Marc quotes lots of metrics, as of early 2004, to cite how "real" JBoss was in comparison with the then Spring 2.0 RC1. By many of them (such as job postings) Spring has overtaken JBoss three years on. Now in your unique view of the world ("Spring vs JBoss"), that must be worrying. - Various JBoss astroturfers get into attacking some of the Spring team (who were all obviously posting under their own name). Remember Arun Patel? More professional open source. And again, some of your colleagues felt so strongly about Spring they needed to use their extra identities to attack it... All that logging in and out, quite a lot of commitment of time to something that you don't talk about. And of course nothing we have ever done could possibly be in advance of anything you do. Just noticed, from the same thread "Mud, shmud. I'm just tired of you guys crying revolution when the revolution was already planned and implemented long before you wrote a line of code." (That was well before EJB 3.0 was announced, btw. I guess you were referring to your EJB 2.x implementation, and perhaps in particular the wonderful pre-Hibernate CMP solution you were promoting before Gavin joined and brought Hibernate to JBoss. Anyone still using that?) Two of the many examples from the Hibernate forums where anyone mentioning Spring gets an extreme, hostile reaction from JBoss folk. Christian Bauer: So don't use the Spring bullshit. Why would you wrap a standardized API with a proprietary one? Christian posted several times about Spring in that thread alone. Interestingly, this is in reaction to a user who was using Hibernate JPA with Spring's JPA support. When we do embrace standards the response is also abuse. This is the "Spring is proprietary" marketing message. Oh and the technical point is also wrong: you don't need to use a Spring API to use Spring with JPA. But this isn't about technology, is it? Also Christian, responding to a user who mentioned he was using Hibernate with Spring. I just love this one: Use the Spring forum, we only discuss untainted Hibernate here. From a comment on the Hibernate blog, also by Christian: Right, I use a weirdo Spring API to get JPA "support" Again, note the "Spring = proprietary" line coming out, even when the technical argument is wrong. (There is no need to use Spring's JpaTemplate with JPA integration; you can use @PersistenceContext etc.) In the press, Marc recently seemed to publically try to hire us. That's a way of talking about us: For as long as I can remember we've been trying to reach out to the Spring folks in terms of coming to JBoss. If you want to do professional open source, this is the place to do it. The same journalist followed up with me, so I've already gone on the record about this, but it's interesting to note the attitude here. We think that enterprise Java open source is more than JBoss (that's probably just as well, judging from these quotes), although we'd love to have a positive relationship with JBoss. Further, some of your colleagues have removed materials about Spring from JBoss web sites, as here. That's certainly a form of communicating about Spring. The reality is that Spring is not going away, and you need to live in a world in which Spring is extremely popular. For some reason this is one of the many things that causes you to react very violently. Definitely not "professional" open source. There's plenty more where that came from. I really don't find googling for your comments enlightening enough to want to spend more time on it. So I hope I've made my point: your assertion that "We don't speak about you in blogs, forums, or in the press that I know of" is laughable, like many of your other comments here. As I have made clear in my replies to Gavin and Norman (and my reply in the press to Marc's quote above): - We would love to engage with JBoss more positively. Our respective communities are not interested in political battles. - From our side, I am trying to work to improve our relationship - The vast majority of independent posters, bloggers etc., not to mention nearly all over vendors in the space, do not share your extreme views on Spring and us - From our side you will not find comparable hostility to Hibernate or other JBoss products. We know that many of our users use them and get value from them; that's fine by us. - It does not need to be JBoss vs the world. Unless you choose to try to make it so. It seems that others in JBoss are able to move on. Gavin and Norman don't seem to want this thread to be a "trainwreck." That's great. If you are not able to move on, it's your problem. Just don't assume that you can get away with making assertions that are clearly incorrect. Rgds Rod
  75. Rod..Not worth it[ Go to top ]

    Bill/Rod/Gavin, Could you guys please keep your s*** in private? This thread is about seam.
  76. a positive negative comment[ Go to top ]

    Boys... I will buy you some candies.
  77. Make it 1 Snickers bar[ Go to top ]

    +1
  78. Re: Rod..Not worth it[ Go to top ]

    No, just the title is mistaken. This is a one-stop-shop decision place about selecting technology for any upcoming projects and/or getting an exact picture of the current state of the JEE industry. I'm sorry taking part of starting all this but I'm happy I see much clearly now.
  79. yep... you are sold[ Go to top ]

    Good to hear from the greats and their technical inputs to this discussion. (I use jboss + spring. May use Seam shortly in a small project) But WHY do I have to put up with their silly stuff? Cant they just talk about seemingly seamless seam and sparingly intrusive spring?
  80. Re: Rod..Not worth it[ Go to top ]

    Bill/Rod/Gavin,

    Could you guys please keep your s*** in private? This thread is about seam.
    At least Hanni hasn't been involved. But at least then we could talk about Bill Burke's breast milk.
  81. Re: JBoss FUD on Spring[ Go to top ]

    Rod,
    That's what you don't get. There is no marketing line on Spring. We don't speak about you in blogs, forums, or in the press that I know of. One exception that I can think of.
    Oh dear. It's time to stop digging now. Can't you take a hint from your own colleague, Gavin, that you're just squandering what remains of your credibility?
    Listen to yourself... seriously. All that junk you posted. Did you even read it? What I'm trying to tell you is that there is no "marketing campaign" by JBoss to FUD Spring. Hibernate team has *always* hated Spring's horrible templating of Hibernate and later on JPA. I don't see how one's opinion of "don't use this crappy piece of Spring" constitutes a concerted marketing campaign by an entire organization. If you read the other stuff, it is all responses to crap like "JBoss competes with Spring" "JBoss must fear Spring", blah blah blah. Responses, not initiatives. No marketing campain. No conspiracies. Nada. If your ego can't handle negative comments on TSS, well, then maybe you shouldn't read or post there. Bill P.S. What makes you think I care if I have any credibility or not? Especially with you?
  82. Re: JBoss FUD on Spring[ Go to top ]

    Listen to yourself... seriously. All that junk you posted. Did you even read it?
    Yes, everything I posted there was pure junk. Sadly, I did read it: I actually read threads in which I participate and base my posts on facts. It was your junk, and you should be embarrassed.
    If you read the other stuff, it is all responses to crap like "JBoss competes with Spring" "JBoss must fear Spring", blah blah blah. Responses, not initiatives.
    Incorrect. Those posts included blogs from JBoss individuals; comments in the press; and multiple replies to forum posts that could easily have been ignored. Anyway, I was replying to your assertion that We don't speak about you in blogs, forums, or in the press that I know of. And, as I mentioned, there's plenty more out there...
    Hibernate team has *always* hated Spring's horrible templating of Hibernate and later on JPA.
    1. False. The Hibernate team were extremely positive about Spring before they joined JBoss. Want some proof? 2. I have explained twice already in this thread, and it's clearly documented that the "templating" you so dislike is not necessary for Spring JPA integration. Your repeating the same mantra out in the face of facts to the contrary is either obtuse or pure marketing (repeat the "Spring is proprietary" message enough and hope it sticks). Several leading members of the JSR-220 expert group such as Mike Keith (co-lead) and Patrick Linskey have been very encouraging and supportive regarding developing this functionality, and clearly think it's useful: only certain JBoss folk cannot understand this feature.
    P.S. What makes you think I care if I have any credibility or not?
    I don't care. It's not my problem. And it's obvious you don't care. Which is just as well. Right, I'm out. I hope any reasonable reader will notice the difference between your and my posts on this thread, as everywhere else.
  83. The definitive solution[ Go to top ]

    Hi guys, I think to have the definitive solution for this terrific debate. The problem with Spring is that is not standard. It doesn’t matter that it works with any conceivable J2EE Server or even without any at all; yeah, it fits great with a lot of APIs starting with ‘J‘ , has built-in support for cool products as Hibernate, iBatis, Quartz, DWR, … but it’s not standard. Well, the solution is sooo obvious … I propose to create JSR 666: CIF (Cool IOP Frameworks). There are endless benefits in being a standard, but just so state a few: * Spring guys will feel the pleasure of using apartheid-like technical arguments like ‘you are not standard’ to other enemy frameworks. Maybe they’ll become addict to that … * The reference implementation is already created … we can take advance and create a good hard-tech acronym (something Spring lacks of and makes it look no serious enough stuff). How about SR (Spring Rocks)?. * Other software giants could feel free to copy Spring without trying to pretend they hate it. Oh yes, I’m almost visualizing JBoss implementation JBRSS (JBoss Rocks Spring Sucks). * We, happy developers will have the possibility of adding a new buzzword wito our resumes for free. * JCP will get closer to their obvious goal of reaching JSR number 1000 before the end of the decade. * It could be included in J2EE. Therefore a new J2EE version would be required: Application Server sellers could add a new version number to their list. * Rod could write a new book!: 'CIF in action (how to keep your house clean)'. As the owner of the idea I propose myself as the JSR absolute and despotic leader. I think an early draft could be delivered next week. In order to reach a final draft for 1.0 on 2032 (when I can retire), I propose Rod and Bill as the main contributors for we to enjoy their funny and constructive discussions. Ok, when do we start? ------------------ Buena pesca a todos. <
  84. Re: The definitive solution[ Go to top ]

    And JCP will be renamed as JVP for Java Very-slow Process.
  85. Re: JBoss FUD on Spring[ Go to top ]

    Wow! If this is how "open source" "vendors" go at each other, then you can just imagine what goes on between commercial vendors. It has always surprised me when developers decide to join one camp or the other. It's not our fight. We have nothing to gain. It seems to me, that JBoss and Spring are just like any other business, and we all know what businesses stand for - profit! The other thing I would like to say is that there are better open source solutions out there for a large range of problems, and I would argue that their advocates are a lot more altruistic too. Ruby and Rails come to mind, and Squeak and Seaside. What happened to the days when leadership meant pursuing innovation and technological progress, for it’s own reward? For example like at Stanford University with Lisp, Bell labs with C/Unix, and Xerox Parc with Smalltalk? I for one choose not to buy into self-serving, over complex technology, and I've blogged as much: http://pab-data.blogspot.com/2007/02/java-state-of-denial.html I would advise everyone who reads this to stop Resume building and to get back to first principles. Knowing Spring or JBoss does not necessarily make you a good programmer and will not guarantee you work for life! Paul.
  86. +1 for Spring[ Go to top ]

    This discussion is just great! I'm a Java newbee that never use either Spring, Hibernate or JBoss-Seam, but after reading your whole discussion, especially the debate between Bill, Rod, and Gavin, I think I will try either Hibernate and/or Spring, not JBoss-Seam or whatever JBoss brings. Maybe Spring for a starter. Good luck Rod! -Dennis- *just another newbee*
  87. Re: +1 for Spring[ Go to top ]

    You will not be able to avoid JBoss server, just as you cannot avoid the core Spring framework (IOC, AOP, CMT etc.), if you do Java to earn your bread, not as a hobby.
  88. Hi George,
    You will not be able to avoid JBoss server
    Actually, for one and other reasons, my company and I are able to avoid JBoss server. We use Oracle AS.
    ...just as you cannot avoid the core Spring framework...
    We've heard so many good things about Spring, but we still not sure what the benefit that Spring can add to our applications. But since in my understanding is that Spring can be plugged in and out, I think it would be interesting to try Spring. Cheers :-)