STRUTS2 series: (25) Internationalization (iii) Textprovider How to search for Resoucebundle locations

1, Struts2 the default Textprovider search Resoucebundle (order) location

Struts 2 default Textprovider resourcebundle location algorithm

In the previous case, we saw that the properties were named the same as the Aciton class and placed under the same package, but this is the simplest way to place the properties file.

We ' ve already seen that the framework looks for bundles that match the name of the your current action class. But it is just the tip of the iceberg.  We'll try to provide a clear outline of the process the framework ' s default Textprovider goes through  When locating resourcebundles. It ' s a rich model. Essentially, Struts 2 leaves the door wide open for your distribute the localized text of your application in about any The to-do see fit.

In addition to the simplest approach mentioned above, the default implementation of the Textprovider interface (which should be the Actionsupport Class) will search for several well-known location. These positions follow similar naming pattern.

In addition to the action-class–named Resourcebundles, the default implementation of Textprovider searches in several othe R "well-known" locations for bundles this might ' ve been created by the developer. Many of these locations follow a similar naming pattern based on the names of Superclasses and implemented interfaces. The following sequence shows the name and derivation of the resourcebundles that Struts 2 attempts to load:

Order: The parent class of the interface--> implementation of the current action class--implemented-->modeldriven-->package.properties-->domain model-- >global Bundles

1 actionclass-is there a resourcebundle with the same name as the current action class? In other words, was there a set of properties files like Actionclass.properties, Actionclass_en_us.properties, a nd so forth?

2 myinterface-if Your action implements any interfaces, is there resourcebundles associated with Thos  E interfaces? In other words, if the current class implements MyInterface, was there a set of properties files like MyInt  Erface.properties, myinterface_en_us.properties, and so forth? Superinterfaces of each interface would also be searched accordingly, with more specific interfaces taking precedence over Superinterfaces.

3 mysuperclass-if Your action extends a superclass, is there a resourcebundle associated with that superclass? In other words, if the superclass are Mysuperclass, is there a set of properties files like Mysuperclass. Properties, mysuperclass_en_us.properties, and so forth? Note that the search continues up the superclass chain all the "the" to Object, looking for resourcebundles all the The. Again, the resourcebundles of classes lower on the chain take precedence over the higher ones. In and words, Object.properties comes last, if it exists.

4 If The action implements Modeldriven, the class of the model object itself'll be used to look up resourcebund Les. In the other words, if your model object is our User class, then user.properties, and so on, would be loaded if they exist. Furthermore, the entire process of searching up the interface and class hierarchy, as outlined, 'll be repeated in the CO ntext of the Model object class.

5 package.properties-next, the search tries to load a package resourcebundle for the $ the current actio  N class, and every superpackage back up the chain. In other words, if your current action is com.rk.struts.i18n.HelloWorldAction, the framework would attempt to find a  Package.properties file located in the com.rk.struts.i18n package and then in the Com.rk.struts package. Note that these properties files is all named Package.properties, and is located in the directory structure of The package to which they belong.

6 Domain Model object exposed on the valuestack referenced by Key-this are similar to #4, Modeldriven. Given a key such as User.username, if the Valuestack have a property exposed on it named user, then the class of that Prope Rty'll is used to load resourcebundles, again following the same process we ' ve outlined. However, when resolving the key against those bundles, the first element of the key is stripped away. In other words, given the key user.username, and a user property on the Valuestack (of type User), the Resourcebun DLEs associated with User, beginning with the user.properties, would be searched for a message with the key username, not User.username.

7 Default resourcebundles-struts 2 allows you-specify global bundles that'll always be available.

Textprovider will load all the found bundle data to form a look hierarchy for searching data.

All bundles is found is added to the stock of messages, the Textprovider would make available. The various resourcebundles that is loaded into the Textprovider form a lookup hierarchy for resolving message keys.

Textprovider from top to bottom, the key value of the first search encountered is returned.

The Textprovider starts is down on the top of the bundle stack and works its. The first bundle, from the top, which can return a value for the key wins.

2, the locale in Textprovider formation bundle hierarchy within the function

LOCALE specificity and MESSAGE retrieval

Through the properties file mentioned above, a lookup hierarchy is formed after loading by Textprovider. However, when locale information is added, will it affect the search order of the original lookup hierarchy?

When working your-through the bundle search and the text retrieval hierarchy, you might ' ve asked yourself how locale I Nfluences the retrieval of messages. Of course, if the current locale matches one of the properties files locale extensions, we expect that the text comes from That file ' s set of values. If that file doesn ' t exist, or if the request key is ' t defined in that file, we must fall through to the next most SPECIF IC locale match.

In the above mentioned textprovider form bundle hierarchy, will not be affected by the locale, locale information can only be in the bundle formed by Textprovider A layer in the hierarchy function. Textprovider form bundles hierarchy play a major role, while the locale plays a secondary role.

This locale specificity hierarchy are always used when Struts 2 attempts to locate your message text. However, this algorithm was isolated within a given bundle from the bundle hierarchy outlined previously. Consider a resourcebundle associated with an interface takes precedence over a resourcebundle associated with a super Class. Here's a quick scenario explaining how locale specificity factors to this. Assume the locale of en_US again. Also, assume that we action implements an interface, MyInterface, and Also have a superclass, Mysuperclass. Assume too that both the interface and the superclass has properties files associated with them so the framework would CRE Ate both the myinterface and the Mysuperclass bundles. Now let's see how happens if we try to resolve the Homepage.greeting key.

As we know, this key would first be tried against the interface bundle and according to the search order we ' ve outlined. Here ' s the question regarding locale specificity. What happens if MyInterface only have a myinterface.properties file, a default set of resources, but Mysuperclas S has a specific mysuperclass_en_us.properties file? You might think so the more specific locale should win, but it doesn ' t. The default message is retrieved from the Myinterface.properties file ahead of the more locale-specific superclass file. This was because locale specificity only matters within the bounds of a given resource bundle, in this case MyInterface. Being higher in the bundle search order trumps locale specificity.

3. How to register DEFAUTL bundles

Defining DEFAULT BUNDLES

STRUTS2 allows us to place the properties file in the "any" location and then register the location of the properties file with the Struts2. The properties file specified by us is called the default bundles.

The first six steps of the bundle search order outline convention-based locations where Struts 2 would search for Propertie s files. In order to has Struts 2 Find your properties files, you must put them where it wants them. The framework, however, does provide you with a-to-locate your properties files according to your own whim. This is the role of the default bundles.

The Default bundles is the properties file that Textprovider last looked up. The Default bundles is very useful and can be considered a global bundles.

Default bundles is great. If none of the convention-oriented bundles exist, such as the action class–associated bundle, there ' s always the default B Undles.  These is the last place where the framework would look if trying to resolve a key. For some projects, it might suffice to use default bundles exclusively, filling them with all of the text resources Requi Red by your entire application. This is a common practice. Other applications might want to organize their text resources according to application region and package SP  Ace. Within this more hierarchical organization of the text resources, you still might find it useful to define globally USEF UL text in a default bundle. Default bundles can, in fact, is thought of as global bundles.

If you want to tell Struts2 where to store defautl bundles, you can set struts.xml in Struts.properties or struts.custom.i18n.resources.

Whatever Your use case, defining default bundles was as simple as telling the framework the name of your bundles. To does this, you just need to set the value for the Struts 2 property struts.custom.i18n.resources. You can set this, and all Struts 2 properties, either in the Struts.properties file or with a constant element in one of Y Our XML configuration files, for example Struts.xml or one of the files it sources. Either, it doesn ' t matter. The following shows the constant element, which can be placed in struts.xml or any of other XML sourced by that file:

<constant name= "struts.custom.i18n.resources" value= "Global-messages"/>

Here's the same bit of configuration as done in the Struts.properties file:

Struts.custom.i18n.resources=global-messages

if more than one bundle exists, it can be separated by ",". If the bundle is stored in a package, you also need to specify the package name .

You can specify a comma-separated list of bundles and to is searched in the given order. You can also specify package space for the location of the bundles. Here's what the would look like:

Struts.custom.i18n.resources=global-messages,manning.utils.otherbundle

This would-for-a properties file Otherbundle.properties in the Manning.util directory space. If for some reason your mix configuration patterns, bear on mind, the struts.properties file trumps the constant elemen T from the XML.

STRUTS2 series: (25) Internationalization (iii) Textprovider How to search for Resoucebundle locations