So we could have something like :
boot-errors => {
boot-error => {
operation => operationModelNode.asString(); or should we clone the whole operation
modelNode ?
failures => {
service-name => stackTrace;
....
};
missing-deps => list of missing dependencies as String;
};
};
returned from a read-boot-errors operation.
I'm wondering also if we should have a "has-boot-errors" operation which
would be useful to just display/check the status ?
Emmanuel
Le 10/07/2014 16:23, Emmanuel Hugonnet a écrit :
# 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev