In my last post I laid the groundwork for a compositional approach to deploying applications in CDI 2.0. The main method doesn’t need to do anything. Portable extensions don’t need to know anything about the main method. User code doesn’t need to know anything about portable extensions.
Recall that our developer has written the following standards-compliant JAX-RS application:
…and just wants to run it. But she also wants to be done here, and doesn’t want to write a main method or depend in code on vendor-specific classes. Also, because we are living in The Future™, she wants to avoid deploying to some application server by hand.
Enter portable extensions and composition.
First, recall our generic main method, parked over in a corner in a jar of its own:
Now let’s say ServerCo authors this nice little extension:
Ignoring the utility methods for a moment, at line 32 the extension is notified that the CDI container it’s a part of is now open for business.
At line 34, using the get() utility method (see line 65), it asks the container for an HttpServer instance, if there is one.
If indeed there is one, then it starts the server.
Control flows back to the main method. Specifically, the main method now has an SeContainer in its hands. It promptly, of course, does nothing, and so the container starts to shut down.
At line 54 above, the portable extension is notified that unless something else happens, the container is going to shut down. It arranges for the server to stay up with the join() call on line 57, and until the server is interrupted or killed or otherwise stopped we will block here.
Look, a JAX-RS server that comes up as a side effect of a CDI container starting up!
No. Not yet.
We’ll address that in the next post!