jira-1436. To really fix it we'll need to make some API changes, which
means it'll not go into 1.3.3. But to provide a solution to 1.3.3
users we could introduce a simple solution (mark it as temporary)
which will than change in 1.4 again. Currently
ComponentStringResourceLoader contains a static constant
"properties,xml" which is a comma separated list of file extensions.
We simply must allow users to get and set it. Users would just call
ComponentStringResourceLoader.setPropertyFileExtenstions("properties")
and the problem would be solved. Of course you can not use any *.xml
property files in the application than.WDYT? Should it go into 1.3.3? Juergen On Sun, Mar 2, 2008 at 11:47 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > gah, thats an interesting unintended side effect :) please file a jira > issue... > > -igor > > > > > On Sat, Mar 1, 2008 at 10:15 AM, Mark Sandori <[EMAIL PROTECTED]> wrote: > > I am trying to use wicket to generate an XML file instead of an HTML file. > > > > I have no problem setting the correct markup type and using an XML file as > > the markup instead of an HTML file. I can get a basic XML file to generate > > without problems. > > > > However, if I try and use any <wicket:message> tags or anything that uses > a > > Localizer, it doesn't work. > > > > This is because the localizer attempts to look for properties in both > > .properties and .xml files. > > > > The resolution process matches the page's markup file as an .XML > properties > > file and attempts to load it. This of course breaks. > > > > So, if I want to generate an XML file, I can't use any wicket localization > > techniques. > > > > Do you have any suggestions? > > > > Thanks, > > Mark. > > >
