Във връзка с въпроса:
Къде (и в какъв ред) се търсят *.properties файловете, когато се зареждат с:
ResourceBundle.getBundle(filename)
се поразрових и преведох следната интересна информация:
1) .properties
файловете се зареждат от classloader
-а, подобно на .java
класовете, т.е. трябва местоположението им да е включено в CLASSPATH
променливата на средата.
2) .properties
файловете имат пълно име (fully-qualified-resource-name), както при .java
класовете, с изключение на това, че не може да се извършва import
на ресурcи (.properties
файлове) в някой .java
клас.
3)
ResourceBundle.getBundle("myBundleProps")
указва на classloader
-a да зареди ресурс с име myBundleProps
в пакета по подразбиране. Това не значи, че ресурса трябва да е в текущия пакет, в който е класа, от който се зарежда.
4)
ResourceBundle.getBundle("package1.package2.package3.myBundleProps")
указва на classloader
-a да зареди ресурс myBundleProps
с пакет package1.package2.package3
. Неговото пълно име (fully-qualified-resource-name) съответно е
package1.package2.package3.myBundleProps
.
Т.е. ако директорийната структура на проекта е следната:
project_path +-- src | +-- package1 | +-- package2 | +-- package3 | +-- TestResourceBundle.java +-- classes +-- package1 +-- package2 +-- package3 +-- TestResourceBundle.class +-- myBundleProps.properties
и ако в TestResourceBundle.java
, ResourceBundel
класa се зарежда със следният код:
ResourceBundle myBundleProps = ResourceBundle.getBundle( "myBundleProps");
е нужно myBundleProps.properties
да се копира в project_path/classes
, на същото директорийно ниво на project1
папката. Като алтернатива може да се пакетира myBundleProps.properties
в един .jar
файл, така че myBundleProps.properties
да е в главната директория в .jar
архива, който няма никакви поддиректории архивирани в него. След това трябва да се добави този .jar
файл в CLASSPATH
променливата на средата.
Ако в TestResourceBundle.java
се зарежда обект от тип ResourceBundel
със следният код:
ResourceBundle myBundleProps = ResourceBundle.getBundle( "package1.package2.package3.myBundleProps");
Тогава е нужно да се копира myBundleProps.properties
в
project_path/classes/package1/package2/package3
. Като алтернатива, може да се сложи
package1/package2/package3/myBundleProps.properties
съответно в един .jar
файл (запазвайки директорийната структура на пакетите и в него) и да се добави този .jar
файл в CLASSPATH
променливата на средата.
Причините за гореописаните начини за употреба на .properties
ресурсни файлове са следните:
1) Прозрачност в локализирането на файла – по време на изпълнение на програмата, myBundleProps.properties
НЕ е файл, той е просто ресурс, който се зарежда. myBundleProps.properties
може да не се съдържа в проекта като цяло, и човека който пише TestResourceBundle.java
може изобщо да не види този ресурс. Един URLClassLoader
може да го намери в мрежовия път или в URL по време на изпълнение. Това специално е важно за server-side компоненти като EJB, Servlet, JSP и т.н., който по принцип нямат достъп до файловата система. При опит да се получи даден ресурс от classloader
, няма значение къде се съхранява съответният ресурс.
2) Mеханизма при работа когато имаш namespaces – конструирайки програмата с пакети, това позволява множество други пакети да съдържат ресурсни файлове (.properties
файлове) със същото кратко име (в случая myBundleProps.properties
) без това да причинява конфликти в цялата работа на системата. Това е като java
пакетите и xml namcesaces
.
[Източник: http://blogs.sun.com/chengfang/entry/p_java_util_missingresourceexception_can]
Is there anybody here?!?
Besides, Shadrik, are you gonna make this Yet Another Programming Blog? Don’t disappoint me this way!!!
Hey Rossi 🙂
I am here 🙂 I was in the back yard and didn’t hear you knocking hahaha 🙂 ;p
How are you doing?
Lately the offline-life is too overloaded and I have no time to drop in around 🙂 But I will try to pass more often around here to take away the spider nets in the corners… you know 😉
About the programming stuff…. well, it is part of my life, and I like it too much, so I have separated a little place in my blog about it too. I know that the topic above is elementary, but while I was fighting with a more complicated problem I found those article in English and liked the way it is related, so I translated it Bulgarian 🙂
Of course I won’t turn this in “another programming blog”, don’t you worry :)) The encapsulation is stuck too deep in my soul, so if I feel some day that the programming topics gain the upper hand over, I will turn them to another blog 😉
Cya for now 🙂