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

[Emmanuel Hugonnet]

Well, the users could quickly check the errors with a script instead of searching through the logs or even looking 'manually' in the log viewer.
Of course they could already be doing something with the logs, this aims to be easier to access / use.

Le 17/07/2014 15:01, Stan Silvert a écrit :
> On 7/17/2014 8:44 AM, Stan Silvert wrote:
>> 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.
> 
> I guess I should be more clear about what I don't understand.  I take it that this proposal wants to gather the boot errors so they can be
> accessed by some other process?  What would the process be able to do with the information?
> 
> If the purpose is to let users see the errors then that is already achieved by reading the log.  So I take it that the use cases are not
> user-centric?
> 
>>
>>> 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
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 538 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140717/b95daece/attachment-0001.bin