Skip to main content

Please review fix for [Issue 73]

4 replies [Last post]
Anonymous

Hi Vladimir,

please review fix for [Issue 73]: "REGRESSION: error messages from the test
suite are not user friendly". The changeset is:

http://fisheye4.cenqua.com/changelog/cqme/branches/users/skavas/Issue73?...

I'm not aware do we have the policy for the format of error messages in the
exceptions? Now we have slightly knotty error messages dialogs. The dialog
message string ends with colon to be able to provide error message from the
exception after. The exception's message by itself is started from capital
letter. So we have the capital letter after colon. But may be it's OK as I have
no idea what to do when an error message from the chain of exceptions is
displayed.

Thanks,
Alexander

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Vladimir Sizikov

Alexander,

On Mon, Apr 23, 2007 at 06:21:45PM +0400, Alexander Alexeev wrote:
> please review fix for [Issue 73]: "REGRESSION: error messages from the test
> suite are not user friendly". The changeset is:
>
> http://fisheye4.cenqua.com/changelog/cqme/branches/users/skavas/Issue73?...
>
> I'm not aware do we have the policy for the format of error messages in the
> exceptions? Now we have slightly knotty error messages dialogs. The dialog
> message string ends with colon to be able to provide error message from the
> exception after. The exception's message by itself is started from capital
> letter. So we have the capital letter after colon. But may be it's OK as I
> have
> no idea what to do when an error message from the chain of exceptions is
> displayed.

Yeah, looks too complicated. Let's try to simplify things.

First, why would we end up with multiple exceptions during the test
run startup? Why won't we just bail out of start() in
LifeCycleAwareManager.java, as soon as the first exception is
thrown. There is no point of starting new and new services, since we
already know that we are going to cancel the run (since some services
didn't start already). Furthermore, some services could (and will)
depend on other services (and expect that those services are started
successfully). So, if some service fails, attempting to start
additional services that depend on the failing service, could end up
with lots of false errors (for example messaging service could
complain that the communication sevice does not work).

Second, why do we need "The following errors occurred: " text in
LifeCycleAwareManager? The manager should just throw the ServiceFault
with error message it gets from the exception from the sub-component
that cannot start.

So, for example, let's say that some Server cannot start on port 8080,
and throws "SomeServer: Cannot start on port 8080" message. Then the
LifeCycleAwareManager should throw ServiceFault with the very same
message "SomeServer: Cannot start on port 8080".

And that's the message users are going to see. For developers, they
could see more details (including the thread stack) in the logs.

Thanks,
--Vladimir

P.S. We should also somehow protect against the empty/null messages
from the services, and provide reasonable default in such a case.

P.P.S. In stop(), unfortunately, we have to stop _ALL_ services, even
though some of them cannot be stopped. And in stop() there is a
possiblity to have more then one exception. Well, exceptions during
stop are not that frequent and very rarely due to user's
misconfiguration, so we can leave with more complex error messages
from stop().

P.P.P.S. If we are not going to start all services in case when some
service fails, we probably should keep track of which services were
started in order to stop them. Or, we could always stop() ALL
services, no matter whether they were started or not. But then, I
think we should update javadocs for LifeCycleAware and mention that
implementors of this interface should be prepared that sometimes
stop() would be called without previously called start().

To me, it's better to resolve this in our code rather ther force users
to think of these things at all..

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Alexander Alexeev

Hi Vladimir,

I've corrected behavior of LifeCycleAwareManager as you suggested. Please see
the changes on:
http://fisheye4.cenqua.com/changelog/cqme/?cs=733

And I've added statement about behavior of stop() method of LifeCycleAware when
it is called on stopped object. CommToJ2MEService stop() method was changed to
align with new statement. I think more specified contract for the interface very
helpful for interface's clients although this introduce some complication for
interface's implementors.

Thanks,
Alexander

Vladimir Sizikov wrote:
> Alexander,
>
> On Mon, Apr 23, 2007 at 06:21:45PM +0400, Alexander Alexeev wrote:
>> please review fix for [Issue 73]: "REGRESSION: error messages from the test
>> suite are not user friendly". The changeset is:
>>
>> http://fisheye4.cenqua.com/changelog/cqme/branches/users/skavas/Issue73?...
>>
>> I'm not aware do we have the policy for the format of error messages in the
>> exceptions? Now we have slightly knotty error messages dialogs. The dialog
>> message string ends with colon to be able to provide error message from the
>> exception after. The exception's message by itself is started from capital
>> letter. So we have the capital letter after colon. But may be it's OK as I
>> have
>> no idea what to do when an error message from the chain of exceptions is
>> displayed.
>
> Yeah, looks too complicated. Let's try to simplify things.
>
> First, why would we end up with multiple exceptions during the test
> run startup? Why won't we just bail out of start() in
> LifeCycleAwareManager.java, as soon as the first exception is
> thrown. There is no point of starting new and new services, since we
> already know that we are going to cancel the run (since some services
> didn't start already). Furthermore, some services could (and will)
> depend on other services (and expect that those services are started
> successfully). So, if some service fails, attempting to start
> additional services that depend on the failing service, could end up
> with lots of false errors (for example messaging service could
> complain that the communication sevice does not work).
>
> Second, why do we need "The following errors occurred: " text in
> LifeCycleAwareManager? The manager should just throw the ServiceFault
> with error message it gets from the exception from the sub-component
> that cannot start.
>
> So, for example, let's say that some Server cannot start on port 8080,
> and throws "SomeServer: Cannot start on port 8080" message. Then the
> LifeCycleAwareManager should throw ServiceFault with the very same
> message "SomeServer: Cannot start on port 8080".
>
> And that's the message users are going to see. For developers, they
> could see more details (including the thread stack) in the logs.
>
> Thanks,
> --Vladimir
>
> P.S. We should also somehow protect against the empty/null messages
> from the services, and provide reasonable default in such a case.
>
> P.P.S. In stop(), unfortunately, we have to stop _ALL_ services, even
> though some of them cannot be stopped. And in stop() there is a
> possiblity to have more then one exception. Well, exceptions during
> stop are not that frequent and very rarely due to user's
> misconfiguration, so we can leave with more complex error messages
> from stop().
>
> P.P.P.S. If we are not going to start all services in case when some
> service fails, we probably should keep track of which services were
> started in order to stop them. Or, we could always stop() ALL
> services, no matter whether they were started or not. But then, I
> think we should update javadocs for LifeCycleAware and mention that
> implementors of this interface should be prepared that sometimes
> stop() would be called without previously called start().
>
> To me, it's better to resolve this in our code rather ther force users
> to think of these things at all..
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Vladimir Sizikov

Hi Alexander,

The changes look good. I'd improve the javadoc for start() method, it
doesn't look right:
"The start() method for each LifeCycleAware
is invoked prior to the first an
Exception or all objects started."

How about:

"Any exception thrown when the registered objects are being started,
terminates the process and the remaining objects are not started."

Thanks,
--Vladimir

On Wed, Apr 25, 2007 at 01:55:51PM +0400, Alexander Alexeev wrote:
> Hi Vladimir,
>
> I've corrected behavior of LifeCycleAwareManager as you suggested. Please
> see
> the changes on:
> http://fisheye4.cenqua.com/changelog/cqme/?cs=733
>
> And I've added statement about behavior of stop() method of LifeCycleAware
> when
> it is called on stopped object. CommToJ2MEService stop() method was changed
> to
> align with new statement. I think more specified contract for the interface
> very
> helpful for interface's clients although this introduce some complication
> for
> interface's implementors.
>
> Thanks,
> Alexander
>
> Vladimir Sizikov wrote:
> >Alexander,
> >
> >On Mon, Apr 23, 2007 at 06:21:45PM +0400, Alexander Alexeev wrote:
> >>please review fix for [Issue 73]: "REGRESSION: error messages from the
> >>test suite are not user friendly". The changeset is:
> >>
> >>http://fisheye4.cenqua.com/changelog/cqme/branches/users/skavas/Issue73?cs=711
> >>
> >>I'm not aware do we have the policy for the format of error messages in
> >>the
> >>exceptions? Now we have slightly knotty error messages dialogs. The dialog
> >>message string ends with colon to be able to provide error message from
> >>the
> >>exception after. The exception's message by itself is started from capital
> >>letter. So we have the capital letter after colon. But may be it's OK as
> >>I have
> >>no idea what to do when an error message from the chain of exceptions is
> >>displayed.
> >
> >Yeah, looks too complicated. Let's try to simplify things.
> >
> >First, why would we end up with multiple exceptions during the test
> >run startup? Why won't we just bail out of start() in
> >LifeCycleAwareManager.java, as soon as the first exception is
> >thrown. There is no point of starting new and new services, since we
> >already know that we are going to cancel the run (since some services
> >didn't start already). Furthermore, some services could (and will)
> >depend on other services (and expect that those services are started
> >successfully). So, if some service fails, attempting to start
> >additional services that depend on the failing service, could end up
> >with lots of false errors (for example messaging service could
> >complain that the communication sevice does not work).
> >
> >Second, why do we need "The following errors occurred: " text in
> >LifeCycleAwareManager? The manager should just throw the ServiceFault
> >with error message it gets from the exception from the sub-component
> >that cannot start.
> >
> >So, for example, let's say that some Server cannot start on port 8080,
> >and throws "SomeServer: Cannot start on port 8080" message. Then the
> >LifeCycleAwareManager should throw ServiceFault with the very same
> >message "SomeServer: Cannot start on port 8080".
> >
> >And that's the message users are going to see. For developers, they
> >could see more details (including the thread stack) in the logs.
> >
> >Thanks,
> > --Vladimir
> >
> >P.S. We should also somehow protect against the empty/null messages
> >from the services, and provide reasonable default in such a case.
> >
> >P.P.S. In stop(), unfortunately, we have to stop _ALL_ services, even
> >though some of them cannot be stopped. And in stop() there is a
> >possiblity to have more then one exception. Well, exceptions during
> >stop are not that frequent and very rarely due to user's
> >misconfiguration, so we can leave with more complex error messages
> >from stop().
> >
> >P.P.P.S. If we are not going to start all services in case when some
> >service fails, we probably should keep track of which services were
> >started in order to stop them. Or, we could always stop() ALL
> >services, no matter whether they were started or not. But then, I
> >think we should update javadocs for LifeCycleAware and mention that
> >implementors of this interface should be prepared that sometimes
> >stop() would be called without previously called start().
> >
> >To me, it's better to resolve this in our code rather ther force users
> >to think of these things at all..
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> >For additional commands, e-mail: meframework-help@cqme.dev.java.net
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Alexander Alexeev

Hi Vladimir,

thanks for review. I've incorporated your javadoc and committed changes.

Thanks,
Alexander

Vladimir Sizikov wrote:
> Hi Alexander,
>
> The changes look good. I'd improve the javadoc for start() method, it
> doesn't look right:
> "The start() method for each LifeCycleAware
> is invoked prior to the first an
> Exception or all objects started."
>
> How about:
>
> "Any exception thrown when the registered objects are being started,
> terminates the process and the remaining objects are not started."
>
> Thanks,
> --Vladimir
>
> On Wed, Apr 25, 2007 at 01:55:51PM +0400, Alexander Alexeev wrote:
>> Hi Vladimir,
>>
>> I've corrected behavior of LifeCycleAwareManager as you suggested. Please
>> see
>> the changes on:
>> http://fisheye4.cenqua.com/changelog/cqme/?cs=733
>>
>> And I've added statement about behavior of stop() method of LifeCycleAware
>> when
>> it is called on stopped object. CommToJ2MEService stop() method was changed
>> to
>> align with new statement. I think more specified contract for the interface
>> very
>> helpful for interface's clients although this introduce some complication
>> for
>> interface's implementors.
>>
>> Thanks,
>> Alexander
>>
>> Vladimir Sizikov wrote:
>>> Alexander,
>>>
>>> On Mon, Apr 23, 2007 at 06:21:45PM +0400, Alexander Alexeev wrote:
>>>> please review fix for [Issue 73]: "REGRESSION: error messages from the
>>>> test suite are not user friendly". The changeset is:
>>>>
>>>> http://fisheye4.cenqua.com/changelog/cqme/branches/users/skavas/Issue73?...
>>>>
>>>> I'm not aware do we have the policy for the format of error messages in
>>>> the
>>>> exceptions? Now we have slightly knotty error messages dialogs. The dialog
>>>> message string ends with colon to be able to provide error message from
>>>> the
>>>> exception after. The exception's message by itself is started from capital
>>>> letter. So we have the capital letter after colon. But may be it's OK as
>>>> I have
>>>> no idea what to do when an error message from the chain of exceptions is
>>>> displayed.
>>> Yeah, looks too complicated. Let's try to simplify things.
>>>
>>> First, why would we end up with multiple exceptions during the test
>>> run startup? Why won't we just bail out of start() in
>>> LifeCycleAwareManager.java, as soon as the first exception is
>>> thrown. There is no point of starting new and new services, since we
>>> already know that we are going to cancel the run (since some services
>>> didn't start already). Furthermore, some services could (and will)
>>> depend on other services (and expect that those services are started
>>> successfully). So, if some service fails, attempting to start
>>> additional services that depend on the failing service, could end up
>>> with lots of false errors (for example messaging service could
>>> complain that the communication sevice does not work).
>>>
>>> Second, why do we need "The following errors occurred: " text in
>>> LifeCycleAwareManager? The manager should just throw the ServiceFault
>>> with error message it gets from the exception from the sub-component
>>> that cannot start.
>>>
>>> So, for example, let's say that some Server cannot start on port 8080,
>>> and throws "SomeServer: Cannot start on port 8080" message. Then the
>>> LifeCycleAwareManager should throw ServiceFault with the very same
>>> message "SomeServer: Cannot start on port 8080".
>>>
>>> And that's the message users are going to see. For developers, they
>>> could see more details (including the thread stack) in the logs.
>>>
>>> Thanks,
>>> --Vladimir
>>>
>>> P.S. We should also somehow protect against the empty/null messages
>> >from the services, and provide reasonable default in such a case.
>>> P.P.S. In stop(), unfortunately, we have to stop _ALL_ services, even
>>> though some of them cannot be stopped. And in stop() there is a
>>> possiblity to have more then one exception. Well, exceptions during
>>> stop are not that frequent and very rarely due to user's
>>> misconfiguration, so we can leave with more complex error messages
>> >from stop().
>>> P.P.P.S. If we are not going to start all services in case when some
>>> service fails, we probably should keep track of which services were
>>> started in order to stop them. Or, we could always stop() ALL
>>> services, no matter whether they were started or not. But then, I
>>> think we should update javadocs for LifeCycleAware and mention that
>>> implementors of this interface should be prepared that sometimes
>>> stop() would be called without previously called start().
>>>
>>> To me, it's better to resolve this in our code rather ther force users
>>> to think of these things at all..
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
>>> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net