Hi Tim,
> Hi, Dies. Fixes such as this make a surprising difference in the user's
> experience. Thanks for pursing this.
'pursuing', yes, sorry. ;)
> I've reviewed several of the changes you've proposed - those for which I
> have at least some responsibility! - and as far as I'm concerned the
> ones I've bolded below from your original list look fine to me.
Thanks for your quick and positive response!
Regards,
Dies
> Dies Koper wrote:
>> Hi Gail, Tim, Hong, Jerome, Shalini, Bhakti, Marina, Byron, Ken S.,
>> Shing-Wai, Jagadish, Bobby, Jan, Satish, Sahoo,
>>
>> I've created the following issue for #3 and attached 3 patches to
>> address it.
>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=10884
>>
>> Please review:
>>
>> *App Client(Tim):
>> - appclient/ (msg-ids-typos.patch, msg-local-typos.patch)
>>
>> deployment (Hong):
>> - deployment/ (msg-ids-typos.patch, msg-local-typos.patch)
>>
>> core/kernel (Jerome?):
>> -
>> core/kernel/src/main/resources/com/sun/logging/enterprise/system/core/LogStrings.properties
>>
>> (msg-ids-typos.patch) *
>>
>> JDBC (Shalini):
>> - jdbc/ (msg-ids-typos.patch, msg-local-typos.patch)
>> - common/container-common/ (msg-ids-typos.patch)
>>
>> Web Services (Bhakti):
>> - webservices/jsr109-impl/ (msg-ids-typos.patch)
>>
>> CMP (Marina?):
>> - persistence/cmp/ (msg-cmp-typos.patch, msg-local-typos.patch)
>>
>> JTA/JTS (Marina):
>> - transaction/ (msg-ids-typos.patch, msg-local-typos.patch)
>>
>> flashlight(Byron?):
>> - flashlight/framework/ (msg-ids-typos.patch)
>>
>> *common-util (Byron?): (these are from the payload component which I
>> worked on)
>> - common/common-util/ (msg-ids-typos.patch, msg-local-typos.patch) *
>>
>> Admin launcher (Byron?):
>> - admin/launcher (msg-local-typos.patch)
>>
>> EJB (Ken S.):
>> - ejb/ejb-container (msg-ids-typos.patch)
>>
>> Security (Shing-Wai):
>> - security/core/ (msg-ids-typos.patch, msg-local-typos.patch)
>>
>> Connectors (Jagadish):
>> - connectors/ (msg-ids-typos.patch, msg-local-typos.patch)
>>
>> Upgrade tool (Bobby?):
>> - extras/upgrade/ (msg-local-typos.patch)
>>
>> *Web container (Jan): the web/gui-plugin-common part
>> - web (msg-local-typos.patch) *
>>
>> JMS (Satish):
>> - jms (msg-local-typos.patch)
>>
>> Verifier (Sahoo?):
>> - verifier (msg-local-typos.patch)
>>
>> Thanks!
>> Dies
>>
>>
>> Gail Risdal wrote:
>>> Hi Dies,
>>>
>>> One other thing ...
>>>
>>> I just heard back from the doc tools developer, who says #3 and #4 in
>>> your list would break the tool we're using to harvest the error
>>> messages for the documentation.
>>>
>>> Thanks,
>>> Gail
>>>
>>> Dies Koper wrote:
>>>> Hi,
>>>>
>>>> We had several threads about the messages: that they need message IDs,
>>>> diag info and (not much discussed) be externalized for localization.
>>>> Sekhar has even prepared a tool to help.
>>>>
>>>> Since then I think everybody has been too busy to actually do the work.
>>>>
>>>> I'd like to help out where I can, and already sent out a patch to
>>>> Shalini directly for jdbc, but felt we still have different opinions
>>>> about what to do. I'd like to move the discussion here to explain my
>>>> intentions so that all the module owners for whom I might prepare
>>>> similar patches are in agreement with it.
>>>>
>>>> For now, I'd like to fix the following issues:
>>>>
>>>> 1. Messages with no ID
>>>>
>>>> 2. Typos (just the obvious ones, I'm not a professional proofreader)
>>>>
>>>> 3. Message ID (layout) issues (such as space in "RAR 7014")
>>>>
>>>> 4. Single apostrophes in messages with arguments (see issue #9896)
>>>>
>>>> For most messages I can't supply the diag info, it would take too much
>>>> time to investigate each and find meaningful check/cause explanations.
>>>> Is that okay?
>>>>
>>>> Although from the discussions I understood that message IDs on INFO
>>>> messages are "not required", I did not take it to mean INFO messages
>>>> CANNOT have IDs. In many cases it will be easier for me to just add IDs
>>>> to all messages, as cross-referencing with the logging code to check
>>>> the
>>>> level would take a lot of time. Is that okay?
>>>> (Of course I would be careful not to add IDs to messages that should
>>>> not
>>>> have IDs, and you'll have a chance to double-check when you review the
>>>> patches.)
>>>>
>>>> Also, it is my understanding that the doc team will run a tool at the
>>>> end to pick up all messages from the property files, so I do not
>>>> need to
>>>> worry about updating the docs. Is that correct?
>>>>
>>>> Thanks,
>>>> Dies
>>