[wildfly-dev] Proposal to read boot errors via WildFly Management APIs

Brian Stansberry brian.stansberry at redhat.com
Thu Jul 10 15:16:37 EDT 2014


What's reported there is a subset of possible management errors during 
boot; i.e. not all errors that can occur during execution of the boot 
ops need to manifest themselves as service failures or missing dependencies.

I also think there needs to be more context; i.e. what management 
operation was being invoked when a problem occurred. We get lots of 
complaints about how users can't understand what our service names mean 
when they try and understand failures. Showing address data doesn't 
solve that completely, but it certainly helps.

On 7/10/14, 9:23 AM, Emmanuel Hugonnet wrote:
> # Ability to read boot errors via  WildFly Management APIs
>
> Tracked by https://issues.jboss.org/browse/WFLY-543
>
> Use Cases
> ---------
>
> If a server starts but reported errors during boot, there is no way to access the error data via the Management API and users are reduced to
> searching the logs.
> This information needs to be captured and stored for later reporting.
> If some problem happens that gets logged at boot but somehow doesn't become visible to the management layer, that's out of scope. A problem
> getting logged but not becoming visible would basically mean some runtime service logged an error but the error didn't prevent the start of
> the service.
>
> Implementation
> --------------
> Create a new sub resource of core-service=service-container because it has the ability to dump services, thus having all the services boot
> errors and missing dependencies near seems like a good place.
> thus we would have :
> core-service => service-container {
> 	boot-errors => {
> 		failures => {
> 			service-name => stackTrace;
> 			....
> 		}
> 		missing-deps => {
> 			... list of missing dependencies as String
> 		}
> 	}
> }
>
> This structure is based on the structure of the failure description returned during verification when starting a service.
> All these informations should be collected in the ModelControllerImpl.
> This resource would have restricted access of course.
>
> What do you think?
>
> Emmanuel
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat


More information about the wildfly-dev mailing list