flexibility rules/priority for message IDs, diag info, externalization

[Dies K]

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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Gail Risdal]

Hi Dies,

Regarding your last statement:

"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?"

That's correct. We'll be harvesting the content from the property files
right after HCF and using that for error message documentation.

Gail
++++
GlassFish Docs

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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Gail Risdal]

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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Carla Mott]

Dies,

Message ids can not have a space as that will cause an exception when we
try to use the message id as a key.

If you would like to help that would be great.  I know that Sekhar was
compiling a list of messages and ids that should be added but I don't
have that list.  the thing that needs to be done when adding the message
ids is to figure out which logger is used and make sure that the message
id is unique in the package where it is used.  Sekhar and I thought it
would be easiest to just assign a range of numbers for each module
(actually logger from LogDomains) and that would minimize duplicates.  I
can publish that list tomorrow.  Note that there are cases where will
may not be able to figure out the logger being used and will have to use
come up with a solution.

Let me know if you have questions.

Carla

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
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>  
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Dies K]

Hi Carla,

> Message ids can not have a space as that will cause an exception when we
> try to use the message id as a key.

I noticed a whole bunch of CLI messages with no colon between message ID
and message text. I suppose CLI messages won't go to the log viewer, but
still for consistency I can put the colon in there. What do you think?

> If you would like to help that would be great.  I know that Sekhar was
> compiling a list of messages and ids that should be added but I don't

It's the following, isn't it?
http://wiki.glassfish.java.net/attach/GlassFishV3LoggingServiceability/msgidlist.html

> have that list.  the thing that needs to be done when adding the message
> ids is to figure out which logger is used and make sure that the message
> id is unique in the package where it is used.  Sekhar and I thought it
> would be easiest to just assign a range of numbers for each module
> (actually logger from LogDomains) and that would minimize duplicates.  I
> can publish that list tomorrow.

That would be great.

> Let me know if you have questions.

1. How to assign/determine the 6 character component name part of the
message ID?
    For example, none of the messages in the following property files
have an ID yet.

flashlight\LogStrings.properties
flashlight\impl\client\LogStrings.properties
flashlight\impl\provider\LogStrings.properties
flashlight\xml\LogStrings.properties

    The messages are logged with the following logger:

    MONITORING_LOGGER=DOMAIN_ROOT + "enterprise.system.tools.monitor";

    Could you include the 6 character component name parts in that list?

2. Who can review/approve my changes?
    Do I need to ask each module owner? If so, how do I find out the
owner for example the 'flashlight' files above?
    I searched the following page but it's not there. Also checked the
pom.xml's but no <developer> elements defined.

http://wiki.glassfish.java.net/Wiki.jsp?page=ModulesAndLeads

3. Is it okay to add ID's to messages of all levels or do I need to look
up the message keys in the code to check the level. What if it's INFO?
Can I add it at my own discretion? (of course reviewer can double-check)

4. When I do check the message level and find it's FINE/FINEST, shall I
move the message back from message file to source code?
    I found one of these in JDBC and just e-mailed Shalini about it.
    I prefer hard-coding of FINE messages because I think these messages
are mostly for debugging by/for GF developers, so we need them to be in
English. (Imagine the trouble you'd be in if the message were logged in
Chinese and a user pasted it in the user mailing list asking for help:
Without a message ID you'd have no idea what message it is! (unless you
read Chinese of course)).
    This is b.t.w. another argument for adding message IDs to all INFO
messages too.

5. What do I do with messages that don't seem to be used anymore (can't
find them when I try to grep them in source). Delete and let the
reviewer make the final call?

Sorry for the detailed questions. I don't want to fix them without
consensus and risk not getting my patches approved :)

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
>>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Marina Vatkina]

Dies,

CMP messages had been i18n-ed even for FINE/FINEST levels for a very long time.
The corresponding Bundle.properties clearly mark sections for such messages, so
that they are not translated.

Regards,
-marina

Dies Koper wrote:

> Hi Carla,
>
>> Message ids can not have a space as that will cause an exception when
>> we try to use the message id as a key.
>
>
> I noticed a whole bunch of CLI messages with no colon between message ID
> and message text. I suppose CLI messages won't go to the log viewer, but
> still for consistency I can put the colon in there. What do you think?
>
>> If you would like to help that would be great.  I know that Sekhar was
>> compiling a list of messages and ids that should be added but I don't
>
>
> It's the following, isn't it?
> http://wiki.glassfish.java.net/attach/GlassFishV3LoggingServiceability/msgidlist.html 
>
>
>> have that list.  the thing that needs to be done when adding the
>> message ids is to figure out which logger is used and make sure that
>> the message id is unique in the package where it is used.  Sekhar and
>> I thought it would be easiest to just assign a range of numbers for
>> each module (actually logger from LogDomains) and that would minimize
>> duplicates.  I can publish that list tomorrow.
>
>
> That would be great.
>
>> Let me know if you have questions.
>
>
> 1. How to assign/determine the 6 character component name part of the
> message ID?
>    For example, none of the messages in the following property files
> have an ID yet.
>
> flashlight\LogStrings.properties
> flashlight\impl\client\LogStrings.properties
> flashlight\impl\provider\LogStrings.properties
> flashlight\xml\LogStrings.properties
>
>    The messages are logged with the following logger:
>
>    MONITORING_LOGGER=DOMAIN_ROOT + "enterprise.system.tools.monitor";
>
>    Could you include the 6 character component name parts in that list?
>
> 2. Who can review/approve my changes?
>    Do I need to ask each module owner? If so, how do I find out the
> owner for example the 'flashlight' files above?
>    I searched the following page but it's not there. Also checked the
> pom.xml's but no <developer> elements defined.
>
> http://wiki.glassfish.java.net/Wiki.jsp?page=ModulesAndLeads
>
> 3. Is it okay to add ID's to messages of all levels or do I need to look
> up the message keys in the code to check the level. What if it's INFO?
> Can I add it at my own discretion? (of course reviewer can double-check)
>
> 4. When I do check the message level and find it's FINE/FINEST, shall I
> move the message back from message file to source code?
>    I found one of these in JDBC and just e-mailed Shalini about it.
>    I prefer hard-coding of FINE messages because I think these messages
> are mostly for debugging by/for GF developers, so we need them to be in
> English. (Imagine the trouble you'd be in if the message were logged in
> Chinese and a user pasted it in the user mailing list asking for help:
> Without a message ID you'd have no idea what message it is! (unless you
> read Chinese of course)).
>    This is b.t.w. another argument for adding message IDs to all INFO
> messages too.
>
> 5. What do I do with messages that don't seem to be used anymore (can't
> find them when I try to grep them in source). Delete and let the
> reviewer make the final call?
>
> Sorry for the detailed questions. I don't want to fix them without
> consensus and risk not getting my patches approved :)
>
> 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
>>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Carla Mott]

Hi Dies,

Dies Koper wrote:
> Hi Carla,
>
>> Message ids can not have a space as that will cause an exception when
>> we try to use the message id as a key.
>
> I noticed a whole bunch of CLI messages with no colon between message ID
> and message text. I suppose CLI messages won't go to the log viewer, but
> still for consistency I can put the colon in there. What do you think?

Well, I want the message ids in the LogStrings.properties file because I
use them to get diagnostic info from the same file.  The messages in
LocalStrings.properties don't go to the server log file and I don't
parse that file for more info.  However,  maybe someone in docs might
find that useful.  For now I would prefer that we concentrate on the
LogStrings.properties file first.
>
>> If you would like to help that would be great.  I know that Sekhar was
>> compiling a list of messages and ids that should be added but I don't
>
> It's the following, isn't it?
> http://wiki.glassfish.java.net/attach/GlassFishV3LoggingServiceability/msgidlist.html 
>
This is one of the first steps.  See below.

>
>> have that list.  the thing that needs to be done when adding the
>> message ids is to figure out which logger is used and make sure that
>> the message id is unique in the package where it is used.  Sekhar and
>> I thought it would be easiest to just assign a range of numbers for
>> each module (actually logger from LogDomains) and that would minimize
>> duplicates.  I can publish that list tomorrow.
>
> That would be great.
>
>> Let me know if you have questions.
>
> 1. How to assign/determine the 6 character component name part of the
> message ID?

To assign a message id you will need to figure out which logger is being
used.   A module can use loggers that are not in their area.  For
example a module may use the deployment logger.  I have a list that
shows the prefix or the alpha characters for the different modules.  It
is a bit old so the new stuff is not there but we can add that.  Once
you have the prefix you need a number.  Note that the message id must be
unique within a module.  I was thinking that if we assign modules a
range of numbers then the prefix and the numbers together would
facilitate generating a unique message id.

In the case where the code is not using LogDomains to get the loggers
don't make a change.

I thought I had the ranges figured out and saw some messageids that had
numbers that I had missed.  I need to rework the numbers.


>    For example, none of the messages in the following property files
> have an ID yet.
>
> flashlight\LogStrings.properties
> flashlight\impl\client\LogStrings.properties
> flashlight\impl\provider\LogStrings.properties
> flashlight\xml\LogStrings.properties
these are part of monitoring and is new.  We need to come up with a prefix.

>
>    The messages are logged with the following logger:
>
>    MONITORING_LOGGER=DOMAIN_ROOT + "enterprise.system.tools.monitor";
>
>    Could you include the 6 character component name parts in that list?
>
> 2. Who can review/approve my changes?
>    Do I need to ask each module owner? If so, how do I find out the
> owner for example the 'flashlight' files above?

It would be great if the module owners can review in most cases.  I
think the changes will be low risk but we still need to run quicklook
tests.  The monitoring code is such that it needs to change to make use
of the LogStrings.properties file.

>    I searched the following page but it's not there. Also checked the
> pom.xml's but no <developer> elements defined.
>
> http://wiki.glassfish.java.net/Wiki.jsp?page=ModulesAndLeads
>
> 3. Is it okay to add ID's to messages of all levels or do I need to look
> up the message keys in the code to check the level. What if it's INFO?
> Can I add it at my own discretion? (of course reviewer can double-check)
>
we want to target SEVERE and WARNING first and then work on INFO.

> 4. When I do check the message level and find it's FINE/FINEST, shall I
> move the message back from message file to source code?
nope.  I don't know why the FINE level messages are in the
LogStrings.properties file.  Please write a bug.

>    I found one of these in JDBC and just e-mailed Shalini about it.
>    I prefer hard-coding of FINE messages because I think these messages
> are mostly for debugging by/for GF developers, so we need them to be in
> English. (Imagine the trouble you'd be in if the message were logged in
> Chinese and a user pasted it in the user mailing list asking for help:
> Without a message ID you'd have no idea what message it is! (unless you
> read Chinese of course)).
>    This is b.t.w. another argument for adding message IDs to all INFO
> messages too.
>
> 5. What do I do with messages that don't seem to be used anymore (can't
> find them when I try to grep them in source). Delete and let the
> reviewer make the final call?

write a bug and let the developer clean it up.

>
> Sorry for the detailed questions. I don't want to fix them without
> consensus and risk not getting my patches approved :)
>
> 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
>>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Dies K]

Hi Jan, Byron, Shin-Wai, admin/monitor owner,

I have attached a patch to issue #9896 (issue #4 in my previous list),
please review.

admin/monitor (?):
admin\monitor\src\main\java\org\glassfish\admin\monitor\LogStrings.properties

common-util (Byron?):
common\common-util\src\main\java\com\sun\logging\enterprise\system\tools\launcher\LogStrings.properties
common\common-util\src\main\java\com\sun\logging\enterprise\system\tools\admin\LogStrings.properties
common\common-util\src\main\java\com\sun\logging\enterprise\system\core\selfmanagement\LogStrings.properties

security (Shin-Wai?):
security\core\src\main\resources\com\sun\logging\enterprise\system\core\security\LogStrings.properties

web (Jan):
web\war-util\src\main\resources\com\sun\logging\enterprise\system\container\web\LogStrings.properties

This patch only covers the issues in LogStrings.properties.
I hope to send out a patch review request for the remaining message
files by Monday or Tuesday. If you think you might be too busy to review
a patch then, would you consider authorizing someone (Carla, for
instance, or even just me) to review it so I can commit it before HCF?
Note that the only changes I'm making here are for the single quotes issue.

Thanks,
Dies


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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Dies K]

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?):
- 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):
- 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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Tim Quinn]

Hi, Dies.  Fixes such as this make a surprising difference in the user's experience.  Thanks for pursing this.

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.

- Tim



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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Dies K]

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
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Tim Quinn]

Dies Koper wrote:
> Hi Tim,
>
>> Hi, Dies.  Fixes such as this make a surprising difference in the
>> user's experience.  Thanks for pursing this.
>
> 'pursuing', yes, sorry. ;)
How ironic that I'd commit a typo in my note to you about correcting
typos.

Sigh.  Must...get...away...from...keyboard...

- Tim

>
>> 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
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Dies K]

Hi Carla,

>> 1. How to assign/determine the 6 character component name part of the
>> message ID?
> To assign a message id you will need to figure out which logger is being
> used.   A module can use loggers that are not in their area.  For
> example a module may use the deployment logger.  I have a list that
> shows the prefix or the alpha characters for the different modules.  It
> is a bit old so the new stuff is not there but we can add that.  Once
> you have the prefix you need a number.  Note that the message id must be
> unique within a module.  I was thinking that if we assign modules a
> range of numbers then the prefix and the numbers together would
> facilitate generating a unique message id.

If each module gets its own unique alpha characters, why do you need to
assign number ranges to modules?
Why would a module use another's logger, and whose alpha characters
should its messages be using in this case?

> In the case where the code is not using LogDomains to get the loggers
> don't make a change.

Why? Don't they need to be in the manual?

>> flashlight\LogStrings.properties
>> flashlight\impl\client\LogStrings.properties
>> flashlight\impl\provider\LogStrings.properties
>> flashlight\xml\LogStrings.properties
> these are part of monitoring and is new.  We need to come up with a prefix.

You mentioned a max of 6 characters so "FLASH" seems a good pick.

>>    Do I need to ask each module owner? If so, how do I find out the
>> owner for example the 'flashlight' files above?
> It would be great if the module owners can review in most cases.  I
> think the changes will be low risk but we still need to run quicklook
> tests.  The monitoring code is such that it needs to change to make use
> of the LogStrings.properties file.

Are you thinking of fixing Java code too? (moving from
LocalStrings.properties to LogStrings.properties?)

>> 3. Is it okay to add ID's to messages of all levels or do I need to
>> look up the message keys in the code to check the level. What if it's
>> INFO? Can I add it at my own discretion? (of course reviewer can
>> double-check)
>>
> we want to target SEVERE and WARNING first and then work on INFO.

To do that I'd need to look up every message in the code. I've tried it
for a few and it took ages. Unless you can teach me a trick to do that
faster, I won't be able to help you as I can't spare that much more time
on it.
Besides, including INFO messages from the start would save us that time,
and I haven't heard a convincing argument yet against adding IDs to INFO
messages too. It just seems hopelessly inefficient.

>> 4. When I do check the message level and find it's FINE/FINEST, shall
>> I move the message back from message file to source code?
> nope.  I don't know why the FINE level messages are in the
> LogStrings.properties file.  Please write a bug.

I suppose they were first intended to have INFO level but were deemed
too 'chatty' and had their level reduced later.

>> 5. What do I do with messages that don't seem to be used anymore
>> (can't find them when I try to grep them in source). Delete and let
>> the reviewer make the final call?
> write a bug and let the developer clean it up.

It takes a lot of time to search for the level or use of messages. Then
writing an issue for it... If the developer has time to look at my
issues they might as well have a quick look at Sekhar's list and fix the
issues themselves. I don't see much value of my effort.

There are three other remaining issues we could start working on instead
that would give more bang for the buck:

1. Address the hard-coded warnings and errors (there's so many :()

2. Check and assist projects GF depends on inclusion of message IDs
(hk2, etc.).

3. Look at adding tasks to the build or QL process to automatically
check for these issues to prevent reintroduction of typos, ID-less
messages, hard-coded messages, etc.

Depending on the interest, after proper risk assessment some of 1. could
still be considered for inclusion in V3 post-HCF?

Regards,
Dies


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jagadish Prasath Ramu]

Hi Dies,
Following changes w.r.t connectors, jdbc look fine.
Thanks for taking care of these changes !

msg-local-typos.patch :

jdbc/jdbc-ra/jdbc-core/src/main/java/com/sun/gjc/common/LocalStrings.properties
jdbc/admin/src/main/java/org/glassfish/jdbc/admin/cli/LocalStrings.properties
connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/LocalStrings.properties

msg-ids-typos.patch

jdbc/jdbc-ra/jdbc-core/src/main/java/com/sun/gjc/common/LocalStrings.properties
jdbc/jdbc-ra/jdbc-core/src/main/resources/com/sun/gjc/spi/LogStrings.properties
common/container-common/src/main/resources/org/glassfish/javaee/services/LogStrings.properties
connectors/work-management/src/main/resources/com/sun/enterprise/connectors/work/LogStrings.properties
connectors/connectors-runtime/src/main/resources/com/sun/logging/enterprise/resource/resourceadapter/LogStrings.properties
connectors/connectors-internal-api/src/main/resources/com/sun/appserv/connectors/internal/api/LogStrings.properties

Thanks,
-Jagadish



On Sun, 2009-11-08 at 14:48 +1100, 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?):
> - 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):
> - 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Carla Mott]

Dies Koper wrote:

> Hi Carla,
>
>>> 1. How to assign/determine the 6 character component name part of the
>>> message ID?
>> To assign a message id you will need to figure out which logger is
>> being used.   A module can use loggers that are not in their area.  
>> For example a module may use the deployment logger.  I have a list
>> that shows the prefix or the alpha characters for the different
>> modules.  It is a bit old so the new stuff is not there but we can add
>> that.  Once you have the prefix you need a number.  Note that the
>> message id must be unique within a module.  I was thinking that if we
>> assign modules a range of numbers then the prefix and the numbers
>> together would facilitate generating a unique message id.
>
> If each module gets its own unique alpha characters, why do you need to
> assign number ranges to modules?
> Why would a module use another's logger, and whose alpha characters
> should its messages be using in this case?

It should be easier to get unique numbers because you don't have to scan
the resource bundles (there may be more than one per module).  I picked
numbers that were outside the range of numbers already in use.
>
>> In the case where the code is not using LogDomains to get the loggers
>> don't make a change.
>
> Why? Don't they need to be in the manual?
You right they should go in the manual.  In this case the messages will
not appear in the logs because we have a different algorithm for finding
the resource bundles (we override getResourceBundle).  Not sure why some
code is not using GF's LogDomains.getLogger API.  You should add them
and we can see how to fix that problem.
>
>>> flashlight\LogStrings.properties
>>> flashlight\impl\client\LogStrings.properties
>>> flashlight\impl\provider\LogStrings.properties
>>> flashlight\xml\LogStrings.properties
>> these are part of monitoring and is new.  We need to come up with a
>> prefix.
>
> You mentioned a max of 6 characters so "FLASH" seems a good pick.
OK.  If the monitoring folks want a say they should suggest something.

>
>>>    Do I need to ask each module owner? If so, how do I find out the
>>> owner for example the 'flashlight' files above?
>> It would be great if the module owners can review in most cases.  I
>> think the changes will be low risk but we still need to run quicklook
>> tests.  The monitoring code is such that it needs to change to make
>> use of the LogStrings.properties file.
>
> Are you thinking of fixing Java code too? (moving from
> LocalStrings.properties to LogStrings.properties?)
>
>>> 3. Is it okay to add ID's to messages of all levels or do I need to
>>> look up the message keys in the code to check the level. What if it's
>>> INFO? Can I add it at my own discretion? (of course reviewer can
>>> double-check)
>>>
>> we want to target SEVERE and WARNING first and then work on INFO.
>
> To do that I'd need to look up every message in the code. I've tried it
> for a few and it took ages. Unless you can teach me a trick to do that
> faster, I won't be able to help you as I can't spare that much more time
> on it.
> Besides, including INFO messages from the start would save us that time,
> and I haven't heard a convincing argument yet against adding IDs to INFO
> messages too. It just seems hopelessly inefficient.

There is no trick.  If it is easier to just do all of them.
>
>>> 4. When I do check the message level and find it's FINE/FINEST, shall
>>> I move the message back from message file to source code?
>> nope.  I don't know why the FINE level messages are in the
>> LogStrings.properties file.  Please write a bug.
>
> I suppose they were first intended to have INFO level but were deemed
> too 'chatty' and had their level reduced later.
could be

>
>>> 5. What do I do with messages that don't seem to be used anymore
>>> (can't find them when I try to grep them in source). Delete and let
>>> the reviewer make the final call?
>> write a bug and let the developer clean it up.
>
> It takes a lot of time to search for the level or use of messages. Then
> writing an issue for it... If the developer has time to look at my
> issues they might as well have a quick look at Sekhar's list and fix the
> issues themselves. I don't see much value of my effort.
>
> There are three other remaining issues we could start working on instead
> that would give more bang for the buck:
>
> 1. Address the hard-coded warnings and errors (there's so many :()
>
> 2. Check and assist projects GF depends on inclusion of message IDs
> (hk2, etc.).
>
> 3. Look at adding tasks to the build or QL process to automatically
> check for these issues to prevent reintroduction of typos, ID-less
> messages, hard-coded messages, etc.
>
> Depending on the interest, after proper risk assessment some of 1. could
> still be considered for inclusion in V3 post-HCF?

Yes.  We were thinking about doing #3 after v3 fcs.  All should be
considered for post v3 fcs.

Thanks,
Carla
>
> Regards,
> Dies
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Hong Zhang]

Hi, Dies
   The deployment ones look good, thanks much for taking care of this!

- Hong

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?):
> - 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):
> - 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Dies K]

Hi Hong, Marina, Jerome, Jan, Byron, Satish, Ken, Jagadish, Sahoo,

I've attached another patch (msg-single-quotes-local.patch) with a fix
for the issues in LocalStrings.properties and Bundle.properties; see:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=9896

This is in addition to the msg-single-quotes.patch I asked a review for
two days ago.

- deployment/dol (Hong)
- persistence/cmp (Marina?)
- core/kernel (Jerome?)
- web (Jan)
- admin (Byron)
- jms (Satish)
- ejb (Ken S.)
- connectors (Jagadish)
- verifier (Sahoo?)

Could you give me the OK to commit them?

Thanks,
Dies


Dies Koper wrote:

> Hi Jan, Byron, Shin-Wai, admin/monitor owner,
>
> I have attached a patch to issue #9896 (issue #4 in my previous list),
> please review.
>
> admin/monitor (?):
> admin\monitor\src\main\java\org\glassfish\admin\monitor\LogStrings.properties
>
>
> common-util (Byron?):
> common\common-util\src\main\java\com\sun\logging\enterprise\system\tools\launcher\LogStrings.properties
>
> common\common-util\src\main\java\com\sun\logging\enterprise\system\tools\admin\LogStrings.properties
>
> common\common-util\src\main\java\com\sun\logging\enterprise\system\core\selfmanagement\LogStrings.properties
>
>
> security (Shin-Wai?):
> security\core\src\main\resources\com\sun\logging\enterprise\system\core\security\LogStrings.properties
>
>
> web (Jan):
> web\war-util\src\main\resources\com\sun\logging\enterprise\system\container\web\LogStrings.properties
>
>
> This patch only covers the issues in LogStrings.properties.
> I hope to send out a patch review request for the remaining message
> files by Monday or Tuesday. If you think you might be too busy to review
> a patch then, would you consider authorizing someone (Carla, for
> instance, or even just me) to review it so I can commit it before HCF?
> Note that the only changes I'm making here are for the single quotes issue.
>
> Thanks,
> Dies
>
>
> 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)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Marina Vatkina]

Hi Dies,

msg-cmp-typos.patch is part of the msg-local-typos.patch, right?

All changes for persistence/cmp/ and jta/jts are correct.

Thank you for fixing them!

Regards,
-marina

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?):
> - 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):
> - 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
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Marina Vatkina]

Hi Dies,

persistence/cmp is OK.

ejb needs a separate bug to remove unused messages, but if it's easier to fix
first, go ahead.

thanks,
-marina

Dies Koper wrote:

> Hi Hong, Marina, Jerome, Jan, Byron, Satish, Ken, Jagadish, Sahoo,
>
> I've attached another patch (msg-single-quotes-local.patch) with a fix
> for the issues in LocalStrings.properties and Bundle.properties; see:
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=9896
>
> This is in addition to the msg-single-quotes.patch I asked a review for
> two days ago.
>
> - deployment/dol (Hong)
> - persistence/cmp (Marina?)
> - core/kernel (Jerome?)
> - web (Jan)
> - admin (Byron)
> - jms (Satish)
> - ejb (Ken S.)
> - connectors (Jagadish)
> - verifier (Sahoo?)
>
> Could you give me the OK to commit them?
>
> Thanks,
> Dies
>
>
> Dies Koper wrote:
>
>> Hi Jan, Byron, Shin-Wai, admin/monitor owner,
>>
>> I have attached a patch to issue #9896 (issue #4 in my previous list),
>> please review.
>>
>> admin/monitor (?):
>> admin\monitor\src\main\java\org\glassfish\admin\monitor\LogStrings.properties
>>
>>
>> common-util (Byron?):
>> common\common-util\src\main\java\com\sun\logging\enterprise\system\tools\launcher\LogStrings.properties
>>
>> common\common-util\src\main\java\com\sun\logging\enterprise\system\tools\admin\LogStrings.properties
>>
>> common\common-util\src\main\java\com\sun\logging\enterprise\system\core\selfmanagement\LogStrings.properties
>>
>>
>> security (Shin-Wai?):
>> security\core\src\main\resources\com\sun\logging\enterprise\system\core\security\LogStrings.properties
>>
>>
>> web (Jan):
>> web\war-util\src\main\resources\com\sun\logging\enterprise\system\container\web\LogStrings.properties
>>
>>
>> This patch only covers the issues in LogStrings.properties.
>> I hope to send out a patch review request for the remaining message
>> files by Monday or Tuesday. If you think you might be too busy to
>> review a patch then, would you consider authorizing someone (Carla,
>> for instance, or even just me) to review it so I can commit it before
>> HCF?
>> Note that the only changes I'm making here are for the single quotes
>> issue.
>>
>> Thanks,
>> Dies
>>
>>
>> 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)
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Satish Kumar-11]

Dies Koper wrote:
> Hi Hong, Marina, Jerome, Jan, Byron, Satish, Ken, Jagadish, Sahoo,
>
> I've attached another patch (msg-single-quotes-local.patch) with a fix
> for the issues in LocalStrings.properties and Bundle.properties; see:
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=9896
Hi Dies,

The changes in the JMS module look good. Please go ahead and check-in
the changes.

Thx,
Satish

>
> This is in addition to the msg-single-quotes.patch I asked a review
> for two days ago.
>
> - deployment/dol (Hong)
> - persistence/cmp (Marina?)
> - core/kernel (Jerome?)
> - web (Jan)
> - admin (Byron)
> - jms (Satish)
> - ejb (Ken S.)
> - connectors (Jagadish)
> - verifier (Sahoo?)
>
> Could you give me the OK to commit them?
>
> Thanks,
> Dies
>
>
> Dies Koper wrote:
>> Hi Jan, Byron, Shin-Wai, admin/monitor owner,
>>
>> I have attached a patch to issue #9896 (issue #4 in my previous
>> list), please review.
>>
>> admin/monitor (?):
>> admin\monitor\src\main\java\org\glassfish\admin\monitor\LogStrings.properties
>>
>>
>> common-util (Byron?):
>> common\common-util\src\main\java\com\sun\logging\enterprise\system\tools\launcher\LogStrings.properties
>>
>> common\common-util\src\main\java\com\sun\logging\enterprise\system\tools\admin\LogStrings.properties
>>
>> common\common-util\src\main\java\com\sun\logging\enterprise\system\core\selfmanagement\LogStrings.properties
>>
>>
>> security (Shin-Wai?):
>> security\core\src\main\resources\com\sun\logging\enterprise\system\core\security\LogStrings.properties
>>
>>
>> web (Jan):
>> web\war-util\src\main\resources\com\sun\logging\enterprise\system\container\web\LogStrings.properties
>>
>>
>> This patch only covers the issues in LogStrings.properties.
>> I hope to send out a patch review request for the remaining message
>> files by Monday or Tuesday. If you think you might be too busy to
>> review a patch then, would you consider authorizing someone (Carla,
>> for instance, or even just me) to review it so I can commit it before
>> HCF?
>> Note that the only changes I'm making here are for the single quotes
>> issue.
>>
>> Thanks,
>> Dies
>>
>>
>> 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)
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...