Hi Gang (Craig McClanahan in particular),

I would like to offer the enclosed patch for the classes in the
org.apache.commons.resources.message package.  This is a very fine package
that provides a nice mechanism for localizing messages maintained in a
properties or XML file.  I noticed that the properties file and XML file is
loaded by the class loader for the PropertyMessageResources or
XMLMessageResources classes or a derived instance of these classes.  Ideally
one should be able to specify the class loader without having to derive
these classes.

I propose the addition of a new factory method in the
MessagesResorucesFactory (and the concrete derivatives) that takes a
ClassLoader as an argument:

    public abstract MessageResources createResources(String config,
ClassLoader classLoader);

I further propose the addition a new constructor for MessageResources and
its concrete derivatives:

    public MessageResources(MessageResourcesFactory factory, String config,
                         boolean returnNull, ClassLoader classLoader)

The MessageResources class is augmented to hold a protected instance
variable with the ClassLoader.  If a class loader is not provided (through
one of the existing constructors), it is obtained from
this.getClass().getClassLoader().

Then, the file input stream in the PropertyMessageResources and
XMLMessageResources is loaded like this:

            is = this.classLoader.getResourceAsStream(name);

where the classLoader instance variable is set from the constructor (and
factory method) or obtained from the class instance (if a class loader was
not explicitly specified).

If we do this, we can rest assured that the properties (or XML) file is
retrieved using the proper class loader.  This is an issue in a J2EE 2.x
application server where the class loader associated with these utilities
(perhaps loaded by the EAR class loader) may not be able to see the resource
bundle property files in (let's say) a Web application.

The enclosed zip file holds the modifications.  Thanks for considering this
patch.  I am sorry if it is not presented in the appropriate format.

 <<message.zip>> 
-- Erik.
Erik K. Worth
Senior Software Engr. / Architect
Altoweb, Inc.
1731 Embarcadero Rd.
Palo Alto, CA 94303
(650) 251-1663
 <<Erik Worth.vcf>> 

message.zip

Erik Worth.vcf

Reply via email to