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

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?

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.

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.)

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.

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.

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.

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.

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

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.

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

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

cool :)

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 :)

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!

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.

..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

..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.

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?

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.

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.

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.

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.

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.

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?

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.

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!

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'?

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.

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.

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.

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?

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.

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,
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 ... .

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.

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.

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.

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.

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.

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?

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? ;)

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 :-)

Yeehaa!

Looking forward to it.

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.

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 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.

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.

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.

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

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.

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.

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

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.

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.

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

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

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).