9:23 a.m.
# 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
2:02 p.m.
You can read the error messages with the read-log-file operation. Does
that not meet the requirements?
/subsystem=logging/:read-log-file(name=server.log,lines=500,skip=0,tail=false)
On 7/10/2014 10: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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
2:16 p.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
2:41 p.m.
On 07/10/2014 09: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.
I think this makes more sense as an operation than a resource - i.e.
"give me all the boot errors" => "okay, here you go as a big
list".
The rule of thumb (for me) is that a resource typically corresponds to
one or more services.
--
- DML
3:02 a.m.
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
4:58 a.m.
On 11 Jul 2014, at 09:02, Emmanuel Hugonnet <ehugonne(a)redhat.com> wrote:
So we could have something like :
boot-errors => {
boot-error => {
operation => operationModelNode.asString(); or should we clone the whole operation
modelNode ?
I think it is better to use it as the 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
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
9:24 a.m.
On 7/11/14, 3:02 AM, Emmanuel Hugonnet wrote:
So we could have something like :
boot-errors => {
boot-error => {
operation => operationModelNode.asString();
For this structure to work, it would need to be a list.
boot-errors => [ {
operation => ...
...
},
{
operations => ...
}
]
That's a list whose elements are complex items.
A hassle here is we are working to get rid of such attributes and
convert them to child resources. To do that though we'd need
1) to have those be child resources, we'd need some id for each boot
error. I don't really see a pure one; the best I can think of would be a
CLI-syntax like conversion of the operation address and name.
2) we need some solid way of provide a list-like ordered semantic for
child resources.
The latter is a big issue that should not block this, so I don't think
you should work initially toward child resources, and instead toward a list.
or should we clone the whole operation modelNode ?
We should make the ModelNode structure available. (Aside: we'll need to
sanitize it for RBAC unless we make all this data security sensitive.)
failures => {
service-name => stackTrace;
....
};
missing-deps => list of missing dependencies as String;
};
You can't count on there being that kind of data for individual boot
operations. When all the Stage.RUNTIME steps have run, that kind of data
is gathered for the overall large set of boot ops (see [1]) but not for
each individual boot op, which are just steps processed by the
OperationContext. The data available for each step is just any exception
thrown by the OperationStepHandler or any data it provides using
OperationContext.getFailureDescription(). See [2].
};
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 ?
What are the chances a caller would call that and then not read the
errors if there are any? There's a bit of value (smaller payload) if
there will be such callers.
I suspect what any such caller would more likely want though would be
some representation of the current state vs the boot state. The
"failures => ..., missing-deps =>" data, but currently rather than what
happened at boot.
[1]
https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j...
[2]
https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j...
for the exception case and just a bit above,
https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j...
for the getFailureDescription() case.
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
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
10:12 a.m.
On 7/14/14, 9:24 AM, Brian Stansberry wrote:
On 7/11/14, 3:02 AM, Emmanuel Hugonnet wrote:
> So we could have something like :
> boot-errors => {
> boot-error => {
> operation => operationModelNode.asString();
For this structure to work, it would need to be a list.
boot-errors => [ {
operation => ...
...
},
{
operations => ...
}
]
That's a list whose elements are complex items.
A hassle here is we are working to get rid of such attributes and
convert them to child resources. To do that though we'd need
1) to have those be child resources, we'd need some id for each boot
error. I don't really see a pure one; the best I can think of would be a
CLI-syntax like conversion of the operation address and name.
2) we need some solid way of provide a list-like ordered semantic for
child resources.
The latter is a big issue that should not block this, so I don't think
you should work initially toward child resources, and instead toward a
list.
I was chatting a bit with David and he kindly pointed out that this
doesn't have to be a resource or attribute at all; it can just be an
operation response.
> or should we clone the whole operation modelNode ?
We should make the ModelNode structure available. (Aside: we'll need to
sanitize it for RBAC unless we make all this data security sensitive.)
> failures => {
> service-name => stackTrace;
> ....
> };
> missing-deps => list of missing dependencies as String;
> };
You can't count on there being that kind of data for individual boot
operations. When all the Stage.RUNTIME steps have run, that kind of data
is gathered for the overall large set of boot ops (see [1]) but not for
each individual boot op, which are just steps processed by the
OperationContext. The data available for each step is just any exception
thrown by the OperationStepHandler or any data it provides using
OperationContext.getFailureDescription(). See [2].
> };
> 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 ?
What are the chances a caller would call that and then not read the
errors if there are any? There's a bit of value (smaller payload) if
there will be such callers.
I suspect what any such caller would more likely want though would be
some representation of the current state vs the boot state. The
"failures => ..., missing-deps =>" data, but currently rather than what
happened at boot.
[1]
https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j...
[2]
https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j...
for the exception case and just a bit above,
https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j...
for the getFailureDescription() case.
>
> 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
>>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
8:21 a.m.
On 07/10/2014 10: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?
Should the application server terminate (with a failure code) when
errors occur during boot? This might make it more obvious that the
server didn't start correctly and that logs should be scanned for the
cause.
Emmanuel
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
9:33 a.m.
On 7/11/14, 8:21 AM, Scott Marlow wrote:
On 07/10/2014 10:23 AM, Emmanuel Hugonnet wrote:
Should the application server terminate (with a failure code) when
errors occur during boot? This might make it more obvious that the
server didn't start correctly and that logs should be scanned for the
cause.
At some point we'll offer an option for that, but I don't see it
becoming our only mode of operation.
Personally, I don't like having the default being continuing to run
"normally."
Brainstorming a bit, I could also see having the server switch into
admin-only mode instead of terminating.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
7:23 p.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
James R. Perkins
JBoss by Red Hat
5:28 a.m.
Well the idea was to avoid log parsing as some service might log errors which are not
preventing it to start for example.
Emmanuel
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
James R. Perkins
JBoss by Red Hat
7:44 a.m.
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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> --
> James R. Perkins
> JBoss by Red Hat
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
8:01 a.m.
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
ashttp://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 byhttps://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
>> --
>> James R. Perkins
>> JBoss by Red Hat
>>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
10:43 a.m.
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(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> --
>>> James R. Perkins
>>> JBoss by Red Hat
>>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
10:35 a.m.
On 07/17/2014 03: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
Excellent. Just wanted to make sure we weren't going to duplicate work
:)
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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> --
> James R. Perkins
> JBoss by Red Hat
>
--
James R. Perkins
JBoss by Red Hat
3816
days inactive
3823
days old
17 comments
8 participants
participants (8)
-
Brian Stansberry -
David M. Lloyd -
Emmanuel Hugonnet -
Heiko Braun -
James R. Perkins -
Kabir Khan -
Scott Marlow -
Stan Silvert