Understanding seam initialization

[lightguard]

I think Pete will probably be able to answer this the easiest (or Gavin).  I'm trying to understand the whole Seam initialization process.  I see the handlers and scanners and have a pretty good idea of how things are happing (just looked it while I was on the bus), but I'm not sure what kicks the whole process off.  Could some enlighten me please?

[keithnaas]

As with many other web application frameworks, its all kicked off at deploy time by a listener as shown in this tutorial. 

If you'd like to see the code, look at SeamListener. The class javadoc for SeamListener:

/**
 * Drives certain Seam functionality such as initialization and cleanup
 * of application and session contexts from the web application lifecycle.
 * 
 * @author Gavin King
 */

That guy kicks off the Initialization class which magically scans for all of the various configuration files.

This method illustrates what is happening pretty clearly:

   public Initialization create()
   {
      deploymentStrategy = new StandardDeploymentStrategy(Thread.currentThread().getContextClassLoader());
      deploymentStrategy.scan();
      addNamespaces();
      initComponentsFromXmlDocument("/WEB-INF/components.xml");
      initComponentsFromXmlDocument("/WEB-INF/events.xml"); //deprecated
      initComponentsFromXmlDocuments();
      initPropertiesFromServletContext();
      initPropertiesFromResource();
      initJndiProperties();
      return this;
   }

[lightguard]

So it's the war that actually starts Seam?  How does it pick up the ejbs in the ear if it's being started in the war?  Wouldn't the classloader that the listener is finding be the war classloader?

[pmuir]

Print out the hierarchy for the war classloader and youy will see the EAR classloader is the parent. In fact, IIRC EE specifies this.

[lightguard]

With seam being loaded via the war, is there a problem having multiple web-apps in the same ear that are seam apps?