1 Reply Latest reply on Jan 23, 2017 4:01 AM by Martin Kouba

    Weld 3.0 - bridging Weld SE containers

    Aaron Anderson Newbie

      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?



        • 1. Re: Weld 3.0 - bridging Weld SE containers
          Martin Kouba Master

          Hi Aaron, there is no SPI which could help you with this - as you already mentioned Weld containers are strictly isolated and have completely independent lifecycle. In fact, bridging container instances might be tricky. I believe the best approach would be to use a provided event bus (third party library) and communicate by means of immutable messages. On the CDI side, you could automatically register the CDI observers as event consumers (see for example GitHub - weld/weld-vertx).