I am using JBoss AS6 with Snowdrop 2.0.0-MP1-SP1, I have updated the spring implementation with 3.0.5.RELEASE (although I wish either that all JARs were named with the version "spring-core-3.0.5.RELEASE.jar", yes you can get them like that from Maven, or you at least put them in a directory of their version "3.0.5.RELEASE/spring-core.jar", which might lend itself to OSGi based version selection for AS7).
I have a number of queries.
My project layout is a straight forward EAR with a JPA jar, with a EJB jar, with a WAR.
EAR has META-INF/earApplicationContext-spring.xml
JPA has META-INF/jpaApplicationContext-spring.xml
EJB has META-INF/ejbApplicationContext-spring.xml
WAR has WEB-INF/classes/spring-context/warApplicationContext-spring.xml and WEB-INF/classes/spring-servlet/servlet-spring.xml
Each of these has a http://www.springframework.org/schema/beans/spring-beans-3.0.xsd and a <description> element with the BeanFactory=(label) and ParentBeanFactory=(label). I have verified in JNDI the name of the bindings for the (label) parts. these are the files names without -spring.xml suffix like "earApplicationContext".
However I have not been able to verify the parent/child relationships are being correctly setup by spring.deployer. I can see in org.jboss.spring.factory.NamedXmlBeanDefinitionParser the new BeanFactory get #setParentBeanFactory() called.
There is also a <description> element variable Instantiation(true) which by default is set to false (which I think should be true) but I can't see how or where it is used by the spring.deployer.
How is the WAR handled, should both the outside ApplicationContext and the child servlet's be setup in the traditional (WAR only) way and using the <listener> and <servlet> settings in web.xml.
Since the JBoss VFS can see inside of the EAR and all the classpaths, is the WAR packaged correctly or should a certain naming convention not be used.
If my EAR was a little more complex. How is it possible to control the order in which both JBoss AS brings up each JAR (so we're talking JPA, EJB and regular JARs) all inside EAR. Does this order also affect how and when SNOWDROP creates the parent/child relationships ? To me it would seem that SNOPDROP should scan for all possible ApplicationContext's to instate just the skeleton factory itself (no beans inside yet), it should create them all and name each. Then once all are created another pass to fixup the parent/child relationship. Then on another pass walking the BeanFactory top-down it would then process the non-lazy beans within.
Does BeanFactoryLocator work within an EAR context like (I think) it should. When I query it, I find it empty. I believe this mechanism could be used to allow 2 sibling BeanFactorys in a hierarchy to find each other. There is some overlap with JNDI in this function but which this is Spring's own method.
I'm sure older version of SNOPWDROP allowed arbitrary naming and bindings to JNDI, such as "spring/myenterprise-mymodule-ear" (note the use of the "spring/" path prefix), this does not seem to be allowed anymore. What/why is the change of policy on this ?
Is there any suitably complex example of multiple ApplicationContexts inside different JEE deployables all wrapped in an EAR to demonstrate/test such functionality ?