Help

28 Sept 2011: Update

We'd like to thank everyone for their comments - on twitter, on IRC and in the comments section. There have been some excellent concerns raised, and, believe it or not, those same reasons are at the heart of why we want to make the changes we discussed here. We have exactly the same concerns the community has raised.

We would like to reassure everyone on a few points:

  • We are convinced that one of things that drove people to adopt Seam 1 and Seam 2 was strong focus on how to build real applications. We are well aware that Seam 3 hasn't offered that and we want to focus on providing that
  • We still believe in portability and standards, and we want to take the knowledge we have about building portable standards and applications out of the Seam silo, and to the rest of the Java EE ecosystem. We will continue to standardise APIs and ideas that we believe are necessary
  • That we love the Seam community and their passion and that we want bring this community into the heart of the Java EE community, where it belongs
  • We will ensure that apps built using Seam 3.x will continue to run. We will continue to support anyone who wants to build a CDI extension

However we made a mistake. We told you about the outcome we think is the right way to address this. We didn't tell you why we want to do it, or how it supports these goals. We don't want to jump right in with a half-baked position right now, and make that mistake again. So we ask that you give us the benefit of the doubt, and trust that we do have the community's best interests at heart, and watch this space for the whole picture over the next couple of days.


I'd like to take a few moments to update everyone on what is happening within the Seam project, and to clear up a few rumours that have started to float around before they start to balloon out of control (how do these things start up anyway???). As some of you might know, we recently held a JBoss face to face meeting in Toronto, Canada where besides consuming vast amounts of alcohol and staying up into the wee hours of the night coding and talking about important stuff like politics and humorous YouTube videos, we actually made a number of important decisions about the direction and focus of the Seam project as a whole.

Over the years, Seam has evolved by quite a substantial amount - if you were to ask the core team members for an executive summary of what Seam was, then the answer would have changed every year. In the very beginning, Seam was intended to solve some of the shortcomings of developing applications with JSF and EJB (and unfortunately this is the impression that has stuck with many people, even until now). It quickly grew into a powerful DI component framework, and more and more features have been added over time. It has spawned quite a number of innovations and sister projects - CDI, Weld and Arquillian to name a few. I'm also pleased to say that Seam is successfully powering many, many production web sites and rich internet applications today.

So, that brings us to the present. In the latter part of 2011, what is Seam's focus, and what goals does it set out to achieve? Well, let's start by looking at the goals it has already achieved. The core features of Seam - dependency injection, contextual component model, event bus, interceptors, i.e. the frameworky stuff has all been standardised as JSR-299 (CDI). Since this is now all part of the Java EE specification, and comes as standard in any compliant Java EE6 container, we now have a fantastic foundation to build on. However, it is just a foundation - as an experienced home renovator I know that the foundation is the most important part of building a structure, however having a foundation alone doesn't give you a place to live - you still need to build a house on top of it.

That's where Seam comes in. It helps you, the developer, by providing the tools and materials necessary to build a house on top of the CDI-based foundation. It does this by integrating various useful libraries - libraries that are important for everyday application development - with the CDI component model so that you can write one kind of stuff, to coin a phrase that Gavin came up with quite some time ago.

But wasn't this already the goal of Seam 3?

Well yes, yes it was. But we've recently come to the conclusion that the Seam project shouldn't be a destination, it should be a journey. Ooh, so Zen!!...but what does this mean? Well, let me explain - Seam's goal is all about supporting the CDI ecosystem, and promoting CDI Everywhere. Why? Because, if we're all building our tools and libraries on the same standards-based component model, then we're all going to be much more productive when it comes to developing our rich internet applications. So, in light of this goal it doesn't make sense for Seam to be gathering crops - rather it should be planting seeds. In other words, there are many modules currently in Seam that we think would make better sense if they were situated somewhere more closer to home, so to speak.

Let's take a look at a concrete example - the Seam Persistence module. This module provides an extension-managed persistence context, useful for when your project needs to inject an EntityManager into a POJO bean, or if your persistence context needs to last longer than a single request. These are features that we consider to be essential for day to day application development. But in light of the goal of strengthening the CDI ecosystem, do these features really belong in Seam? At JBoss we have another well known project which deals with EntityManagers and persistence contexts and other databasey-related stuff - perhaps you've even heard of it (I'll give you a clue, it starts with H).

So instead of Seam trying to capture all of the CDI extensions in one place, like Pokemon, we should be trying to propagate them throughout the greater developer community instead. To that end, our focus is going to shift somewhat, and we've already made some concrete plans towards achieving that goal. Here's a few of the changes that we're proposing:

  • Seam Persistence - Move into the Hibernate core project, re-brand as Hibernate CDI
  • Seam Validation - Move into Hibernate Validator, make CDI support part of the core offering
  • Seam Wicket - Moving into the Wicket project itself, this is already in motion
  • Seam REST - Moving into the RESTEasy project
  • Seam Faces - Moving into RichFaces as a standalone Faces CDI integration library

As a part of the Seam community, you may have concerns that these changes might fracture the Seam project, or the community itself. I'd like to address this concern up front, and say that what we want to achieve is the exact opposite of this. Our aim is to broaden the existing community, by working closer with other projects to achieve a common goal. The current module leads will stay the same, however they will be working together with the other project leads to deliver native CDI support directly from their project. The end of result of this can only be a positive gain, as projects take more ownership of their own CDI integration, and work more closely with the Seam developer community to leverage the experience we have at building CDI extensions.

Seam's role in this new world

So while some modules may graduate from Seam to become part of the broader CDI ecosystem, there are still many features that are unique to Seam itself. These modules will remain within the Seam project for the foreseeable future, and Seam will continue to be an incubator for innovative development solutions and ideas. We still have much work to do, and many ideas on how we can provide new value-added features to Seam for our users.

So will there still be Seam releases?

We are planning on our next bundled release (3.1) to be our last. Note I said bundled - this release is basically a big zip file that contains the latest versions of all our modules. With our new focus, the bundled release just doesn't make a whole lot of sense any more. What we will continue to do however, is release each Seam module whenever it has received enough bug fixes and feature updates to warrant a brand new release.

From what I have heard personally, most of our developers are using Maven for dependency management anyway and so this change isn't going to make an iota of difference to them.

In Summary

So to sum up, Seam is not going away, rather its new goal is to unite the CDI developer community, and it will continue to foster innovation and encourage new ideas and improvements. If you have any questions or concerns about this, I look forward to addressing them in the comment section below.

32 comments:
 
27. Sep 2011, 10:34 CET | Link

Hi,

I think one of the strong point of Seam is to be not relate to any other framework by default. I can use Seam Persistence without using Hibernate, will it still be the case with Hibernate CDI ? I can use Seam Faces without using RichFaces. Same question ?

Even if the awser if yes, isn't it a bit strange to look for generic tools like Seam Faces inside a particular JSF library like RichFaces ? I mean, if I already use another JSF library, I have no reason to look inside RichFaces in order to find tool for my own library, isn't it ?

Regards.

 
27. Sep 2011, 10:39 CET | Link
gonzalad

Hello,

you may have concerns that these changes might fracture the Seam project, or the community itself.

I agree, with this new approach I fear we'll miss :

  1. centralized documentation (à la Seam 2 : how to develop a full Seam Application [CDI + JSF + JPA + seam extensions]).
  2. sample applications - quite similar to first point. Will there be some sample applications demonstrating all seam ext usage ?
 
27. Sep 2011, 12:29 CET | Link
gonzalad wrote on Sep 27, 2011 04:39:
Hello, you may have concerns that these changes might fracture the Seam project, or the community itself. I agree, with this new approach I fear we'll miss :
  1. centralized documentation (à la Seam 2 : how to develop a full Seam Application [CDI + JSF + JPA + seam extensions]).
  2. sample applications - quite similar to first point. Will there be some sample applications demonstrating all seam ext usage ?

We agree entirely with this, and we are hoping to accelerate, not diminish, this effort over the next few months. We plan to extend the approach Seam 2 took in showing you how to build complete applications (through tutorials and samples) to the entire JBoss stack, not just Seam.

 
27. Sep 2011, 13:03 CET | Link
Austin

Paul hit the nail on the head. Seam and CDI are supposed to be implementation agnostic. Won't we lose this by moving these extensions under specific JSR implementations?

 
27. Sep 2011, 13:40 CET | Link
Ex-Seam user

Well that is it then. Good bye Seam. R.I.P.

IMHO Seam 3 was overly-ambitious and JBoss was not putting enough resources behind the project to actually turn these ambitions into code. So the last resort is to hand off workload to 3rd party projects... sorry but that is NOT what I consider a solid enterprise class application framework anymore.

So long and thanks for all the fish...

 
27. Sep 2011, 16:40 CET | Link
Antoine Sabot-Durand
Working on one of the "incubatored modules" (Seam Social), I'm also concerned about the blending of main seam modules to your JSR implementations.
I'm currently building a POC with CDI and Primefaces. Seam Faces helps a lot for this POC but tomorrow, someone else won't look for this module since it'll be blend with RichFaces.
The same for Hibernate CDI.

The strength of Seam was that it was an integration solution of others technologies like a kind of cement. Spliting this cement in each project will create (psychological) adherence to each project (Resteasy, Hibernate, Richfaces) and will obfuscate seam modules.

IMHO the name Seam was a bad choice for these extensions since most people saw them as a new version of Seam 2 which they are not (and that created a need to create a very expensive migration solution). And now it's another bad choice to scatter and hide these modules.

Unless the Seam Framework Web site keeps track to these new modules and stays to provide a spine to them.

However we have to compete with Spring de Facto standard and I don't think that blurring the CDI eco system a little more is a good move.
 
27. Sep 2011, 18:24 CET | Link
WangLiyu
I guess this is good and bad, for unique framework like Apache Wicket, it's good to moving in to the project, that's help both side.
for framework that is implementation of some JSRs, it may not be a good idea, it may be good for a short time, but in a long run it may hurt some.
The purpose of having the JSR is to eliminate the bundle to the vendor, with the Seam addon, it actually go back the spring route which is not cool.
And what about if I want to switch to use Primefaces instead of richfaces, or say using eclipselink, so people might go back to use Spring.

split the boundle is OK to me.

Also if you guys really decided to go that far, please make sure those are still seperated modules (I mean seperated jars).
 
27. Sep 2011, 20:04 CET | Link
Alexey Kazakov | akazakov(AT)exadel.com

What about the basic modules such as Seam Solder and Seam Config modules? Are they going to be developed as part of Seam 3 project or they will move to some other projects too?

 
27. Sep 2011, 20:18 CET | Link

Plus 1, agree with Paul Dijou and Antoine Sabot-Durand.

I think (perhaps I'm wrong) you guys lost of focus about what the purpose of seam project is. Well, for me, at least in seam 2 era, seam is solution for 'journeyman java programmers' daily job. Creating a POC for make a presentation for a clients? Use seam-gen. Creating a project structure? Use seam gen. One of client love JSF and your boss ask to creating JSF based application, just use seam. Feel annoying with Springs HibernateTemplate and still got LIE, and then your team members complaining to much, just use seam (Yeah, I know that this is so 2006, and HibernateTemplate already obsolete these days).

Unfortunately, those things not happen in seam 3. I know that this is not your fault at all. Not everybody familiar with maven, even you start to learn maven, this migration will change the way you build an application. And I know forge-team still struggling to make this all easier.

So I think, back to the decision, from my personal opinion, it's important that you guys need to define your purpose about this project. I think the old purpose that added by Gavin give a positive impact. So, why not continuing the purpose, to creating a complete solution.

As Antoine said, blurring this ecosystem is not good move. Instead, I think you need to build and increase a seam brand, using the seam way or something smiliar propaganda ;).

 
27. Sep 2011, 20:37 CET | Link
Paul Dijou wrote on Sep 27, 2011 04:34:
I think one of the strong point of Seam is to be not relate to any other framework by default. I can use Seam Persistence without using Hibernate, will it still be the case with Hibernate CDI ? I can use Seam Faces without using RichFaces. Same question ?

That's a good question, and a valid concern. The two examples you mentioned, Seam Persistence and Seam Faces will remain unchanged in the fact that they will not be tied to any particular implementation. Seam Persistence has always targetted JPA (with some Hibernate-specific value adds, which has been this way since Seam 1) and will continue to do so as Hibernate CDI. Seam Faces will exist as a standalone module in the RichFaces project.

Even if the awser if yes, isn't it a bit strange to look for generic tools like Seam Faces inside a particular JSF library like RichFaces ? I mean, if I already use another JSF library, I have no reason to look inside RichFaces in order to find tool for my own library, isn't it ?

At JBoss we love standards. We strive to follow them where they exist, and to create them in areas where we recognize there is a deficiency. Our vision and goal is to push the improvements and integrations we create into the specifications and standards where they make most sense. The Seam Faces module contains features that are extremely useful for any developer that uses JSF. Being able to inject the JSF API objects such as FacesContext, or write CDI observer methods for the JSF lifecycle events is to me, just common sense, and I think should be provided by default as part of the JSF specification.

Continuing on, the RichFaces project is where all things JSF should be happening at JBoss. This is the project that is most closely associated with the JSF standard, and it is this platform that we will use to push for native CDI support in a future version of the JSF specification. Our goal is not to simply farm off the Seam modules into other projects wherever they fit, that would be extremely unproductive. Our goal is to use these other projects as a stepping stone, to push CDI integration into the standards most closely associated with those projects.

This goes the same for Hibernate. We all know that most of the inspiration for JPA comes from the Hibernate project. If we want to include CDI integration as a core offering of JPA, then Hibernate is the platform we need to use to achieve that. I realise my blog post above didn't express this aspect of the vision, and I apologise for that. However I do truly believe that the fruits of this vision will benefit a far greater number of developers in the long run.

 
27. Sep 2011, 20:40 CET | Link

This also seems like a strange move to me.

Firstly, as far as I know e.g. Seam Persistance provides JPA, not Hibernate integration. And using Hibernate CDI with another JPA impl sounds weird ;). Same for Seam Faces etc.

Secondly, there was quite a clear opposition between Seam and Spring. Now the choice will be Spring or ... JEE plus a bunch of loose additional components? To a new user I don't think this will build confidence that he's using a tested, integrated application framework.

Adam

ps And please, start using something else then this blog/forum. JBoss Community is really good comparing to the commenting anti-features found in in.relation.to ;)

 
27. Sep 2011, 20:41 CET | Link
Ex-Seam user wrote on Sep 27, 2011 07:40:
Well that is it then. Good bye Seam. R.I.P. IMHO Seam 3 was overly-ambitious and JBoss was not putting enough resources behind the project to actually turn these ambitions into code. So the last resort is to hand off workload to 3rd party projects... sorry but that is NOT what I consider a solid enterprise class application framework anymore.

I've already clearly stated that Seam is not going away. And the last thing we are doing is handing off workload - all the same people will still be working on the same modules, with the added advantage that we will benefit from the additional expertise gained from collaborating more closely with other projects. Perhaps it's my fault for not communicating clearly enough, but the point here has definitely been missed.

 
27. Sep 2011, 20:47 CET | Link
Alberto Gori
Alexey Kazakov wrote on Sep 27, 2011 14:04:
What about the basic modules such as Seam Solder and Seam Config modules? Are they going to be developed as part of Seam 3 project or they will move to some other projects too?

AFAIK seam-config and seam-catch are going to be part of Solder module (different packages but same module).

 
27. Sep 2011, 20:50 CET | Link
Antoine Sabot-Durand wrote on Sep 27, 2011 10:40:
The strength of Seam was that it was an integration solution of others technologies like a kind of cement. Spliting this cement in each project will create (psychological) adherence to each project (Resteasy, Hibernate, Richfaces) and will obfuscate seam modules. IMHO the name Seam was a bad choice for these extensions since most people saw them as a new version of Seam 2 which they are not (and that created a need to create a very expensive migration solution). And now it's another bad choice to scatter and hide these modules. Unless the Seam Framework Web site keeps track to these new modules and stays to provide a spine to them.

Antoine you bring up some great points, and I agree with your opinion about the Seam name (we really should have rebranded this when we had a chance, instead of releasing version 3... hindsight is always clearer).

I'd like to personally reassure you though, that the unified stack concept is very important to us both from a strategic point of view and a usability point of view. In some ways, this announcement was a little premature because we do have some grander efforts underway that will address this but unfortunately we are not ready to announce any details about it yet. I can understand that some people might be concerned about the investment they've made in Seam, however I can assure them that their investment is safe and in good hands. We'll be announcing some bits and pieces in the coming weeks, so all I can ask is that people be patient until we flesh out some of the finer details for the announcement.

 
27. Sep 2011, 22:06 CET | Link
Cool Seam

I really hope Seam 3.1 can implement some important Seam 2 modules, e.g. EntityHome (Create, Read, Update and Delete (CRUD) persistent storage), Seam Mail, and etc, in order to help Seam 2 projects to upgrade to Seam 3 and CDI.

 
28. Sep 2011, 00:21 CET | Link
Alberto Gori wrote on Sep 27, 2011 14:47:
AFAIK seam-config and seam-catch are going to be part of Solder module (different packages but same module).

Correct, the seam-config, seam-catch and seam-servlet modules have been combined with Solder, and Solder is becoming a top level JBoss project (still maintained by us though) which we will be encouraging other projects to consume for their own CDI integrations.

 
28. Sep 2011, 01:29 CET | Link

I'd like to add a few notes that may help clear things up.

Forge

Let's consider JBoss Forge, which is a project that highlights the direction we want to take things. Specifically, Forge is not seam-centric (though it has had some issues distancing itself due to the initial use of the Seam brand), and it is being positioned to strategically help getting started quickly with Java EE, and extensions to Java EE (which is where Forge plugins come in.)

So how does this relate to Seam and this announcement? As Shane stated above, Seam is not going away, even if the name changes. We are not abandoning our centralized approach with this move, rather we are positioning the project so that we can refocus centralized effort onto the platform for which it was intended, Java EE, using tools like Forge to make learning easy. In short, we are not abandoning Seam, but we are expanding its mission to encompass Java EE as a whole.

But Seam?

The problem with doing this specifically for Seam is that we were not doing justice to the portability aspects of Java EE, and our Seam Centric documentation and examples were really only good for educating people interested in using Seam, not necessarily plain Java EE, or even Java EE with Spring. In order to do this, we need to get support from other projects like Forge, Hibernate, HornetQ, RichFaces, which is why we've started to try to get those teams more involved in working on the individual modules themselves (and why they may be moving closer to the projects that implement those specs.) We want people to talk more, we want the specs to work better together, and the future of seam is critical for making sure that happens.

To tie this all together- I will say that we do have a strategy to provide a centralized, easy to use framework; however, this announcement came out a bit early, and we are not ready to talk about that part of the plan yet.

Never fear. Seam, all of the Seam modules, and other CDI extensions are going to be working very well together. And the community will be bigger and stronger than ever.

In summary:

Seam + Forge + Centralized Information + Java EE + JBoss AS7 = Getting started easier + Doing more faster

 
28. Sep 2011, 01:46 CET | Link

We've heard all of your arguments, both for and against, please don't think they're falling on deaf ears. We're still trying to figure some of this out ourselves. Yes, this announcement was a little premature, but hopefully, the community views some botched communication better than nothing at well, which have admitted to doing in the past. We're sorry this announcement created more ripples than we thought it would.

Seam has been and will continue to be a place to go help you more easily create and develop applications for your specific needs. That message from Seam, even from the 1.0 days hasn't changed, nor will it change. You'll still be able to come to the Seam project for information about integrating technologies in the Java EE space. If anything, we're hoping we're able to do more of this kind of work in the future, stay tuned.

Of course we're going to work a little closer with other JBoss projects, and there may be some features that won't be available when using another implementation of a spec, I think we all understand that. I think it is also important to understand that those of us working on Seam aren't experts with all the technologies Seam integrates. Speaking for myself, I know JSF pretty well both component libraries and core JSF spec related ideas. I also have used Hibernate as a JPA provider for a while, but I'm not really all that familiar with Core Hibernate. I've done next to nothing with Drools / JBPM, etc. We all have familiarities with different things on the project, but those who actually create projects themselves will have a much better idea how their projects are being used and ideas for using CDI that we may not come across. Getting help from those projects, and / or asking them to take ownership of the CDI integration, I think is a good thing, you'll have one place to go for information about Project XYZ. For example, look at Hibernate Validator, aka Bean Validation. If you're looking for Bean Validation and CDI integration where would you look by default, Hibernate Validator, or some 3rd party project (Seam in this case)? Shifting some bits around, I don't think is going to be a bad thing in the long run. There may be some confusion, we're hoping not, but that may happen, what we're hoping to gain is better cohesion with specs and projects.

Seam will continue to offer Java EE specification integration. As Shane has stated, some great ideas and also whole specifications have grown from the Seam project in the past, that also won't change. We're hoping this move helps foster other ideas that can help improve specifications, and provide our users with a better overall experience with people and projects you work with, it may even create new relationships which may not have ever taken place. Please bear with us and keep the comments and feedback coming!

 

Author of Seam Catch

 
28. Sep 2011, 06:00 CET | Link
Eric McIntyre | cybermac912(AT)gmail.com
Cool Seam wrote on Sep 27, 2011 16:06:
I really hope Seam 3.1 can implement some important Seam 2 modules, e.g. EntityHome (Create, Read, Update and Delete (CRUD) persistent storage), Seam Mail, and etc, in order to help Seam 2 projects to upgrade to Seam 3 and CDI.

I think you've missed the point. Why wait for JBoss to do it? As you can see, they're encouraging others to fill the needs that they see, to participate in the ecosystem. For instance, like you I really miss the Home/Controller/Query stuff from Seam 2. To me this refocused direction is actually good news, because I can start the port myself, and release it to the community, without needing to get JBoss' buy-in and collaboration. Just put together something that I think is good, and see if others agree.

 
28. Sep 2011, 08:39 CET | Link
Marx

It's what I understand so far:

1) JBoss people try to force us to use JBoss7 (I don't think this version is production ready - see open bug list)

2) Seam as open framework is dead - Seam will try to force us to use other JBoss products like Hibernate etc

3) We had better or worse seam gen (it was ant times) - moving to maven should give us maven archetype (JBoss like to use stanards, yes?) but no - he have seam forge. So learn new tool instead of well known archetypes

4) Looks like Richfaces team fears of Prime Faces - Prime Faces are way better than RichFaces, many peoples choose it, so let's try make their life harder - move Seam Faces to RichFaces...

I'm really dissapointed about a way Seam is going. What I had expected from Seam is framework which gives you ability too choose puuzles from different vendors and glue them together. I had expected unified example of all this technologies. I had expected it would be easier to develop such an application and test it, measure it etc. As I see most of Seam applications are web based and uses the same architecture. They use CRUD technology (JPA), some security, they need logs, exceptions and some xxxFaces framework to visualise. It doesn't change from years. Instead of giving us good framework to do such an application, we have some modules lousely coupled which in theory can be used singly, but in practice one module force to use another (and now while Seam modules will not have one version, we will have to puzzle versions of different modules)

And to give another pinch of salt: Seam forum is written in Seam and it isn't user friendly. Session timeouts, forget page we are at and works veeeery slowly. You should write something usefull to show power of Seam and no - Booking example isn't such a thing. Try to rewrite forums to Seam 3 and show us it really works. Show us your test cases with Selenium and Arquillian for it. Than I believe Seam is alive.

Ps. While writing this post session timeouts twice hiding Post button. Is it also written in Seam....?

 
28. Sep 2011, 09:46 CET | Link
Siarhei

@Marx, that's quite some conspiracy theory you've worked out :)

It seems pretty obvious to me that the main reason is that the Seam team resources are stretched. And then there is Weld which is more important...

 
28. Sep 2011, 10:04 CET | Link
gaboo

Please make sure all Seam 2 features are available. Seam 2 is getting old and unmaintained, we need to start migrating. For a 4 year old seam2 project, this will be a long ride. We need a Seam Framework replacement. Mail templating. PDF generation. Security (roles, permissions, page level restrictions, etc). And that's what is great about seam2 : fast and powerful application development framework!

And please keep it integrated so that I don't have to look for many librairies in many different places.

Failing to setup a fast a reliable seam framework website for years is also hurting you.

I am a happy seam2 user and only hope for a great successor :) Thank you!

 
28. Sep 2011, 12:21 CET | Link
Paul Dijou wrote on Sep 27, 2011 04:34:
Hi, I think one of the strong point of Seam is to be not relate to any other framework by default. I can use Seam Persistence without using Hibernate, will it still be the case with Hibernate CDI ? I can use Seam Faces without using RichFaces. Same question ? Even if the awser if yes, isn't it a bit strange to look for generic tools like Seam Faces inside a particular JSF library like RichFaces ? I mean, if I already use another JSF library, I have no reason to look inside RichFaces in order to find tool for my own library, isn't it ? Regards.

I just wanted to mention that the Hibernate team have a track record of being usable outside of Hibernate - Hibernate Validator is used in GlassFish, which uses TopLink.

 
28. Sep 2011, 12:36 CET | Link

Why is Seam Faces bundled in RichFaces? It makes more sense to try to integrate it in all Rich clients like Primefaces, Icefaces and so on, or even create a new jsf implementation that adds support for Seam Faces?

 
28. Sep 2011, 15:35 CET | Link
esteve

Hi,

I think that Jboss people should put themselves in the skin of the enterprises and the people at enterprises that have to make the choice of this kind of stuff. Seam, like Spring, is a very good choice as is a layer of common functionalities needed by everyone. It was also a very good strategy makeing weld standarized. With this kind of move, software arquitects will have to be the integrators and testers of the all frameworks and projects (everyone with its own priorities), bringing back the old integration headaches we thought were solved with Seam.

JBoss allways has succeded in make thinks very clear with all their projects. I don't know why with Seam it is different.

Well I think we will have to wait for a clearer explanation about all this matter, but remember: a bad project well explained can succeed, but a good project badly explained will never succeed.

 
29. Sep 2011, 02:43 CET | Link
Miles Chang

What about the Seam Security, Seam JMS ... etc modules?

 
29. Sep 2011, 10:14 CET | Link
Werner

I am using Seam2 extensively and I am very pleased with it.

As for Seam 3 I hope to find a bundle of useful modules (built on CDI) which would replace most modules of Seam 2 independent of which library one uses.

As stated before, more effort should go into developing some solid examples which present the different modules.According to me, this was one of the big promotors of Seam 2 (good documentation , plenty of examples plus Seam in Action ).

Moving seam faces module to richfaces project is a bit of an odd choice. At work we are planning to use both richfaces and primefaces. From JSF2 on, it should be simpler to work with different component libraries at the same time. Putting an extension to JSF2 (as I see Seam Faces) at a specific component library looks to me if the seam faces module is only specific to richfaces.

I am not very thrilled about this move but I hope some further information will clarify this.

I rather see some examples that we could use the different seam modules as jboss modules. This would promote the modularity of Jboss 7 server.

Seam2 was all about the package, you had dependency injection but on top you had plenty of useful technologies. You did not need to implement all and it was not limit to specific libraries.

Although the use of certain other jboss libraries/projects would let you do more advanced stuff.

PS I got ejected twice because of a session time out so I typed this text somewhere else and did a good old copy and paste

 
29. Sep 2011, 10:16 CET | Link

So will module continute to work together towards the goal of providing an easy to use programming model?

For instance if seam-faces now go out of seam project, and seam-security stays with seam will we have integration between the two? So far seam-faces had the @ViewConfig annotation which was wokring nicely if you had seam-security on the classpath. Will stuff like that continue to be added to those non-seam modules? For instace we were all hoping that @ViewConfig will get some form of view action similar to

<s:viewAction />

But specifiable in java code.

 
29. Sep 2011, 17:15 CET | Link

I understand everyone is a little scared right now. Everything will work out, and we're confident we'll end up with a better solution in the end.

To those wondering about portability, yes, things will continue to be portable wherever a module may end up. We'll also continue to support inter-module integration. Just because a couple of modules were called out doesn't mean that's the final resting place for them. They may have contributions from other projects, they may not. Things will continue to work.

 

Author of Seam Catch

 
30. Sep 2011, 08:19 CET | Link
Geoffrey De Smet

Don't stop the bundled releases of the stuff that remains in seam, like solder, catch, international, security, ... I am using maven, and when GAV's change (like from seam 3.0 to 3.1) or there is a chance on behavioral backwards incompatibilities (mixing solder 3.1 with security 3.0 is not tested by the seam unit tests), those bundled releases save you from a lot of headache.

It's a good thing that some modules are moving into their owner's home, but that doesn't mean the rest of seam is dead.

 
30. Sep 2011, 08:22 CET | Link
Geoffrey De Smet
PS I got ejected twice because of a session time out so I typed this text somewhere else and did a good old copy and paste

me too

 
30. Sep 2011, 13:34 CET | Link

Shane has written follow up blog. Please take a look.

Thanks again for all your feedback, it's great to hear such passion and belief in Seam! We honestly want to do what is best for the community, and agree with many of the points raised here. However, it's become clear to us that our radar was slightly off in how you guys want to see Seam go forward. For that reason we've started a consultation period to gather your feedback. Please comment on the forum with your thoughts.

To keep things orderly, I'm disabling new comments on this post - please use the forum if you want to chime in!