Judy Tang wrote:
> I saw Dies mentioned about FishCAT :-)
Go, FishCAT(s)!
>
> Gail, may be we can think about some good ideas on how to involve
> FishCAT members to test and review GlassFish v3 Error Message Reference.
Definitely. Reviews will be needed (and greatly appreciated!) once the
book is created, after HCF. The book will also be on the wiki, so as
Dies mentioned, there will be an opportunity to add to the content later.
Gail
>
>
> Thanks,
> Judy
>
> Gail Risdal wrote:
>
>> Thanks, Dies. Yes, you are correct. The GlassFish v3 Error Message
>> Reference will be generated from the diagnostic information in the
>> resource bundles (cause/check).
>>
>> The plan is to post the book on docs.sun.com and also in wiki format
>> on the GlassFish wiki. The documentation plan provides a few more
>> details:
>> http://wiki.glassfish.java.net/Wiki.jsp?page=GlassFishV3DocPlanErrMsgRef
>>
>> Gail
>> ++++++
>> GlassFish Documentation
>>
>> Dies Koper wrote:
>>
>>> I think Paul Davies once mentioned that the Messages manual is generated
>>> from the check and diagnostics information in the message property
>>> files. So that's where yours would go:
>>>
>>> http://wiki.glassfish.java.net/Wiki.jsp?page=ErrorMessageReference
>>>
>>> I think a great added advantage of having an online message manual is
>>> that the cause/solution can easily be updated even after the HCF(?)
>>> deadlines or even after a release.
>>> Of course for that to work ALL warning/error messages need to have
>>> some kind of ID (ID number or exception pkg/class?) to index them with.
>>>
>>> In some cases the testers might be in a better position to write this
>>> information as they knew what they were doing when the error occurred.
>>>
>>> Maybe you could get their help (FishCAT and your QA team?) in eagerly
>>> pointing out when they see undocumented messages? They might even be
>>> willing to suggest the Solution part.
>>>
>>> Regards,
>>> Dies
>>>
>>>
>>> Bill Shannon wrote:
>>>
>>>> Right, but the admin console never runs asadmin, right? So how are the
>>>> error messages produced by asadmin going to be visible in the admin
>>>> console?
>>>> These aren't messages that are logged to the log file, these are
>>>> messages
>>>> that are displayed on stdout.
>>>>
>>>>
>>>> Anissa Lam wrote on 9/16/09 10:50 PM:
>>>>
>>>>> Admin console will display the diagnostic causes if one is available.
>>>>> In the logviewer, there is a 'detail' link for each message that when
>>>>> you click on it, will popup a Log Entry Detail Screen. If there
>>>>> is a
>>>>> Message ID for this log message, then there *may* be Diagnostic
>>>>> information displayed as well.
>>>>> GUI calls getDiagnosticChecks() and getDiagnosticCauses() based on
>>>>> this
>>>>> message ID and the module name. Whatever returned will be
>>>>> displayed to
>>>>> the user. However, so far, many of the Message ID is incorrect,
>>>>> and
>>>>> i have never seen one that actually return some diag. info :(
>>>>>
>>>>> Anissa.
>>>>>
>>>>> Bill Shannon wrote:
>>>>>
>>>>>> Thanks for the pointer, Carla. It seems that no one else is doing
>>>>>> a very good job of keeping this information up to date either. :-)
>>>>>>
>>>>>> The CLI doesn't really have the concept of SEVERE, WARNING, etc. so
>>>>>> it's harder to decide which messages deserve message ids.
>>>>>>
>>>>>> If the CLI were to include all the "cause" information in the message
>>>>>> catalog, who would display it and when?
>>>>>>
>>>>>>
>>>>>> Carla Mott wrote on 9/16/09 9:39 PM:
>>>>>>
>>>>>>
>>>>>>> this is important for serviceability requirements. Other modules do
>>>>>>> maintain these tags which are called message ids. The message
>>>>>>> ids and
>>>>>>> corresponding messages will be displayed in by the admin console
>>>>>>> under
>>>>>>> logviewer. See the following page for more info:
>>>>>>>
>>>>>>> http://wiki.glassfish.java.net/Wiki.jsp?page=GlassFishV3LoggingServiceability
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I think that you are right that maintaining the message ids is a
>>>>>>> manual
>>>>>>> process. There are a limited amount of message ids with
>>>>>>> corresponding
>>>>>>> diagnostic messages in the resource bundles at this time.
>>>>>>> Abhijit has
>>>>>>> asked me to follow up with folks and get more of this data in the
>>>>>>> resource bundles, at least for SEVERE and WARNING messages. I think
>>>>>>> that for SEVERE and WARNING messages these should be manageable.
>>>>>>> I know
>>>>>>> that the support folks find this info very helpful.
>>>>>>>
>>>>>>> carla
>>>>>>>
>>>>>>> Bill Shannon wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Some of the error messages from the CLI include message
>>>>>>>> numbers/tags,
>>>>>>>> like "CLI128". It seems that the intent was that customers
>>>>>>>> could look
>>>>>>>> up this tag and get more information about the error.
>>>>>>>>
>>>>>>>> Is this still important?
>>>>>>>>
>>>>>>>> Is anyone other than the CLI maintaining these numbers/tags?
>>>>>>>>
>>>>>>>> Maintaining the numbers/tags is a fair amount of work, especially
>>>>>>>> without any tools to help. And it's not clear that anyone is
>>>>>>>> maintaining
>>>>>>>> the corresponding message database.
>>>>>>>>
>>>>>>>> Should we continue with this? Can we afford it?
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: quality-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: quality-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: quality-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: quality-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: quality-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: quality-help_at_glassfish.dev.java.net
>