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

[Stan Silvert]

On 7/17/2014 6:28 AM, Emmanuel Hugonnet wrote:
> Well the idea was to avoid log parsing as some service might log errors which are not preventing it to start for example.
> Emmanuel
"some service might log errors"?

Do we have a solid use case?  I'd like to understand what this is for.

>
> Le 15/07/2014 02:23, James R. Perkins a écrit :
>> I don't see a JIRA for this, but there has been some discussions around log viewing in general. This looks like it might be similar to or
>> possibly the same as http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002336.html.
>>
>> On 07/10/2014 07: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
>> -- 
>> James R. Perkins
>> JBoss by Red Hat
>>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140717/309012a9/attachment.html