[vote] release 1.4.2

[igor.vaynberg]

Be sure to test with your projects and let us know of any problems

svn: https://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.2
dist: http://people.apache.org/~ivaynberg/wicket-1.4.2/dist
maven: http://people.apache.org/~ivaynberg/wicket-1.4.2/m2-repo
changelog: see below

Your vote please (vote will close Thursday Oct 1st):

[ ] Yes release
[ ] No, don't release it and here is why...

-igor


Release Notes - Wicket - Version 1.4.2


** Bug
    * [WICKET-2393] - Passwords should not be trimmed
    * [WICKET-2430] - Malformed \uxxxx encoding in
MultipleUploadField_sl.properties
    * [WICKET-2433] - Ajax support for multipart forms broken in a nested form
    * [WICKET-2434] - RequestCycle urlFor ignores existing parameters
when appending provided params
    * [WICKET-2436] - invalid DataTable markup breaks table layout
    * [WICKET-2438] - AjaxEventBehavior not working on feedback
message components
    * [WICKET-2453] - Form.findForm(Component c) bug. When form is
part of Border and form component like TextField is inside another
Border , component cannot resolve its form.
    * [WICKET-2456] - DateTextField cannot work with default converter
(or javadoc wrong)
    * [WICKET-2457] - Flash/ExternalInterface does not work in IE if
movie is fetched via Wicket/Ajax
    * [WICKET-2458] - JavascriptUtils.escapeQuotes() misses escaping
double quotes
    * [WICKET-2461] - AjaxPagingNavigationIncrementLink does not work
without AjaxPagingNavigator component
    * [WICKET-2463] - Ajax miltipart form submitting ignores
setDefaultFormProcessing(false)
    * [WICKET-2466] - javadoc the CryptedUrlWebRequestCodingStrategy
needs to be update/corrected to reflect the usage of session-id for
encryption and hence URLs which were bookmarkable before will NOT
remain bookmarkable.
    * [WICKET-2475] - NPE after application hot redeployment
    * [WICKET-2477] - AjaxEditableChoiceLabel does not detach choices model
    * [WICKET-2478] - TabbedPanel rendering bug
    * [WICKET-2485] - IComponentResolvers are not supported inside
wicket:enclosure
    * [WICKET-2488] - QuickFix proposal
WicketTesterHelper.assertEquals(final Collection<?> expects, final
Collection<?> actuals) should compare list sizes

** Improvement
    * [WICKET-626] - profile Wicket for 1.4.0
    * [WICKET-2435] - TabbedPanel extract factory method for tabs-container
    * [WICKET-2439] - Improve MixedParamUrlCodingStrategy, introduce Hybrid
    * [WICKET-2444] - Internal Spring beans should be ignored
    * [WICKET-2445] - FormInput.java needs the validators updated.
    * [WICKET-2449] - Fix javadoc biggest mistakes - mainly @Deprecated tags
    * [WICKET-2451] - Add ability to load UTF-8 encoded properties not
in XML format.
    * [WICKET-2454] - IE8: be more verbose if ajax refresh fails
    * [WICKET-2469] - Allow using a different FileItemFactory by
extracting a method in MultipartServletWebRequest class
    * [WICKET-2492] - Application_pt_BR.properties path

** New Feature
    * [WICKET-2395] - add MixedParamHybridUrlCodingStrategy
    * [WICKET-2483] - Access to WizardModel.conditions

** Wish
    * [WICKET-2120] - widen visibiliy of GuiceProxyTargetLocator  and
findBindingAnnotation
    * [WICKET-2462] - Would it possible add chinese resource label for
WizardButton eg. CancelButton, NextButton and PreviousButton etc.
    * [WICKET-2489] - need to know if a component has been added to
the AjaxRequestTarget

[Stefan Lindner]

[x] Yes release
[ ] No, don't release it and here is why...

[Sam Stainsby-2]

Are non-binding votes preferred or discouraged here? If the former, then
after some testing with my projects:

(nonbinding)
[X] Yes release
[ ] No, don't release it and here is why...

[igor.vaynberg]

all votes are more then welcome.

-igor

On Sun, Sep 27, 2009 at 5:20 PM, Sam Stainsby
<sam@...> wrote:
> Are non-binding votes preferred or discouraged here? If the former, then
> after some testing with my projects:
>
> (nonbinding)
> [X] Yes release
> [ ] No, don't release it and here is why...
>
>

[reiern70]

> [ X] No, don't release it and here is why...
>

After upgrading to 1.4.2 all my ISO-8859-1 encoded property files fail to
work. I haven't look into it in detail but I guess this is related to
* [WICKET-2451] - Add ability to load UTF-8 encoded properties not
in XML format.


I know I shouldn't be using ISO-8859-1... but right now I have a bunch of
those properties files. Is there an easy way to get around this?.... After
looking into changes I see the line (379)....

Reader reader = new InputStreamReader(is, "UTF-8");

Shouldn't this be cofingurable somehow?

Best,

Ernesto


On Mon, Sep 28, 2009 at 2:33 AM, Igor Vaynberg <igor.vaynberg@...>wrote:

> all votes are more then welcome.
>
> -igor
>
> On Sun, Sep 27, 2009 at 5:20 PM, Sam Stainsby
> <sam@...> wrote:
> > Are non-binding votes preferred or discouraged here? If the former, then
> > after some testing with my projects:
> >
> > (nonbinding)
> > [X] Yes release
> > [ ] No, don't release it and here is why...
> >
> >
>

[Johan Compagner]

-1 then yes
that shouldnt be hardcoded but a property in our settings.


On Mon, Sep 28, 2009 at 11:02, Ernesto Reinaldo Barreiro <reiern70@...
> wrote:

> > [ X] No, don't release it and here is why...
> >
>
> After upgrading to 1.4.2 all my ISO-8859-1 encoded property files fail to
> work. I haven't look into it in detail but I guess this is related to
> * [WICKET-2451] - Add ability to load UTF-8 encoded properties not
> in XML format.
>
>
> I know I shouldn't be using ISO-8859-1... but right now I have a bunch of
> those properties files. Is there an easy way to get around this?.... After
> looking into changes I see the line (379)....
>
> Reader reader = new InputStreamReader(is, "UTF-8");
>
> Shouldn't this be cofingurable somehow?
>
> Best,
>
> Ernesto
>
>
> On Mon, Sep 28, 2009 at 2:33 AM, Igor Vaynberg <igor.vaynberg@...
> >wrote:
>
> > all votes are more then welcome.
> >
> > -igor
> >
> > On Sun, Sep 27, 2009 at 5:20 PM, Sam Stainsby
> > <sam@...> wrote:
> > > Are non-binding votes preferred or discouraged here? If the former,
> then
> > > after some testing with my projects:
> > >
> > > (nonbinding)
> > > [X] Yes release
> > > [ ] No, don't release it and here is why...
> > >
> > >
> >
>

[reiern70]

Another down side of this is that you can implement your
own IStringResourceLoader which does not have to rely on PropertiesFactory
for reading properties... I have done that for some applications, and then I
end up with some property files which I can (do have, as it is now) write on
UTF-8 and some that I cannot... But, of course, that is just a limitation of
my own implementation of IStringResourceLoader that i'll try to fix.
Best,

Ernesto

On Mon, Sep 28, 2009 at 11:42 AM, Johan Compagner <jcompagner@...>wrote:

> -1 then yes
> that shouldnt be hardcoded but a property in our settings.
>
>
> On Mon, Sep 28, 2009 at 11:02, Ernesto Reinaldo Barreiro <
> reiern70@...
> > wrote:
>
> > > [ X] No, don't release it and here is why...
> > >
> >
> > After upgrading to 1.4.2 all my ISO-8859-1 encoded property files fail to
> > work. I haven't look into it in detail but I guess this is related to
> > * [WICKET-2451] - Add ability to load UTF-8 encoded properties not
> > in XML format.
> >
> >
> > I know I shouldn't be using ISO-8859-1... but right now I have a bunch of
> > those properties files. Is there an easy way to get around this?....
> After
> > looking into changes I see the line (379)....
> >
> > Reader reader = new InputStreamReader(is, "UTF-8");
> >
> > Shouldn't this be cofingurable somehow?
> >
> > Best,
> >
> > Ernesto
> >
> >
> > On Mon, Sep 28, 2009 at 2:33 AM, Igor Vaynberg <igor.vaynberg@...
> > >wrote:
> >
> > > all votes are more then welcome.
> > >
> > > -igor
> > >
> > > On Sun, Sep 27, 2009 at 5:20 PM, Sam Stainsby
> > > <sam@...> wrote:
> > > > Are non-binding votes preferred or discouraged here? If the former,
> > then
> > > > after some testing with my projects:
> > > >
> > > > (nonbinding)
> > > > [X] Yes release
> > > > [ ] No, don't release it and here is why...
> > > >
> > > >
> > >
> >
>

[Robin Sander]

I think the default should remain ISO 8859-1 because otherwise 1.4.2  
wouldn't be
backward compatible.
And isn't the Java default for property files ISO 8859-1so any  
deveoper and most IDEs
would assume this encoding?

robin.


On Sep 28, 2009, at 11:42, Johan Compagner wrote:

> -1 then yes
> that shouldnt be hardcoded but a property in our settings.
>
>
> On Mon, Sep 28, 2009 at 11:02, Ernesto Reinaldo Barreiro <reiern70@...
>> wrote:
>
>>> [ X] No, don't release it and here is why...
>>>
>>
>> After upgrading to 1.4.2 all my ISO-8859-1 encoded property files  
>> fail to
>> work. I haven't look into it in detail but I guess this is related to
>> * [WICKET-2451] - Add ability to load UTF-8 encoded properties not
>> in XML format.
>>
>>
>> I know I shouldn't be using ISO-8859-1... but right now I have a  
>> bunch of
>> those properties files. Is there an easy way to get around  
>> this?.... After
>> looking into changes I see the line (379)....
>>
>> Reader reader = new InputStreamReader(is, "UTF-8");
>>
>> Shouldn't this be cofingurable somehow?
>>
>> Best,
>>
>> Ernesto
>>
>>
>> On Mon, Sep 28, 2009 at 2:33 AM, Igor Vaynberg <igor.vaynberg@...
>>> wrote:
>>
>>> all votes are more then welcome.
>>>
>>> -igor
>>>
>>> On Sun, Sep 27, 2009 at 5:20 PM, Sam Stainsby
>>> <sam@...> wrote:
>>>> Are non-binding votes preferred or discouraged here? If the former,
>> then
>>>> after some testing with my projects:
>>>>
>>>> (nonbinding)
>>>> [X] Yes release
>>>> [ ] No, don't release it and here is why...
>>>>
>>>>
>>>
>>

[Juergen Donnerstag]

I think SUNs default is the char encoding configured with the OS or
env vars. If you don't explicitly provide a char encoding, that is
what is used. I don't think we should assume ISO 8859-1 or any other
to be the default, but use what is configured with the OS/env.

-Juergen

On Mon, Sep 28, 2009 at 1:49 PM, Robin Sander <robin.sander@...> wrote:

>
> I think the default should remain ISO 8859-1 because otherwise 1.4.2
> wouldn't be
> backward compatible.
> And isn't the Java default for property files ISO 8859-1so any deveoper and
> most IDEs
> would assume this encoding?
>
> robin.
>
>
> On Sep 28, 2009, at 11:42, Johan Compagner wrote:
>
>> -1 then yes
>> that shouldnt be hardcoded but a property in our settings.
>>
>>
>> On Mon, Sep 28, 2009 at 11:02, Ernesto Reinaldo Barreiro
>> <reiern70@...
>>>
>>> wrote:
>>
>>>> [ X] No, don't release it and here is why...
>>>>
>>>
>>> After upgrading to 1.4.2 all my ISO-8859-1 encoded property files fail to
>>> work. I haven't look into it in detail but I guess this is related to
>>> * [WICKET-2451] - Add ability to load UTF-8 encoded properties not
>>> in XML format.
>>>
>>>
>>> I know I shouldn't be using ISO-8859-1... but right now I have a bunch of
>>> those properties files. Is there an easy way to get around this?....
>>> After
>>> looking into changes I see the line (379)....
>>>
>>> Reader reader = new InputStreamReader(is, "UTF-8");
>>>
>>> Shouldn't this be cofingurable somehow?
>>>
>>> Best,
>>>
>>> Ernesto
>>>
>>>
>>> On Mon, Sep 28, 2009 at 2:33 AM, Igor Vaynberg <igor.vaynberg@...
>>>>
>>>> wrote:
>>>
>>>> all votes are more then welcome.
>>>>
>>>> -igor
>>>>
>>>> On Sun, Sep 27, 2009 at 5:20 PM, Sam Stainsby
>>>> <sam@...> wrote:
>>>>>
>>>>> Are non-binding votes preferred or discouraged here? If the former,
>>>
>>> then
>>>>>
>>>>> after some testing with my projects:
>>>>>
>>>>> (nonbinding)
>>>>> [X] Yes release
>>>>> [ ] No, don't release it and here is why...
>>>>>
>>>>>
>>>>
>>>
>
>

[Martin Funk-3]

Within the last 10 years SUN, so successfully, ironed into my brain that
properties are ISO 8859-1, I wouldn't even dare to thinkt it could be
different.

see also:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html

mf

2009/9/28 Juergen Donnerstag <juergen.donnerstag@...>

> I think SUNs default is the char encoding configured with the OS or
> env vars. If you don't explicitly provide a char encoding, that is
> what is used. I don't think we should assume ISO 8859-1 or any other
> to be the default, but use what is configured with the OS/env.
>
> -Juergen
>
> On Mon, Sep 28, 2009 at 1:49 PM, Robin Sander <robin.sander@...>
> wrote:
> >
> > I think the default should remain ISO 8859-1 because otherwise 1.4.2
> > wouldn't be
> > backward compatible.
> > And isn't the Java default for property files ISO 8859-1so any deveoper
> and
> > most IDEs
> > would assume this encoding?
> >
> > robin.
> >
> >
> > On Sep 28, 2009, at 11:42, Johan Compagner wrote:
> >
> >> -1 then yes
> >> that shouldnt be hardcoded but a property in our settings.
> >>
> >>
> >> On Mon, Sep 28, 2009 at 11:02, Ernesto Reinaldo Barreiro
> >> <reiern70@...
> >>>
> >>> wrote:
> >>
> >>>> [ X] No, don't release it and here is why...
> >>>>
> >>>
> >>> After upgrading to 1.4.2 all my ISO-8859-1 encoded property files fail
> to
> >>> work. I haven't look into it in detail but I guess this is related to
> >>> * [WICKET-2451] - Add ability to load UTF-8 encoded properties not
> >>> in XML format.
> >>>
> >>>
> >>> I know I shouldn't be using ISO-8859-1... but right now I have a bunch
> of
> >>> those properties files. Is there an easy way to get around this?....
> >>> After
> >>> looking into changes I see the line (379)....
> >>>
> >>> Reader reader = new InputStreamReader(is, "UTF-8");
> >>>
> >>> Shouldn't this be cofingurable somehow?
> >>>
> >>> Best,
> >>>
> >>> Ernesto
> >>>
> >>>
> >>> On Mon, Sep 28, 2009 at 2:33 AM, Igor Vaynberg <
> igor.vaynberg@...
> >>>>
> >>>> wrote:
> >>>
> >>>> all votes are more then welcome.
> >>>>
> >>>> -igor
> >>>>
> >>>> On Sun, Sep 27, 2009 at 5:20 PM, Sam Stainsby
> >>>> <sam@...> wrote:
> >>>>>
> >>>>> Are non-binding votes preferred or discouraged here? If the former,
> >>>
> >>> then
> >>>>>
> >>>>> after some testing with my projects:
> >>>>>
> >>>>> (nonbinding)
> >>>>> [X] Yes release
> >>>>> [ ] No, don't release it and here is why...
> >>>>>
> >>>>>
> >>>>
> >>>
> >
> >
>

[Johan Compagner]

that was then really a stupid decision of sun..
If it is not even the os default (so text editor default encoding) why then
choose one that doesnt map everything?

On Mon, Sep 28, 2009 at 15:18, Martin Funk <mafulafunk@...>wrote:

> Within the last 10 years SUN, so successfully, ironed into my brain that
> properties are ISO 8859-1, I wouldn't even dare to thinkt it could be
> different.
>
> see also:
> http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html
>
> mf
>
> 2009/9/28 Juergen Donnerstag <juergen.donnerstag@...>
>
> > I think SUNs default is the char encoding configured with the OS or
> > env vars. If you don't explicitly provide a char encoding, that is
> > what is used. I don't think we should assume ISO 8859-1 or any other
> > to be the default, but use what is configured with the OS/env.
> >
> > -Juergen
> >
> > On Mon, Sep 28, 2009 at 1:49 PM, Robin Sander <robin.sander@...>
> > wrote:
> > >
> > > I think the default should remain ISO 8859-1 because otherwise 1.4.2
> > > wouldn't be
> > > backward compatible.
> > > And isn't the Java default for property files ISO 8859-1so any deveoper
> > and
> > > most IDEs
> > > would assume this encoding?
> > >
> > > robin.
> > >
> > >
> > > On Sep 28, 2009, at 11:42, Johan Compagner wrote:
> > >
> > >> -1 then yes
> > >> that shouldnt be hardcoded but a property in our settings.
> > >>
> > >>
> > >> On Mon, Sep 28, 2009 at 11:02, Ernesto Reinaldo Barreiro
> > >> <reiern70@...
> > >>>
> > >>> wrote:
> > >>
> > >>>> [ X] No, don't release it and here is why...
> > >>>>
> > >>>
> > >>> After upgrading to 1.4.2 all my ISO-8859-1 encoded property files
> fail
> > to
> > >>> work. I haven't look into it in detail but I guess this is related to
> > >>> * [WICKET-2451] - Add ability to load UTF-8 encoded properties not
> > >>> in XML format.
> > >>>
> > >>>
> > >>> I know I shouldn't be using ISO-8859-1... but right now I have a
> bunch
> > of
> > >>> those properties files. Is there an easy way to get around this?....
> > >>> After
> > >>> looking into changes I see the line (379)....
> > >>>
> > >>> Reader reader = new InputStreamReader(is, "UTF-8");
> > >>>
> > >>> Shouldn't this be cofingurable somehow?
> > >>>
> > >>> Best,
> > >>>
> > >>> Ernesto
> > >>>
> > >>>
> > >>> On Mon, Sep 28, 2009 at 2:33 AM, Igor Vaynberg <
> > igor.vaynberg@...
> > >>>>
> > >>>> wrote:
> > >>>
> > >>>> all votes are more then welcome.
> > >>>>
> > >>>> -igor
> > >>>>
> > >>>> On Sun, Sep 27, 2009 at 5:20 PM, Sam Stainsby
> > >>>> <sam@...> wrote:
> > >>>>>
> > >>>>> Are non-binding votes preferred or discouraged here? If the former,
> > >>>
> > >>> then
> > >>>>>
> > >>>>> after some testing with my projects:
> > >>>>>
> > >>>>> (nonbinding)
> > >>>>> [X] Yes release
> > >>>>> [ ] No, don't release it and here is why...
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >
> > >
> >
>

[Robin Sander]

Yeah, but I have to second Martin, the default encoding is also  
"ironed into my brain"... :-)
And the OS default isn't a better choice since the default language of  
your application would
depend on the OS environment and not on your app's or at least app-
server's configuration.
But that's a different discussion. (american people and i18n.... :-))
Why don't stick to the old default encoding almost everone assumes  
(e.g. Eclipse too)
and provide a configuration option in Application?


On Sep 28, 2009, at 15:27, Johan Compagner wrote:

> that was then really a stupid decision of sun..
> If it is not even the os default (so text editor default encoding)  
> why then
> choose one that doesnt map everything?
>
> On Mon, Sep 28, 2009 at 15:18, Martin Funk  
> <mafulafunk@...>wrote:
>
>> Within the last 10 years SUN, so successfully, ironed into my brain  
>> that
>> properties are ISO 8859-1, I wouldn't even dare to thinkt it could be
>> different.
>>
>> see also:
>> http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html
>>
>> mf
>>
>> 2009/9/28 Juergen Donnerstag <juergen.donnerstag@...>
>>
>>> I think SUNs default is the char encoding configured with the OS or
>>> env vars. If you don't explicitly provide a char encoding, that is
>>> what is used. I don't think we should assume ISO 8859-1 or any other
>>> to be the default, but use what is configured with the OS/env.
>>>
>>> -Juergen
>>>
>>> On Mon, Sep 28, 2009 at 1:49 PM, Robin Sander <robin.sander@...>
>>> wrote:
>>>>
>>>> I think the default should remain ISO 8859-1 because otherwise  
>>>> 1.4.2
>>>> wouldn't be
>>>> backward compatible.
>>>> And isn't the Java default for property files ISO 8859-1so any  
>>>> deveoper
>>> and
>>>> most IDEs
>>>> would assume this encoding?
>>>>
>>>> robin.
>>>>
>>>>
>>>> On Sep 28, 2009, at 11:42, Johan Compagner wrote:
>>>>
>>>>> -1 then yes
>>>>> that shouldnt be hardcoded but a property in our settings.
>>>>>
>>>>>
>>>>> On Mon, Sep 28, 2009 at 11:02, Ernesto Reinaldo Barreiro
>>>>> <reiern70@...
>>>>>>
>>>>>> wrote:
>>>>>
>>>>>>> [ X] No, don't release it and here is why...
>>>>>>>
>>>>>>
>>>>>> After upgrading to 1.4.2 all my ISO-8859-1 encoded property files
>> fail
>>> to
>>>>>> work. I haven't look into it in detail but I guess this is  
>>>>>> related to
>>>>>> * [WICKET-2451] - Add ability to load UTF-8 encoded properties  
>>>>>> not
>>>>>> in XML format.
>>>>>>
>>>>>>
>>>>>> I know I shouldn't be using ISO-8859-1... but right now I have a
>> bunch
>>> of
>>>>>> those properties files. Is there an easy way to get around  
>>>>>> this?....
>>>>>> After
>>>>>> looking into changes I see the line (379)....
>>>>>>
>>>>>> Reader reader = new InputStreamReader(is, "UTF-8");
>>>>>>
>>>>>> Shouldn't this be cofingurable somehow?
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Ernesto
>>>>>>
>>>>>>
>>>>>> On Mon, Sep 28, 2009 at 2:33 AM, Igor Vaynberg <
>>> igor.vaynberg@...
>>>>>>>
>>>>>>> wrote:
>>>>>>
>>>>>>> all votes are more then welcome.
>>>>>>>
>>>>>>> -igor
>>>>>>>
>>>>>>> On Sun, Sep 27, 2009 at 5:20 PM, Sam Stainsby
>>>>>>> <sam@...> wrote:
>>>>>>>>
>>>>>>>> Are non-binding votes preferred or discouraged here? If the  
>>>>>>>> former,
>>>>>>
>>>>>> then
>>>>>>>>
>>>>>>>> after some testing with my projects:
>>>>>>>>
>>>>>>>> (nonbinding)
>>>>>>>> [X] Yes release
>>>>>>>> [ ] No, don't release it and here is why...
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>

[reiern70]

IMHO the main issue here is backward compatibility. What should I do with
existing resources, e.g. packaged inside a jar file, that were not created
on UTF-8 format? I wouldn't mind UTF-8 been an option if this could be
configured setting some property at application level... which by default
is ISO 8859-1. Right now I do have other resources, that are NOT read via
wicket default machinery, which has to be on  ISO 8859-1 and I would not
like to have to keep in mind this distinction...
Best,

Ernesto

On Mon, Sep 28, 2009 at 3:44 PM, Robin Sander <robin.sander@...> wrote:

>
> Yeah, but I have to second Martin, the default encoding is also "ironed
> into my brain"... :-)
> And the OS default isn't a better choice since the default language of your
> application would
> depend on the OS environment and not on your app's or at least app-server's
> configuration.
> But that's a different discussion. (american people and i18n.... :-))
> Why don't stick to the old default encoding almost everone assumes (e.g.
> Eclipse too)
> and provide a configuration option in Application?
>
>
>
> On Sep 28, 2009, at 15:27, Johan Compagner wrote:
>
>  that was then really a stupid decision of sun..
>> If it is not even the os default (so text editor default encoding) why
>> then
>> choose one that doesnt map everything?
>>
>> On Mon, Sep 28, 2009 at 15:18, Martin Funk <mafulafunk@...
>> >wrote:
>>
>>  Within the last 10 years SUN, so successfully, ironed into my brain that
>>> properties are ISO 8859-1, I wouldn't even dare to thinkt it could be
>>> different.
>>>
>>> see also:
>>> http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html
>>>
>>> mf
>>>
>>> 2009/9/28 Juergen Donnerstag <juergen.donnerstag@...>
>>>
>>>  I think SUNs default is the char encoding configured with the OS or
>>>> env vars. If you don't explicitly provide a char encoding, that is
>>>> what is used. I don't think we should assume ISO 8859-1 or any other
>>>> to be the default, but use what is configured with the OS/env.
>>>>
>>>> -Juergen
>>>>
>>>> On Mon, Sep 28, 2009 at 1:49 PM, Robin Sander <robin.sander@...>
>>>> wrote:
>>>>
>>>>>
>>>>> I think the default should remain ISO 8859-1 because otherwise 1.4.2
>>>>> wouldn't be
>>>>> backward compatible.
>>>>> And isn't the Java default for property files ISO 8859-1so any deveoper
>>>>>
>>>> and
>>>>
>>>>> most IDEs
>>>>> would assume this encoding?
>>>>>
>>>>> robin.
>>>>>
>>>>>
>>>>> On Sep 28, 2009, at 11:42, Johan Compagner wrote:
>>>>>
>>>>>  -1 then yes
>>>>>> that shouldnt be hardcoded but a property in our settings.
>>>>>>
>>>>>>
>>>>>> On Mon, Sep 28, 2009 at 11:02, Ernesto Reinaldo Barreiro
>>>>>> <reiern70@...
>>>>>>
>>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>
>>>>>>  [ X] No, don't release it and here is why...
>>>>>>>>
>>>>>>>>
>>>>>>> After upgrading to 1.4.2 all my ISO-8859-1 encoded property files
>>>>>>>
>>>>>> fail
>>>
>>>> to
>>>>
>>>>> work. I haven't look into it in detail but I guess this is related to
>>>>>>> * [WICKET-2451] - Add ability to load UTF-8 encoded properties not
>>>>>>> in XML format.
>>>>>>>
>>>>>>>
>>>>>>> I know I shouldn't be using ISO-8859-1... but right now I have a
>>>>>>>
>>>>>> bunch
>>>
>>>> of
>>>>
>>>>> those properties files. Is there an easy way to get around this?....
>>>>>>> After
>>>>>>> looking into changes I see the line (379)....
>>>>>>>
>>>>>>> Reader reader = new InputStreamReader(is, "UTF-8");
>>>>>>>
>>>>>>> Shouldn't this be cofingurable somehow?
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Ernesto
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Sep 28, 2009 at 2:33 AM, Igor Vaynberg <
>>>>>>>
>>>>>> igor.vaynberg@...
>>>>
>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>
>>>>>>>  all votes are more then welcome.
>>>>>>>>
>>>>>>>> -igor
>>>>>>>>
>>>>>>>> On Sun, Sep 27, 2009 at 5:20 PM, Sam Stainsby
>>>>>>>> <sam@...> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Are non-binding votes preferred or discouraged here? If the former,
>>>>>>>>>
>>>>>>>>
>>>>>>> then
>>>>>>>
>>>>>>>>
>>>>>>>>> after some testing with my projects:
>>>>>>>>>
>>>>>>>>> (nonbinding)
>>>>>>>>> [X] Yes release
>>>>>>>>> [ ] No, don't release it and here is why...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>

[igor.vaynberg]

Hrm. I thought the code was supposed to convert 8859 to utf8 on the
fly. Can you please open a jira issue and attach a test case.

-Igor

On Mon, Sep 28, 2009 at 2:02 AM, Ernesto Reinaldo Barreiro
<reiern70@...> wrote:

>> [ X] No, don't release it and here is why...
>>
>
> After upgrading to 1.4.2 all my ISO-8859-1 encoded property files fail to
> work. I haven't look into it in detail but I guess this is related to
> * [WICKET-2451] - Add ability to load UTF-8 encoded properties not
> in XML format.
>
>
> I know I shouldn't be using ISO-8859-1... but right now I have a bunch of
> those properties files. Is there an easy way to get around this?.... After
> looking into changes I see the line (379)....
>
> Reader reader = new InputStreamReader(is, "UTF-8");
>
> Shouldn't this be cofingurable somehow?
>
> Best,
>
> Ernesto
>
>
> On Mon, Sep 28, 2009 at 2:33 AM, Igor Vaynberg <igor.vaynberg@...>wrote:
>
>> all votes are more then welcome.
>>
>> -igor
>>
>> On Sun, Sep 27, 2009 at 5:20 PM, Sam Stainsby
>> <sam@...> wrote:
>> > Are non-binding votes preferred or discouraged here? If the former, then
>> > after some testing with my projects:
>> >
>> > (nonbinding)
>> > [X] Yes release
>> > [ ] No, don't release it and here is why...
>> >
>> >
>>
>

[reiern70]

Yes I see the code at readUTFStreamToEscapedASCII... Maybe I'm making a
wrong use of properties files? I'll check out and come back either with a
test case... or an explanation of why is not working form me
Many thanks,

Ernesto

On Mon, Sep 28, 2009 at 6:36 PM, Igor Vaynberg <igor.vaynberg@...>wrote:

> Hrm. I thought the code was supposed to convert 8859 to utf8 on the
> fly. Can you please open a jira issue and attach a test case.
>
> -Igor
>
> On Mon, Sep 28, 2009 at 2:02 AM, Ernesto Reinaldo Barreiro
> <reiern70@...> wrote:
> >> [ X] No, don't release it and here is why...
> >>
> >
> > After upgrading to 1.4.2 all my ISO-8859-1 encoded property files fail to
> > work. I haven't look into it in detail but I guess this is related to
> > * [WICKET-2451] - Add ability to load UTF-8 encoded properties not
> > in XML format.
> >
> >
> > I know I shouldn't be using ISO-8859-1... but right now I have a bunch of
> > those properties files. Is there an easy way to get around this?....
> After
> > looking into changes I see the line (379)....
> >
> > Reader reader = new InputStreamReader(is, "UTF-8");
> >
> > Shouldn't this be cofingurable somehow?
> >
> > Best,
> >
> > Ernesto
> >
> >
> > On Mon, Sep 28, 2009 at 2:33 AM, Igor Vaynberg <igor.vaynberg@...
> >wrote:
> >
> >> all votes are more then welcome.
> >>
> >> -igor
> >>
> >> On Sun, Sep 27, 2009 at 5:20 PM, Sam Stainsby
> >> <sam@...> wrote:
> >> > Are non-binding votes preferred or discouraged here? If the former,
> then
> >> > after some testing with my projects:
> >> >
> >> > (nonbinding)
> >> > [X] Yes release
> >> > [ ] No, don't release it and here is why...
> >> >
> >> >
> >>
> >
>

[reiern70]

Hi Igor,
I just created a quick start and attached it to

https://issues.apache.org/jira/browse/WICKET-2496
<https://issues.apache.org/jira/browse/WICKET-2496>
Home page displays fine with 1.4.1 and not with 1.4.2.

Best,

Ernesto

On Mon, Sep 28, 2009 at 6:36 PM, Igor Vaynberg <igor.vaynberg@...>wrote:

> Hrm. I thought the code was supposed to convert 8859 to utf8 on the
> fly. Can you please open a jira issue and attach a test case.
>
> -Igor
>
> On Mon, Sep 28, 2009 at 2:02 AM, Ernesto Reinaldo Barreiro
> <reiern70@...> wrote:
> >> [ X] No, don't release it and here is why...
> >>
> >
> > After upgrading to 1.4.2 all my ISO-8859-1 encoded property files fail to
> > work. I haven't look into it in detail but I guess this is related to
> > * [WICKET-2451] - Add ability to load UTF-8 encoded properties not
> > in XML format.
> >
> >
> > I know I shouldn't be using ISO-8859-1... but right now I have a bunch of
> > those properties files. Is there an easy way to get around this?....
> After
> > looking into changes I see the line (379)....
> >
> > Reader reader = new InputStreamReader(is, "UTF-8");
> >
> > Shouldn't this be cofingurable somehow?
> >
> > Best,
> >
> > Ernesto
> >
> >
> > On Mon, Sep 28, 2009 at 2:33 AM, Igor Vaynberg <igor.vaynberg@...
> >wrote:
> >
> >> all votes are more then welcome.
> >>
> >> -igor
> >>
> >> On Sun, Sep 27, 2009 at 5:20 PM, Sam Stainsby
> >> <sam@...> wrote:
> >> > Are non-binding votes preferred or discouraged here? If the former,
> then
> >> > after some testing with my projects:
> >> >
> >> > (nonbinding)
> >> > [X] Yes release
> >> > [ ] No, don't release it and here is why...
> >> >
> >> >
> >>
> >
>

[Robin Sander]

I doubt that this is possible, iso-8859-1 is not a subset of UTF-8 and  
though it may be possible
to guess the encoding of a byte array it will always be just a guess.  
That's one main
advantage of XML over plain text format, the encoding is stated  
upfront (itself in a fixed
encoding btw.)
So with plain text you have to simply know the encoding before parsing  
it, that's why Sun
had to define one for property (plain text) files.

Robin.

On Sep 28, 2009, at 18:36, Igor Vaynberg wrote:

> Hrm. I thought the code was supposed to convert 8859 to utf8 on the
> fly. Can you please open a jira issue and attach a test case.
>
> -Igor
>
> On Mon, Sep 28, 2009 at 2:02 AM, Ernesto Reinaldo Barreiro
> <reiern70@...> wrote:
>>> [ X] No, don't release it and here is why...
>>>
>>
>> After upgrading to 1.4.2 all my ISO-8859-1 encoded property files  
>> fail to
>> work. I haven't look into it in detail but I guess this is related to
>> * [WICKET-2451] - Add ability to load UTF-8 encoded properties not
>> in XML format.
>>
>>
>> I know I shouldn't be using ISO-8859-1... but right now I have a  
>> bunch of
>> those properties files. Is there an easy way to get around  
>> this?.... After
>> looking into changes I see the line (379)....
>>
>> Reader reader = new InputStreamReader(is, "UTF-8");
>>
>> Shouldn't this be cofingurable somehow?
>>
>> Best,
>>
>> Ernesto
>>
>>
>> On Mon, Sep 28, 2009 at 2:33 AM, Igor Vaynberg <igor.vaynberg@...
>> >wrote:
>>
>>> all votes are more then welcome.
>>>
>>> -igor
>>>
>>> On Sun, Sep 27, 2009 at 5:20 PM, Sam Stainsby
>>> <sam@...> wrote:
>>>> Are non-binding votes preferred or discouraged here? If the  
>>>> former, then
>>>> after some testing with my projects:
>>>>
>>>> (nonbinding)
>>>> [X] Yes release
>>>> [ ] No, don't release it and here is why...
>>>>
>>>>
>>>
>>

[igor.vaynberg]

ok. lets consider this vote closed.

there doesnt seem to be a good way to fix utf8 thing, i am going to
roll it back and recreate 1.4.2 sans that.

i will start a new vote thread when that is done.

-igor

On Tue, Sep 29, 2009 at 2:07 AM, Robin Sander <robin.sander@...> wrote:

>
> I doubt that this is possible, iso-8859-1 is not a subset of UTF-8 and
> though it may be possible
> to guess the encoding of a byte array it will always be just a guess. That's
> one main
> advantage of XML over plain text format, the encoding is stated upfront
> (itself in a fixed
> encoding btw.)
> So with plain text you have to simply know the encoding before parsing it,
> that's why Sun
> had to define one for property (plain text) files.
>
> Robin.
>
> On Sep 28, 2009, at 18:36, Igor Vaynberg wrote:
>
>> Hrm. I thought the code was supposed to convert 8859 to utf8 on the
>> fly. Can you please open a jira issue and attach a test case.
>>
>> -Igor
>>
>> On Mon, Sep 28, 2009 at 2:02 AM, Ernesto Reinaldo Barreiro
>> <reiern70@...> wrote:
>>>>
>>>> [ X] No, don't release it and here is why...
>>>>
>>>
>>> After upgrading to 1.4.2 all my ISO-8859-1 encoded property files fail to
>>> work. I haven't look into it in detail but I guess this is related to
>>> * [WICKET-2451] - Add ability to load UTF-8 encoded properties not
>>> in XML format.
>>>
>>>
>>> I know I shouldn't be using ISO-8859-1... but right now I have a bunch of
>>> those properties files. Is there an easy way to get around this?....
>>> After
>>> looking into changes I see the line (379)....
>>>
>>> Reader reader = new InputStreamReader(is, "UTF-8");
>>>
>>> Shouldn't this be cofingurable somehow?
>>>
>>> Best,
>>>
>>> Ernesto
>>>
>>>
>>> On Mon, Sep 28, 2009 at 2:33 AM, Igor Vaynberg
>>> <igor.vaynberg@...>wrote:
>>>
>>>> all votes are more then welcome.
>>>>
>>>> -igor
>>>>
>>>> On Sun, Sep 27, 2009 at 5:20 PM, Sam Stainsby
>>>> <sam@...> wrote:
>>>>>
>>>>> Are non-binding votes preferred or discouraged here? If the former,
>>>>> then
>>>>> after some testing with my projects:
>>>>>
>>>>> (nonbinding)
>>>>> [X] Yes release
>>>>> [ ] No, don't release it and here is why...
>>>>>
>>>>>
>>>>
>>>
>
>

[Vladimir K]

[] Yes release
[X] No, don't release it and here is why...

Igor, can I ask you to work a bit on my patch for wicket-2491 in order to add it to 1.4.2? I find the problem important because any mounted page containing ajax multipart form submit does not work.
The fix can be wrong but it shows the key points where multipart form submitting is inconsistent with the regular ajax submit.
I'm concerned about how MultipartServletWebRequest is created. It contains its own copy of RequestParameters. I just propagated URL depth property that is used when prepending the resource URL and I consider it inconsistent. Pprobably propagation of RequestParameters instance would be more consistent.

There is another problem. Multipart form ajax submit might result in invocation of setResponsePage(). In fact in produces the response that contains just "-" sign ("<ajax-response />" is expected afaik). Could you have a look at that as well?

[nino martinez wael]

This is correct Juergen. I've playede around this a couple of years back.
And was exactly what I discovered. For me the default are inherieted from
the container and that are cp1252, at least in eclipse.. I would believe
that eclipse are grabbing the same way as tomcat maven etc.. You actually
have to configure maven to use UTF for example other wise it will also grab
code page from os etc....

2009/9/28 Juergen Donnerstag <juergen.donnerstag@...>

> I think SUNs default is the char encoding configured with the OS or
> env vars. If you don't explicitly provide a char encoding, that is
> what is used. I don't think we should assume ISO 8859-1 or any other
> to be the default, but use what is configured with the OS/env.
>
> -Juergen
>
> On Mon, Sep 28, 2009 at 1:49 PM, Robin Sander <robin.sander@...>
> wrote:
> >
> > I think the default should remain ISO 8859-1 because otherwise 1.4.2
> > wouldn't be
> > backward compatible.
> > And isn't the Java default for property files ISO 8859-1so any deveoper
> and
> > most IDEs
> > would assume this encoding?
> >
> > robin.
> >
> >
> > On Sep 28, 2009, at 11:42, Johan Compagner wrote:
> >
> >> -1 then yes
> >> that shouldnt be hardcoded but a property in our settings.
> >>
> >>
> >> On Mon, Sep 28, 2009 at 11:02, Ernesto Reinaldo Barreiro
> >> <reiern70@...
> >>>
> >>> wrote:
> >>
> >>>> [ X] No, don't release it and here is why...
> >>>>
> >>>
> >>> After upgrading to 1.4.2 all my ISO-8859-1 encoded property files fail
> to
> >>> work. I haven't look into it in detail but I guess this is related to
> >>> * [WICKET-2451] - Add ability to load UTF-8 encoded properties not
> >>> in XML format.
> >>>
> >>>
> >>> I know I shouldn't be using ISO-8859-1... but right now I have a bunch
> of
> >>> those properties files. Is there an easy way to get around this?....
> >>> After
> >>> looking into changes I see the line (379)....
> >>>
> >>> Reader reader = new InputStreamReader(is, "UTF-8");
> >>>
> >>> Shouldn't this be cofingurable somehow?
> >>>
> >>> Best,
> >>>
> >>> Ernesto
> >>>
> >>>
> >>> On Mon, Sep 28, 2009 at 2:33 AM, Igor Vaynberg <
> igor.vaynberg@...
> >>>>
> >>>> wrote:
> >>>
> >>>> all votes are more then welcome.
> >>>>
> >>>> -igor
> >>>>
> >>>> On Sun, Sep 27, 2009 at 5:20 PM, Sam Stainsby
> >>>> <sam@...> wrote:
> >>>>>
> >>>>> Are non-binding votes preferred or discouraged here? If the former,
> >>>
> >>> then
> >>>>>
> >>>>> after some testing with my projects:
> >>>>>
> >>>>> (nonbinding)
> >>>>> [X] Yes release
> >>>>> [ ] No, don't release it and here is why...
> >>>>>
> >>>>>
> >>>>
> >>>
> >
> >
>