It would be great to have a tool to check for some of these style issues
and point out possible errors, but see my previous message on this
subject for some of the challenges. I'm a strong believer is such automated
tools, even the heuristic ones that encourage good style in addition to
strong rules, but I don't think the tool is going to be as easy as you
originally envisioned.
If it turns out that *almost* all messages in LocalStrings.properties
are error messages that should include a message ID, then that seems
like a good thing to check for, but you'll need a way to tag messages
that are exceptions to the general rule.
If you find that there are a lot of exceptions, you'll need to take
a different approach.
Certainly every message that looks like it starts with a message ID
ought to follow some pattern, and the message IDs ought to be unique.
Also, such messages ought to have the corresponding ".diag" entries.
I asked a few months ago about tools to manage message IDs and keep the
source code in sync with the message catalogs. I got some interesting
answers, but haven't yet had time to follow up on them. You might want
to look into such tools as well, and combine your work here with such
a tool.
Sekhar Vajjhala wrote on 10/19/09 9:40 AM:
> I am looking for clarification on the GlassFish V3 message ID syntax :
>
> To develop the tool (discussed in another thread), I started with the
> GlassFish V3 messaging log format described in
> http://wiki.glassfish.java.net/Wiki.jsp?page=GlassFishV3LoggingMessageFormat
>
> . However, that messaging format is not detailed enough - for
> e.g. treatment of white spaces, separator between key value pairs,
> line continuations etc. Since we are looking for messages in
> LogStrings.properties, one assumption I am making is that the syntax
> of the message IDs follows the syntax described in the Java doc for
> Properties (
> http://java.sun.com/javase/6/docs/api/java/util/Properties.html#load%28java.io.Reader%29
>
> ).
>
> Must message ID present in GF V3 resource bundles
> comply with the syntax described in the above javadoc ? Or are there
> different requirements on the syntax ?
>
> The tool currently checks for some of the syntax described in the
> javadoc that I referenced above (and I can add the rest of the checks i.e.
> unless there message ID syntax requirements are different from those in
> the javadoc).
> So the tool will for e.g.
>
> 1. flag an error for text of a message id can be split across multiple
> lines. e.g.
> sgmt.instancehang_hctimeout=SGMT0232: Instance hang check - The
> threshold timeout= {1} specified for server: {0} is l
> ess than the load balancer health checker configured for it. Raising
> this timeout to its load balancer health checker va
> lue of {2}.
>
> 2. Some messages ids have a white space after = e.g.
> enterprise_util.UNIX.error.0 = UTIL9000: UNIX command completed
> successfully.
>
> 3. A space betweeen upppercase message id and number. e.g. ( RAR 7014 )
> below
> error_reading_connectorservice_elt=RAR 7014: Error reading Connector
> Service Element from domain.xml while trying to get
> shutdown-timeout-in-seconds value. Continuing wih the default shutdown
> timeout value
>
> Sekhar Vajjhala
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>