Weld 3.0 - bridging Weld SE containers
I am using Weld 3.0 Beta1 SE to start a server based application in one container and then start several other containers for embedded Tomcat WAR webapps. I investigated combining Weld SE with Weld Servlet but I didn't think I could make it to work. Here is what I am doing now:
new Weld("Server").initialize() - ran in bootstrap classpath with Weld SE, Embedded Tomcat, my server runtime CDI annotated classes and extensions, and other shared dependencies. Tomcat is started through CDI events
-> new Weld("WAR1").setClassLoader(tomcatWebAppCtx.getClassLoader()).initialize() - In a Tomcat Context LifeCycleListener start a Weld SE container with the web application classload
I don't need full JavaEE injection support (JSF, EJB, etc) but I would like CDI injection inorder to dynamically deployed applications to my server to be able to inject instances from the runtime container and perhaps even support eventing.
My main problem is that the web application containers are reloading the singletons and extensions defined in the runtime container because they are completely isolated which is well documented. I naively thought CDI and Weld supported resolution delegation like classloading where a child container could defer to parent container but that does not appear to be the case.
My current idea is to split up my classpath like this:
Bootstrap classpath - main global server classes, Embedded Tomcat , Weld SE but no CDI annotations or bean.xmls. Embedded Tomcat started without CDI.
-> new Weld("Server").initialize() - runtime classpath server runtime CDI annotated classes
-> new Weld("WAR1").setClassLoader(ctx.getClassLoader()).initialize() - web application classpath + parent bootstrap classpath. A bridge CDI extension is built to expose predefined instances generated in Server container to WAR1 container as unmanaged instances
Does this sound like a good solution? With the new container feature I was trying to avoid creating a full blown JaveEE appserver like Environment implementation but are there any other SPI hooks that would assist me with exposing produced instances/events from a parent container to a child container?
Thanks!!!
