JBossDeveloper

and how bout some pics/figures in the docs like SiA has??

Have to be careful not to make it perfect!

RH make money out of support.

People write books on Seam and make a living.

So... i.m.h.o. it can't be too comprehensive; it has to be, what it is, a good reference!

Book like Advanced Seam/Seam in Action/etc. are for those who want to know more!

A book like Seam for Dummies would follow a blueprint approach (i.e. ONLY discuss say one way of doing a seam project - e.g. go with (and only discuss) Seam Managed Transactions, EJB3, jBPM etc.) and even have a skeleton to start with.

Shoutout to Arbi for taking the time to answer so thoroughly with quotes from the SiA also. Although I understand that the Seam guys are very buys with Seam 3 and WebBeans, still JBoss should dedicate people X amount of percent to the forums like the RichFaces team does.

Seam is so huge, and even though I have over 2,5 years of daily seam usage experience, I still cannot answer all questions because I have only used Seam/JSF with JBoss AS, thus so many tomcat, glassfish, wicket, rest etc are just beyond my grip.

I am looking very much forward to Seam 3, and I also think for our project it will be nearly impossible to migrate to JSF 2 and Seam 3.

Plus one for Arbi,

I also reiterate my comment about forum trolls.

Jboss hire a couple, they shadow a seamster to gain a working relationship and some deeper knowledge. They then get let loose doing support with a safety net of their mentor.

Ultimately they could contribute even more to seam stack.

Value vs Cost

A couple of good people want to earn what? €75.000 a year including taxes? That will cost an employer around €100.000 a year for 1 person or €200.000 in total.

Who is going to pay that?

What I think should happen is that seam users (users of any foss framework for that matter) should try less to implement all kinds of workarounds because they are afraid to make changes to seam. And if this workaround does not work anymore in a next version they make a new workaround. Instead they should learn a (little) more of the seam internals and provide fixes/enhancements/.... or even examples. Why is everybody so afraid of that? The wiki is open, the documentation is open (in svn) source etc...

Ronald van Kuijk wrote on Aug 27, 2009 01:42:


A couple of good people want to earn what? €75.000 a year including taxes? That will cost an employer around €100.000 a year for 1 person or €200.000 in total.

Who is going to pay that?

What I think should happen is that seam users (users of any foss framework for that matter) should try less to implement all kinds of workarounds because they are afraid to make changes to seam. And if this workaround does not work anymore in a next version they make a new workaround. Instead they should learn a (little) more of the seam internals and provide fixes/enhancements/.... or even examples. Why is everybody so afraid of that? The wiki is open, the documentation is open (in svn) source etc...

They're not interested in spending massive amounts of time and effort to learn things that seem to be so easy to do in alternative platforms like RoR and .NET.

Plus, a lot of this Seam stuff is borderline rocket science IMO...  It's an intimidating and large amount of information to learn and use, this entire JBoss dev stack if you really think about it.  JBoss even has AOP but who/what uses it?

http://www.redhat.com/about/news/prarchive/2008/thirdquarter.html

is not seam part of redhat stack?

Ronald van Kuijk wrote on Aug 27, 2009 01:42:


A couple of good people want to earn what? €75.000 a year including taxes? That will cost an employer around €100.000 a year for 1 person or €200.000 in total.

Who is going to pay that?

What I think should happen is that seam users (users of any foss framework for that matter) should try less to implement all kinds of workarounds because they are afraid to make changes to seam. And if this workaround does not work anymore in a next version they make a new workaround. Instead they should learn a (little) more of the seam internals and provide fixes/enhancements/.... or even examples. Why is everybody so afraid of that? The wiki is open, the documentation is open (in svn) source etc...

Patching Seam code sounds all fine and in a perfect world it would work well. But employers are already paying us $xx/hr to do what they want us to do. So, the time spent analysing what impact our patch to the Seam source base would have is that supposed to be paid by our employers who really arn't interested in Seam itself? I would imagine that there are probly only 1 or 2 percent of people using Seam that are confident enough to make changes at the core level. Others may do it but probably wouldn't be able to tell you if their change will affect anything else. I've spent a lot of time in the Seam core code and I think I have a fairly good understanding of how it works in my environment but, I would be very skeptical about my abilities to implement a patch that would not break someone else's environment.

Community is great but at the end of the day if you want a large market share for your product there has to be ownership and direction.

Ronald van Kuijk wrote on Aug 27, 2009 01:42:


Why is everybody so afraid of that? The wiki is open, the documentation is open (in svn) source etc...

Yes, everything is open, but since subversion is not distributed, you can not really keep control of your changes and merge them with Seam as new versions are released, maybe if they switched to Mercurial... (at least I would then dare to make changes and share them)

Francisco Peredo wrote on Aug 27, 2009 05:22:

Ronald van Kuijk wrote on Aug 27, 2009 01:42:


Why is everybody so afraid of that? The wiki is open, the documentation is open (in svn) source etc...

Yes, everything is open, but since subversion is not distributed, you can not really keep control of your changes and merge them with Seam as new versions are released, maybe if they switched to Mercurial... (at least I would then dare to make changes and share them)

The approach would be to submit a patch in a JIRA I suppose...

Tim Evers wrote on Aug 27, 2009 02:44:


I've spent a lot of time in the Seam core code and I think I have a fairly good understanding of how it works in my environment but, I would be very skeptical about my abilities to implement a patch that would not break someone else's environment.

Community is great but at the end of the day if you want a large market share for your product there has to be ownership and direction.

Another problem is that Seam 2 is not really designed with the idea of a core and modules so for, example, Tim can not easily share his enhanced navigation code (and there is no way I could implement my nested temp conversations) without having to recompile seam code. I hope that Seam 3 follows the Open Closed Principle better. Yes, having the code is great, to understand it, and to fix bugs but, real flexibility comes when the behavior can modified without altering the source, for example I can create any number of eclipse plugins without worrying about recompiling eclipse itself (and I guess that is one of the reasons Spring is so popular, because they have tried to make its code follow modularity and the Open Closed Principle as much as they can).

Arbi Sookazian wrote on Aug 27, 2009 05:31:

Francisco Peredo wrote on Aug 27, 2009 05:22:


Yes, everything is open, but since subversion is not distributed, you can not really keep control of your changes and merge them with Seam as new versions are released, maybe if they switched to Mercurial... (at least I would then dare to make changes and share them)

The approach would be to submit a patch in a JIRA I suppose...

Mmm, let see:

1. I download Seam 2.2.


2. I see a problem in Seam code base, or I implement a new feature I need, I modify 10 files and submit the patch that is Seam2.2FrancPatch1


3. I see another problem in Seam code base, or I implement a new feature I need, I modify 10 files and submit another patch... but... is it a patch from Seam 2.2... no...it is a patch after Seam2.2FrancPatch1 has been applied...


4. Another change, another patch...


5. I realize that I made a mistake with the first one so I.... download Seam 2.2 again and re-patch it?


6. Seam 2.3 is released... what do I do now with this mess!


7. Now multiply this for the 1 o 2 other people where I work that could do the same: Welcome to patch hell!

A distributed version system like Mercurial or a more strict adherence to the OpenClosed principle is must if you want a thriving community that contributes back in to Seam.

Francisco Peredo wrote on Aug 27, 2009 05:48:

Arbi Sookazian wrote on Aug 27, 2009 05:31:

Francisco Peredo wrote on Aug 27, 2009 05:22:


Yes, everything is open, but since subversion is not distributed, you can not really keep control of your changes and merge them with Seam as new versions are released, maybe if they switched to Mercurial... (at least I would then dare to make changes and share them)

The approach would be to submit a patch in a JIRA I suppose...

Mmm, let see:

1. I download Seam 2.2.


2. I see a problem in Seam code base, or I implement a new feature I need, I modify 10 files and submit the patch that is Seam2.2FrancPatch1


3. I see another problem in Seam code base, or I implement a new feature I need, I modify 10 files and submit another patch... but... is it a patch from Seam 2.2... no...it is a patch after Seam2.2FrancPatch1 has been applied...


4. Another change, another patch...


5. I realize that I made a mistake with the first one so I.... download Seam 2.2 again and re-patch it?


6. Seam 2.3 is released... what do I do now with this mess!


7. Now multiply this for the 1 o 2 other people where I work that could do the same: Welcome to patch hell!

A distributed version system like Mercurial or a more strict adherence to the OpenClosed principle is must if you want a thriving community that contributes back in to Seam.

Very good counter-argument.  Isn't JBoss AS 5 partially OSGi-based?  Spring has their new dm server which is fully OSGi-based. 

SpringSource dm Server™ is an open source, completely modular, OSGi-based Java server designed to run enterprise Java applications and Spring-powered applications with a new degree of flexibility and reliability. The SpringSource dm Server is based on the new SpringSource Dynamic Module Kernel™ (dm Kernel). The dm Kernel provides a module-based backbone for the server, which also harnesses the power of Spring, Apache Tomcat and OSGi-based technologies.

The cool thing about Spring is you can pick and choose which libraries you need for your particular project, unlike Seam which has the bloated jboss-seam.jar for core API (although I believe Seam core dev team is modularizing that now for Seam 3).

Modularize the Seam framework, dividing it into distinct units that have a well-defined dependency graph

http://seamframework.org/Documentation/Seam3BuildSystem

We've gone for a totally modular approach for Seam 3, in fact there is no Seam 'core' any more, although some modules may optionally depend on functionality from other modules.

http://seamframework.org/Community/ModularizingSeamALaSpring

IMHO, the Seam core dev team needs to release more videos, webinars, etc. about upcoming design and features in Seam 3.  That really seems to be missing.  Microsoft is really good about this (they even have videos embedded in their IDE which are very helpful to start projects with).  Here's a great MS link: http://msdn.microsoft.com/en-us/asp.net/aa336576.aspx

The benefits of the OSGi platform include:

_Modularization and versioning_. The OSGi platform allows you to keep and enforce the modular
structure of your applications. In addition to this, the OSGi platform supports versioning of the
modules.

_Manageability_. The OSGi platform includes module management tools that allow you to install,
uninstall, start and stop bundles without writing a line of code.

_Non-intrusiveness_. The OSGi platform does not force you to write your application’s classes and
interfaces in any special way. There is no special contract that your bundles must use to be
able to export or import a service.

_Laziness_. The applications that use the OSGi platform can take advantage of lazy initialization
of the required bundles and services. The platform can delay loading and initialization of a
bundle (and all bundles it depends on) until it is needed.

http://manning.com/machacek/Machacek_MEAP_01.pdf