How do I reverse engineer from mul...

Why do I see duplicate association...

Seam employs a special hot deploy classloader that's capable of reloaded Java classes that have been modified at runtime. There are several conditions which must be met in order for this to work.

1. The application must be packaged as a standalone WAR (not inside an EAR)
2. Seam must be running in development mode (<core:init debug="true"/>)
3. The Java class must be a Seam component (annotated with @Name and installed)
4. The Java class must be compiled to a the classpath location in the WAR, WEB-INF/classes/dev

When Seam detects a change, it removes all of the hot deployable components from their respective contexts, reads in the new component definitions (there can be additions and removals), and instantiates any hot deploy startup components. The hot deployable components are once again ready to use.

One of the main reasons Ant is used at the build tool for seam-gen projects is because it's flexible enough to support two isolated source paths. If you have been using Seam 2.0, you'll recognize these directories as:

• src/action
• src/model

Components (Java classes) in src/action are compiled and Groovy scripts copied to the hot deploy classpath, WEB-INF/classes/dev, in the exploded WAR structure. Components and regular classes src/model directory where compiled and resources copied to the main (static) classpath, WEB-INF/classes. In production mode, of course, the artifacts in these two directories both would end up in the main classpath.

In Seam 2.1, the names of the source directories were changed. The reason is that hot deployable classes are not always actions and non-hot deployable classes are not always the model. Better is to name the folders after how they are treated by the compiler. To fix this semantic mixup, the source directories are now:

• src/hot
• src/main

JBoss Tools still uses the old convention for the time being. Despite the difference, it has no problem consuming a seam-gen project with the new folder names since, internally, it relies on a mapping between folder name and function (seam-gen prepares the mapping configuration to reflect this new convention).

If you want to use Maven 2 to build seam-gen projects, you either have to merge the source paths, effectively doing away with the hot deploy feature, or you have to use a Maven 2 plugin that adds a separate compile step to the Maven 2 life cycle.