<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 7/17/2014 6:28 AM, Emmanuel Hugonnet
wrote:<br>
</div>
<blockquote cite="mid:53C7A544.3000203@redhat.com" type="cite">
<pre wrap="">Well the idea was to avoid log parsing as some service might log errors which are not preventing it to start for example.
Emmanuel</pre>
</blockquote>
"some service might log errors"?<br>
<br>
Do we have a solid use case? I'd like to understand what this is
for.<br>
<br>
<blockquote cite="mid:53C7A544.3000203@redhat.com" type="cite">
<pre wrap="">
Le 15/07/2014 02:23, James R. Perkins a écrit :
</pre>
<blockquote type="cite">
<pre wrap="">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 <a class="moz-txt-link-freetext" href="http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002336.html">http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002336.html</a>.
On 07/10/2014 07:23 AM, Emmanuel Hugonnet wrote:
</pre>
<blockquote type="cite">
<pre wrap=""># Ability to read boot errors via WildFly Management APIs
Tracked by <a class="moz-txt-link-freetext" href="https://issues.jboss.org/browse/WFLY-543">https://issues.jboss.org/browse/WFLY-543</a>
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
<a class="moz-txt-link-abbreviated" href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a>
</pre>
</blockquote>
<pre wrap="">
--
James R. Perkins
JBoss by Red Hat
</pre>
</blockquote>
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
wildfly-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></pre>
</blockquote>
<br>
</body>
</html>