You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Karan Malhi <ka...@gmail.com> on 2007/08/22 20:43:03 UTC
[THOUGHT] Annotating Messages.properties
Someday maybe an annotated version like:
# @class(EnvEntriesPropertiesDeployer)
#@method(foo)
#debug("envprops.override", componentName, entry.getName(),
entry.getEnvEntryValue(), newEntry.getEnvEntryValue());
envprops.override = Overriding env-entry(name '{1}', old-value='{2}',
new-value='{3}'), Bean='{0}'
# @method(bar)
#debug("envprops.add", componentName, newEntry.getName(),
newEntry.getEnvEntryValue());
envprops.add = Adding env-entry(name='{1}', value='{2}',
type='java.lang.String'), Bean='{0}'
Just a thought. I know it might seem like an overkill, but its so easy
to read ;)
On 8/22/07, Karan Malhi <ka...@gmail.com> wrote:
> I really liked the way the properties were added to the
> Messages.properties file i.e. with th e actual code commented out
> above the property and also mentioning the log level and the class
> name. Becomes so much easier to read the messages in the properties
> file and relate them back to the actual line in code which the message
> is for.
>
> On 8/22/07, dblevins@apache.org <db...@apache.org> wrote:
> > Author: dblevins
> > Date: Wed Aug 22 10:22:39 2007
> > New Revision: 568707
> >
> > URL: http://svn.apache.org/viewvc?rev=568707&view=rev
> > Log:
> > Adding i18n messages to EnvEntriesPropertiesDeployer
> >
> > Modified:
> > openejb/trunk/openejb3/container/openejb-core/src/main/java/org/apache/openejb/config/EnvEntriesPropertiesDeployer.java
> > openejb/trunk/openejb3/container/openejb-core/src/main/resources/org/apache/openejb/config/Messages.properties
> >
> > Modified: openejb/trunk/openejb3/container/openejb-core/src/main/java/org/apache/openejb/config/EnvEntriesPropertiesDeployer.java
> > URL: http://svn.apache.org/viewvc/openejb/trunk/openejb3/container/openejb-core/src/main/java/org/apache/openejb/config/EnvEntriesPropertiesDeployer.java?rev=568707&r1=568706&r2=568707&view=diff
> > ==============================================================================
> > --- openejb/trunk/openejb3/container/openejb-core/src/main/java/org/apache/openejb/config/EnvEntriesPropertiesDeployer.java (original)
> > +++ openejb/trunk/openejb3/container/openejb-core/src/main/java/org/apache/openejb/config/EnvEntriesPropertiesDeployer.java Wed Aug 22 10:22:39 2007
> > @@ -111,7 +111,7 @@
> >
> > return new HashMap(envEntriesProps);
> > } catch (IOException e) {
> > - log.error("envprops.notLoaded", e, propsUrl.toExternalForm());
> > + log.error("envprops.notLoaded", e, module.getModuleId(), propsUrl.toExternalForm());
> > return Collections.EMPTY_MAP;
> > }
> > }
> >
> > Modified: openejb/trunk/openejb3/container/openejb-core/src/main/resources/org/apache/openejb/config/Messages.properties
> > URL: http://svn.apache.org/viewvc/openejb/trunk/openejb3/container/openejb-core/src/main/resources/org/apache/openejb/config/Messages.properties?rev=568707&r1=568706&r2=568707&view=diff
> > ==============================================================================
> > --- openejb/trunk/openejb3/container/openejb-core/src/main/resources/org/apache/openejb/config/Messages.properties (original)
> > +++ openejb/trunk/openejb3/container/openejb-core/src/main/resources/org/apache/openejb/config/Messages.properties Wed Aug 22 10:22:39 2007
> > @@ -43,4 +43,14 @@
> > cmd.deploy.destExists = Application already deployed at '{1}'
> >
> > # throw new DeploymentTerminatedException(messages.format("cmd.deploy.cantCopy", file.getAbsolutePath(), destFile.getAbsolutePath()));
> > -cmd.deploy.cantCopy = Unable to copy application to '{1}'. Check that the directory is writable and that there is enough disk space.
> > \ No newline at end of file
> > +cmd.deploy.cantCopy = Unable to copy application to '{1}'. Check that the directory is writable and that there is enough disk space.
> > +
> > +# EnvEntriesPropertiesDeployer
> > +# debug("envprops.override", componentName, entry.getName(), entry.getEnvEntryValue(), newEntry.getEnvEntryValue());
> > +envprops.override = Overriding env-entry(name '{1}', old-value='{2}', new-value='{3}'), Bean='{0}'
> > +
> > +# debug("envprops.add", componentName, newEntry.getName(), newEntry.getEnvEntryValue());
> > +envprops.add = Adding env-entry(name='{1}', value='{2}', type='java.lang.String'), Bean='{0}'
> > +
> > +# error("envprops.notLoaded", e, module.getModuleId(), propsUrl.toExternalForm());
> > +envprops.notLoaded = Could not load META-INF/env-entries.properties for module '{0}'.
> > \ No newline at end of file
> >
> >
> >
>
>
> --
> Karan Singh Malhi
>
--
Karan Singh Malhi
Re: [THOUGHT] Annotating Messages.properties
Posted by Karan Malhi <ka...@gmail.com>.
> "I wonder if we couldn't put i18n messages in
> annotations of a package-info.java file"
I just cannot get this one out of my head now, keep thinking about it
and I am getting all crazy ideas of using this one ;)
Compile time checking of message keys, no need to catch Exceptions
(MissingResourceExceptions -- resource checked at compile time), no
need to maintain a separate cache (classloading will take care of
loading static fields (keys+messages) are probably the biggest
benefits I can see here. This basically means that you cannot log a
message whose key is not available in package-info.java.
--
Karan Singh Malhi
Re: [THOUGHT] Annotating Messages.properties
Posted by David Blevins <da...@visi.com>.
On Aug 22, 2007, at 1:21 PM, Karan Malhi wrote:
> I agree, not much value over what David Blevins is doing. I was just
> thinking about something where we could parse annotations and generate
> some reports, but on later thoughts , I dropped the idea . This may
> become too cumbersome.
>
> So, just ignore my email ;).
Half-baked ideas are the best kind :)
Like this, ... "I wonder if we couldn't put i18n messages in
annotations of a package-info.java file" Why would someone want to
do that? I have no idea, but maybe someday I'll think of one.
-David
Re: [THOUGHT] Annotating Messages.properties
Posted by Karan Malhi <ka...@gmail.com>.
> No, no, no. Don't get me wrong. Only because I can't understand it
> should not be the reason to drop the idea. I'd appreciate if you
> explained it a bit more.
I absolutely did not get you wrong. So please don't worry about it. I
just thought it might be much neater to also put method names before
the property names in the file. I just picked annotation as a
mechanism. I was thinking that maybe someday it might help me in
finding the diff between messages which we log, but which are missing
the keys in the properties file (by writing some kind of an annotation
parser). I think there are much more simpler ways to do it. I just
need to add a little convenience method to the logger class and it
will spit out everything for me.
Thats why I said that on second thoughts, this idea just adds more
verbosity and makes the process of adding a message more cumbersome.
--
Karan Singh Malhi
Re: [THOUGHT] Annotating Messages.properties
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 8/22/07, Karan Malhi <ka...@gmail.com> wrote:
> I agree, not much value over what David Blevins is doing. I was just
> thinking about something where we could parse annotations and generate
> some reports, but on later thoughts , I dropped the idea . This may
> become too cumbersome.
>
> So, just ignore my email ;).
No, no, no. Don't get me wrong. Only because I can't understand it
should not be the reason to drop the idea. I'd appreciate if you
explained it a bit more.
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: [THOUGHT] Annotating Messages.properties
Posted by Karan Malhi <ka...@gmail.com>.
I agree, not much value over what David Blevins is doing. I was just
thinking about something where we could parse annotations and generate
some reports, but on later thoughts , I dropped the idea . This may
become too cumbersome.
So, just ignore my email ;).
On 8/22/07, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
> On 8/22/07, Karan Malhi <ka...@gmail.com> wrote:
> > Someday maybe an annotated version like:
> >
> > # @class(EnvEntriesPropertiesDeployer)
> >
> > #@method(foo)
> > #debug("envprops.override", componentName, entry.getName(),
> > entry.getEnvEntryValue(), newEntry.getEnvEntryValue());
> >
> > envprops.override = Overriding env-entry(name '{1}', old-value='{2}',
> > new-value='{3}'), Bean='{0}'
> >
> > # @method(bar)
> > #debug("envprops.add", componentName, newEntry.getName(),
> > newEntry.getEnvEntryValue());
> > envprops.add = Adding env-entry(name='{1}', value='{2}',
> > type='java.lang.String'), Bean='{0}'
> >
> > Just a thought. I know it might seem like an overkill, but its so easy
> > to read ;)
>
> I can't see a value in this proposal. Can you describe a bit more how
> it could help? You want a message file (like a class) to be annotated.
> Some class would read the values from these annotations and...that's
> where I miss the point. Messages.properties doesn't have to be a file
> - it can be a property class instead (see java.util.ResourceBundle
> [1]).
>
> [1] http://java.sun.com/j2se/1.5.0/docs/api/java/util/ResourceBundle.html
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.JacekLaskowski.pl
>
--
Karan Singh Malhi
Re: [THOUGHT] Annotating Messages.properties
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 8/22/07, Karan Malhi <ka...@gmail.com> wrote:
> Someday maybe an annotated version like:
>
> # @class(EnvEntriesPropertiesDeployer)
>
> #@method(foo)
> #debug("envprops.override", componentName, entry.getName(),
> entry.getEnvEntryValue(), newEntry.getEnvEntryValue());
>
> envprops.override = Overriding env-entry(name '{1}', old-value='{2}',
> new-value='{3}'), Bean='{0}'
>
> # @method(bar)
> #debug("envprops.add", componentName, newEntry.getName(),
> newEntry.getEnvEntryValue());
> envprops.add = Adding env-entry(name='{1}', value='{2}',
> type='java.lang.String'), Bean='{0}'
>
> Just a thought. I know it might seem like an overkill, but its so easy
> to read ;)
I can't see a value in this proposal. Can you describe a bit more how
it could help? You want a message file (like a class) to be annotated.
Some class would read the values from these annotations and...that's
where I miss the point. Messages.properties doesn't have to be a file
- it can be a property class instead (see java.util.ResourceBundle
[1]).
[1] http://java.sun.com/j2se/1.5.0/docs/api/java/util/ResourceBundle.html
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl