Having state machine which set the state from "Starting" to "Running" after all ressources has been initialized, all deployments are finished and server ports are listening could help to define container "up" mabe. Von meinem iPhone gesendet Am 30.01.2014 um 22:15 schrieb "David M. Lloyd" <david.lloyd(a)redhat.com&gt;: > 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 > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

There is apparently no work going on in any related EE JSR that is covering this? One would think most application servers could benefit from this. On Fri, Jan 31, 2014 at 2:47 AM, David M. Lloyd <david.lloyd(a)redhat.com&gt; wrote: The problem is that deployments may be added and removed at any time, as can other server ports and services. The case that this causes a problem is where a server starts up, mistakenly without an essential deployment, and the server thinks it's "up" but actually a required part is missing, possibly causing the end user to observe a "broken" server. On 01/30/2014 05:54 PM, Rodakr wrote: > Having state machine which set the state from "Starting" to "Running" after all ressources has been initialized, all deployments are finished and server ports are listening could help to define container "up" mabe. > > > > Von meinem iPhone gesendet > > Am 30.01.2014 um 22:15 schrieb "David M. Lloyd" <david.lloyd(a)redhat.com&gt;: > >> 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 >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- - DML _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Nicklas Karlsson, +358 40 5062266 Vaakunatie 10 as 7, 20780 Kaarina _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev