4:15 p.m.
I've been sitting on this idea for a while so I thought I'd put it out
there and get some feedback on it.
Problem: People want things to happen when the container is "up".
Unfortunately, there really isn't a black-and-white concept for what
"up" means. Often times, the user is simply going for "my application
will function correctly", so they can make a load-balancing decision or
perform some other monitoring action.
Semantically, the desire would be for some external mechanism to receive
a notification when the services corresponding to the specifically
applicable components have completely started or are going to stop. The
obvious implementation of such a mechanism is a service which depends on
the set of component services.
Solution 1: In theory, a user could create a deployment that performs
availability tasks in a service which depends on all the requisite
services. The user needs specific knowledge of service names in this
case, which may change, or they must use specific technologies (for
example, use a singleton EJB which @DependsOn each dependency).
Solution 2: Introduce a subsystem which allows definition of different
availability configurations. The configuration would enumerate the
items that are required for the configuration to be considered
available. The configuration would be associated with an action. We
would use management.next-style extensibility points to let the user
define add-in items like EJBs, servlets, POJOs, MBeans, CDI beans, etc.
without the subsystem needing specific knowledge of the service schemes
for each.
We could make solution 1 work more effectively by providing a more
uniform deployment-based dependency mechanism, but that seems more
complex to me than just introducing a subsystem and SPI for this purpose.
With a subsystem we could bundle actions for things like mod_cluster,
other potential future Undertow- and Remoting-based proxies, simple
notification schemes like MBean notification or logging, POST
notification, and so on.
The timeline would not be 8 (obviously), nor 9. I think having the
simplified management SPI in place is a definite prerequisite, else the
effort/reward ratio is far too low to justify doing this. Otherwise, I
think this is a simple idea that could be pretty damn useful, so I want
to put it out here so it's in the back of everyone's mind.
--
- DML