Seam 2.0 enters beta

Discussions

News: Seam 2.0 enters beta

  1. Seam 2.0 enters beta (92 messages)

    Gavin King has posted that Seam 2.0 (download) has entered the beta phase. Major changes include the ability for Seam services to serve as Web service endpoints, a new expression language, components can be written in Groovy, better transaction support for non-JTA environments, and more. The full change list:
    • Seam WS allows Seam components to function as Web Service endpoints
    • Seam components may now be writted in Groovy
    • The Seam core is now independent of JSF
    • Experimental support for the Google Web Toolkit
    • Integration of Hibernate Search
    • Introduction of JBoss EL, an extension to the Unified EL of Java EE 5
    • Major enhancements to Seam Asynchronicity, including Quartz integration
    • Major enhancements to jBPM integration
    • Completely reorganized packaging of built-in components
    • Migration to JSF 1.2
    • Simplified configuration
    • Support for pageflow composition
    • Enhancements to the integration testing framework
    • New transaction abstraction layer with support for non-JTA environments
    • Enhanced JavaDoc
    • Two new example applications
    • Migration to the new Embedded JBoss
    • Seam JSF controls reimplemented using Ajax4JSF CDK
    • Many, many bugfixes
    A few notes: one wonders what other JSF vendors think of Ajax4JSF being used in Seam, as they certainly use other mechanisms, and while the "Seam core" is independent of JSF, Seam now has been migrated to JSF 1.2 - the specifics here are unclear to you Humble Editor. However, the beta is good news - Seam is an impressive example of a full-scale framework.

    Threaded Messages (92)

  2. Congratulation...[ Go to top ]

    Congratulation for the seam team and to all its community for the new release some questions 1-which parts will be standardised as webbeans,is the JBoss EL extensions will be in standardisation effort 2-why use Seam WS ,not JAX-WS ,what about interoperability to java ws frameworks and .Net as well? 3-why reimplement the jsf comp in ajax4jsf? am i locked in somehow to this framework 4-what about running on other appservers,or other ejb3 implementations as openEJB3 or spring pitchfork
  3. Re: Congratulation...[ Go to top ]

    [quote]which parts will be standardised as webbeans,is the JBoss EL extensions will be in standardisation effort[/quote] The Web Beans spec itself will focus upon: * the basic component model including bijection/resolvers and mapping to EL * the extensible context and context propagation/demarcation model * persistence context / transaction management * bindings to JSF and EJB Some other extra things either have or will come up for debate (validation, CRUD, packaging, BPM, databinding, security) but many of these issues are probably better dealt with in the other expert groups with which we are collaborating. Our current status is that we have got a really good chunk of the component model worked out, with a lot of influence from both Guice and Seam. We've also made a great start on the context model though there is certainly some more work to be done there. Binding of the component model to JSF and EJB should fall pretty naturally out of all this work. We've not yet done any work on persistence. The work we're doing in Web Beans goes hand-in-hand with other work thats happening in the JSF, Validation and JPA expert groups and you can't get the "whole picture" just from our spec. We have been pushing Sun to do a rev of the Unified EL, in order to address some major deficiencies that we have identified and that Jacob Hookom has fixed in JBoss EL. [quote]why use Seam WS ,not JAX-WS ,what about interoperability to java ws frameworks and .Net as well?[/quote] It's not a WS implementation, just a binding of the Seam component model to JAX-WS. [quote]why reimplement the jsf comp in ajax4jsf? am i locked in somehow to this framework[/quote] We're refactoring Ajax4JSF/RichFaces. The tags and Ajax functionality will go into RichFaces, the CDK (Component Development Kit) will be a standalone distribution. CDK is a set of tools that makes it *much* easier to write JSF components, and does not, in any way, tie you to using Ajax4JSF/RichFaces in your application. [quote]what about running on other appservers,or other ejb3 implementations as openEJB3 or spring pitchfork[/quote] We've tested Seam2 on the following platforms: * JBoss 4.2 * Tomcat 6.0 * GlassFish V2 and V1 * WLS 9.2 * OC4J 11g Technology Preview Note that there is zero application-server specific code in Seam, so this is a great validation of what you can do just by following Java EE standards. We also tested against WAS, but we found a problem that we weren't able to resolve in time for the beta release. We're working on it.
  4. Re: Congratulation...[ Go to top ]

    Eeek, let me try again...
    which parts will be standardised as webbeans,is the JBoss EL extensions will be in standardisation effort
    The Web Beans spec itself will focus upon: * the basic component model including bijection/resolvers and mapping to EL * the extensible context and context propagation/demarcation model * persistence context / transaction management * bindings to JSF and EJB Some other extra things either have or will come up for debate (validation, CRUD, packaging, BPM, databinding, security) but many of these issues are probably better dealt with in the other expert groups with which we are collaborating. Our current status is that we have got a really good chunk of the component model worked out, with a lot of influence from both Guice and Seam. We've also made a great start on the context model though there is certainly some more work to be done there. Binding of the component model to JSF and EJB should fall pretty naturally out of all this work. We've not yet done any work on persistence. The work we're doing in Web Beans goes hand-in-hand with other work thats happening in the JSF, Validation and JPA expert groups and you can't get the "whole picture" just from our spec. We have been pushing Sun to do a rev of the Unified EL, in order to address some major deficiencies that we have identified and that Jacob Hookom has fixed in JBoss EL.
    why use Seam WS ,not JAX-WS ,what about interoperability to java ws frameworks and .Net as well?
    It's not a WS implementation, just a binding of the Seam component model to JAX-WS.
    why reimplement the jsf comp in ajax4jsf? am i locked in somehow to this framework
    We're refactoring Ajax4JSF/RichFaces. The tags and Ajax functionality will go into RichFaces, the CDK (Component Development Kit) will be a standalone distribution. CDK is a set of tools that makes it *much* easier to write JSF components, and does not, in any way, tie you to using Ajax4JSF/RichFaces in your application.
    what about running on other appservers,or other ejb3 implementations as openEJB3 or spring pitchfork
    We've tested Seam2 on the following platforms: * JBoss 4.2 * Tomcat 6.0 * GlassFish V2 and V1 * WLS 9.2 * OC4J 11g Technology Preview Note that there is zero application-server specific code in Seam, so this is a great validation of what you can do just by following Java EE standards. We also tested against WAS, but we found a problem that we weren't able to resolve in time for the beta release. We're working on it.
  5. Re: Congratulation...[ Go to top ]

    Note that there is zero application-server specific code in Seam, so this is a great validation of what you can do just by following Java EE standards.
    That's great news! Has anybody some valuable thoughts on Seam vs Wicket? Productivity, maintainability, best use case, familiarization?
  6. Seam vs. Wicket[ Go to top ]

    Seam is a big, complicated, messy kludge on top of a terrible "standard" (JSF). Wicket is a lean, elegant and flexible component-based framework. If you want to be buzzword-compliant, use Seam. If you want to do good work and preserve your sanity, use Wicket.
  7. Re: Seam vs. Wicket[ Go to top ]

    Seam is a big, complicated, messy kludge on top of a terrible "standard" (JSF). Wicket is a lean, elegant and flexible component-based framework. If you want to be buzzword-compliant, use Seam. If you want to do good work and preserve your sanity, use Wicket.
    Productivity, maintainability, best use case, familiarization?
  8. Re: Seam vs. Wicket[ Go to top ]

    Seam is a big, complicated, messy kludge on top of a terrible "standard" (JSF). Wicket is a lean, elegant and flexible component-based framework. If you want to be buzzword-compliant, use Seam. If you want to do good work and preserve your sanity, use Wicket.
    Ouch! Question: have you ever used Seam to build an application? ;-) By the way, it's now possible (easy, in fact) to build Wicket integration for Seam, if anyone is interested. I don't personally find Wicket to be "better" than JSF (I'll take facelets templates over Swing-style code any day), but it's clear that it has fans, and I imagine it would be interesting to the Wicket community to have Seam's contextual component model, conversations, BPM integration, persistence context management, EJB3 integration, asynchronicity, rule-based security model, Drools integration, etc, in the context of a Wicket application. Just putting that suggestion out there... ;-)
  9. Re: Seam vs. Wicket[ Go to top ]

    Seam is a big, complicated, messy kludge on top of a terrible "standard" (JSF). Wicket is a lean, elegant and flexible component-based framework. If you want to be buzzword-compliant, use Seam. If you want to do good work and preserve your sanity, use Wicket.
    I'm sorry but I seriously doubt you're qualified to make any of those statements. Read the post. Specifically, # Seam components may now be written in Groovy # The Seam core is now independent of JSF
  10. Re: Seam vs. Wicket[ Go to top ]

    Seam is a big, complicated, messy kludge on top of a terrible "standard" (JSF). Wicket is a lean, elegant and flexible component-based framework. If you want to be buzzword-compliant, use Seam. If you want to do good work and preserve your sanity, use Wicket.
    You almost had me convinced, but forgot "bolted-on", so I decided to stay with Seam.
  11. blah vs lalala[ Go to top ]

    Java is a big, complicated, messy kludge on top of a terrible "standard" (JVM). VB is a lean, elegant and flexible component-based framework. If you want to be buzzword-compliant, use Java. If you want to do good work and preserve your sanity, use VB. An RDBMS is a big, complicated, messy kludge on top of a terrible "standard" (SQL). ODBMS is a lean, elegant and flexible based db. If you want to be buzzword-compliant, use an RDBMS. If you want to do good work and preserve your sanity, use an ODBMS. Eclipse is a big, complicated, messy kludge on top of a terrible "standard" (Java). VI is a lean, elegant and flexible editor. If you want to be buzzword-compliant, use Eclipse. If you want to do good work and preserve your sanity, use VI. A toilet is a big, complicated, messy kludge on top of a terrible "standard" (pluming). An outhouse is a lean, elegant and flexible crapper. If you want to be buzzword-compliant, use a toilet. If you want to do good work and preserve your sanity, use outhouse. Ok enough fun. I am very interested in learning both Seam and Wicket. Sorry Bruce, but your post is pretty lame.
  12. Re: blah vs lalala[ Go to top ]

    Ja,aja ja,ja,jaa!!!!! Still LOL!. That was really nice.
  13. Re: blah vs lalala[ Go to top ]

    Sorry. I almost forgot!. Congrats, to the JBoss Seam Team. Nice piece of software!!!. I see a pattern here: Hibernate - (became)-> JPA Seam - (will become) -> WebBeans? o part of it? Congrats, - Rory.
  14. Re: Congratulation...[ Go to top ]

    Has anybody some valuable thoughts on Seam vs Wicket? Productivity, maintainability, best use case, familiarization?
    Wicket and Seam are not comparable. Wicket's feature set is more equivalent with JSF. What is important is that JSF is slowly becoming an accepted standard in corporate world. It's still a long way from Strut's (un-deserved) popularity, but if you need to concern yourself with non-technical issues, like finding a job, development contract or consulting gig, or convincing the powers in charge about platform choice, then JSF leads by about 1000x: http://www.indeed.com/jobtrends?q=java+jsf%2C+java+wicket&l= Compared to the graph above any real or perceived differences in frameworks technical merits are not significant (as long as the framework is not struts, thats just too bad :)
  15. Re: Congratulation...[ Go to top ]

    Wicket and Seam are not comparable.
    I thought both are web frameworks!?
  16. Re: Congratulation...[ Go to top ]

    Wicket and Seam are not comparable.
    I thought both are web frameworks!?
    No, not really. JSF is a web framework. Seam is an application framework that integrates very closely and elegantly with JSF. I don't think there's anything in Wicket that "overlaps" with Seam.
  17. Seam is not a web framework[ Go to top ]

    Wicket and Seam are not comparable.
    I thought both are web frameworks!?
    No, not really. JSF is a web framework. Seam is an application framework that integrates very closely and elegantly with JSF.

    I don't think there's anything in Wicket that "overlaps" with Seam.
    Thanks for this clarification.
  18. a wicket user tries jsf[ Go to top ]

    Wicket and Seam are not comparable.
    I thought both are web frameworks!?
    No, not really. JSF is a web framework. Seam is an application framework that integrates very closely and elegantly with JSF.

    I don't think there's anything in Wicket that "overlaps" with Seam.
    Thanks for this clarification.
    At least I found this wicket/jsf comparison: http://ptrthomas.wordpress.com/2007/05/14/a-wicket-user-tries-jsf/ What do you think about it?
  19. For the records[ Go to top ]

    Found some valuable thoughts: http://www.virtuas.com/articles/webframework-sweetspots.html
  20. Seam, Wicket and all the rest[ Go to top ]

    Wicket and Seam are not comparable.
    I thought both are web frameworks!?


    No, not really. JSF is a web framework. Seam is an application framework that integrates very closely and elegantly with JSF.

    I don't think there's anything in Wicket that "overlaps" with Seam.
    I disagree. JSF is a user interface framework. JSF defines a component model for the web UI. Nothing more. It's in the spec, chapter 1. JSF, GWT and Struts good examples for different kinds web UI frameworks. None of them really tell me how to develop a web application, they help me to manage the UI part of the web application. The architecture is up to me. I can take the full Java EE stack and some patterns book and build webapps. Now Seam is really a Web *Application* Framework, from A to Z. No more architectural thoughts, its a "one size fits all" architecture. As far as I know, Wicket does the same. So it is with Guice, if I got it right. And there is this ruby on rails stuff. Did someone cry Bullshit bingo? :-) So I have to choose, I have to learn from all of them, respect the cool ideas everyone is having and pick the best one for me today. Having a look at Seam was great, lots of good ideas. But unfortunately Seam 2.0 beta is already legacy (thank you Gavin for the hint), I'll wait until Seam 3.0 comes up and see what is going to be (JSF or GWT, Webbeans components, etc). Maybe the reference documentation gets updated too, and there nothing like "this silly people" (Seam reference documentation, chapter 18. Caching) more in it. Until then I will stick to Spring, it is already released and does all this integration I need. Wicket and Guice are worth a look at, see what I can learn from them. brgds, Papick
  21. Re: Congratulation...[ Go to top ]


    We've tested Seam2 on the following platforms:

    * JBoss 4.2
    * Tomcat 6.0
    * GlassFish V2 and V1
    * WLS 9.2
    * OC4J 11g Technology Preview
    Gavin, Any reason why Seam2 would not work with OC4J 10.1.3? I'm worried it will be a while before I will be able to deploy 11 at our company. Thanks, ~Matt
  22. Re: Congratulation...[ Go to top ]


    We've tested Seam2 on the following platforms:

    * JBoss 4.2
    * Tomcat 6.0
    * GlassFish V2 and V1
    * WLS 9.2
    * OC4J 11g Technology Preview


    Gavin,

    Any reason why Seam2 would not work with OC4J 10.1.3? I'm worried it will be a while before I will be able to deploy 11 at our company.

    Thanks,

    ~Matt
    Um. I'm not sure we've tried it. What version of JSF does it support?
  23. Re: Congratulation...[ Go to top ]


    We've tested Seam2 on the following platforms:

    * JBoss 4.2
    * Tomcat 6.0
    * GlassFish V2 and V1
    * WLS 9.2
    * OC4J 11g Technology Preview


    Gavin,

    Any reason why Seam2 would not work with OC4J 10.1.3? I'm worried it will be a while before I will be able to deploy 11 at our company.

    Thanks,

    ~Matt


    Um. I'm not sure we've tried it.

    What version of JSF does it support?
    Darn, looks like 10.1.3 only supports 1.1. Thanks, ~Matt
  24. Re: Congratulation...[ Go to top ]

    Darn, looks like 10.1.3 only supports 1.1.
    There might be a way to upgrade the server to support 1.2. There certainly is in JBoss.
  25. Re: Congratulations...[ Go to top ]

    I know this post is a bit old, but:
    Darn, looks like 10.1.3 only supports 1.1.
    I'm fairly new to the OC4J world, but I believe 10.1.3 only supports the Servlet 2.4 spec, whereas the JSF 1.2 spec requires (sort of. See below) Servlet 2.5 due to some dependencies in the JSP area. However, if you are using something like Facelets or JSFTemplating, you can happily run JSF 1.2 in a Servlet 2.4 container. My memory's a bit cloudy at the moment as I've been trying so many different things, but I'm pretty sure I have a JSF 1.2/Facelets app running under 10.1.3 (it was .2, I think, but I've downgraded to .1 as that's what we're going to production with. Don't ask. :) You just have to bundle the JSF jars with your app or deploy them to the applib/ directory on the server. I don't think 10.1.3 bundles a JSF impl of any kind, so you shouldn't have any conflicts. I'm also in the process of getting a Seam 2.0B1 app running under 10.1.3. That's pretty close to working, hampered largely by my inexperience with Seam. I'm going to get the app running under GlassFish, where Seam 2 is known to work, then work out any deployment issues that might exist under oc4j. If I find anything noteworthy, I'll make a note of it on my blog (blogs.steeplesoft.com -- sorry if that comes across as a self-promotion. It's not meant to be. It's just that if I post it here, no one's likely so see it on a story that's already a few weeks old. ;) Cheers!
  26. Seam + Oracle[ Go to top ]

    Matt, Evaluating Seam 1.x we came to the conclusion that it needs JEE 5. Which only OC4J 11 supports. So I guess upgrading JSF to 1.2 is not enough. As a result we had to give up on Seam unfortunately; it will be some time before that server will be available at our place, just like in your situation. We are using Spring Webflow now although Seam was our first choice. btw I'm getting a bit fed up with the Wicket wankers posting in threads that are not about Wicket.
  27. Re: Seam; Oracle[ Go to top ]

    Evaluating Seam 1.x we came to the conclusion that it needs JEE 5. Which only OC4J 11 supports. So I guess upgrading JSF to 1.2 is not enough. As a result we had to give up on Seam unfortunately; it will be some time before that server will be available at our place, just like in your situation. We are using Spring Webflow now although Seam was our first choice.
    valuable information.
    btw I'm getting a bit fed up with the Wicket wankers posting in threads that are not about Wicket.
    less valuable information.
  28. works fine on oc4j 10.1.3[ Go to top ]

    Matt,

    Evaluating Seam 1.x we came to the conclusion that it needs JEE 5. Which only OC4J 11 supports. So I guess upgrading JSF to 1.2 is not enough.
    As a result we had to give up on Seam unfortunately; it will be some time before that server will be available at our place, just like in your situation.
    We are using Spring Webflow now although Seam was our first choice.

    btw I'm getting a bit fed up with the Wicket wankers posting in threads that are not about Wicket.
    Joost, Seam 2.1 works fine on oc4j 10.1.3.3. We have a working setup here... - oc4j 10.1.3.3 - jsf ri 1.2_10 - richfaces 3.3.0 ga - facelets 1.1.14 just my 2 cents.
  29. Re: Congratulation...[ Go to top ]

    Congratulation guys...
  30. Hello, Did anybody understand what does GWT intergation give to developer? From the first glance it gives almost nothing comparing to Spring. In Spring developer can use GWT service as a regular Spring Bean with AOP,Transactions and of course as general IoC bean. In Seam exapmple the developer can call @WebMethod annotated methods of Seam componets. What benefits does it give? --Mark
  31. Congrats on the release. Seam is definitely one of the most innovative frameworks. Unfortunately, it has also become one of the most bloated. For those of us who want to keep things lean and mean, it would be great if we could have some preliminary info about which features will be included in the JSR299/WebBeans.
  32. Congrats on the release.
    Seam is definitely one of the most innovative frameworks. Unfortunately, it has also become one of the most bloated.
    Define "bloated", does it mean: * Complex APIs that make it difficult to do simple things * A huge lot of dependencies other things I'm not interested in * A lot of purely optional features that I happen to not be using One of the things that Seam2 does much better than Seam 1.x is that we've split out a lot of functionality into independent packages and carefully studied exactly what dependencies each package has. If you're not using Seam Security (most Seam users are), just ignore org.jboss.seam.security. If you're not using Seam-managed persistence contexts (most Seam users are) just ignore org.jboss.seam.persistence. If you're not using Seam asynchronicity, just ignore org.jboss.seam.async. If you're not using jBPM, just ignore org.jboss.seam.bpm. If your application is not internationalized, ignore org.jboss.seam.international. If you don't send mail, ignore org.jboss.seam.mail. If you don't send messages, ignore org.jboss.seam.jms. If you don't need business rules, ignore org.jboss.seam.drools. Etcetera. ALL mature software is "bloated". Why? Because all mature software must have features that only 10% of the userbase is actually using. So for 90% of the userbase, any of these features looks like bloat. The trouble is that *every* user is using at least 1 or 2 of these features, and could not do without it :-) Anyway, if you have feedback as to how we can better manage the "bloat", please let us know, its the first time I've heard this criticism, but I'm sensitive to it.
    For those of us who want to keep things lean and mean, it would be great if we could have some preliminary info about which features will be included in the JSR299/WebBeans.
    See my previous post. Web Beans will certainly be extremely lean. It is the core component model of an application / integration framework, it does not actually do any integration itself. The future direction is that Web Beans will define the component model, and there will be various implementations of Web Beans containers to choose from. Seam3 will come in three parts: * An implementation of Web Beans, with support for legacy Seam2 components. * An integration suite that runs on any Web Beans implementation, and provides integration of jBPM, Drools, Mail. * A suite of JSF controls that runs on any JSF implementation.
  33. Gavin King Wrote:
    Define "bloated", does it mean:
    ... Any or all of those three would be fine. Lets not start defining words. Instead, let me eloborate my concerns with Seam. I'v been prototyping with and comparing Seam vs. Spring + Spring Web Flows + Spring Security based stacks for several weeks. Thoughts: 1. Much of Seam -- the unified component model and pervasive use of dependency injection in particular -- is just brilliant and elegant. 2. Much of Spring is 'previous gen', XML heavy and in many parts shows that Spring was not designed from 'the ground up' to the requirements that Seam handles so elegantly. 3. Spring's documentation beats Seam by massive margin. For example the documentation of 'conversation scope' in Seam is couple of pages, while the documentation of Spring's equivalent concept is same size as ALL of the Seam docs combined (about 800k html). 4. Seam poses difficult requirements at runtime -- EJB3 or embedded jboss thingy inside tomcat -- while Spring runs anywhre. Most large corps run either Weblogic or Websphere, and then Tomcat as light alternative. Of these Websphere is not EE5 yet, it will be possibly years before those pervasive Weblogic 'eight-ones' will be upgraded to v10, and running jboss inside tomcat is not going to be easily approved in most large corps. 5. Spring is old, battle proven and has large knowledge base. It has great rep of stable releases and honouring backwards compatibility. 6. Spring's dependency injection model is battle proven. Seam's.. well, time will show, but i think there is a fair possibility that the current 'name' -based autowiring and outjection becomes too risky and difficult to maintain in large projects, and will force a move to type based autowiring approach. So.. In terms of getting Seam adopted in large scale, critical enterprise development it seems to me that the real concerns are: -- Documentation -- Difficult runtime environment requirements -- Lack of previous adoption/battle provness/knowledge base (aka "we don't want to be first") -- Fear, Uncertainty and Doubt, but perhaps justified, regarding Seam's dynamic dependency bijection etc. Now, how did Seam respond to these enterprise developer concerns with v2.0? By adding support for yet another bunch of acronyms that marginal number closet developers use. Perhaps it's true that you cannot please everyone. But also perhaps now would be time to choose if you want to please the "gee they added XYZ, i'll play with this in my basement this evening" crowd, or the serious large scale enterprise development crowd.
    Anyway, if you have feedback as to how we can better manage the "bloat", please let us know
    Sure. Stop adding features. Instead, direct resources for solving the concerns i pointed out earlier. Regards, Henri Karapuu
  34. I'v been prototyping with and comparing Seam vs. Spring + Spring Web Flows + Spring Security based stacks for several weeks. Thoughts:
    It would be really great to see some prototype code insted of thoughts :-) Please blog and share what you have. Current Seam and Spring Web Flow examples are not so good imho. They show you a particular feature each, but fail to show a real world scenario in a real app imho. /Magnus
  35. Re: Seam vs. Spring[ Go to top ]

    Most large corps run either Weblogic or Websphere, and then Tomcat as light alternative. Of these Websphere is not EE5 yet...
    Serious problems with Websphere?
  36. Spring's documentation beats Seam by massive margin.
    We will try to improve on this, I've been feeling lately like the docs need a total restructuring. They make it kinda hard to find exactly which bits of Seam you "need" for a particular problem. In the meantime, get this: http://www.amazon.com/JBoss-Seam-Simplicity-Beyond-Prentice/dp/0131347969/ref=pd_bbs_sr_1/104-4470274-5887144?ie=UTF8&s=books&qid=1183149431&sr=8-1 Note that I did spend a bunch of time on JavaDoc this release :)
    Seam poses difficult requirements at runtime -- EJB3 or embedded jboss thingy inside tomcat
    Definitely not true in Seam2. See the line item above about the "transaction management abstraction" thingy. We're now able to deploy on Tomcat with no jboss embedded. This was requested by users.
    Spring's dependency injection model is battle proven. Seam's.. well, time will show, but i think there is a fair possibility that the current 'name' -based autowiring and outjection becomes too risky and difficult to maintain in large projects, and will force a move to type based autowiring approach.
    You will be happy to know that the Web Beans EG is adopting a primarily type-based approach, based upon Bob Lee's work in Guice. But I don't see that our name-based injection is different to Spring's "bean id" based injection. An id is just a name. Guice is the one which has gone its own (innovative) way here.
    -- Documentation -- Difficult runtime environment requirements -- Lack of previous adoption/battle provness/knowledge base (aka "we don't want to be first") -- Fear, Uncertainty and Doubt, but perhaps justified, regarding Seam's dynamic dependency bijection etc.
    -- We'll work on it! -- Fixed in 2.0! -- Confidence grows gradually and slowly with time, I'm not bothered by that, I've helped grow several technologies from "new and cool" to "mature and accepted" -- Dynamic injection is something different that people get used to after 2 weeks of working with Seam and then wonder why you would do it in any other way
    Now, how did Seam respond to these enterprise developer concerns with v2.0? By adding support for yet another bunch of acronyms that marginal number closet developers use.
    Don't imagine for a second that the list of new features represents all the work that we've done. Most of the work is stuff that's "invisible" :-)
    Perhaps it's true that you cannot please everyone. But also perhaps now would be time to choose if you want to please the "gee they added XYZ, i'll play with this in my basement this evening" crowd, or the serious large scale enterprise development crowd.
    IMO, things like WS support, Hibernate Search, improved jBPM integration, enhanced testing fwk, Quartz integration is stuff for grownups, with enterprise apps. It's not buzzwordy stuff. It's stuff that serious people need. Thanks for the feedback, I appreciate it.
  37. We will try to improve on this, I've been feeling lately like the docs need a total restructuring. They make it kinda hard to find exactly which bits of Seam you "need" for a particular problem.
    Exactly my feeling. They are good 'quickstart' style, fast paced and not boring. But then comes time for finding reference information and it's just not there, you have to scroll through the examples again and hope to find something that gives a glue, and then experiment.
    We're now able to deploy on Tomcat with no jboss embedded.
    This is huge news for me, and turns the balance seriously in Seam's favor.
    You will be happy to know that the Web Beans EG is adopting a primarily type-based approach, based upon Bob Lee's work in Guice.
    Hey, my day is starting to look much better :) I'm not familiar with Guice, but as i wrote i'm feeling rather strongly that type based injection might be needed. Yes, Spring is id based for the standard use, but it's a very different scenario; there are normally much less injections, you can just enforce 'no-autowiring'rule over the project and then use xml local ref to get development time checking. So things are tedious, but safe and stay in control. With seam, if i rename a private instance variable it can wreak havoc across the app as the default context variable name changes along. Thats a really dangerous 'feature' in Seam.
    Dynamic injection is something different that people get used to after 2 weeks of working with Seam and then wonder why you would do it in any other way
    The background is that i wrote a dynamic injection and nested conversation scope implementations before you came out of closet with seam, and i'm now looking to trash my versions of these, and use Seam or Spring's stack instead. So yes, i agree with the dynamic injection. I was trying to point out more generally issues that might prevent Seam's adaptation in enterprise development.
    Thanks for the feedback, I appreciate it.
    I hope i didn't sound too harsh -- as i wrote i do think that Seam is in most parts just brilliant. Which, btw is a lot more than i can say about the quoting system in this forum .. Regards, Henri Karapuu
  38. In the meantime, get this:

    http://www.amazon.com/JBoss-Seam-Simplicity-Beyond-Prentice/dp/0131347969/ref=pd_bbs_sr_1/104-4470274-5887144?ie=UTF8&s=books&qid=1183149431&sr=8-1
    Sorry to say but I did not like that book that much. Actually I think that was the worst $27.99 I've spent this year so far.
    You will be happy to know that the Web Beans EG is adopting a primarily type-based approach, based upon Bob Lee's work in Guice.

    But I don't see that our name-based injection is different to Spring's "bean id" based injection. An id is just a name. Guice is the one which has gone its own (innovative) way here.
    Why not give credit where credit's due? It wasn't that long ago to already forget who did the pioneer work on inversion of control and type-based injection in the Java world.
    I'm not bothered by that, I've helped grow several technologies from "new and cool" to "mature and accepted"
    Please do name a few besides Hibernate, I'm seriously interested.
    Dynamic injection is something different that people get used to after 2 weeks of working with Seam and then wonder why you would do it in any other way
    I'm getting a bit tired about all that marketing flowing everywhere. Not everyone buys automatically into anything which is 'something different', 'invisible', 'magic', etc. You seriously think java devs/architects don't deserve real tech reasons without the garnish and you rather need to follow close that crap TV-ad style?
  39. You will be happy to know that the Web Beans EG is adopting a primarily type-based approach, based upon Bob Lee's work in Guice.

    But I don't see that our name-based injection is different to Spring's "bean id" based injection. An id is just a name. Guice is the one which has gone its own (innovative) way here.


    Why not give credit where credit's due? It wasn't that long ago to already forget who did the pioneer work on inversion of control and type-based injection in the Java world.
    I'm not sure who you think I should be giving credit to. Certainly Guice is the first component model to make typesafe dependency resolution really practical, via the use of "binding annotations". AFAIK, no other project has that even today. But there were certainly typesafe approaches to dependency injection in PicoContainer and XWork, and even as far back as Apache Avalon, if we're looking for who "invented" the basic concept.
  40. jboss embedded[ Go to top ]

    4. Seam poses difficult requirements at runtime -- EJB3 or embedded jboss thingy inside tomcat -- while Spring runs anywhre.
    The jboss embedded is there if you want to run a TM, connection pooling, messaging, or a EJB3 container. It is no different or more overhead than if you wanted to use Spring to instantiate JOTM and/or ActiveMQ. And you can pick and choose which components you want to run (like you would if u were using Spring to instantiate these services). The overhead to start all these services is about 5-6 sec on a 2.4ghz intel box, and again, u can tune this.
    But also perhaps now would be time to choose if you want to please the "gee they added XYZ, i'll play with this in my basement this evening" crowd
    Spring + dependencies is a 65M download. Seam 90M, but it includes more services/components (jboss embedded (hibernate, TM, messaging, JPA, EJB3) is +20M alone, jbpm, JSF, faces, and drools.)
  41. Re: jboss embedded[ Go to top ]

    4. Seam poses difficult requirements at runtime -- EJB3 or embedded jboss thingy inside tomcat -- while Spring runs anywhre.


    The jboss embedded is there if you want to run a TM, connection pooling, messaging, or a EJB3 container. It is no different or more overhead than if you wanted to use Spring to instantiate JOTM and/or ActiveMQ. And you can pick and choose which components you want to run (like you would if u were using Spring to instantiate these services). The overhead to start all these services is about 5-6 sec on a 2.4ghz intel box, and again, u can tune this.

    But also perhaps now would be time to choose if you want to please the "gee they added XYZ, i'll play with this in my basement this evening" crowd


    Spring + dependencies is a 65M download. Seam 90M, but it includes more services/components (jboss embedded (hibernate, TM, messaging, JPA, EJB3) is +20M alone, jbpm, JSF, faces, and drools.)
    I wouldnt call spring too lightweight either, both nowadays are rather heavy irons, but, springs depencencies in most cases can be reduced to a few third party libs (due to the fact that you use only small subparts of spring. I really have to look how Seam nowadays behaves in this area, last time I checked it it had 70 or so jars which were needed dependencies. It would be heavens sent if they had reduced those dependencies. Anyway again Congratulations guys Seam is an excellent framework, and one of the most innovative ones as well.
  42. Re: jboss embedded[ Go to top ]

    Spring + dependencies is a 65M download. Seam 90M
    This is not really a meaningful comparison. The 90meg Seam download includes * about 15 full example applications * documentation * all _optional_ dependencies: drools, jbpm, itext, jfreechart, hibernate, ajax4jsf+richfaces, groovy, jbosscache, JSF RI, Meldware mail, java ee api jars * the seam-gen tool and its dependencies: including ant, hibernate tools and freemarker * an entire integration testing framework and its dependencies: TestNG and Embedded JBoss - which is not required at runtime in _any_ environment, not even in Tomcat * the actual seam-* and jboss-el jars which amount to less than 2meg IIRC, and which are all optional apart from jboss-seam.jar which is < 1 meg and jboss-el jars. Why did we decide to package all this stuff together in one download? Well, because it actually makes getting started with Seam much easier for new users. People complain endlessly about how hard it is to get started building a new application in Java, so we wanted to make it as easy as: (1) Unzip (2) type "seam new-project" (3) Start coding Now, this clearly contributes to the perception of bloatedness, since its not immediately clear to users exactly which bits are really necessary. So what we will try to do is repackage stuff for Seam 2.0 and give you several download options: * a bundled distribution for people who just want to get started * a minimal distribution for people who complain about bloat * unbundled packages of seam-gen, examples, Seam JSF tags and perhaps some other stuff which we might decide to split out (for example, I might do a seam-jsf.jar to completely split the JSF-specific stuff from the core). I hope that approach can satisfy both constituencies. (To be honest, this thread is the first time I've really heard this complaint.) We are also PoCing a Maven build to try and make dependency management simpler. We'll only go in that direction if things really *do* get simpler, however.
  43. Re: jboss embedded[ Go to top ]

    I really have to look how Seam nowadays behaves in this area, last time I checked it it had 70 or so jars which were needed dependencies. It would be heavens sent if they had reduced those dependencies.
    I don't know which version you looked at, but I don't recall any version which had 70 runtime dependencies! Certainly we have reduced hard dependencies as we went along and right now you can run a version of the Seam booking demo in Tomcat with only seam, jboss-el, ajax4jsf, jsf ri and hibernate, I believe. Ajax4JSF could be eliminated by removing some UI sugar. I'll check that this is the exact dependency list.
  44. Congrats on the release. Seam is definitely one of the most innovative frameworks.

    Unfortunately, it has also become one of the most bloated.

    For those of us who want to keep things lean and mean, it would be great if we could have some preliminary info about which features will be included in the JSR299/WebBeans.
    Geez. I don't even use Seam but come on! "Bloated" is right up there with "When all you have is a hammer..." What exactly is bloated? I don't use ashtrays or the sunroof in my car. I guess this must be bloated. Everyone doesn't use the same features. Just because you don't want a feature doesn't mean someone else doesn't find value in it.
  45. Congrats on the release. Seam is definitely one of the most innovative frameworks.

    Unfortunately, it has also become one of the most bloated.


    Geez. I don't even use Seam but come on! "Bloated" is right up there with "When all you have is a hammer..."

    What exactly is bloated? I don't use ashtrays or the sunroof in my car. I guess this must be bloated.

    Everyone doesn't use the same features. Just because you don't want a feature doesn't mean someone else doesn't find value in it.
    I already gave Gavin a rather long answer earlier in the thread. In addition to the points made in that post, i have to say that i also strongly disagree with your and Gavin's views that Seam, or any product, should include all the features that small portion of the user base needs or wants. Every feature has a cost, which during the entire life cycle of a software product is of entirely different magnitude than the cost of implementing that feature at the beginning. As of now, Seam includes things such as formatting text based on *funny* _characters_, while lacking proper reference documentation of many core features, or deployment issues on different application servers. Honestly, i cannot find better word than "bloat" for such software. At the same time, as i'v said, the core parts of Seam are incredibly elegant. Regards, Henri Karapuu
  46. Re: Seam 2.0 enters beta[ Go to top ]

    A few notes: one wonders what other JSF vendors think of Ajax4JSF being used in Seam,
    Seam has no runtime dependency (i.e. in an application built using Seam) on any part of Ajax4jsf - it is required if you want to build Seam from source; but of course we've put lots of effort in to making sure Seam and Ajax4jsf work really nicely together.
    Seam now has been migrated to JSF 1.2
    Beyond having to tweak your configuration files, this really shouldn't hurt at all - anything written (well, ok written well) for JSF 1.1 will run smoothly on JSF 1.2 (but without utilizing the improvements JSF 1.2 brings). For example Ajax4jsf and MyFaces Trinidad are both desgined for JSF 1.1, but work great when using a JSF 1.2 implementation.
  47. wicket and seam[ Go to top ]

    Gavin, I too have been thinking of an integration with seams's converstaions/continuations with wicket. I'll try to make it happen :) Thanks for decoupling from JSF. After watching devs suffer through jsf even with facelets we're ready to move on, but I can see many pieces of value that seam could add with its support for conversations and continuations. James
  48. Re: wicket and seam[ Go to top ]

    I too have been thinking of an integration with seams's converstaions/continuations with wicket. I'll try to make it happen :)
    cool :)
  49. Re: wicket and seam[ Go to top ]

    I too have been thinking of an integration with seams's converstaions/continuations with wicket. I'll try to make it happen :)


    cool :)
    It happened :)
  50. Re: wicket and seam[ Go to top ]

    I too have been thinking of an integration with seams's converstaions/continuations with wicket. I'll try to make it happen :)
    cool :)
    It happened :)
    Congratulations!
  51. Re: Seam 2.0 enters beta[ Go to top ]

    Hi All, I thought I give this stuff a read, and no I have no experience with Seam. My first thought is that pulling data from a database and sucking a string through a socket, just shouldn't be this complex :^) When things get this complicated isn't it a sure sign that perhaps we've lost our way? Sorry - but when Gavin first started talking about this stuff back in the hay-days of the Application Server it did have some credablity sort of, but today with options like Rails, it beggers belief that people are actually buying into this stuff. The again, it does mean that your contract needs to be twice as long, and if you have taken the time to master all this stuff then you'll become indispensible, so you can hike your rate :^) Too cynical? Probably not. Paul.
  52. Re: Seam 2.0 enters beta[ Go to top ]

    ..The again, it does mean that your contract needs to be twice as long, and if you have taken the time to master all this stuff then you'll become indispensible, so you can hike your rate :^)

    Too cynical? Probably not.

    Paul.
    Hehe ....Yeah you're right. Being an "agile coach" is a way more prestigious/honest way to make a living. cheers =p
  53. Re: Seam 2.0 enters beta[ Go to top ]

    ..The again, it does mean that your contract needs to be twice as long, and if you have taken the time to master all this stuff then you'll become indispensible, so you can hike your rate :^)

    Too cynical? Probably not.

    Paul.


    Hehe ....Yeah you're right. Being an "agile coach" is a way more prestigious/honest way to make a living.

    cheers

    =p
    Hi, Yeah, we've all got to pay the bills... And I agree there are plenty of "wannabe Agile" people out there trying to get paid :^) I'm no saint, but it does concern me that our industry can be soo self serving. Do you remember the Y2K rip-off? Most end users and business customers I come across have a totally cynical attitude towards software, and many see sponsoring a software development project as a career limiting move :^) Customer apathy means that we're all out of a job :^). I guess I was having a bad day when I posted this, and I apologise to Gavin et al. There is a serious point here however. JBoss makes it's money through consulting services. People need consultants when things get so complicated that they can't work them out for themselves... Am I the only one who sees the potential conflict in interest? :^) Paul.
  54. Re: Seam 2.0 enters beta[ Go to top ]

    There is a serious point here however. JBoss makes it's money through consulting services. People need consultants when things get so complicated that they can't work them out for themselves...

    Am I the only one who sees the potential conflict in interest? :^)

    Paul.
    Interface21 is a consultancy too. Has the Spring project been saperated from Interface 21?
  55. Re: Seam 2.0 enters beta[ Go to top ]

    There is a serious point here however. JBoss makes it's money through consulting services. People need consultants when things get so complicated that they can't work them out for themselves...

    Am I the only one who sees the potential conflict in interest? :^)

    Paul.


    Interface21 is a consultancy too. Has the Spring project been saperated from Interface 21?
    Agreed! The same goes for them too. Personally I don't like the Marketing tone that eminates from both of these companies. It just isn't plain honest IMO, and not appropriate for what is supposed to be community based, open source, "free" software. I've blogged as such: http://pab-data.blogspot.com/2007/07/king-is-dead-long-live.html I wonder what Richard Stallman would have to say? :^) Paul.
  56. Re: Seam 2.0 enters beta[ Go to top ]

    I know this post is a flamebait, but I've heard this argument again and again over the years on TSS.
    JBoss makes it's money through consulting services. People need consultants when things get so complicated that they can't work them out for themselves...
    We're not IBM. Red Hat(JBoss) makes most of its money through subscriptions, not consulting.
    Am I the only one who sees the potential conflict in interest? :^)
    Yes, I see a conflict, but not the one you're thinking of. Since we're a support/subscription based business, it would be a conflict of interest for Red Hat's business to produce buggy or too complex software. Our support business just wouldn't scale.
  57. Re: Seam 2.0 enters beta[ Go to top ]

    I know this post is a flamebait, but I've heard this argument again and again over the years on TSS.

    JBoss makes it's money through consulting services. People need consultants when things get so complicated that they can't work them out for themselves...


    We're not IBM. Red Hat(JBoss) makes most of its money through subscriptions, not consulting.

    Am I the only one who sees the potential conflict in interest? :^)


    Yes, I see a conflict, but not the one you're thinking of. Since we're a support/subscription based business, it would be a conflict of interest for Red Hat's business to produce buggy or too complex software. Our support business just wouldn't scale.
    Hi Bill, Thanks for responding, and attempting to clarify the situation. The simple fact is that I just don't know how the "business side" and the "community side" of an organisation like JBoss relate to each other. What I'm looking for is openness and disclosure. Your response is a step in this direction, but it prompts as many questions as it does answers. For example AFAIK a support business model is based on the idea of providing support for a product with an agreed level of service. I see Jboss however as a tool. So I understand that if Jboss as a product has bugs, then a support agreement helps, but if Jboss as a tool is complicated and unwieldy, how does product support help here? When you market a product or a service under the altruistic banner of community based free software, then I believe that the questions I pose are only fair. Perhaps your are totally transparent, in which case please post a link to where your business policies are disclosed. Regards, Paul.
  58. Re: Seam 2.0 enters beta[ Go to top ]

    When you market a product or a service under the altruistic banner of community based free software, then I believe that the questions I pose are only fair.
    Paul, FYI, no-one at JBoss or in any other open source community ever represented themselves as "altruistic". Not even Apache claims altruism as a motive. JBoss has said very clearly that it is an open source business. Open source is not about charity and has never been evangelized as such. Indeed, OSI, the folks who coined the word "open source" were concerned with creating businesses in the field of free software. Now, if you think altruism is such a great thing, do yourself a favor and go read some Ayn Rand. Oh and your blog accusing myself and Rod Johnson of "dishonesty" because we happen to prefer Java to Ruby is just absurd.
  59. Re: Seam 2.0 enters beta[ Go to top ]

    When you market a product or a service under the altruistic banner of community based free software, then I believe that the questions I pose are only fair.


    Paul, FYI, no-one at JBoss or in any other open source community ever represented themselves as "altruistic". Not even Apache claims altruism as a motive. JBoss has said very clearly that it is an open source business. Open source is not about charity and has never been evangelized as such. Indeed, OSI, the folks who coined the word "open source" were concerned with creating businesses in the field of free software.

    Now, if you think altruism is such a great thing, do yourself a favor and go read some Ayn Rand.

    Oh and your blog accusing myself and Rod Johnson of "dishonesty" because we happen to prefer Java to Ruby is just absurd.
    Hi Gavin, I didn't say that I thought altruism was great, I just associate the idea with free software. Perhaps it's my age, but I was introduced to free software through the ideas and thoughts of Richard Stallman. So this is the mental picture I have. The OSI may define things differently of course. As for my blog being absurd. I'll leave that to others to judge :^) BTW. This response does nothing to address openness and transparency. These are fair questions to pose. Perhaps Bill will be less sensitive and provide some answers. Paul.
  60. Re: Seam 2.0 enters beta[ Go to top ]

    I was introduced to free software through the ideas and thoughts of Richard Stallman.
    I've never known RMS to use the word "altruism", or any synonym, in connection with Free Software. Perhaps you have a link? But anyway, the point is moot, it's clear that the open source software movement is now much, much bigger than RMS, and is inclusive of many different models and communities.
    This response does nothing to address openness and transparency.
    I'm sorry, but I have absolutely no idea what you want us to be more open about. Red Hat is a public company, and so its financials and strategy are matters of public record. Development of Seam, JBoss and all our other projects goes on in full view in public sourcecode repositories. Our forum and issue tracker, where most development-related discussions take place, are both completely open to all. If you don't understand our business model, you'll find plenty of information on google. Or taek a look at the Red Hat annual report. Perhaps you just havn't been paying attention?
  61. Re: Seam 2.0 enters beta[ Go to top ]

    Perhaps Bill will be less sensitive and provide some answers.
    ROFL. Somebody suggesting that I might be less sensitive?
    So I understand that if Jboss as a product has bugs, then a support agreement helps, but if Jboss as a tool is complicated and unwieldy, how does product support help here?
    Bad software is bad business. Its just that simple.
  62. Re: Seam 2.0 enters beta[ Go to top ]

    Perhaps Bill will be less sensitive and provide some answers.


    ROFL. Somebody suggesting that I might be less sensitive?

    So I understand that if Jboss as a product has bugs, then a support agreement helps, but if Jboss as a tool is complicated and unwieldy, how does product support help here?


    Bad software is bad business. Its just that simple.
    I suggest that this is the quote of the year!
  63. Re: Seam 2.0 enters beta[ Go to top ]

    Perhaps your are totally transparent, in which case please post a link to where your business policies are disclosed.
    I personally find your logic odd, but for the sake of my curiously can you please post a link to the policies of an open source company that holds up to your 'standards'?
  64. Re: Seam 2.0 enters beta[ Go to top ]

    Perhaps your are totally transparent, in which case please post a link to where your business policies are disclosed.


    I personally find your logic odd, but for the sake of my curiously can you please post a link to the policies of an open source company that holds up to your 'standards'?
    Ok, Firstly, I am admitting complete ignorance of the business model used at Jboss/RedHat Interface21 or any of these other so called "Open Source Software Businesses". But it seems quite clear to me that if you invite the developer community to commit their time and effort producing software for free, then you owe it to that said community to be totally transparent and perhaps even accountable in your business practices. An example of this is the Squeak Foundation: http://people.squeakfoundation.org/ Squeak is an open source Smalltalk implementation. As I understand it Squeak is controlled by a board of directors who are elected on a periodic basis by the Squeak community. I am not sure whether Squeak has a business arm, but if they do the Squeak Foundation provides a clear mechanism for accountability to the Squeak Community. Basically, it is the community that gets to decide. Another good example IMO is the person who started all this stuff with GNU: Richard Stallman. The free Software Foundation has a clear and transparent definition of what "free" means: http://en.wikipedia.org/wiki/Free_software_definition#The_definition For example, under this definition anyone should be able to branch the code as they see fit. So no one can own the code. Like I say I'm not an expert here, and I have no idea of the license under which JBoss works, but it seems unlikely that Red Hat would have paid all that money for something that they cannot own and control. Paul.
  65. Re: Seam 2.0 enters beta[ Go to top ]

    Another good example IMO is the person who started all this stuff with GNU: Richard Stallman. The free Software Foundation has a clear and transparent definition of what "free" means:

    http://en.wikipedia.org/wiki/Free_software_definition#The_definition

    For example, under this definition anyone should be able to branch the code as they see fit. So no one can own the code. Like I say I'm not an expert here, and I have no idea of the license under which JBoss works, but it seems unlikely that Red Hat would have paid all that money for something that they cannot own and control.


    Paul.
    I think I see where your confusion is. Seam is licensed under LGPL, a license of the Free software foundation. Here is the link: http://www.gnu.org/licenses/lgpl.html Almost everything RedHat does is released under LGPL or GPL. Redhat and Gavin have always been very supportive of the open source community, and IMO your comments have been a overly accusatory. (especially considering that you didn't even bother to lookup the license or business model that the software is offered under). All of this is also true for Spring and Rod.
  66. Re: Seam 2.0 enters beta[ Go to top ]

    Another good example IMO is the person who started all this stuff with GNU: Richard Stallman. The free Software Foundation has a clear and transparent definition of what "free" means:

    http://en.wikipedia.org/wiki/Free_software_definition#The_definition

    For example, under this definition anyone should be able to branch the code as they see fit. So no one can own the code. Like I say I'm not an expert here, and I have no idea of the license under which JBoss works, but it seems unlikely that Red Hat would have paid all that money for something that they cannot own and control.


    Paul.


    I think I see where your confusion is. Seam is licensed under LGPL, a license of the Free software foundation.

    Here is the link: http://www.gnu.org/licenses/lgpl.html

    Almost everything RedHat does is released under LGPL or GPL.

    Redhat and Gavin have always been very supportive of the open source community, and IMO your comments have been a overly accusatory. (especially considering that you didn't even bother to lookup the license or business model that the software is offered under).

    All of this is also true for Spring and Rod.
    We are all entitled to an opinion. BTW. I believe the JBoss license is a modified form of the LGPL and the Lesser GNU License is not the same as the GNU license. I believe the keyword word is lesser. Here is the Rails license: http://wiki.rubyonrails.org/rails/pages/License And here is the JBoss license: http://www.redhat.com/licenses/jboss_eula.html Read and decide for yourself. BTW, I'm not accusing, but I do have my suspicions. If these guys have nothing to hide, then they could have provided a straight answer here long ago. Paul.
  67. Re: Seam 2.0 enters beta[ Go to top ]

    We are all entitled to an opinion. BTW. I believe the JBoss license is a modified form of the LGPL and the Lesser GNU License is not the same as the GNU license. I believe the keyword word is lesser.

    Here is the Rails license:

    http://wiki.rubyonrails.org/rails/pages/License

    And here is the JBoss license:

    http://www.redhat.com/licenses/jboss_eula.html

    Read and decide for yourself.

    BTW, I'm not accusing, but I do have my suspicions. If these guys have nothing to hide, then they could have provided a straight answer here long ago.

    Paul.
    LGPL license is more similar to the MIT license then the GPL license is. I don't think pointing to the word lesser is meaningful to your point. I agree you are entitled to your opinion, and I respect that, but may I point out that your post is comparing the EULA of a large suite of products to one product. Was there something about the EULA from JBoss that you found confusing?
  68. Re: Seam 2.0 enters beta[ Go to top ]

    If these guys have nothing to hide, then they could have provided a straight answer here long ago.
    A straight answer to _what_ straight question?? So far you have raised no substantial point, merely smears and innuendo directed at people like Bill, Rod, myself who spend our whole lives developing open source software and supporting open source communities, while speaking as if you are Richard Stallman's only son, sent here to earth to purge us of our sins against Free Software. And you have exhibited your ignorance of JBoss, Red Hat, OSS licenses and OSS communities in general. If you're going to accuse people of dishonesty in blogs, and of having "something to hide" in community fourms, it beehoves you to be at the very least marginally informed about the topics at hand. FYI, the license under which Seam, JBoss, Hibernate, etc, are distributed is the LGPL. Not a "modified form" of the LGPL. The exact verbatim unadulterated LGPL as written by the hand of your hero Richard Stallman himself. This is a *less* restrictive license than the GPL, which much of Red Hat's other software is licensed under. We choose the LGPL for some projects, because it is more friendly to use by OEMs. Everyone else here knows this already. You're the only one who thinks there's something being hidden somewhere.
  69. Re: Seam 2.0 enters beta[ Go to top ]

    If these guys have nothing to hide, then they could have provided a straight answer here long ago.



    A straight answer to _what_ straight question??

    So far you have raised no substantial point, merely smears and innuendo directed at people like Bill, Rod, myself who spend our whole lives developing open source software and supporting open source communities, while speaking as if you are Richard Stallman's only son, sent here to earth to purge us of our sins against Free Software. And you have exhibited your ignorance of JBoss, Red Hat, OSS licenses and OSS communities in general. If you're going to accuse people of dishonesty in blogs, and of having "something to hide" in community fourms, it beehoves you to be at the very least marginally informed about the topics at hand.

    FYI, the license under which Seam, JBoss, Hibernate, etc, are distributed is the LGPL. Not a "modified form" of the LGPL. The exact verbatim unadulterated LGPL as written by the hand of your hero Richard Stallman himself. This is a *less* restrictive license than the GPL, which much of Red Hat's other software is licensed under. We choose the LGPL for some projects, because it is more friendly to use by OEMs.

    Everyone else here knows this already. You're the only one who thinks there's something being hidden somewhere.
    Hi Gavin, Your tone says a lot. Thanks. I still don't understand what exactly Red Hat bought. But like you say, I guess everyone else does, and it is only me that is confused. I am suspicious, and I did ask for clarification. Thanks for the information. I'm still "confused", but don't worry about that. All I would say is that I don't think that I am the only one :^). Good luck. Paul
  70. Re: Seam 2.0 enters beta[ Go to top ]

    Paul, Read this one and put your claws into them - http://www.theserverside.com/news/thread.tss?thread_id=46004 This project looks like it IS doing what you accuse JBoss and Spring of. Of course if you dig in and read the license ... .
  71. Re: Seam 2.0 enters beta[ Go to top ]

    Paul,
    Read this one and put your claws into them - http://www.theserverside.com/news/thread.tss?thread_id=46004
    This project looks like it IS doing what you accuse JBoss and Spring of. Of course if you dig in and read the license ... .
    Hi Mark, Thanks for the link. I wish these licenses where written in "plain english", as it stands you need to be a lawyer to fully understand the implications. The license definitely implies that IBM owns the code. The JBoss EULA I posted earlier is as long and confusing too, with Rad Hat stamped all over it. I am not accusing, simply because I don't know. What I was doing was presenting an opportunity for the JBoss guys to disclose their business model in a clear, open and concise way. As you and I both know, it is not always the best products and tools that succeed, often it is the best marketed tools. Free is a strong marketing slogan, hence everyone including IBM are jumping on the band wagon. So my simple point is who can you trust and who can't you? As it stands today I simply don't know. Paul.
  72. Re: Seam 2.0 enters beta[ Go to top ]

    As you and I both know, it is not always the best products and tools that succeed, often it is the best marketed tools.

    Free is a strong marketing slogan, hence everyone including IBM are jumping on the band wagon.

    So my simple point is who can you trust and who can't you?

    As it stands today I simply don't know.

    Paul.
    I wish I would have read your posts on other forums before I had responded to you. It would have been more obvious that you are not actually looking for clarification, but using vague questions as a means to support misinformed posts. * BTW I don't work for JBoss or RedHat.
  73. Re: Seam 2.0 enters beta[ Go to top ]

    If these guys have nothing to hide, then they could have provided a straight answer here long ago.



    A straight answer to _what_ straight question??

    So far you have raised no substantial point, merely smears and innuendo directed at people like Bill, Rod, myself who spend our whole lives developing open source software and supporting open source communities, while speaking as if you are Richard Stallman's only son, sent here to earth to purge us of our sins against Free Software. And you have exhibited your ignorance of JBoss, Red Hat, OSS licenses and OSS communities in general. If you're going to accuse people of dishonesty in blogs, and of having "something to hide" in community fourms, it beehoves you to be at the very least marginally informed about the topics at hand.

    FYI, the license under which Seam, JBoss, Hibernate, etc, are distributed is the LGPL. Not a "modified form" of the LGPL. The exact verbatim unadulterated LGPL as written by the hand of your hero Richard Stallman himself. This is a *less* restrictive license than the GPL, which much of Red Hat's other software is licensed under. We choose the LGPL for some projects, because it is more friendly to use by OEMs.

    Everyone else here knows this already. You're the only one who thinks there's something being hidden somewhere.


    Hi Gavin,

    Your tone says a lot. Thanks. I still don't understand what exactly Red Hat bought. But like you say, I guess everyone else does, and it is only me that is confused.

    I am suspicious, and I did ask for clarification. Thanks for the information. I'm still "confused", but don't worry about that. All I would say is that I don't think that I am the only one :^).

    Good luck.

    Paul
    Paul, you are the only one. Even Pirates understand LGPL, GPL and Richard Stallman's vision.
  74. Re: Seam 2.0 enters beta[ Go to top ]

    Perhaps your are totally transparent, in which case please post a link to where your business policies are disclosed.


    I personally find your logic odd, but for the sake of my curiously can you please post a link to the policies of an open source company that holds up to your 'standards'?


    Ok,

    Firstly, I am admitting complete ignorance of the business model used at Jboss/RedHat Interface21 or any of these other so called "Open Source Software Businesses". But it seems quite clear to me that if you invite the developer community to commit their time and effort producing software for free, then you owe it to that said community to be totally transparent and perhaps even accountable in your business practices.

    An example of this is the Squeak Foundation:

    http://people.squeakfoundation.org/

    Squeak is an open source Smalltalk implementation. As I understand it Squeak is controlled by a board of directors who are elected on a periodic basis by the Squeak community. I am not sure whether Squeak has a business arm, but if they do the Squeak Foundation provides a clear mechanism for accountability to the Squeak Community. Basically, it is the community that gets to decide.

    Another good example IMO is the person who started all this stuff with GNU: Richard Stallman. The free Software Foundation has a clear and transparent definition of what "free" means:

    http://en.wikipedia.org/wiki/Free_software_definition#The_definition

    For example, under this definition anyone should be able to branch the code as they see fit. So no one can own the code. Like I say I'm not an expert here, and I have no idea of the license under which JBoss works, but it seems unlikely that Red Hat would have paid all that money for something that they cannot own and control.


    Paul.
    So what the point, you can't provide good OS software and make out money of it? I think the model is pretty clear : offering support in case something goes wrong (in a lot of cases, the troubles not even come from the product but from the environment so I don't see any conflict here), provide guidance on how to use the product (the best documentation in the world is not sufficient for some companies) and personalize the product if its needed. If the product wasn't good, people would stop using and there would be no market at all so I don't see why you are being suspicious.
  75. "Bloated" not really but...[ Go to top ]

    Henri Karapuu wrote As of now, Seam includes things such as formatting text based on *funny* _characters_, while lacking proper reference documentation of many core features, or deployment issues on different application servers.
    I strongly agree with Henri (thanks for his thread) but at the same time I can't agree that SEAM 2.0 is fully bloated (eventhough forcing towards that stage). So please concentrate on making the framework aware among enterprise community (ofcourse decision makers) and then slowly take the right track to add features.
  76. Hi Guys, Has anybody deployed and run successfully the sample on Glassfish. In the examples directory I built the jee5 by executing 'glassfish-toplink' target and deployed it on glassfish v2 b53. It deploys fine, but when I try accessing the http://localhost:8080/seam-jee5/, I get the following message in firefox : The page isn't redirecting properly Firefox has detected that the server is redirecting the request for this address in a way that will never complete. * This problem can sometimes be caused by disabling or refusing to accept cookies. I may mention that cookies are enabled in my firefox. Did somebody else also have the same experience?
  77. Thank you for Seam![ Go to top ]

    Congratulations on becoming beta, but I cannot wait till this beast makes it to the final release. ;) Seam is such a great piece of software. From what I have seen so far, I dont think it is bloated at all. Spring is more documented? more proven? Well, Spring is much older, it had much more time to be prove itself. ;) But the best news out of this for me is the fact, that Seam developers and Guice developers work hand in hand together. Guice is one of the most innovative and best things that happened to Java (well lets say to Java 5 and above) in the near past. I would love to have Guice in the JDK and the core parts of Seam in the JEE standard. That way it would be easy to adopt the core features of Seam to other environments while at the same time leaving enough space for innovation for vendors. My favourite App-Framework + my favourite DI framework = me happy! ;) Question for Gavin: How is the progress on Red Hat Developer Studio and especially Seam Support? RHDS is the only thing that could make me switch back to Eclipse ;) I am planning to port a half-finished-appfuse-generated application to Seam at the end of this year (maybe starting october). Will I be able to do this with RHDS? ;)
  78. Re: Thank you for Seam![ Go to top ]

    My favourite App-Framework + my favourite DI framework = me happy! ;)
    :-)
    Question for Gavin: How is the progress on Red Hat Developer Studio and especially Seam Support? RHDS is the only thing that could make me switch back to Eclipse ;)

    I am planning to port a half-finished-appfuse-generated application to Seam at the end of this year (maybe starting october). Will I be able to do this with RHDS? ;)
    Yeah, the first big release is planned for August. A lot of feverish work is being done on it :-)
  79. RHDS[ Go to top ]

    Yeah, the first big release is planned for August. A lot of >feverish work is being done on it :-)
    Yeehaa! Looking forward to it.
  80. Has anybody deployed and run successfully the sample on Glassfish.
    Sorry about that, Vimal, there was a bug in the ejb-jar.xml that shipped with that example in the beta release. There are instructions in the forum for fixing that, and it was fixed in CVS days ago.
  81. Hi Paul, I'm quite surprised to see you endorsing RoR while being such a big proponent of "pure OO". Is it because it is the only credible Ruby framework out there or what? Personally, I really don't consider Ruby has a good OO framework. Sure it's get the job done pretty fast and can be a great tool in a simple CRUD application but please don't tell me that an RoR application is more Object Oriented than one built using Seam. It just doesn't cut it. RoR is based upon the active record pattern and therefore discourages the use of a real domain model. Sure RoR use those great Ruby OO meta facilities à la Smalltalk but I always thought that the real power of OO was in the expressiveness and robustness of a domain model, not in the dark insides of a framework. Well from what I know RoR active record forces you to spread your business logic in some kind of artificial objects (even when you are totally in control of the database schema, your objects still have to obey to a lot more constraints than if you were using a framework as Hibernate), encouraging you in the process to not think in terms of objects but in terms of data and procedures which is clearly not in the spirit of OO. Anyways, I'm also quite surprised to see a fan of agile methods as you disrespecting Java as a good language based only on theoretical arguments. I mean I thought the point of agile methods was to base our judgement on a evolutionary path instead of trying to theorize everything, to experiment and see what's work and what's not. Well if you are pragmatic, you have to admit Java is simply dominating now. I suppose you'll say it has won over Ruby simply because of economical and political reasons here but I have to disagree. A programming language wouldn't be able to win without having some really great qualities. If the language was a bad as you say compare to Ruby, some companies would be able to grab the market and show how better is Ruby at getting the job done. The fact is that it hasn't been demonstrated yet and therefore I have no reason whatsoever to think that Ruby is just better than Java. I guess it's depends of the criterias on which you choose to evaluate a programming a language. To me Java is simply a good balance between expressiveness and powerfulness while Ruby sacrifices all this expressiveness to powerfulness. Of course, if you think expressiveness and readability are not worth it than I guess you can consider Java as a bad language even though I think it's kind of bad to only think in term of powerfulness. Well back to the subject, congratulations to the Seam's team, one of the most innovating project out there.
  82. Re: Seam 2.0 enters beta[ Go to top ]

    Hi Paul,

    I'm quite surprised to see you endorsing RoR while being such a big proponent of "pure OO". Is it because it is the only credible Ruby framework out there or what? Personally, I really don't consider Ruby has a good OO framework. Sure it's get the job done pretty fast and can be a great tool in a simple CRUD application but please don't tell me that an RoR application is more Object Oriented than one built using Seam. It just doesn't cut it.

    RoR is based upon the active record pattern and therefore discourages the use of a real domain model. Sure RoR use those great Ruby OO meta facilities à la Smalltalk but I always thought that the real power of OO was in the expressiveness and robustness of a domain model, not in the dark insides of a framework. Well from what I know RoR active record forces you to spread your business logic in some kind of artificial objects (even when you are totally in control of the database schema, your objects still have to obey to a lot more constraints than if you were using a framework as Hibernate), encouraging you in the process to not think in terms of objects but in terms of data and procedures which is clearly not in the spirit of OO.

    Anyways, I'm also quite surprised to see a fan of agile methods as you disrespecting Java as a good language based only on theoretical arguments. I mean I thought the point of agile methods was to base our judgement on a evolutionary path instead of trying to theorize everything, to experiment and see what's work and what's not. Well if you are pragmatic, you have to admit Java is simply dominating now. I suppose you'll say it has won over Ruby simply because of economical and political reasons here but I have to disagree. A programming language wouldn't be able to win without having some really great qualities. If the language was a bad as you say compare to Ruby, some companies would be able to grab the market and show how better is Ruby at getting the job done. The fact is that it hasn't been demonstrated yet and therefore I have no reason whatsoever to think that Ruby is just better than Java. I guess it's depends of the criterias on which you choose to evaluate a programming a language.

    To me Java is simply a good balance between expressiveness and powerfulness while Ruby sacrifices all this expressiveness to powerfulness. Of course, if you think expressiveness and readability are not worth it than I guess you can consider Java as a bad language even though I think it's kind of bad to only think in term of powerfulness.

    Well back to the subject, congratulations to the Seam's team, one of the most innovating project out there.
    Hi Alexandre, Firstly, I'm not "dissing" Java or Championing Ruby. What I am saying is that Java has limitations when it comes to Object Orientation. Now the points raised by Gilad are not theoretical believe me. Now there are good reasons to use Java, but not to acknowledge these limitations in an open and honest way, especially when your framework is designed to overcome language limitations, is being economic with the truth IMO. What is in question is trust and leadership. If we choose to adopt open source businesses as our community leaders, then we need to feel that they are open honest and transparent and are representing us not just themselves. With a closed source business like Oracle or Sun, their motives and the business imperative is pretty clear. With these new businesses their motives are unclear to me. Compare this with the Python community and the Ruby community and you see what I mean. For example as I understand it 37Signals does not profit directly from Rails at all, whether that be through consulting, subscriptions or support. They merely supply it to the community as is. If you want to use it then do so, if you want to fork it then go ahead. What they do to make money is build application software like the rest of us. They just so happened to have an in-house framework, that they choose to give away to the community for free. You can choose to use it, fork it or whatever. This to me seem significantly different to the business model of JBoss or Interface21. Hopefully Bill or Gavin, will get back and clear things up. Perhaps it's just my cynical nature at play, but it would be nice to get a clear answer.
  83. Re: Seam 2.0 enters beta[ Go to top ]



    Compare this with the Python community and the Ruby community and you see what I mean.

    For example as I understand it 37Signals does not profit directly from Rails at all, whether that be through consulting, subscriptions or support. They merely supply it to the community as is. If you want to use it then do so, if you want to fork it then go ahead.

    What they do to make money is build application software like the rest of us. They just so happened to have an in-house framework, that they choose to give away to the community for free. You can choose to use it, fork it or whatever.

    This to me seem significantly different to the business model of JBoss or Interface21.

    Hopefully Bill or Gavin, will get back and clear things up. Perhaps it's just my cynical nature at play, but it would be nice to get a clear answer.
    How is this different from Interface21? First, people like myself were asking form the code that became Spring based on one of Rod's books. Second, AFAIK, Spring preceeded Interface 21. Third, they charge nothing for the software, the forum, or the documentation. JBoss, for example, has always charged for the JBoss docs and it was a bear to use JBoss without the docs. If some Redhat or Interface21 makes money consulting for software that they give way and doesn't really need consulting, what exactly is the issue? What exactly has any of this even relevent? No one is forcing anyone to use this software? Regardless, am cynical when someone describes any group of individuals as altruistic and similar group as profiteering.
  84. Re: Seam 2.0 enters beta[ Go to top ]



    Compare this with the Python community and the Ruby community and you see what I mean.

    For example as I understand it 37Signals does not profit directly from Rails at all, whether that be through consulting, subscriptions or support. They merely supply it to the community as is. If you want to use it then do so, if you want to fork it then go ahead.

    What they do to make money is build application software like the rest of us. They just so happened to have an in-house framework, that they choose to give away to the community for free. You can choose to use it, fork it or whatever.

    This to me seem significantly different to the business model of JBoss or Interface21.

    Hopefully Bill or Gavin, will get back and clear things up. Perhaps it's just my cynical nature at play, but it would be nice to get a clear answer.



    How is this different from Interface21? First, people like myself were asking form the code that became Spring based on one of Rod's books. Second, AFAIK, Spring preceeded Interface 21. Third, they charge nothing for the software, the forum, or the documentation. JBoss, for example, has always charged for the JBoss docs and it was a bear to use JBoss without the docs.

    If some Redhat or Interface21 makes money consulting for software that they give way and doesn't really need consulting, what exactly is the issue? What exactly has any of this even relevent? No one is forcing anyone to use this software?

    Regardless, am cynical when someone describes any group of individuals as altruistic and similar group as profiteering.


    Compare this with the Python community and the Ruby community and you see what I mean.

    For example as I understand it 37Signals does not profit directly from Rails at all, whether that be through consulting, subscriptions or support. They merely supply it to the community as is. If you want to use it then do so, if you want to fork it then go ahead.

    What they do to make money is build application software like the rest of us. They just so happened to have an in-house framework, that they choose to give away to the community for free. You can choose to use it, fork it or whatever.

    This to me seem significantly different to the business model of JBoss or Interface21.

    Hopefully Bill or Gavin, will get back and clear things up. Perhaps it's just my cynical nature at play, but it would be nice to get a clear answer.



    How is this different from Interface21? First, people like myself were asking form the code that became Spring based on one of Rod's books. Second, AFAIK, Spring preceeded Interface 21. Third, they charge nothing for the software, the forum, or the documentation. JBoss, for example, has always charged for the JBoss docs and it was a bear to use JBoss without the docs.

    If some Redhat or Interface21 makes money consulting for software that they give way and doesn't really need consulting, what exactly is the issue? What exactly has any of this even relevent? No one is forcing anyone to use this software?

    Regardless, am cynical when someone describes any group of individuals as altruistic and similar group as profiteering.
    Hi David, If a company makes it's money out of product consulting, then I am suspicious that the companies products are likely to be over complex. Why? Well if that company has managed to establish a strong brand and has a strong marketing arm - it will sell product. You have got to remember the types of people who make buying decisions. They will stick with the branded products because it feels less risky. That’s why they tend to buy IBM, Microsoft, Oracle, etc. (have you ever used Oracle software products?) Secondly, if you sell a complex product, once the dev team begins to struggle with it you can go back and sell product consulting. I have watched both Oracle and BEA do this over many years. I've been told that IBM does exactly the same thing. So the issue is what motivates the product design. Is it coming up with a product that is an easy sell to company executive types? You know a product with all the right badges like J2EE5 compliant? Or is it coming up with a product that provides ample product consulting opportunities? Or is the motive to solve my problem the simplest way I can as a programmer and then to share that solution with the programming community? These are important questions. I will say one last time, I am not accusing. What I am doing is questioning. I am also arguing for transparency. These guys can adopt whatever business model they like. It would be nice just to know what it is exactly. That way I get to make an informed choice. Paul.
  85. Re: Seam 2.0 enters beta[ Go to top ]

    Secondly, if you sell a complex product, once the dev team begins to struggle with it you can go back and sell product consulting. I have watched both Oracle and BEA do this over many years. I've been told that IBM does exactly the same thing.
    I used to believe in conspiracy theories. Unfortunately life is not so exciting as a "24" episode where Jack Bauer comes to save the day.
    So the issue is what motivates the product design. Is it coming up with a product that is an easy sell to company executive types? You know a product with all the right badges like J2EE5 compliant? Or is it coming up with a product that provides ample product consulting opportunities? Or is the motive to solve my problem the simplest way I can as a programmer and then to share that solution with the programming community?
    I think you should go read Red Hat financials and see what percentage of revenue comes from subscriptions and what comes from consulting. I think once you do this you'll see that we are a software company and not a consulting company. Bill
  86. Re: Seam 2.0 enters beta[ Go to top ]

    I think you should go read Red Hat financials and see what percentage of revenue comes from subscriptions and what comes from consulting. I think once you do this you'll see that we are a software company and not a consulting company.

    Bill
    Hi Bill, Thanks, I will. A page on your website disclosing what you do, and why you do it would be great too. You know something spelling out your motives and philosophy. This is my last post on this subject. I really do not understand why my questioning was perceived as an attack. I see some passion in your last response that implies that you are strongly motivated and that your motives are altruistic to some degree. If you want people to trust you, just be open :^) Paul.
  87. Re: Seam 2.0 enters beta[ Go to top ]

    I think you should go read Red Hat financials and see what percentage of revenue comes from subscriptions and what comes from consulting. I think once you do this you'll see that we are a software company and not a consulting company.

    Bill


    Hi Bill,

    Thanks, I will. A page on your website disclosing what you do, and why you do it would be great too. You know something spelling out your motives and philosophy.

    This is my last post on this subject. I really do not understand why my questioning was perceived as an attack. I see some passion in your last response that implies that you are strongly motivated and that your motives are altruistic to some degree.

    If you want people to trust you, just be open :^)

    Paul.
    Hi Bill, I read the JBoss front page and clicked across to the commecial site. The description and explanations there are clear, and I now have a better understanding of how you guys work. Perhaps I should have done this at the beginning. The business model is clear to me now and it all seems straight forward, sorry for implying otherwise. Regards, Paul.
  88. Re: Seam 2.0 enters beta[ Go to top ]

    How is this different from Interface21? First, people like myself were asking form the code that became Spring based on one of Rod's books. Second, AFAIK, Spring preceeded Interface 21. Third, they charge nothing for the software, the forum, or the documentation. JBoss, for example, has always charged for the JBoss docs and it was a bear to use JBoss without the docs.
    Huh??? Now here's where I get sensitive... * All JBoss documentation for all projects has been free since 2003/2004 (i forget when) * JBoss never ever charged for the software or forum or mail-list. * When we sold docs, we were <= 10 people. The sales of the docs were plowed back into the project. It funded the salary of Scott Stark and subsidized the salaries of myself, Sacha, and Dain Sundstrom ( I think Hiram too, I don't remember, Hiram?). Selling docs basically allowed us to bootstrap our business until we reached critical mass on support/consulting/training. Selling docs at $30 a pop is a small price to pay for getting key individuals off the corporate tit and onto fulltime open source development. As we grew we were able to make docs free and actually hire full time tech writers to improve and maintain the documentation. Growing the business allowed to us to fund projects like Hibernate, Tomcat, JGroups, jBPM, and Drools. Growing the business allowed us to bring mature, closed-source projects like Arjuna's Transaction Manager into open source. Bill
  89. Re: Seam 2.0 enters beta[ Go to top ]

    How is this different from Interface21? First, people like myself were asking form the code that became Spring based on one of Rod's books. Second, AFAIK, Spring preceeded Interface 21. Third, they charge nothing for the software, the forum, or the documentation. JBoss, for example, has always charged for the JBoss docs and it was a bear to use JBoss without the docs.


    Huh??? Now here's where I get sensitive...

    * All JBoss documentation for all projects has been free since 2003/2004 (i forget when)
    * JBoss never ever charged for the software or forum or mail-list.
    * When we sold docs, we were <= 10 people. The sales of the docs were plowed back into the project. It funded the salary of Scott Stark and subsidized the salaries of myself, Sacha, and Dain Sundstrom ( I think Hiram too, I don't remember, Hiram?). Selling docs basically allowed us to bootstrap our business until we reached critical mass on support/consulting/training. <br>
    Selling docs at $30 a pop is a small price to pay for getting key individuals off the corporate tit and onto fulltime open source development. As we grew we were able to make docs free and actually hire full time tech writers to improve and maintain the documentation. Growing the business allowed to us to fund projects like Hibernate, Tomcat, JGroups, jBPM, and Drools. Growing the business allowed us to bring mature, closed-source projects like Arjuna's Transaction Manager into open source.

    Bill
    I don't care if you sell the docs or not. Make a buck, nothing wrong with that, but you did charge and JBoss was tough to use without the documentation. I would submit that Spring needed documentation also, but they didn't charge. Simply as that. I buy software and buy books. The GWT in Action book, for example, has been invaluble to me. $40 bucks saves many hours and pays for itself almost immediately. Heck, JFreeChart also charges...nothing wrong with that. So don't be sensitive, I was just pointing out to...uh...dude that JBoss has one difference, as I see it.
  90. Re: Seam 2.0 enters beta[ Go to top ]

    A programming language wouldn't be able to win without having some really great qualities. If the language was a bad as you say compare to Ruby, some companies would be able to grab the market and show how better is Ruby at getting the job done. The fact is that it hasn't been demonstrated yet and therefore I have no reason whatsoever to think that Ruby is just better than Java. I guess it's depends of the criterias on which you choose to evaluate a programming a language.
    I haven't used Ruby for anything intensive, and I'm rather glad that I didn't. http://blog.cbcg.net/articles/2007/04/22/python-up-ruby-down-if-that-runtime-dont-work-then-its-bound-to-drizzown I've heard similar stories from others. The Ruby runtime (not JRuby) just isn't that stable, at least for intensive load on long running processes. I imagine you can work around that by regularly restarting processes, but that's a hack. The problem is you have to match a tool with it's purpose. Someone doing data analysis has different needs that someone doing real-time trading applications has different needs from someone building quick-turn webapps. But many people advocate a solution that works well for them in one situation without ever qualifying that situation.
  91. congrats[ Go to top ]

    Congrats with the beta release. In september we will release our first SEAM-application. We started our project in Spring-Hibernate-JSF but because of some programming-problems, and on advice by a wellknown Belgian Java-specialist consultant (Gavin will know who I mean) we evaluated and moved to SEAM. As I speak we don't have/had any blocking problem in our development work. Keep up the good work
  92. i have been investing in SEAM, so i'm glad to see that the project moves ahead fast. SEAM is a great peice of work. but as there is always room for improvent, below my main wishes: - guidelines / support on how to organize a more complex project into modules and manage the dependencies. (maven?) [ entity beans in one jar, a module with actions, a corresponding war, shared code, etc ] - improved debugging and error messages
  93. Impressive pieace of work[ Go to top ]

    I got to say I'm really impressed by the amount of functionalities in lastest Seam. It packs very much all the arsenals you need to develop a good web application quick and easy. Less java code - annotations take care of most thing I hate about EJB -, stateful support - a great relief for anyone doing web app -, persistence/security built-in - appfuse quick start application -, generation of complete front-to-back from DB tables (though I want another option :) I haven't used JBoss for a while since the early day, but Seam pull this great feat. Congrats, Gavin and the team! You should take a look at it or give it a try. Of course, like most new open-source project, documentation is a little lacking. Couple things I want to see in the documentation like: - How to use customized Hibernate mapping files. - Comprehensive annotations (all possible Seam & Hibernate or whatever else you can use there). Finally, my dearest request to have "Seam generate-entities" to work with Hibernate mapping files instead of db tables (since it's hard to pull the right relationship).