Frank Martínez has written a sample project with Seam 1.2.1, deploying to Glassfish, and using Netbeans 5.5.1 as the IDE. Customizing the project is mostly a matter of search and replace, with one jar being required in the domain library directory for proper operation. The search/replace operations handle project-level datasources, EAR names, web application contexts, home directories, and the like - nothing difficult. It's an interesting approach, and highlights a problem Java EE still suffers - things like Seam, which rely on specifications, still require specialization for IDEs, build processes, and application servers. Kudos to Frank for documenting the process and providing a sample project.

shouldnt that be done by seam-gen? I have worked with seam-gen quite a bit and I think it is a very useful tool, but it needs some improvement. 1) It should ask which container you would like as the target runtime and generate the project skeleton based upon that decision. (Still it seems crazy to me that despite all of the standardization processes going on, we STILL need separate configuration for different containers. Cant we have exactly ONE version to define modules? I dont have much experience about the following but maybe OSGi can do a little something about that.) 2) You should be able to use seam-gen for multiple projects much easier. Why not create a little swing-app with file-choosers for the JDBC drivers and so on. I hate to paste the path to the driver into the cmd. But maybe that is just too much to ask. There a bigger issues than that. 3) Some generated project-skeletons are not as smart as the example projects. For example the build file, when it comes to exploeded deployment/deployment, there is no clear winner. The idea to have a tool that generates a project skeleton is very good, because thats just a tedious non-productive thing to do by hand. A question towards the package structure: Why is there a need for java.service/java.controller and especially java.web ? Isnt Seam all about unifying most of that stuff (when a separate layer just for the layer's sake is not needed).

should have been: 3) Some generated project-skeletons are not as smart as the example projects. For example the build file, when it comes to exploeded deployment/tomcat deployment, there is no clear winner. 4) application profiles: Seam-gen should not ask for only one datasource, but also for a dev, test datasources. 5) deployment strategies: a) exploded deployment on JBoss during development and b) tomcat compatible deployment for production* * For those poor soules that are allowed to only produce .war files in our jobs.

Why is there a need for java.service/java.controller and especially java.web ? Isnt Seam all about unifying most of that stuff (when a separate layer just for the layer's sake is not needed).

I think there is a slight misunderstanding. Seam unifies the layers from technological point of view, and does not force layering. How to layer your application is not anymore dictated by the technology, but that does not mean that everything should be in one big pile.

Thats true, now it is no longer dictated by the technology, but by the project template ;) No, just kidding, I understand what your point is.

Thats true, now it is no longer dictated by the technology, but by the project template ;)


No, just kidding, I understand what your point is.

Hi guys, Thanks for your comments. I used this project structure in a project i developed recently. The basic idea of this layout is for reusability, because i need to share common services between many controllers and in the web layer i put some internationalization files, formatters, and view helpers .... I dont like a big Stateful EJB with all (logic, control, and presentation code) ....

shouldnt that be done by seam-gen?


I have worked with seam-gen quite a bit and I think it is a very useful tool, but it needs some improvement.

I use a Seam a lot - I also use Maven 2 for project creation etc. I choose Seam because I like its programming model (much less code and XML via annotations). I don't choose Seam because of its project-creation-mgmt-build capabilities. FWIW, I think it would be 'nice' to see some standard (open-source) Maven2 archetypes evolve for Seam projects. I've found that my IDE (IntelliJ) is smart enough now to discover a module has a pom, parse the pom, and add dependencies to the IDE project (I don't think it can do that with an ant build script). Furthermore, a Maven2 archetype can be customized to generate projects with whatever layout you prefer. So... I don't think seam-gen should do that or any of that other stuff" ;-) and I prefer to see project generation decoupled from a particular framework as much as possible.

Speaking of Seam, you probably already know about it, so this post is just info for people that doesn't, but might be interested: http://www.redhat.com/developers/rhds/index.html Bye

.. unless you are fine with buying a developer subscription or building the eclipse plugins yourself. Yes, you heard it right, RHDS final will require you to buy a subscription from Red Hat.

.. unless you are fine with buying a developer subscription or building the eclipse plugins yourself.


Yes, you heard it right, RHDS final will require you to buy a subscription from Red Hat.

There will be an open source version available for free, I'm not entirely sure you will end up building your own plugins. Alternatively, you can buy a subscription which gives you a very stable and tested release for a small amount of cash. Personally, I don't mind shelling out a few bucks for something that gets me going, rather than having to deal with spending time getting my IDE working and keeping it working. Of course, my ideal scenario would be Netbeans getting some decent Seam support so I don't have to use eclipse. Those that get hot under the collar at the thought of shelling out a few bucks for a good IDE that is suited specifically to your needs (i.e. Seam development) would probably prefer to build their own eclipse plugins. Not everything needs to be free.

Seam-gen should not ask for only one datasource, but also for a dev, test datasources.

Seam does files for dev/test/prod datasources, and you set the one you want to include ina build by setting a value in build.properties or something like that. Seam gen creates the files, you just need to go and edit the datasource info in them.

I know and that is good. But why not just ask for the different schema/username/pw during seam-gen? You could leave it blank, if you dont have such datasources. I dont have a problem with paying money for a stable, robust, functioning bundle of RHDS + JBossAS/Tomcat + Hibernate + Seam + Richfaces/Icefaces. It is just that people are not aware of RHDS not being completely free and I wanted to point that out. However the day that Netbeans 6 has proper Seam support, I probably wont use RHDS anymore. The ease of use that Netbeans provides is just unbeatable.

The ease of use that Netbeans provides is just unbeatable.

+1 on that one

I know it is not as comfortable as a full Seem support, but there is a couple of HowTos for NetBeans, see: http://wiki.netbeans.org/wiki/view/FaqSeamSupport http://weblogs.java.net/blog/kalali/archive/2006/08/develop_web_app.html