[jira] [Updated] (WICKET-5647) missing generic cast causes compile error on OS X / jdk 8
[
https://issues.apache.org/jira/browse/WICKET-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl updated WICKET-5647:
---
Description:
when trying to compile wicket-7 from HEAD it fails under OS X / JDK 1.8.0_11.
Casting a NULL to generic type (T) solves the issues. This seems like some odd
case of failing type inference.
The problematic source line is:
{code}return getEnumImpl(key, eClass, null);{code}
The compiler error is:
{code}Error:(792, 35) java: incompatible types: inference variable T has
incompatible upper bounds java.lang.Enum,T{code}
This will fix the issue:
{code}return getEnumImpl(key, eClass, (T)null);{code}
I found that there is a fix WICKET-5427 which does not work in most current JDK
1.8.0_11 anymore. --Could not change the wicket-6 branch since the change will
break the clirr plugin (see WICKET-5427).--
was:
when trying to compile wicket-7 from HEAD it fails under OS X / JDK 1.8.0_11.
Casting a NULL to generic type (T) solves the issues. This seems like some odd
case of failing type inference.
The problematic source line is:
{{return getEnumImpl(key, eClass, null);}}
The compiler error is:
{{Error:(792, 35) java: incompatible types: inference variable T has
incompatible upper bounds java.lang.Enum,T}}
This will fix the issue:
{{return getEnumImpl(key, eClass, (T)null);}}
I found that there is a fix WICKET-5427 which does not work in most current JDK
1.8.0_11 anymore. --Could not change the wicket-6 branch since the change will
break the clirr plugin (see WICKET-5427).--
> missing generic cast causes compile error on OS X / jdk 8
> -
>
> Key: WICKET-5647
> URL: https://issues.apache.org/jira/browse/WICKET-5647
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 6.16.0, 7.0.0-M2
> Environment: OS X 10.9.4
> JDK 1.8.0_11
>Reporter: Peter Ertl
>Assignee: Peter Ertl
> Fix For: 7.0.0-M3, 6.17.0
>
>
> when trying to compile wicket-7 from HEAD it fails under OS X / JDK 1.8.0_11.
> Casting a NULL to generic type (T) solves the issues. This seems like some
> odd case of failing type inference.
> The problematic source line is:
> {code}return getEnumImpl(key, eClass, null);{code}
> The compiler error is:
> {code}Error:(792, 35) java: incompatible types: inference variable T has
> incompatible upper bounds java.lang.Enum,T{code}
> This will fix the issue:
> {code}return getEnumImpl(key, eClass, (T)null);{code}
> I found that there is a fix WICKET-5427 which does not work in most current
> JDK 1.8.0_11 anymore. --Could not change the wicket-6 branch since the change
> will break the clirr plugin (see WICKET-5427).--
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (WICKET-5647) missing generic cast causes compile error on OS X / jdk 8
[
https://issues.apache.org/jira/browse/WICKET-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl updated WICKET-5647:
---
Description:
when trying to compile wicket-7 from HEAD it fails under OS X / JDK 1.8.0_11.
Casting a NULL to generic type (T) solves the issues. This seems like some odd
case of failing type inference.
The problematic source line is:
{{return getEnumImpl(key, eClass, null);}}
The compiler error is:
{{Error:(792, 35) java: incompatible types: inference variable T has
incompatible upper bounds java.lang.Enum,T}}
This will fix the issue:
{{return getEnumImpl(key, eClass, (T)null);}}
I found that there is a fix WICKET-5427 which does not work in most current JDK
1.8.0_11 anymore. --Could not change the wicket-6 branch since the change will
break the clirr plugin (see WICKET-5427).--
was:
when trying to compile wicket-7 from HEAD it fails under OS X / JDK 1.8.0_11.
Casting a NULL to generic type (T) solves the issues. This seems like some odd
case of failing type inference.
The problematic source line is:
{{return getEnumImpl(key, eClass, null);}}
The compiler error is:
{{Error:(792, 35) java: incompatible types: inference variable T has
incompatible upper bounds java.lang.Enum,T}}
This will fix the issue:
{{return getEnumImpl(key, eClass, *(T)*null);}}
I found that there is a fix WICKET-5427 which does not work in most current JDK
1.8.0_11 anymore. --Could not change the wicket-6 branch since the change will
break the clirr plugin (see WICKET-5427).--
> missing generic cast causes compile error on OS X / jdk 8
> -
>
> Key: WICKET-5647
> URL: https://issues.apache.org/jira/browse/WICKET-5647
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 6.16.0, 7.0.0-M2
> Environment: OS X 10.9.4
> JDK 1.8.0_11
>Reporter: Peter Ertl
>Assignee: Peter Ertl
> Fix For: 7.0.0-M3, 6.17.0
>
>
> when trying to compile wicket-7 from HEAD it fails under OS X / JDK 1.8.0_11.
> Casting a NULL to generic type (T) solves the issues. This seems like some
> odd case of failing type inference.
> The problematic source line is:
> {{return getEnumImpl(key, eClass, null);}}
> The compiler error is:
> {{Error:(792, 35) java: incompatible types: inference variable T has
> incompatible upper bounds java.lang.Enum,T}}
> This will fix the issue:
> {{return getEnumImpl(key, eClass, (T)null);}}
> I found that there is a fix WICKET-5427 which does not work in most current
> JDK 1.8.0_11 anymore. --Could not change the wicket-6 branch since the change
> will break the clirr plugin (see WICKET-5427).--
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (WICKET-5647) missing generic cast causes compile error on OS X / jdk 8
[
https://issues.apache.org/jira/browse/WICKET-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl updated WICKET-5647:
---
Description:
when trying to compile wicket-7 from HEAD it fails under OS X / JDK 1.8.0_11.
Casting a NULL to generic type (T) solves the issues. This seems like some odd
case of failing type inference.
The problematic source line is:
{{return getEnumImpl(key, eClass, null);}}
The compiler error is:
{{Error:(792, 35) java: incompatible types: inference variable T has
incompatible upper bounds java.lang.Enum,T}}
This will fix the issue:
{{return getEnumImpl(key, eClass, *(T)*null);}}
I found that there is a fix WICKET-5427 which does not work in most current JDK
1.8.0_11 anymore. --Could not change the wicket-6 branch since the change will
break the clirr plugin (see WICKET-5427).--
was:
when trying to compile wicket-7 from HEAD it fails under OS X / JDK 1.8.0_11.
Casting a NULL to generic type (T) solves the issues. This seems like some odd
case of failing type inference.
The problematic source line is:
return getEnumImpl(key, eClass, null);
The compiler error is:
Error:(792, 35) java: incompatible types: inference variable T has
incompatible upper bounds java.lang.Enum,T
This will fix the issue:
return getEnumImpl(key, eClass, (T)null);
I found that there is a fix WICKET-5427 which does not work in most current JDK
1.8.0_11 anymore. --Could not change the wicket-6 branch since the change will
break the clirr plugin (see WICKET-5427).--
> missing generic cast causes compile error on OS X / jdk 8
> -
>
> Key: WICKET-5647
> URL: https://issues.apache.org/jira/browse/WICKET-5647
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 6.16.0, 7.0.0-M2
> Environment: OS X 10.9.4
> JDK 1.8.0_11
>Reporter: Peter Ertl
>Assignee: Peter Ertl
> Fix For: 7.0.0-M3, 6.17.0
>
>
> when trying to compile wicket-7 from HEAD it fails under OS X / JDK 1.8.0_11.
> Casting a NULL to generic type (T) solves the issues. This seems like some
> odd case of failing type inference.
> The problematic source line is:
> {{return getEnumImpl(key, eClass, null);}}
> The compiler error is:
> {{Error:(792, 35) java: incompatible types: inference variable T has
> incompatible upper bounds java.lang.Enum,T}}
> This will fix the issue:
> {{return getEnumImpl(key, eClass, *(T)*null);}}
> I found that there is a fix WICKET-5427 which does not work in most current
> JDK 1.8.0_11 anymore. --Could not change the wicket-6 branch since the change
> will break the clirr plugin (see WICKET-5427).--
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (WICKET-5647) missing generic cast causes compile error on OS X / jdk 8
[ https://issues.apache.org/jira/browse/WICKET-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl updated WICKET-5647: --- Description: when trying to compile wicket-7 from HEAD it fails under OS X / JDK 1.8.0_11. Casting a NULL to generic type (T) solves the issues. This seems like some odd case of failing type inference. The problematic source line is: return getEnumImpl(key, eClass, null); The compiler error is: Error:(792, 35) java: incompatible types: inference variable T has incompatible upper bounds java.lang.Enum,T This will fix the issue: return getEnumImpl(key, eClass, (T)null); I found that there is a fix WICKET-5427 which does not work in most current JDK 1.8.0_11 anymore. --Could not change the wicket-6 branch since the change will break the clirr plugin (see WICKET-5427).-- was: when trying to compile wicket-7 from HEAD it fails under OS X / JDK 1.8.0_11. Casting a NULL to generic type (T) solves the issues. This seems like some odd case of failing type inference. The problematic source line is: return getEnumImpl(key, eClass, null); The compiler error is: Error:(792, 35) java: incompatible types: inference variable T has incompatible upper bounds java.lang.Enum,T This will fix the issue: return getEnumImpl(key, eClass, (T)null); I found that there is a fix WICKET-5427 which does not work in most current JDK 1.8.0_11 anymore. Could not change the wicket-6 branch since the change will break the clirr plugin (see WICKET-5427). > missing generic cast causes compile error on OS X / jdk 8 > - > > Key: WICKET-5647 > URL: https://issues.apache.org/jira/browse/WICKET-5647 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 6.16.0, 7.0.0-M2 > Environment: OS X 10.9.4 > JDK 1.8.0_11 >Reporter: Peter Ertl >Assignee: Peter Ertl > Fix For: 7.0.0-M3, 6.17.0 > > > when trying to compile wicket-7 from HEAD it fails under OS X / JDK 1.8.0_11. > Casting a NULL to generic type (T) solves the issues. This seems like some > odd case of failing type inference. > The problematic source line is: > return getEnumImpl(key, eClass, null); > The compiler error is: > Error:(792, 35) java: incompatible types: inference variable T has > incompatible upper bounds java.lang.Enum,T > This will fix the issue: > return getEnumImpl(key, eClass, (T)null); > I found that there is a fix WICKET-5427 which does not work in most current > JDK 1.8.0_11 anymore. --Could not change the wicket-6 branch since the change > will break the clirr plugin (see WICKET-5427).-- -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (WICKET-5647) missing generic cast causes compile error on OS X / jdk 8
[ https://issues.apache.org/jira/browse/WICKET-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl updated WICKET-5647: --- Fix Version/s: 6.17.0 > missing generic cast causes compile error on OS X / jdk 8 > - > > Key: WICKET-5647 > URL: https://issues.apache.org/jira/browse/WICKET-5647 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 6.16.0, 7.0.0-M2 > Environment: OS X 10.9.4 > JDK 1.8.0_11 >Reporter: Peter Ertl >Assignee: Peter Ertl > Fix For: 7.0.0-M3, 6.17.0 > > > when trying to compile wicket-7 from HEAD it fails under OS X / JDK 1.8.0_11. > Casting a NULL to generic type (T) solves the issues. This seems like some > odd case of failing type inference. > The problematic source line is: > return getEnumImpl(key, eClass, null); > The compiler error is: > Error:(792, 35) java: incompatible types: inference variable T has > incompatible upper bounds java.lang.Enum,T > This will fix the issue: > return getEnumImpl(key, eClass, (T)null); > I found that there is a fix WICKET-5427 which does not work in most current > JDK 1.8.0_11 anymore. Could not change the wicket-6 branch since the change > will break the clirr plugin (see WICKET-5427). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (WICKET-5647) missing generic cast causes compile error on OS X / jdk 8
[ https://issues.apache.org/jira/browse/WICKET-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl updated WICKET-5647: --- Affects Version/s: 6.16.0 > missing generic cast causes compile error on OS X / jdk 8 > - > > Key: WICKET-5647 > URL: https://issues.apache.org/jira/browse/WICKET-5647 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 6.16.0, 7.0.0-M2 > Environment: OS X 10.9.4 > JDK 1.8.0_11 >Reporter: Peter Ertl >Assignee: Peter Ertl > Fix For: 7.0.0-M3, 6.17.0 > > > when trying to compile wicket-7 from HEAD it fails under OS X / JDK 1.8.0_11. > Casting a NULL to generic type (T) solves the issues. This seems like some > odd case of failing type inference. > The problematic source line is: > return getEnumImpl(key, eClass, null); > The compiler error is: > Error:(792, 35) java: incompatible types: inference variable T has > incompatible upper bounds java.lang.Enum,T > This will fix the issue: > return getEnumImpl(key, eClass, (T)null); > I found that there is a fix WICKET-5427 which does not work in most current > JDK 1.8.0_11 anymore. Could not change the wicket-6 branch since the change > will break the clirr plugin (see WICKET-5427). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (WICKET-5647) missing generic cast causes compile error on OS X / jdk 8
[ https://issues.apache.org/jira/browse/WICKET-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl updated WICKET-5647: --- Description: when trying to compile wicket-7 from HEAD it fails under OS X / JDK 1.8.0_11. Casting a NULL to generic type (T) solves the issues. This seems like some odd case of failing type inference. The problematic source line is: return getEnumImpl(key, eClass, null); The compiler error is: Error:(792, 35) java: incompatible types: inference variable T has incompatible upper bounds java.lang.Enum,T This will fix the issue: return getEnumImpl(key, eClass, (T)null); I found that there is a fix WICKET-5427 which does not work in most current JDK 1.8.0_11 anymore. Could not change the wicket-6 branch since the change will break the clirr plugin (see WICKET-5427). was: when trying to compile wicket-7 from HEAD it fails under OS X / JDK 1.8.0_11. Casting a NULL to generic type (T) solves the issues. This seems like some odd case of failing type inference. The problematic source line is: return getEnumImpl(key, eClass, null); The compiler error is: Error:(792, 35) java: incompatible types: inference variable T has incompatible upper bounds java.lang.Enum,T This will fix the issue: return getEnumImpl(key, eClass, (T)null); I found that there is a fix WICKET-5427 which does not work in most current JDK 1.8.0_11 anymore. > missing generic cast causes compile error on OS X / jdk 8 > - > > Key: WICKET-5647 > URL: https://issues.apache.org/jira/browse/WICKET-5647 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 7.0.0-M2 > Environment: OS X 10.9.4 > JDK 1.8.0_11 >Reporter: Peter Ertl >Assignee: Peter Ertl > Fix For: 7.0.0-M3 > > > when trying to compile wicket-7 from HEAD it fails under OS X / JDK 1.8.0_11. > Casting a NULL to generic type (T) solves the issues. This seems like some > odd case of failing type inference. > The problematic source line is: > return getEnumImpl(key, eClass, null); > The compiler error is: > Error:(792, 35) java: incompatible types: inference variable T has > incompatible upper bounds java.lang.Enum,T > This will fix the issue: > return getEnumImpl(key, eClass, (T)null); > I found that there is a fix WICKET-5427 which does not work in most current > JDK 1.8.0_11 anymore. Could not change the wicket-6 branch since the change > will break the clirr plugin (see WICKET-5427). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (WICKET-5467) NumberTextField should support "any" as valid step attribute value
[
https://issues.apache.org/jira/browse/WICKET-5467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl updated WICKET-5467:
---
Fix Version/s: 6.14.0
> NumberTextField should support "any" as valid step attribute value
> --
>
> Key: WICKET-5467
> URL: https://issues.apache.org/jira/browse/WICKET-5467
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 6.13.0
> Environment: wicket 6.11.0
>Reporter: Per Newgro
>Assignee: Martin Grigorov
> Labels: WICKET-5096
> Fix For: 6.14.0, 7.0.0-M1
>
> Attachments: fix-WICKET-5467-src.zip, fix-WICKET-5467.patch
>
>
> The NumberTextField removes the any value from step attribute added to markup.
> E.g.
> and add(new NumberTextField("myNumber", numModel);
> leads to markup
>
> but should be
>
> I can see 2 possbile solutions
> 1. Don't remove the step attribute
> 2. Add a constant ANY to NumberTextField
> public static final Number ANY = 0;
> and let this be configurable to users (setStep(ANY))
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (WICKET-5647) missing generic cast causes compile error on OS X / jdk 8
[ https://issues.apache.org/jira/browse/WICKET-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl updated WICKET-5647: --- Affects Version/s: (was: 6.16.0) > missing generic cast causes compile error on OS X / jdk 8 > - > > Key: WICKET-5647 > URL: https://issues.apache.org/jira/browse/WICKET-5647 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 7.0.0-M2 > Environment: OS X 10.9.4 > JDK 1.8.0_11 >Reporter: Peter Ertl >Assignee: Peter Ertl > Fix For: 7.0.0-M3 > > > when trying to compile wicket-7 from HEAD it fails under OS X / JDK 1.8.0_11. > Casting a NULL to generic type (T) solves the issues. This seems like some > odd case of failing type inference. > The problematic source line is: > return getEnumImpl(key, eClass, null); > The compiler error is: > Error:(792, 35) java: incompatible types: inference variable T has > incompatible upper bounds java.lang.Enum,T > This will fix the issue: > return getEnumImpl(key, eClass, (T)null); > I found that there is a fix WICKET-5427 which does not work in most current > JDK 1.8.0_11 anymore. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (WICKET-5467) NumberTextField should support "any" as valid step attribute value
[
https://issues.apache.org/jira/browse/WICKET-5467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl updated WICKET-5467:
---
Fix Version/s: (was: 6.14.0)
> NumberTextField should support "any" as valid step attribute value
> --
>
> Key: WICKET-5467
> URL: https://issues.apache.org/jira/browse/WICKET-5467
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 6.13.0
> Environment: wicket 6.11.0
>Reporter: Per Newgro
>Assignee: Martin Grigorov
> Labels: WICKET-5096
> Fix For: 6.14.0, 7.0.0-M1
>
> Attachments: fix-WICKET-5467-src.zip, fix-WICKET-5467.patch
>
>
> The NumberTextField removes the any value from step attribute added to markup.
> E.g.
> and add(new NumberTextField("myNumber", numModel);
> leads to markup
>
> but should be
>
> I can see 2 possbile solutions
> 1. Don't remove the step attribute
> 2. Add a constant ANY to NumberTextField
> public static final Number ANY = 0;
> and let this be configurable to users (setStep(ANY))
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (WICKET-5647) missing generic cast causes compile error on OS X / jdk 8
[ https://issues.apache.org/jira/browse/WICKET-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl updated WICKET-5647: --- Fix Version/s: (was: 6.17.0) > missing generic cast causes compile error on OS X / jdk 8 > - > > Key: WICKET-5647 > URL: https://issues.apache.org/jira/browse/WICKET-5647 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 7.0.0-M2 > Environment: OS X 10.9.4 > JDK 1.8.0_11 >Reporter: Peter Ertl >Assignee: Peter Ertl > Fix For: 7.0.0-M3 > > > when trying to compile wicket-7 from HEAD it fails under OS X / JDK 1.8.0_11. > Casting a NULL to generic type (T) solves the issues. This seems like some > odd case of failing type inference. > The problematic source line is: > return getEnumImpl(key, eClass, null); > The compiler error is: > Error:(792, 35) java: incompatible types: inference variable T has > incompatible upper bounds java.lang.Enum,T > This will fix the issue: > return getEnumImpl(key, eClass, (T)null); > I found that there is a fix WICKET-5427 which does not work in most current > JDK 1.8.0_11 anymore. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (WICKET-5647) missing generic cast causes compile error on OS X / jdk 8
[ https://issues.apache.org/jira/browse/WICKET-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl updated WICKET-5647: --- Fix Version/s: 6.17.0 7.0.0-M3 > missing generic cast causes compile error on OS X / jdk 8 > - > > Key: WICKET-5647 > URL: https://issues.apache.org/jira/browse/WICKET-5647 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 6.16.0, 7.0.0-M2 > Environment: OS X 10.9.4 > JDK 1.8.0_11 >Reporter: Peter Ertl >Assignee: Peter Ertl > Fix For: 7.0.0-M3, 6.17.0 > > > when trying to compile wicket-7 from HEAD it fails under OS X / JDK 1.8.0_11. > Casting a NULL to generic type (T) solves the issues. This seems like some > odd case of failing type inference. > The problematic source line is: > return getEnumImpl(key, eClass, null); > The compiler error is: > Error:(792, 35) java: incompatible types: inference variable T has > incompatible upper bounds java.lang.Enum,T > This will fix the issue: > return getEnumImpl(key, eClass, (T)null); > I found that there is a fix WICKET-5427 which does not work in most current > JDK 1.8.0_11 anymore. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (WICKET-5647) missing generic cast causes compile error on OS X / jdk 8
[ https://issues.apache.org/jira/browse/WICKET-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl resolved WICKET-5647. Resolution: Fixed > missing generic cast causes compile error on OS X / jdk 8 > - > > Key: WICKET-5647 > URL: https://issues.apache.org/jira/browse/WICKET-5647 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 6.16.0, 7.0.0-M2 > Environment: OS X 10.9.4 > JDK 1.8.0_11 >Reporter: Peter Ertl >Assignee: Peter Ertl > Fix For: 7.0.0-M3, 6.17.0 > > > when trying to compile wicket-7 from HEAD it fails under OS X / JDK 1.8.0_11. > Casting a NULL to generic type (T) solves the issues. This seems like some > odd case of failing type inference. > The problematic source line is: > return getEnumImpl(key, eClass, null); > The compiler error is: > Error:(792, 35) java: incompatible types: inference variable T has > incompatible upper bounds java.lang.Enum,T > This will fix the issue: > return getEnumImpl(key, eClass, (T)null); > I found that there is a fix WICKET-5427 which does not work in most current > JDK 1.8.0_11 anymore. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (WICKET-5647) missing generic cast causes compile error on OS X / jdk 8
[ https://issues.apache.org/jira/browse/WICKET-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl updated WICKET-5647: --- Affects Version/s: 6.16.0 > missing generic cast causes compile error on OS X / jdk 8 > - > > Key: WICKET-5647 > URL: https://issues.apache.org/jira/browse/WICKET-5647 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 6.16.0, 7.0.0-M2 > Environment: OS X 10.9.4 > JDK 1.8.0_11 >Reporter: Peter Ertl >Assignee: Peter Ertl > > when trying to compile wicket-7 from HEAD it fails under OS X / JDK 1.8.0_11. > Casting a NULL to generic type (T) solves the issues. This seems like some > odd case of failing type inference. > The problematic source line is: > return getEnumImpl(key, eClass, null); > The compiler error is: > Error:(792, 35) java: incompatible types: inference variable T has > incompatible upper bounds java.lang.Enum,T > This will fix the issue: > return getEnumImpl(key, eClass, (T)null); -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (WICKET-5647) missing generic cast causes compile error on OS X / jdk 8
[ https://issues.apache.org/jira/browse/WICKET-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl updated WICKET-5647: --- Description: when trying to compile wicket-7 from HEAD it fails under OS X / JDK 1.8.0_11. Casting a NULL to generic type (T) solves the issues. This seems like some odd case of failing type inference. The problematic source line is: return getEnumImpl(key, eClass, null); The compiler error is: Error:(792, 35) java: incompatible types: inference variable T has incompatible upper bounds java.lang.Enum,T This will fix the issue: return getEnumImpl(key, eClass, (T)null); I found that there is a fix WICKET-5427 which does not work in most current JDK 1.8.0_11 anymore. was: when trying to compile wicket-7 from HEAD it fails under OS X / JDK 1.8.0_11. Casting a NULL to generic type (T) solves the issues. This seems like some odd case of failing type inference. The problematic source line is: return getEnumImpl(key, eClass, null); The compiler error is: Error:(792, 35) java: incompatible types: inference variable T has incompatible upper bounds java.lang.Enum,T This will fix the issue: return getEnumImpl(key, eClass, (T)null); > missing generic cast causes compile error on OS X / jdk 8 > - > > Key: WICKET-5647 > URL: https://issues.apache.org/jira/browse/WICKET-5647 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 6.16.0, 7.0.0-M2 > Environment: OS X 10.9.4 > JDK 1.8.0_11 >Reporter: Peter Ertl >Assignee: Peter Ertl > > when trying to compile wicket-7 from HEAD it fails under OS X / JDK 1.8.0_11. > Casting a NULL to generic type (T) solves the issues. This seems like some > odd case of failing type inference. > The problematic source line is: > return getEnumImpl(key, eClass, null); > The compiler error is: > Error:(792, 35) java: incompatible types: inference variable T has > incompatible upper bounds java.lang.Enum,T > This will fix the issue: > return getEnumImpl(key, eClass, (T)null); > I found that there is a fix WICKET-5427 which does not work in most current > JDK 1.8.0_11 anymore. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (WICKET-5647) missing generic cast causes compile error on OS X / jdk 8
Peter Ertl created WICKET-5647: -- Summary: missing generic cast causes compile error on OS X / jdk 8 Key: WICKET-5647 URL: https://issues.apache.org/jira/browse/WICKET-5647 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 7.0.0-M2 Environment: OS X 10.9.4 JDK 1.8.0_11 Reporter: Peter Ertl Assignee: Peter Ertl when trying to compile wicket-7 from HEAD it fails under OS X / JDK 1.8.0_11. Casting a NULL to generic type (T) solves the issues. This seems like some odd case of failing type inference. The problematic source line is: return getEnumImpl(key, eClass, null); The compiler error is: Error:(792, 35) java: incompatible types: inference variable T has incompatible upper bounds java.lang.Enum,T This will fix the issue: return getEnumImpl(key, eClass, (T)null); -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (WICKET-4848) Reporter of FeedbackMessage should not be set to 'null' on detach
[ https://issues.apache.org/jira/browse/WICKET-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl resolved WICKET-4848. Resolution: Fixed Fix Version/s: 6.3.0 > Reporter of FeedbackMessage should not be set to 'null' on detach > - > > Key: WICKET-4848 > URL: https://issues.apache.org/jira/browse/WICKET-4848 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 6.2.0 >Reporter: Peter Ertl >Assignee: Peter Ertl >Priority: Minor > Fix For: 6.3.0 > > > When FeedbackMessages are detached via IDetachable#detach() the reporter of > the message is set to null. > This seems to be part of legacy cleanup before feedback messages were stored > in the components meta data. > Since settings the reporter to null changes the state of the message and > also partially bypasses the logic behing > IApplicationSettings#setFeedbackMessageCleanupFilter(..) > we should remove that logic. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (WICKET-4848) Reporter of FeedbackMessage should not be set to 'null' on detach
Peter Ertl created WICKET-4848: -- Summary: Reporter of FeedbackMessage should not be set to 'null' on detach Key: WICKET-4848 URL: https://issues.apache.org/jira/browse/WICKET-4848 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 6.2.0 Reporter: Peter Ertl Assignee: Peter Ertl Priority: Minor When FeedbackMessages are detached via IDetachable#detach() the reporter of the message is set to null. This seems to be part of legacy cleanup before feedback messages were stored in the components meta data. Since settings the reporter to null changes the state of the message and also partially bypasses the logic behing IApplicationSettings#setFeedbackMessageCleanupFilter(..) we should remove that logic. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4745) Allow to set initial state of DebugBar to expanded / collapsed
[
https://issues.apache.org/jira/browse/WICKET-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl updated WICKET-4745:
---
Fix Version/s: (was: 6.0.1)
6.1.0
> Allow to set initial state of DebugBar to expanded / collapsed
> --
>
> Key: WICKET-4745
> URL: https://issues.apache.org/jira/browse/WICKET-4745
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-devutils
>Affects Versions: 1.5.8, 6.0.0
> Environment: Wicket 1.5
>Reporter: Markus Krischke
>Assignee: Peter Ertl
>Priority: Minor
> Fix For: 6.1.0, 1.5.9
>
>
> The current implementation of DebugBar initially loads in expanded state and
> can be collapsed by clicking on it.
> If possible I would like to be able to set the initial state of the DebugBar
> from code.
> Right now I'm using
> @Override
> public void renderHead(final IHeaderResponse response) {
>super.renderHead(response);
>response.renderOnLoadJavaScript("wicketDebugBarCollapse();");
> }
> as a workaround.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4745) Allow to set initial state of DebugBar to expanded / collapsed
[
https://issues.apache.org/jira/browse/WICKET-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454821#comment-13454821
]
Peter Ertl commented on WICKET-4745:
true :-)
I changed it.
> Allow to set initial state of DebugBar to expanded / collapsed
> --
>
> Key: WICKET-4745
> URL: https://issues.apache.org/jira/browse/WICKET-4745
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-devutils
>Affects Versions: 1.5.8, 6.0.0
> Environment: Wicket 1.5
>Reporter: Markus Krischke
>Assignee: Peter Ertl
>Priority: Minor
> Fix For: 6.1.0, 1.5.9
>
>
> The current implementation of DebugBar initially loads in expanded state and
> can be collapsed by clicking on it.
> If possible I would like to be able to set the initial state of the DebugBar
> from code.
> Right now I'm using
> @Override
> public void renderHead(final IHeaderResponse response) {
>super.renderHead(response);
>response.renderOnLoadJavaScript("wicketDebugBarCollapse();");
> }
> as a workaround.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-4745) Allow to set initial state of DebugBar to expanded / collapsed
[
https://issues.apache.org/jira/browse/WICKET-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl resolved WICKET-4745.
Resolution: Fixed
Fix Version/s: 1.5.9
6.0.1
> Allow to set initial state of DebugBar to expanded / collapsed
> --
>
> Key: WICKET-4745
> URL: https://issues.apache.org/jira/browse/WICKET-4745
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-devutils
>Affects Versions: 1.5.8, 6.0.0
> Environment: Wicket 1.5
>Reporter: Markus Krischke
>Assignee: Peter Ertl
>Priority: Minor
> Fix For: 6.0.1, 1.5.9
>
>
> The current implementation of DebugBar initially loads in expanded state and
> can be collapsed by clicking on it.
> If possible I would like to be able to set the initial state of the DebugBar
> from code.
> Right now I'm using
> @Override
> public void renderHead(final IHeaderResponse response) {
>super.renderHead(response);
>response.renderOnLoadJavaScript("wicketDebugBarCollapse();");
> }
> as a workaround.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4745) Allow to set initial state of DebugBar to expanded / collapsed
[
https://issues.apache.org/jira/browse/WICKET-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13447364#comment-13447364
]
Peter Ertl commented on WICKET-4745:
fixed for next release of 1.5 and 6.0
added additional constructor
public DebugBar(final String id, boolean initiallyExpanded)
to specify the initial state (expanded / collapsed) of the debug bar.
> Allow to set initial state of DebugBar to expanded / collapsed
> --
>
> Key: WICKET-4745
> URL: https://issues.apache.org/jira/browse/WICKET-4745
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-devutils
>Affects Versions: 1.5.8, 6.0.0
> Environment: Wicket 1.5
>Reporter: Markus Krischke
>Assignee: Peter Ertl
>Priority: Minor
> Fix For: 6.0.1, 1.5.9
>
>
> The current implementation of DebugBar initially loads in expanded state and
> can be collapsed by clicking on it.
> If possible I would like to be able to set the initial state of the DebugBar
> from code.
> Right now I'm using
> @Override
> public void renderHead(final IHeaderResponse response) {
>super.renderHead(response);
>response.renderOnLoadJavaScript("wicketDebugBarCollapse();");
> }
> as a workaround.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4745) Allow to set initial state of DebugBar to expanded / collapsed
[
https://issues.apache.org/jira/browse/WICKET-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl updated WICKET-4745:
---
Component/s: wicket-devutils
Affects Version/s: 1.5.8
6.0.0
> Allow to set initial state of DebugBar to expanded / collapsed
> --
>
> Key: WICKET-4745
> URL: https://issues.apache.org/jira/browse/WICKET-4745
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-devutils
>Affects Versions: 1.5.8, 6.0.0
> Environment: Wicket 1.5
>Reporter: Markus Krischke
>Assignee: Peter Ertl
>Priority: Minor
>
> The current implementation of DebugBar initially loads in expanded state and
> can be collapsed by clicking on it.
> If possible I would like to be able to set the initial state of the DebugBar
> from code.
> Right now I'm using
> @Override
> public void renderHead(final IHeaderResponse response) {
>super.renderHead(response);
>response.renderOnLoadJavaScript("wicketDebugBarCollapse();");
> }
> as a workaround.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (WICKET-4745) Allow to set initial state of DebugBar to expanded / collapsed
[
https://issues.apache.org/jira/browse/WICKET-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl reassigned WICKET-4745:
--
Assignee: Peter Ertl
> Allow to set initial state of DebugBar to expanded / collapsed
> --
>
> Key: WICKET-4745
> URL: https://issues.apache.org/jira/browse/WICKET-4745
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-devutils
>Affects Versions: 1.5.8, 6.0.0
> Environment: Wicket 1.5
>Reporter: Markus Krischke
>Assignee: Peter Ertl
>Priority: Minor
>
> The current implementation of DebugBar initially loads in expanded state and
> can be collapsed by clicking on it.
> If possible I would like to be able to set the initial state of the DebugBar
> from code.
> Right now I'm using
> @Override
> public void renderHead(final IHeaderResponse response) {
>super.renderHead(response);
>response.renderOnLoadJavaScript("wicketDebugBarCollapse();");
> }
> as a workaround.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-4539) move UrlEncoder and UrlDecoder into wicket-util
[ https://issues.apache.org/jira/browse/WICKET-4539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl resolved WICKET-4539. Resolution: Fixed Fix Version/s: 6.0.0-beta1 > move UrlEncoder and UrlDecoder into wicket-util > --- > > Key: WICKET-4539 > URL: https://issues.apache.org/jira/browse/WICKET-4539 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 6.0.0-beta1 >Reporter: Peter Ertl >Assignee: Peter Ertl >Priority: Minor > Fix For: 6.0.0-beta1 > > > move these classes into wicket-util since they are generally usable classes > for encoding to /decoding from RFC 3986 strings > (http://www.ietf.org/rfc/rfc3986.txt). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (WICKET-4539) move UrlEncoder and UrlDecoder into wicket-util
Peter Ertl created WICKET-4539: -- Summary: move UrlEncoder and UrlDecoder into wicket-util Key: WICKET-4539 URL: https://issues.apache.org/jira/browse/WICKET-4539 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 6.0.0-beta1 Reporter: Peter Ertl Assignee: Peter Ertl Priority: Minor move these classes into wicket-util since they are generally usable classes for encoding to /decoding from RFC 3986 strings (http://www.ietf.org/rfc/rfc3986.txt). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4457) setTextEncoding on JavascriptResourceReferences/CssResourceReferences
[
https://issues.apache.org/jira/browse/WICKET-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13270064#comment-13270064
]
Peter Ertl commented on WICKET-4457:
sample (wicket 1.5.x)
JavaScriptResourceReference reference = new
JavaScriptResourceReference(Home.class, "foo.js")
{
@Override
public IResource getResource()
{
PackageResource resource =
(PackageResource)super.getResource();
resource.setTextEncoding("ISO-8859-1");
return resource;
}
};
sample (wicket 6.x, no cast need like in 1.5.x):
JavaScriptResourceReference reference = new
JavaScriptResourceReference(Home.class, "foo.js")
{
@Override
public JavaScriptPackageResource getResource()
{
JavaScriptPackageResource resource =
super.getResource();
resource.setTextEncoding("ISO-8859-1");
return resource;
}
};
> setTextEncoding on JavascriptResourceReferences/CssResourceReferences
> -
>
> Key: WICKET-4457
> URL: https://issues.apache.org/jira/browse/WICKET-4457
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Affects Versions: 1.5.4, 6.0.0-beta1
>Reporter: David Loidolt
>Assignee: Peter Ertl
> Fix For: 6.0.0-beta1, 1.5.7
>
>
> Setting the encoding of JavascriptResources and CssResources in wicket is by
> now not easily to achieve.
> By now only html files are equipped with the charset option afterwads, but
> not CSS or JS files.
> Content-Type: application/javascript;charset=UTF8
> org.apache.wicket.request.resource.AbstractResource#setResponseHeaders() does
> take the textEncoding into account,
> but there is no way to set it from the outside without introducing new
> classes by copy/pasting existing Resources and adapt them.
> The only resource which is able to modify the content-type through the
> constructor is the TextTemplateResource.
> One can specify "application/javascript; charset=UTF8" and pass it as the
> content-type parameter.
> It's a hack, but this string then used for the content-type header.
> A separate charset parameter would be better in my opinion.
> UserGroup post:
> http://apache-wicket.1842946.n4.nabble.com/setTextEncoding-on-JavascriptResourceReferences-CssResourceReferences-td4472204.html
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-4457) setTextEncoding on JavascriptResourceReferences/CssResourceReferences
[ https://issues.apache.org/jira/browse/WICKET-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl resolved WICKET-4457. Resolution: Fixed Fix Version/s: 6.0.0-beta1 1.5.7 > setTextEncoding on JavascriptResourceReferences/CssResourceReferences > - > > Key: WICKET-4457 > URL: https://issues.apache.org/jira/browse/WICKET-4457 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.5.4, 6.0.0-beta1 >Reporter: David Loidolt >Assignee: Peter Ertl > Fix For: 1.5.7, 6.0.0-beta1 > > > Setting the encoding of JavascriptResources and CssResources in wicket is by > now not easily to achieve. > By now only html files are equipped with the charset option afterwads, but > not CSS or JS files. > Content-Type: application/javascript;charset=UTF8 > org.apache.wicket.request.resource.AbstractResource#setResponseHeaders() does > take the textEncoding into account, > but there is no way to set it from the outside without introducing new > classes by copy/pasting existing Resources and adapt them. > The only resource which is able to modify the content-type through the > constructor is the TextTemplateResource. > One can specify "application/javascript; charset=UTF8" and pass it as the > content-type parameter. > It's a hack, but this string then used for the content-type header. > A separate charset parameter would be better in my opinion. > UserGroup post: > http://apache-wicket.1842946.n4.nabble.com/setTextEncoding-on-JavascriptResourceReferences-CssResourceReferences-td4472204.html > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4457) setTextEncoding on JavascriptResourceReferences/CssResourceReferences
[ https://issues.apache.org/jira/browse/WICKET-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl updated WICKET-4457: --- Affects Version/s: 6.0.0-beta1 > setTextEncoding on JavascriptResourceReferences/CssResourceReferences > - > > Key: WICKET-4457 > URL: https://issues.apache.org/jira/browse/WICKET-4457 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.5.4, 6.0.0-beta1 >Reporter: David Loidolt >Assignee: Peter Ertl > > Setting the encoding of JavascriptResources and CssResources in wicket is by > now not easily to achieve. > By now only html files are equipped with the charset option afterwads, but > not CSS or JS files. > Content-Type: application/javascript;charset=UTF8 > org.apache.wicket.request.resource.AbstractResource#setResponseHeaders() does > take the textEncoding into account, > but there is no way to set it from the outside without introducing new > classes by copy/pasting existing Resources and adapt them. > The only resource which is able to modify the content-type through the > constructor is the TextTemplateResource. > One can specify "application/javascript; charset=UTF8" and pass it as the > content-type parameter. > It's a hack, but this string then used for the content-type header. > A separate charset parameter would be better in my opinion. > UserGroup post: > http://apache-wicket.1842946.n4.nabble.com/setTextEncoding-on-JavascriptResourceReferences-CssResourceReferences-td4472204.html > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (WICKET-4457) setTextEncoding on JavascriptResourceReferences/CssResourceReferences
[ https://issues.apache.org/jira/browse/WICKET-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl reassigned WICKET-4457: -- Assignee: Peter Ertl > setTextEncoding on JavascriptResourceReferences/CssResourceReferences > - > > Key: WICKET-4457 > URL: https://issues.apache.org/jira/browse/WICKET-4457 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.5.4 >Reporter: David Loidolt >Assignee: Peter Ertl > > Setting the encoding of JavascriptResources and CssResources in wicket is by > now not easily to achieve. > By now only html files are equipped with the charset option afterwads, but > not CSS or JS files. > Content-Type: application/javascript;charset=UTF8 > org.apache.wicket.request.resource.AbstractResource#setResponseHeaders() does > take the textEncoding into account, > but there is no way to set it from the outside without introducing new > classes by copy/pasting existing Resources and adapt them. > The only resource which is able to modify the content-type through the > constructor is the TextTemplateResource. > One can specify "application/javascript; charset=UTF8" and pass it as the > content-type parameter. > It's a hack, but this string then used for the content-type header. > A separate charset parameter would be better in my opinion. > UserGroup post: > http://apache-wicket.1842946.n4.nabble.com/setTextEncoding-on-JavascriptResourceReferences-CssResourceReferences-td4472204.html > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (WICKET-4532) Disable caching for particular resources.
[
https://issues.apache.org/jira/browse/WICKET-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13269477#comment-13269477
]
Peter Ertl edited comment on WICKET-4532 at 5/7/12 10:00 AM:
-
there is now a new method
boolean
org.apache.wicket.request.resource.caching.IStaticCacheableResource#isCachingEnabled()
which controls whether caching is applied or not.
in case of PackageResourceReference (and friends) disabling caching could
e.g.be achieved like this:
PackageResourceReference reference = new
PackageResourceReference(Home.class, "Beer.gif") {
@Override
public PackageResource getResource()
{
final PackageResource resource =
super.getResource();
resource.setCachingEnabled(false);
return resource;
}
};
I will add this to the wiki later...
Since the interface change breaks the api we can not offer this for 1.5.x but
only for 6.x.
was (Author: pete):
there is now a new method
boolean
org.apache.wicket.request.resource.caching.IStaticCacheableResource#isCacheEnabled()
which controls whether caching is applied or not.
in case of PackageResourceReference (and friends) disabling caching could
e.g.be achieved like this:
PackageResourceReference reference = new
PackageResourceReference(Home.class, "Beer.gif") {
@Override
public PackageResource getResource()
{
final PackageResource resource =
super.getResource();
resource.setCacheEnabled(false);
return resource;
}
};
I will add this to the wiki later...
Since the interface change breaks the api we can not offer this for 1.5.x but
only for 6.x.
> Disable caching for particular resources.
> -
>
> Key: WICKET-4532
> URL: https://issues.apache.org/jira/browse/WICKET-4532
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
>Affects Versions: 1.5.5, 6.0.0-beta1
>Reporter: Daniel Lipski
>Assignee: Peter Ertl
>Priority: Minor
> Fix For: 6.0.0-RC1
>
> Attachments: disable-caching-for-resource.patch
>
>
> Currently it is possible to disable resources versioning by :
> getResourceSettings().setCachingStrategy(NoOpResourceCachingStrategy.INSTANCE);
> Unfortunately this disables caching for every resource, it would be nice to
> disable caching for particular (package) resource, something like:
> PackageResourceReference res = new PackageResourceReference();
> res.setCashable(false);
> Caching in general is good think but some javascript libraries get broken
> when filenames are modified with "-ver-..." token.
> Regards
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-4532) Disable caching for particular resources.
[ https://issues.apache.org/jira/browse/WICKET-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl resolved WICKET-4532. Resolution: Fixed Fix Version/s: 6.0.0-RC1 > Disable caching for particular resources. > - > > Key: WICKET-4532 > URL: https://issues.apache.org/jira/browse/WICKET-4532 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5.5, 6.0.0-beta1 >Reporter: Daniel Lipski >Assignee: Peter Ertl >Priority: Minor > Fix For: 6.0.0-RC1 > > Attachments: disable-caching-for-resource.patch > > > Currently it is possible to disable resources versioning by : > getResourceSettings().setCachingStrategy(NoOpResourceCachingStrategy.INSTANCE); > Unfortunately this disables caching for every resource, it would be nice to > disable caching for particular (package) resource, something like: > PackageResourceReference res = new PackageResourceReference(); > res.setCashable(false); > Caching in general is good think but some javascript libraries get broken > when filenames are modified with "-ver-..." token. > Regards -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4532) Disable caching for particular resources.
[ https://issues.apache.org/jira/browse/WICKET-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl updated WICKET-4532: --- Affects Version/s: 6.0.0-beta1 > Disable caching for particular resources. > - > > Key: WICKET-4532 > URL: https://issues.apache.org/jira/browse/WICKET-4532 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5.5, 6.0.0-beta1 >Reporter: Daniel Lipski >Assignee: Peter Ertl >Priority: Minor > Attachments: disable-caching-for-resource.patch > > > Currently it is possible to disable resources versioning by : > getResourceSettings().setCachingStrategy(NoOpResourceCachingStrategy.INSTANCE); > Unfortunately this disables caching for every resource, it would be nice to > disable caching for particular (package) resource, something like: > PackageResourceReference res = new PackageResourceReference(); > res.setCashable(false); > Caching in general is good think but some javascript libraries get broken > when filenames are modified with "-ver-..." token. > Regards -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4532) Disable caching for particular resources.
[
https://issues.apache.org/jira/browse/WICKET-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13269477#comment-13269477
]
Peter Ertl commented on WICKET-4532:
there is now a new method
boolean
org.apache.wicket.request.resource.caching.IStaticCacheableResource#isCacheEnabled()
which controls whether caching is applied or not.
in case of PackageResourceReference (and friends) disabling caching could
e.g.be achieved like this:
PackageResourceReference reference = new
PackageResourceReference(Home.class, "Beer.gif") {
@Override
public PackageResource getResource()
{
final PackageResource resource =
super.getResource();
resource.setCacheEnabled(false);
return resource;
}
};
I will add this to the wiki later...
Since the interface change breaks the api we can not offer this for 1.5.x but
only for 6.x.
> Disable caching for particular resources.
> -
>
> Key: WICKET-4532
> URL: https://issues.apache.org/jira/browse/WICKET-4532
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
>Affects Versions: 1.5.5
>Reporter: Daniel Lipski
>Assignee: Peter Ertl
>Priority: Minor
> Attachments: disable-caching-for-resource.patch
>
>
> Currently it is possible to disable resources versioning by :
> getResourceSettings().setCachingStrategy(NoOpResourceCachingStrategy.INSTANCE);
> Unfortunately this disables caching for every resource, it would be nice to
> disable caching for particular (package) resource, something like:
> PackageResourceReference res = new PackageResourceReference();
> res.setCashable(false);
> Caching in general is good think but some javascript libraries get broken
> when filenames are modified with "-ver-..." token.
> Regards
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4523) Use new maven compiler plugin to speed up build time
[ https://issues.apache.org/jira/browse/WICKET-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13269242#comment-13269242 ] Peter Ertl commented on WICKET-4523: I ran the test several times :-( > Use new maven compiler plugin to speed up build time > > > Key: WICKET-4523 > URL: https://issues.apache.org/jira/browse/WICKET-4523 > Project: Wicket > Issue Type: Improvement > Environment: maven 3 >Reporter: Christoph Leiter >Assignee: Carl-Eric Menzel >Priority: Minor > Attachments: WICKET-4523-5.patch, WICKET-4523-6.patch > > > There's a new Java compiler plugin for maven which caches the classloader for > JavaCompiler. This has a huge positive performance impact. See > http://jira.codehaus.org/browse/PLXCOMP-202 > For me this change reduced the time for "mvn clean compile" on wicket master > branch from 56s to 34s. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4532) Disable caching for particular resources.
[ https://issues.apache.org/jira/browse/WICKET-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl updated WICKET-4532: --- Attachment: disable-caching-for-resource.patch > Disable caching for particular resources. > - > > Key: WICKET-4532 > URL: https://issues.apache.org/jira/browse/WICKET-4532 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5.5 >Reporter: Daniel Lipski >Assignee: Peter Ertl >Priority: Minor > Attachments: disable-caching-for-resource.patch > > > Currently it is possible to disable resources versioning by : > getResourceSettings().setCachingStrategy(NoOpResourceCachingStrategy.INSTANCE); > Unfortunately this disables caching for every resource, it would be nice to > disable caching for particular (package) resource, something like: > PackageResourceReference res = new PackageResourceReference(); > res.setCashable(false); > Caching in general is good think but some javascript libraries get broken > when filenames are modified with "-ver-..." token. > Regards -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4532) Disable caching for particular resources.
[ https://issues.apache.org/jira/browse/WICKET-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13268945#comment-13268945 ] Peter Ertl commented on WICKET-4532: I could fix this in 6.x (not in 1.5 since it will break the api) with the patch that is included in this issue. Can I get some feedback please if it's okay to commit it into master since we so close to 6.0.0 ? > Disable caching for particular resources. > - > > Key: WICKET-4532 > URL: https://issues.apache.org/jira/browse/WICKET-4532 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5.5 >Reporter: Daniel Lipski >Assignee: Peter Ertl >Priority: Minor > > Currently it is possible to disable resources versioning by : > getResourceSettings().setCachingStrategy(NoOpResourceCachingStrategy.INSTANCE); > Unfortunately this disables caching for every resource, it would be nice to > disable caching for particular (package) resource, something like: > PackageResourceReference res = new PackageResourceReference(); > res.setCashable(false); > Caching in general is good think but some javascript libraries get broken > when filenames are modified with "-ver-..." token. > Regards -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (WICKET-4532) Disable caching for particular resources.
[ https://issues.apache.org/jira/browse/WICKET-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl reassigned WICKET-4532: -- Assignee: Peter Ertl > Disable caching for particular resources. > - > > Key: WICKET-4532 > URL: https://issues.apache.org/jira/browse/WICKET-4532 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5.5 >Reporter: Daniel Lipski >Assignee: Peter Ertl >Priority: Minor > > Currently it is possible to disable resources versioning by : > getResourceSettings().setCachingStrategy(NoOpResourceCachingStrategy.INSTANCE); > Unfortunately this disables caching for every resource, it would be nice to > disable caching for particular (package) resource, something like: > PackageResourceReference res = new PackageResourceReference(); > res.setCashable(false); > Caching in general is good think but some javascript libraries get broken > when filenames are modified with "-ver-..." token. > Regards -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4509) Spaces in path cause ModifcationWatcher to fail
[ https://issues.apache.org/jira/browse/WICKET-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13268520#comment-13268520 ] Peter Ertl commented on WICKET-4509: @Sven: In 6.x, can we move UrlDecoder into wicket-util? > Spaces in path cause ModifcationWatcher to fail > --- > > Key: WICKET-4509 > URL: https://issues.apache.org/jira/browse/WICKET-4509 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.5 > Environment: Windows 7 >Reporter: Christoph Leiter >Assignee: Sven Meier > Fix For: 1.5.6, 6.0.0-RC1 > > Attachments: WICKET-4509.patch > > > The ModificationWatcher isn't able to reload resource files if there's a > space in the path. > The problem is that Files#getLocalFileFromUrl(String) receives an URL encoded > String in which spaces are encoded to %20. They are never decoded and passed > to File(). The fix is not to use the external representation of an URL but > the file representation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4509) Spaces in path cause ModifcationWatcher to fail
[ https://issues.apache.org/jira/browse/WICKET-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13268521#comment-13268521 ] Peter Ertl commented on WICKET-4509: ^ and add some comment in the migration-wiki? > Spaces in path cause ModifcationWatcher to fail > --- > > Key: WICKET-4509 > URL: https://issues.apache.org/jira/browse/WICKET-4509 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.5 > Environment: Windows 7 >Reporter: Christoph Leiter >Assignee: Sven Meier > Fix For: 1.5.6, 6.0.0-RC1 > > Attachments: WICKET-4509.patch > > > The ModificationWatcher isn't able to reload resource files if there's a > space in the path. > The problem is that Files#getLocalFileFromUrl(String) receives an URL encoded > String in which spaces are encoded to %20. They are never decoded and passed > to File(). The fix is not to use the external representation of an URL but > the file representation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-4531) Last modified token not added to resource name.
[ https://issues.apache.org/jira/browse/WICKET-4531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl resolved WICKET-4531. Resolution: Duplicate this should already be fixed with WICKET-4509 > Last modified token not added to resource name. > --- > > Key: WICKET-4531 > URL: https://issues.apache.org/jira/browse/WICKET-4531 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.6 > Environment: Windows Xp sp 3, Google Chrome 20.0.1123.4 dev-m, Apache > Tomcat-7.0.25, JDK 1.6.30 >Reporter: Daniel Lipski > > When file system path to resource reference (file) contains space " " version > token is not appended to its name. File is still accessible via web browser. > I think that problem is with encoding space with %20 and later when > lastModified date is calculated for this file %20 is not decoded to space and > file system could not find file. > When lastModified is not calculated for resource versioning token is not > added to file name. > Regards > Daniel -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4523) Use new maven compiler plugin to speed up build time
[ https://issues.apache.org/jira/browse/WICKET-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267721#comment-13267721 ] Peter Ertl commented on WICKET-4523: I tried it on OS X with 2.3GHz i7 and SSD and it took... - 12.7sec without the change - 13.1sec with your patch applied for 'mvn clean compile' on 'master'. So it had no effect for me... maybe somebody else can try ? > Use new maven compiler plugin to speed up build time > > > Key: WICKET-4523 > URL: https://issues.apache.org/jira/browse/WICKET-4523 > Project: Wicket > Issue Type: Improvement > Environment: maven 3 >Reporter: Christoph Leiter >Priority: Minor > Attachments: WICKET-4523-5.patch, WICKET-4523-6.patch > > > There's a new Java compiler plugin for maven which caches the classloader for > JavaCompiler. This has a huge positive performance impact. See > http://jira.codehaus.org/browse/PLXCOMP-202 > For me this change reduced the time for "mvn clean compile" on wicket master > branch from 56s to 34s. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-4528) make recorder component of wicket-extensions palette more efficient for large number of items and easier to extend
[ https://issues.apache.org/jira/browse/WICKET-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl resolved WICKET-4528. Resolution: Fixed Fix Version/s: 1.5.7 6.0.0-RC1 > make recorder component of wicket-extensions palette more efficient for large > number of items and easier to extend > -- > > Key: WICKET-4528 > URL: https://issues.apache.org/jira/browse/WICKET-4528 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Affects Versions: 1.5.6, 6.0.0-beta1 >Reporter: Peter Ertl >Assignee: Peter Ertl >Priority: Minor > Fix For: 6.0.0-RC1, 1.5.7 > > > the recorder component does a double-nested loop when determining the > selected / unselected items for the palette. This can be enhanced by using a > set for maintaining the ids. also the component is hard to extend, so give > more extension points (at least in 6.x, eventually in 1.5.x also) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (WICKET-4528) make recorder component of wicket-extensions palette more efficient for large number of items and easier to extend
Peter Ertl created WICKET-4528: -- Summary: make recorder component of wicket-extensions palette more efficient for large number of items and easier to extend Key: WICKET-4528 URL: https://issues.apache.org/jira/browse/WICKET-4528 Project: Wicket Issue Type: Improvement Components: wicket-extensions Affects Versions: 6.0.0-beta1, 1.5.6 Reporter: Peter Ertl Assignee: Peter Ertl Priority: Minor the recorder component does a double-nested loop when determining the selected / unselected items for the palette. This can be enhanced by using a set for maintaining the ids. also the component is hard to extend, so give more extension points (at least in 6.x, eventually in 1.5.x also) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-4527) Recorder#getSelectedChoices() can be very slow under certain circumstances
[ https://issues.apache.org/jira/browse/WICKET-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl resolved WICKET-4527. Resolution: Fixed Fix Version/s: 1.5.7 6.0.0-RC1 fixed - thanks for reporting! > Recorder#getSelectedChoices() can be very slow under certain circumstances > -- > > Key: WICKET-4527 > URL: https://issues.apache.org/jira/browse/WICKET-4527 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Affects Versions: 1.5.5, 6.0.0-beta1 >Reporter: Markus Krischke >Assignee: Peter Ertl > Fix For: 6.0.0-RC1, 1.5.7 > > > In Recorder#getSelectedChoices() the inner for-loop > getPalette().getChoices() is called for every iteration. Depending on the > efficiency of the implementation of the underlying model this might result in > poor performance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4527) Recorder#getSelectedChoices() can be very slow under certain circumstances
[ https://issues.apache.org/jira/browse/WICKET-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl updated WICKET-4527: --- Affects Version/s: (was: 6.0.0-RC1) 6.0.0-beta1 > Recorder#getSelectedChoices() can be very slow under certain circumstances > -- > > Key: WICKET-4527 > URL: https://issues.apache.org/jira/browse/WICKET-4527 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Affects Versions: 1.5.5, 6.0.0-beta1 >Reporter: Markus Krischke >Assignee: Peter Ertl > > In Recorder#getSelectedChoices() the inner for-loop > getPalette().getChoices() is called for every iteration. Depending on the > efficiency of the implementation of the underlying model this might result in > poor performance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4527) Recorder#getSelectedChoices() can be very slow under certain circumstances
[ https://issues.apache.org/jira/browse/WICKET-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl updated WICKET-4527: --- Component/s: (was: wicket) wicket-extensions Affects Version/s: 6.0.0-RC1 > Recorder#getSelectedChoices() can be very slow under certain circumstances > -- > > Key: WICKET-4527 > URL: https://issues.apache.org/jira/browse/WICKET-4527 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Affects Versions: 1.5.5, 6.0.0-beta1 >Reporter: Markus Krischke >Assignee: Peter Ertl > > In Recorder#getSelectedChoices() the inner for-loop > getPalette().getChoices() is called for every iteration. Depending on the > efficiency of the implementation of the underlying model this might result in > poor performance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (WICKET-4527) Recorder#getSelectedChoices() can be very slow under certain circumstances
[ https://issues.apache.org/jira/browse/WICKET-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl reassigned WICKET-4527: -- Assignee: Peter Ertl > Recorder#getSelectedChoices() can be very slow under certain circumstances > -- > > Key: WICKET-4527 > URL: https://issues.apache.org/jira/browse/WICKET-4527 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.5.5 >Reporter: Markus Krischke >Assignee: Peter Ertl > > In Recorder#getSelectedChoices() the inner for-loop > getPalette().getChoices() is called for every iteration. Depending on the > efficiency of the implementation of the underlying model this might result in > poor performance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4083) WebResponse#enableCaching does not take care of a possible "Pragma: no-cache" header
[
https://issues.apache.org/jira/browse/WICKET-4083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl updated WICKET-4083:
---
Affects Version/s: 1.5.1
Fix Version/s: 1.5.2
> WebResponse#enableCaching does not take care of a possible "Pragma: no-cache"
> header
>
>
> Key: WICKET-4083
> URL: https://issues.apache.org/jira/browse/WICKET-4083
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.5.1
>Reporter: Rodolfo Hansen
>Assignee: Peter Ertl
>Priority: Minor
> Fix For: 1.5.2
>
>
> in WebResponse#enableCaching
> a call to setHeader("Pragma", "") might be a good idea to assure that no
> conflicting http header information is being sent out.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-4083) WebResponse#enableCaching does not take care of a possible "Pragma: no-cache" header
[
https://issues.apache.org/jira/browse/WICKET-4083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl resolved WICKET-4083.
Resolution: Fixed
> WebResponse#enableCaching does not take care of a possible "Pragma: no-cache"
> header
>
>
> Key: WICKET-4083
> URL: https://issues.apache.org/jira/browse/WICKET-4083
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.5.1
>Reporter: Rodolfo Hansen
>Assignee: Peter Ertl
>Priority: Minor
> Fix For: 1.5.2
>
>
> in WebResponse#enableCaching
> a call to setHeader("Pragma", "") might be a good idea to assure that no
> conflicting http header information is being sent out.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4083) WebResponse#enableCaching does not take care of a possible "Pragma: no-cache" header
[
https://issues.apache.org/jira/browse/WICKET-4083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114084#comment-13114084
]
Peter Ertl commented on WICKET-4083:
It seems there is no corresponding counterpart for header value "no-cache". I
don't like to elimimate an eventual "no-cache" value with an empty header like
this:
Pragma:
Some (broken) servers could have a problem with that...
Also
setHeader("Pragma", null)
works on jetty but could be fragile on some others servlet containers.
Also there's no way in the servlet api to remove an header completely. So I
will add
Pragma: cache
which clearly signal our intention. Even in the case of an unknown value it
will not hurt.
@Rodolfo: Thanks for reporting!
> WebResponse#enableCaching does not take care of a possible "Pragma: no-cache"
> header
>
>
> Key: WICKET-4083
> URL: https://issues.apache.org/jira/browse/WICKET-4083
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Reporter: Rodolfo Hansen
>Assignee: Peter Ertl
>Priority: Minor
>
> in WebResponse#enableCaching
> a call to setHeader("Pragma", "") might be a good idea to assure that no
> conflicting http header information is being sent out.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4051) max-age header is set in milliseconds rather than seconds
[ https://issues.apache.org/jira/browse/WICKET-4051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104465#comment-13104465 ] Peter Ertl commented on WICKET-4051: thanks a lot for reporting ... fixed in trunk! > max-age header is set in milliseconds rather than seconds > - > > Key: WICKET-4051 > URL: https://issues.apache.org/jira/browse/WICKET-4051 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.0 >Reporter: Emond Papegaaij >Assignee: Peter Ertl > Fix For: 1.5.1 > > Attachments: headerfix.diff > > > According to http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html the > max-age in Cache-Control should be set in seconds, but > WebResponse.enableCaching sets it in milliseconds. The attached patch fixes > this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-4051) max-age header is set in milliseconds rather than seconds
[ https://issues.apache.org/jira/browse/WICKET-4051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl resolved WICKET-4051. Resolution: Fixed Fix Version/s: 1.5.1 > max-age header is set in milliseconds rather than seconds > - > > Key: WICKET-4051 > URL: https://issues.apache.org/jira/browse/WICKET-4051 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.0 >Reporter: Emond Papegaaij >Assignee: Peter Ertl > Fix For: 1.5.1 > > Attachments: headerfix.diff > > > According to http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html the > max-age in Cache-Control should be set in seconds, but > WebResponse.enableCaching sets it in milliseconds. The attached patch fixes > this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (WICKET-4051) max-age header is set in milliseconds rather than seconds
[ https://issues.apache.org/jira/browse/WICKET-4051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl reassigned WICKET-4051: -- Assignee: Peter Ertl > max-age header is set in milliseconds rather than seconds > - > > Key: WICKET-4051 > URL: https://issues.apache.org/jira/browse/WICKET-4051 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.0 >Reporter: Emond Papegaaij >Assignee: Peter Ertl > Attachments: headerfix.diff > > > According to http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html the > max-age in Cache-Control should be set in seconds, but > WebResponse.enableCaching sets it in milliseconds. The attached patch fixes > this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-4053) AbstractTree#updateTree(AjaxRequestTarget target) is invoked even when request is non-ajax
[
https://issues.apache.org/jira/browse/WICKET-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl resolved WICKET-4053.
Resolution: Fixed
> AbstractTree#updateTree(AjaxRequestTarget target) is invoked even when
> request is non-ajax
> --
>
> Key: WICKET-4053
> URL: https://issues.apache.org/jira/browse/WICKET-4053
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.5.0
> Environment: Wicket 1.5.0
>Reporter: James McIntosh
>Assignee: Peter Ertl
> Fix For: 1.5.1
>
>
> I came across an issue when trying to get Brix working in wicket 1.5.
> It occurs when the Tree has: setLinkType(LinkType.REGULAR);
> Caused by: java.lang.IllegalArgumentException: Argument 'target' may not be
> null.
> at org.apache.wicket.util.lang.Args.notNull(Args.java:39)
> at
> org.apache.wicket.markup.html.tree.AbstractTree.updateTree(AbstractTree.java:1138)
> at
> org.apache.wicket.markup.html.tree.LinkIconPanel.onNodeLinkClicked(LinkIconPanel.java:82)
> at
> org.apache.wicket.markup.html.tree.LinkIconPanel$1.onClick(LinkIconPanel.java:59)
> at
> org.apache.wicket.markup.html.tree.BaseTree$5.onClick(BaseTree.java:386)
> at org.apache.wicket.markup.html.link.Link.onLinkClicked(Link.java:187)
> I only had a quick search across the wicket codebase to see if this method is
> called elsewhere
> To fix LinkIconPanel line 82 should be
> if (target != null) {
> tree.updateTree(target);
> }
> BaseTree - line 294 also calls updateTree(target) with no null check.
>
>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4053) AbstractTree#updateTree(AjaxRequestTarget target) is invoked even when request is non-ajax
[
https://issues.apache.org/jira/browse/WICKET-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104456#comment-13104456
]
Peter Ertl commented on WICKET-4053:
all occurences of updateTree(..) with possible null pointers should be fixed
now in trunk.
thanks for reporting !
> AbstractTree#updateTree(AjaxRequestTarget target) is invoked even when
> request is non-ajax
> --
>
> Key: WICKET-4053
> URL: https://issues.apache.org/jira/browse/WICKET-4053
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.5.0
> Environment: Wicket 1.5.0
>Reporter: James McIntosh
>Assignee: Peter Ertl
> Fix For: 1.5.1
>
>
> I came across an issue when trying to get Brix working in wicket 1.5.
> It occurs when the Tree has: setLinkType(LinkType.REGULAR);
> Caused by: java.lang.IllegalArgumentException: Argument 'target' may not be
> null.
> at org.apache.wicket.util.lang.Args.notNull(Args.java:39)
> at
> org.apache.wicket.markup.html.tree.AbstractTree.updateTree(AbstractTree.java:1138)
> at
> org.apache.wicket.markup.html.tree.LinkIconPanel.onNodeLinkClicked(LinkIconPanel.java:82)
> at
> org.apache.wicket.markup.html.tree.LinkIconPanel$1.onClick(LinkIconPanel.java:59)
> at
> org.apache.wicket.markup.html.tree.BaseTree$5.onClick(BaseTree.java:386)
> at org.apache.wicket.markup.html.link.Link.onLinkClicked(Link.java:187)
> I only had a quick search across the wicket codebase to see if this method is
> called elsewhere
> To fix LinkIconPanel line 82 should be
> if (target != null) {
> tree.updateTree(target);
> }
> BaseTree - line 294 also calls updateTree(target) with no null check.
>
>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4053) AbstractTree#updateTree(AjaxRequestTarget target) is invoked even when request is non-ajax
[
https://issues.apache.org/jira/browse/WICKET-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl updated WICKET-4053:
---
Fix Version/s: 1.5.1
> AbstractTree#updateTree(AjaxRequestTarget target) is invoked even when
> request is non-ajax
> --
>
> Key: WICKET-4053
> URL: https://issues.apache.org/jira/browse/WICKET-4053
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.5.0
> Environment: Wicket 1.5.0
>Reporter: James McIntosh
>Assignee: Peter Ertl
> Fix For: 1.5.1
>
>
> I came across an issue when trying to get Brix working in wicket 1.5.
> It occurs when the Tree has: setLinkType(LinkType.REGULAR);
> Caused by: java.lang.IllegalArgumentException: Argument 'target' may not be
> null.
> at org.apache.wicket.util.lang.Args.notNull(Args.java:39)
> at
> org.apache.wicket.markup.html.tree.AbstractTree.updateTree(AbstractTree.java:1138)
> at
> org.apache.wicket.markup.html.tree.LinkIconPanel.onNodeLinkClicked(LinkIconPanel.java:82)
> at
> org.apache.wicket.markup.html.tree.LinkIconPanel$1.onClick(LinkIconPanel.java:59)
> at
> org.apache.wicket.markup.html.tree.BaseTree$5.onClick(BaseTree.java:386)
> at org.apache.wicket.markup.html.link.Link.onLinkClicked(Link.java:187)
> I only had a quick search across the wicket codebase to see if this method is
> called elsewhere
> To fix LinkIconPanel line 82 should be
> if (target != null) {
> tree.updateTree(target);
> }
> BaseTree - line 294 also calls updateTree(target) with no null check.
>
>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4053) AbstractTree#updateTree(AjaxRequestTarget target) is invoked even when request is non-ajax
[
https://issues.apache.org/jira/browse/WICKET-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl updated WICKET-4053:
---
Summary: AbstractTree#updateTree(AjaxRequestTarget target) is invoked even
when request is non-ajax (was: LinkIconPanel throws an Exception when links
are non-ajax)
> AbstractTree#updateTree(AjaxRequestTarget target) is invoked even when
> request is non-ajax
> --
>
> Key: WICKET-4053
> URL: https://issues.apache.org/jira/browse/WICKET-4053
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.5.0
> Environment: Wicket 1.5.0
>Reporter: James McIntosh
>Assignee: Peter Ertl
>
> I came across an issue when trying to get Brix working in wicket 1.5.
> It occurs when the Tree has: setLinkType(LinkType.REGULAR);
> Caused by: java.lang.IllegalArgumentException: Argument 'target' may not be
> null.
> at org.apache.wicket.util.lang.Args.notNull(Args.java:39)
> at
> org.apache.wicket.markup.html.tree.AbstractTree.updateTree(AbstractTree.java:1138)
> at
> org.apache.wicket.markup.html.tree.LinkIconPanel.onNodeLinkClicked(LinkIconPanel.java:82)
> at
> org.apache.wicket.markup.html.tree.LinkIconPanel$1.onClick(LinkIconPanel.java:59)
> at
> org.apache.wicket.markup.html.tree.BaseTree$5.onClick(BaseTree.java:386)
> at org.apache.wicket.markup.html.link.Link.onLinkClicked(Link.java:187)
> I only had a quick search across the wicket codebase to see if this method is
> called elsewhere
> To fix LinkIconPanel line 82 should be
> if (target != null) {
> tree.updateTree(target);
> }
> BaseTree - line 294 also calls updateTree(target) with no null check.
>
>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (WICKET-4053) LinkIconPanel throws an Exception when links are non-ajax
[
https://issues.apache.org/jira/browse/WICKET-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl reassigned WICKET-4053:
--
Assignee: Peter Ertl
> LinkIconPanel throws an Exception when links are non-ajax
> -
>
> Key: WICKET-4053
> URL: https://issues.apache.org/jira/browse/WICKET-4053
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.5.0
> Environment: Wicket 1.5.0
>Reporter: James McIntosh
>Assignee: Peter Ertl
>
> I came across an issue when trying to get Brix working in wicket 1.5.
> It occurs when the Tree has: setLinkType(LinkType.REGULAR);
> Caused by: java.lang.IllegalArgumentException: Argument 'target' may not be
> null.
> at org.apache.wicket.util.lang.Args.notNull(Args.java:39)
> at
> org.apache.wicket.markup.html.tree.AbstractTree.updateTree(AbstractTree.java:1138)
> at
> org.apache.wicket.markup.html.tree.LinkIconPanel.onNodeLinkClicked(LinkIconPanel.java:82)
> at
> org.apache.wicket.markup.html.tree.LinkIconPanel$1.onClick(LinkIconPanel.java:59)
> at
> org.apache.wicket.markup.html.tree.BaseTree$5.onClick(BaseTree.java:386)
> at org.apache.wicket.markup.html.link.Link.onLinkClicked(Link.java:187)
> I only had a quick search across the wicket codebase to see if this method is
> called elsewhere
> To fix LinkIconPanel line 82 should be
> if (target != null) {
> tree.updateTree(target);
> }
> BaseTree - line 294 also calls updateTree(target) with no null check.
>
>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-4032) ComponentStringResourceLoader must not include the index of repeater items in resource lookup but still resolve properties to them
[ https://issues.apache.org/jira/browse/WICKET-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl resolved WICKET-4032. Resolution: Fixed Fix Version/s: 1.5.1 > ComponentStringResourceLoader must not include the index of repeater items in > resource lookup but still resolve properties to them > -- > > Key: WICKET-4032 > URL: https://issues.apache.org/jira/browse/WICKET-4032 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.18, 1.5-RC7 >Reporter: Nathan Messer >Assignee: Peter Ertl > Fix For: 1.4.19, 1.5.1 > > Attachments: resource-lookup.zip, resource-lookup2.zip, > resourceloadingissue.patch, resourceloadingissue.patch > > > Issue when using a StringResourceModel to lookup a resource for a component > underneath a repeating view. > When a StringResourceModel is used by a component under a repeating view, the > ComponentStringResourceLoader doesn't find the resource. > This seems to be a problem introduced by the fix for 3671. > In ComponentStringResourceLoader, getResourcePath excludes all > AbstractRepeaters, however getComponentStack doesn't leading to the two being > out of sync for the elements of the component hierarchy under the repeating > view. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4032) ComponentStringResourceLoader must not include the index of repeater items in resource lookup but still resolve properties to them
[ https://issues.apache.org/jira/browse/WICKET-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13100331#comment-13100331 ] Peter Ertl commented on WICKET-4032: @Nathan: Thanks for reporting. We always want things to get better :-) > ComponentStringResourceLoader must not include the index of repeater items in > resource lookup but still resolve properties to them > -- > > Key: WICKET-4032 > URL: https://issues.apache.org/jira/browse/WICKET-4032 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.18, 1.5-RC7 >Reporter: Nathan Messer >Assignee: Peter Ertl > Fix For: 1.4.19, 1.5.1 > > Attachments: resource-lookup.zip, resource-lookup2.zip, > resourceloadingissue.patch, resourceloadingissue.patch > > > Issue when using a StringResourceModel to lookup a resource for a component > underneath a repeating view. > When a StringResourceModel is used by a component under a repeating view, the > ComponentStringResourceLoader doesn't find the resource. > This seems to be a problem introduced by the fix for 3671. > In ComponentStringResourceLoader, getResourcePath excludes all > AbstractRepeaters, however getComponentStack doesn't leading to the two being > out of sync for the elements of the component hierarchy under the repeating > view. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4030) HeaderResponse.renderCSSReference does not render context path relative url, but wicket filter url-pattern relative url
[ https://issues.apache.org/jira/browse/WICKET-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl updated WICKET-4030: --- Attachment: relative-url.patch added patch in case we want to fix this... > HeaderResponse.renderCSSReference does not render context path relative url, > but wicket filter url-pattern relative url > --- > > Key: WICKET-4030 > URL: https://issues.apache.org/jira/browse/WICKET-4030 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5-RC7 >Reporter: Matteo Sotil >Assignee: Peter Ertl >Priority: Minor > Attachments: quickstart.zip, relative-url.patch > > > In an application with a wicket filter url-pattern different than /*, if you > use HeaderResponse.renderCSSReference(String url), where url is a > context-path-relative url (css/main.css, for example), the generated css link > is not context relative, but wicket url-pattern relative. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4030) HeaderResponse.renderCSSReference does not render context path relative url, but wicket filter url-pattern relative url
[ https://issues.apache.org/jira/browse/WICKET-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098877#comment-13098877 ] Peter Ertl commented on WICKET-4030: @Matteo: Indeed the current javadoc is wrong. The rendering happens relative to wicket filter root both in current wicket release 1.4.18 and 1.5.0. I sent a mail to the developer mailing list to clarify that issue. Currently the solution will be to properly escape the filter path with '..' to access context relative resources. > HeaderResponse.renderCSSReference does not render context path relative url, > but wicket filter url-pattern relative url > --- > > Key: WICKET-4030 > URL: https://issues.apache.org/jira/browse/WICKET-4030 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5-RC7 >Reporter: Matteo Sotil >Assignee: Peter Ertl >Priority: Minor > Attachments: quickstart.zip > > > In an application with a wicket filter url-pattern different than /*, if you > use HeaderResponse.renderCSSReference(String url), where url is a > context-path-relative url (css/main.css, for example), the generated css link > is not context relative, but wicket url-pattern relative. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4032) ComponentStringResourceLoader must not include the index of repeater items in resource lookup but still resolve properties to them
[ https://issues.apache.org/jira/browse/WICKET-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098823#comment-13098823 ] Peter Ertl commented on WICKET-4032: @igor: done for 1.4 and 1.5 > ComponentStringResourceLoader must not include the index of repeater items in > resource lookup but still resolve properties to them > -- > > Key: WICKET-4032 > URL: https://issues.apache.org/jira/browse/WICKET-4032 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.18, 1.5-RC7 >Reporter: Nathan Messer >Assignee: Peter Ertl > Fix For: 1.4.19 > > Attachments: resource-lookup.zip, resource-lookup2.zip, > resourceloadingissue.patch, resourceloadingissue.patch > > > Issue when using a StringResourceModel to lookup a resource for a component > underneath a repeating view. > When a StringResourceModel is used by a component under a repeating view, the > ComponentStringResourceLoader doesn't find the resource. > This seems to be a problem introduced by the fix for 3671. > In ComponentStringResourceLoader, getResourcePath excludes all > AbstractRepeaters, however getComponentStack doesn't leading to the two being > out of sync for the elements of the component hierarchy under the repeating > view. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (WICKET-4030) HeaderResponse.renderCSSReference does not render context path relative url, but wicket filter url-pattern relative url
[ https://issues.apache.org/jira/browse/WICKET-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl reopened WICKET-4030: > HeaderResponse.renderCSSReference does not render context path relative url, > but wicket filter url-pattern relative url > --- > > Key: WICKET-4030 > URL: https://issues.apache.org/jira/browse/WICKET-4030 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5-RC7 >Reporter: Matteo Sotil >Assignee: Peter Ertl >Priority: Minor > Attachments: quickstart.zip > > > In an application with a wicket filter url-pattern different than /*, if you > use HeaderResponse.renderCSSReference(String url), where url is a > context-path-relative url (css/main.css, for example), the generated css link > is not context relative, but wicket url-pattern relative. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4032) ComponentStringResourceLoader must not include the index of repeater items in resource lookup but still resolve properties to them
[ https://issues.apache.org/jira/browse/WICKET-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098363#comment-13098363 ] Peter Ertl commented on WICKET-4032: leaving this issue open for a while to gather feedback if everything is okay > ComponentStringResourceLoader must not include the index of repeater items in > resource lookup but still resolve properties to them > -- > > Key: WICKET-4032 > URL: https://issues.apache.org/jira/browse/WICKET-4032 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.18, 1.5-RC7 >Reporter: Nathan Messer >Assignee: Peter Ertl > Fix For: 1.4.19 > > Attachments: resource-lookup.zip, resource-lookup2.zip, > resourceloadingissue.patch, resourceloadingissue.patch > > > Issue when using a StringResourceModel to lookup a resource for a component > underneath a repeating view. > When a StringResourceModel is used by a component under a repeating view, the > ComponentStringResourceLoader doesn't find the resource. > This seems to be a problem introduced by the fix for 3671. > In ComponentStringResourceLoader, getResourcePath excludes all > AbstractRepeaters, however getComponentStack doesn't leading to the two being > out of sync for the elements of the component hierarchy under the repeating > view. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4032) ComponentStringResourceLoader must not include the index of repeater items in resource lookup but still resolve properties to them
[ https://issues.apache.org/jira/browse/WICKET-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098357#comment-13098357 ] Peter Ertl commented on WICKET-4032: fixed for 1.5 as well, please check and report any issues... thank you! > ComponentStringResourceLoader must not include the index of repeater items in > resource lookup but still resolve properties to them > -- > > Key: WICKET-4032 > URL: https://issues.apache.org/jira/browse/WICKET-4032 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.18, 1.5-RC7 >Reporter: Nathan Messer >Assignee: Peter Ertl > Fix For: 1.4.19 > > Attachments: resource-lookup.zip, resource-lookup2.zip, > resourceloadingissue.patch, resourceloadingissue.patch > > > Issue when using a StringResourceModel to lookup a resource for a component > underneath a repeating view. > When a StringResourceModel is used by a component under a repeating view, the > ComponentStringResourceLoader doesn't find the resource. > This seems to be a problem introduced by the fix for 3671. > In ComponentStringResourceLoader, getResourcePath excludes all > AbstractRepeaters, however getComponentStack doesn't leading to the two being > out of sync for the elements of the component hierarchy under the repeating > view. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (WICKET-4032) ComponentStringResourceLoader must not include the index of repeater items in resource lookup but still resolve properties to them
[ https://issues.apache.org/jira/browse/WICKET-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl reopened WICKET-4032: this seems to affect 1.5 also > ComponentStringResourceLoader must not include the index of repeater items in > resource lookup but still resolve properties to them > -- > > Key: WICKET-4032 > URL: https://issues.apache.org/jira/browse/WICKET-4032 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.18, 1.5-RC7 >Reporter: Nathan Messer >Assignee: Peter Ertl > Fix For: 1.4.19 > > Attachments: resource-lookup.zip, resource-lookup2.zip, > resourceloadingissue.patch, resourceloadingissue.patch > > > Issue when using a StringResourceModel to lookup a resource for a component > underneath a repeating view. > When a StringResourceModel is used by a component under a repeating view, the > ComponentStringResourceLoader doesn't find the resource. > This seems to be a problem introduced by the fix for 3671. > In ComponentStringResourceLoader, getResourcePath excludes all > AbstractRepeaters, however getComponentStack doesn't leading to the two being > out of sync for the elements of the component hierarchy under the repeating > view. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4032) ComponentStringResourceLoader must not include the index of repeater items in resource lookup but still resolve properties to them
[ https://issues.apache.org/jira/browse/WICKET-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl updated WICKET-4032: --- Affects Version/s: 1.5-RC7 > ComponentStringResourceLoader must not include the index of repeater items in > resource lookup but still resolve properties to them > -- > > Key: WICKET-4032 > URL: https://issues.apache.org/jira/browse/WICKET-4032 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.18, 1.5-RC7 >Reporter: Nathan Messer >Assignee: Peter Ertl > Fix For: 1.4.19 > > Attachments: resource-lookup.zip, resource-lookup2.zip, > resourceloadingissue.patch, resourceloadingissue.patch > > > Issue when using a StringResourceModel to lookup a resource for a component > underneath a repeating view. > When a StringResourceModel is used by a component under a repeating view, the > ComponentStringResourceLoader doesn't find the resource. > This seems to be a problem introduced by the fix for 3671. > In ComponentStringResourceLoader, getResourcePath excludes all > AbstractRepeaters, however getComponentStack doesn't leading to the two being > out of sync for the elements of the component hierarchy under the repeating > view. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-4032) ComponentStringResourceLoader must not include the index of repeater items in resource lookup but still resolve properties to them
[ https://issues.apache.org/jira/browse/WICKET-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl resolved WICKET-4032. Resolution: Fixed > ComponentStringResourceLoader must not include the index of repeater items in > resource lookup but still resolve properties to them > -- > > Key: WICKET-4032 > URL: https://issues.apache.org/jira/browse/WICKET-4032 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.18 >Reporter: Nathan Messer >Assignee: Peter Ertl > Fix For: 1.4.19 > > Attachments: resource-lookup.zip, resource-lookup2.zip, > resourceloadingissue.patch, resourceloadingissue.patch > > > Issue when using a StringResourceModel to lookup a resource for a component > underneath a repeating view. > When a StringResourceModel is used by a component under a repeating view, the > ComponentStringResourceLoader doesn't find the resource. > This seems to be a problem introduced by the fix for 3671. > In ComponentStringResourceLoader, getResourcePath excludes all > AbstractRepeaters, however getComponentStack doesn't leading to the two being > out of sync for the elements of the component hierarchy under the repeating > view. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4032) ComponentStringResourceLoader must not include the index of repeater items in resource lookup but still resolve properties to them
[ https://issues.apache.org/jira/browse/WICKET-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098321#comment-13098321 ] Peter Ertl commented on WICKET-4032: I added a fix that resolves a resource key against AbstractRepeater and it's associated repeater items in the same manner. For example in the following hierarchy MyPage -- MyRepeater (id = "repeater") -- MyRepeaterItem (id = "3") -- MyWebMarkupContainer (id = "container") the key = 'label' resolved against base component "container" will cause a lookup in that order - MyPage.properties with key = "repeater.container.label" - MyRepeater.properties with key = "container.label" - MyRepeaterItem.properties with key = "container.label" - MyWebMarkupContainer.properties with key = "label" Please verify the fix and let me know if something is broken or missing ... > ComponentStringResourceLoader must not include the index of repeater items in > resource lookup but still resolve properties to them > -- > > Key: WICKET-4032 > URL: https://issues.apache.org/jira/browse/WICKET-4032 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.18 >Reporter: Nathan Messer >Assignee: Peter Ertl > Fix For: 1.4.19 > > Attachments: resource-lookup.zip, resource-lookup2.zip, > resourceloadingissue.patch, resourceloadingissue.patch > > > Issue when using a StringResourceModel to lookup a resource for a component > underneath a repeating view. > When a StringResourceModel is used by a component under a repeating view, the > ComponentStringResourceLoader doesn't find the resource. > This seems to be a problem introduced by the fix for 3671. > In ComponentStringResourceLoader, getResourcePath excludes all > AbstractRepeaters, however getComponentStack doesn't leading to the two being > out of sync for the elements of the component hierarchy under the repeating > view. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4032) ComponentStringResourceLoader must not include the index of repeater items in resource lookup but still resolve properties to them
[ https://issues.apache.org/jira/browse/WICKET-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl updated WICKET-4032: --- Summary: ComponentStringResourceLoader must not include the index of repeater items in resource lookup but still resolve properties to them (was: ComponentStringResourceLoader must not include repeater items in resource lookup) > ComponentStringResourceLoader must not include the index of repeater items in > resource lookup but still resolve properties to them > -- > > Key: WICKET-4032 > URL: https://issues.apache.org/jira/browse/WICKET-4032 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.18 >Reporter: Nathan Messer >Assignee: Peter Ertl > Fix For: 1.4.19 > > Attachments: resource-lookup.zip, resource-lookup2.zip, > resourceloadingissue.patch, resourceloadingissue.patch > > > Issue when using a StringResourceModel to lookup a resource for a component > underneath a repeating view. > When a StringResourceModel is used by a component under a repeating view, the > ComponentStringResourceLoader doesn't find the resource. > This seems to be a problem introduced by the fix for 3671. > In ComponentStringResourceLoader, getResourcePath excludes all > AbstractRepeaters, however getComponentStack doesn't leading to the two being > out of sync for the elements of the component hierarchy under the repeating > view. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (WICKET-4032) ComponentStringResourceLoader must not include repeater items in resource lookup
[ https://issues.apache.org/jira/browse/WICKET-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl reopened WICKET-4032: > ComponentStringResourceLoader must not include repeater items in resource > lookup > > > Key: WICKET-4032 > URL: https://issues.apache.org/jira/browse/WICKET-4032 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.18 >Reporter: Nathan Messer >Assignee: Peter Ertl > Fix For: 1.4.19 > > Attachments: resource-lookup.zip, resource-lookup2.zip, > resourceloadingissue.patch, resourceloadingissue.patch > > > Issue when using a StringResourceModel to lookup a resource for a component > underneath a repeating view. > When a StringResourceModel is used by a component under a repeating view, the > ComponentStringResourceLoader doesn't find the resource. > This seems to be a problem introduced by the fix for 3671. > In ComponentStringResourceLoader, getResourcePath excludes all > AbstractRepeaters, however getComponentStack doesn't leading to the two being > out of sync for the elements of the component hierarchy under the repeating > view. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-4030) HeaderResponse.renderCSSReference does not render correct css link with relative url in an application with contextPath different than /*
[ https://issues.apache.org/jira/browse/WICKET-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl resolved WICKET-4030. Resolution: Invalid > HeaderResponse.renderCSSReference does not render correct css link with > relative url in an application with contextPath different than /* > - > > Key: WICKET-4030 > URL: https://issues.apache.org/jira/browse/WICKET-4030 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5-RC7 >Reporter: Matteo Sotil >Assignee: Peter Ertl >Priority: Minor > Attachments: quickstart.zip > > > In an application with a contextPath different than /*, if you use > HeaderResponse.renderCSSReference(String url), where url is a relative url > (../../css/main.css, for example), the generated css link is not correct when > page path has some /. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4030) HeaderResponse.renderCSSReference does not render correct css link with relative url in an application with contextPath different than /*
[
https://issues.apache.org/jira/browse/WICKET-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098144#comment-13098144
]
Peter Ertl commented on WICKET-4030:
The problem is:
response.renderCSSReference(path) expects a context-relative(!) path (see
javadoc). This is not to be confused with the effective path that get's
rendered.
basically what you did wrong is call
response.renderCSSReference("../css/main.css")
when instead you should use the _context-relative_ path (relative to
"/contextPath" in your sample).
So the correct method call is
response.renderCSSReference("css/main.css")
It will work no matter how you mount your home page or if you mount it at all.
In any case wicket will generate the required number of ".." in the path.
> HeaderResponse.renderCSSReference does not render correct css link with
> relative url in an application with contextPath different than /*
> -
>
> Key: WICKET-4030
> URL: https://issues.apache.org/jira/browse/WICKET-4030
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.5-RC7
>Reporter: Matteo Sotil
>Assignee: Peter Ertl
>Priority: Minor
> Attachments: quickstart.zip
>
>
> In an application with a contextPath different than /*, if you use
> HeaderResponse.renderCSSReference(String url), where url is a relative url
> (../../css/main.css, for example), the generated css link is not correct when
> page path has some /.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (WICKET-4030) HeaderResponse.renderCSSReference does not render correct css link with relative url in an application with contextPath different than /*
[ https://issues.apache.org/jira/browse/WICKET-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl reassigned WICKET-4030: -- Assignee: Peter Ertl > HeaderResponse.renderCSSReference does not render correct css link with > relative url in an application with contextPath different than /* > - > > Key: WICKET-4030 > URL: https://issues.apache.org/jira/browse/WICKET-4030 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5-RC7 >Reporter: Matteo Sotil >Assignee: Peter Ertl >Priority: Minor > Attachments: quickstart.zip > > > In an application with a contextPath different than /*, if you use > HeaderResponse.renderCSSReference(String url), where url is a relative url > (../../css/main.css, for example), the generated css link is not correct when > page path has some /. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-4032) ComponentStringResourceLoader must not include repeater items in resource lookup
[ https://issues.apache.org/jira/browse/WICKET-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl resolved WICKET-4032. Resolution: Fixed Fix Version/s: 1.4.19 thanks for reporting... the problem is fixed in trunk ... please report if you still got issues > ComponentStringResourceLoader must not include repeater items in resource > lookup > > > Key: WICKET-4032 > URL: https://issues.apache.org/jira/browse/WICKET-4032 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.18 >Reporter: Nathan Messer >Assignee: Peter Ertl > Fix For: 1.4.19 > > Attachments: resource-lookup.zip, resourceloadingissue.patch, > resourceloadingissue.patch > > > Issue when using a StringResourceModel to lookup a resource for a component > underneath a repeating view. > When a StringResourceModel is used by a component under a repeating view, the > ComponentStringResourceLoader doesn't find the resource. > This seems to be a problem introduced by the fix for 3671. > In ComponentStringResourceLoader, getResourcePath excludes all > AbstractRepeaters, however getComponentStack doesn't leading to the two being > out of sync for the elements of the component hierarchy under the repeating > view. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4032) ComponentStringResourceLoader must not include repeater items in resource lookup
[ https://issues.apache.org/jira/browse/WICKET-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl updated WICKET-4032: --- Summary: ComponentStringResourceLoader must not include repeater items in resource lookup (was: Issue when using a StringResourceModel to lookup a resource for a component underneath a repeating view.) > ComponentStringResourceLoader must not include repeater items in resource > lookup > > > Key: WICKET-4032 > URL: https://issues.apache.org/jira/browse/WICKET-4032 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.18 >Reporter: Nathan Messer >Assignee: Peter Ertl > Attachments: resource-lookup.zip, resourceloadingissue.patch, > resourceloadingissue.patch > > > Issue when using a StringResourceModel to lookup a resource for a component > underneath a repeating view. > When a StringResourceModel is used by a component under a repeating view, the > ComponentStringResourceLoader doesn't find the resource. > This seems to be a problem introduced by the fix for 3671. > In ComponentStringResourceLoader, getResourcePath excludes all > AbstractRepeaters, however getComponentStack doesn't leading to the two being > out of sync for the elements of the component hierarchy under the repeating > view. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-4020) ResourceMapper throws IllegalStateException when attempting to map a request to a URL ending in a empty segment (directory)
[ https://issues.apache.org/jira/browse/WICKET-4020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl resolved WICKET-4020. Resolution: Fixed Fix Version/s: 1.5.1 thanks for reporting > ResourceMapper throws IllegalStateException when attempting to map a request > to a URL ending in a empty segment (directory) > --- > > Key: WICKET-4020 > URL: https://issues.apache.org/jira/browse/WICKET-4020 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5-RC7 > Environment: When a ResourceMapper is mounted >Reporter: Jesse Long >Assignee: Peter Ertl > Fix For: 1.5.1 > > Attachments: fix-WICKET-4020.patch > > > ResourceMapper.mapRequest() calls ResourceMapper.removeCachingDecoration() > which, throws IllegalStateException if the URL's last segment is an empty > string. > URLs like: path/to/my/non/wicket/directory/ end in a empty segment. > We must change the behaviour to not attempt to undecorate a URL ending in an > empty segment. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-3938) Impossible to remove particular key-value from PageParameters
[
https://issues.apache.org/jira/browse/WICKET-3938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092743#comment-13092743
]
Peter Ertl commented on WICKET-3938:
I think he meant to remove 'value1' from multi-value 'key1' so that
key1='value2' will be left
> Impossible to remove particular key-value from PageParameters
> -
>
> Key: WICKET-3938
> URL: https://issues.apache.org/jira/browse/WICKET-3938
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Affects Versions: 1.5-RC5.1
> Environment: not important
>Reporter: Igor Azarny
> Labels: page, parameter, wicket
> Attachments: patch-3938.diff
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> There is no way to delete particular key-value from page parameters.
> Example:
> PageParameters parameters = new PageParameters("key1=value1,key1=value2");
> //just to demonstrate, but actuall parameters comes from get request
> imposible to remove value1 from parameters.
> Workaround - create new PageParameters with filtering by key and value.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-3987) setUseTimestampOnResources and PackageResourceReference#getLastModified removed
[ https://issues.apache.org/jira/browse/WICKET-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090581#comment-13090581 ] Peter Ertl commented on WICKET-3987: Technically a resource is something that responds to a request with some kind of response to the client. A package is just a virtual location represented by a file system folder or a jar file location. So it should be treated differently from a resource. But I could imagine it makes sense to support urlFor(...) to resolve a package location. However this has to be discussed first and will not happen before 1.5.0 since we are almost gone final. > setUseTimestampOnResources and PackageResourceReference#getLastModified > removed > --- > > Key: WICKET-3987 > URL: https://issues.apache.org/jira/browse/WICKET-3987 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.0 > Environment: 1.5.0 trunk >Reporter: Konstantin Ignatyev >Assignee: Peter Ertl > > IResourceSettings#setUseTimestampOnResources and > PackageResourceReference#getLastModified removed in the trunk breaking some > of my components which rendered JScript reference from a component package. > Now URL has timestamp and therefore parts of JScript relying on relative to > the script positions of assets stopped working. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-3987) setUseTimestampOnResources and PackageResourceReference#getLastModified removed
[ https://issues.apache.org/jira/browse/WICKET-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090576#comment-13090576 ] Peter Ertl commented on WICKET-3987: some obsolete documentation - thanks for the pointer :-) > setUseTimestampOnResources and PackageResourceReference#getLastModified > removed > --- > > Key: WICKET-3987 > URL: https://issues.apache.org/jira/browse/WICKET-3987 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.0 > Environment: 1.5.0 trunk >Reporter: Konstantin Ignatyev >Assignee: Peter Ertl > > IResourceSettings#setUseTimestampOnResources and > PackageResourceReference#getLastModified removed in the trunk breaking some > of my components which rendered JScript reference from a component package. > Now URL has timestamp and therefore parts of JScript relying on relative to > the script positions of assets stopped working. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-3987) setUseTimestampOnResources and PackageResourceReference#getLastModified removed
[
https://issues.apache.org/jira/browse/WICKET-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090482#comment-13090482
]
Peter Ertl commented on WICKET-3987:
not pretty but working:
String url = urlFor(new
ResourceReference(StarRatingPanel.class, "img")
{
@Override
public IResource getResource()
{
return new IResource()
{
@Override
public void respond(Attributes
attributes)
{
}
};
}
}, new PageParameters()).toString();
log.info("url=" + url);
Basically it's a kludge to resolve the url to a package location with a
resource reference pointing to a non-existant resource. I don't know if a
package counts as a resource. Maybe we should add some kind of official support
for that?!
> setUseTimestampOnResources and PackageResourceReference#getLastModified
> removed
> ---
>
> Key: WICKET-3987
> URL: https://issues.apache.org/jira/browse/WICKET-3987
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.5.0
> Environment: 1.5.0 trunk
>Reporter: Konstantin Ignatyev
>Assignee: Peter Ertl
>
> IResourceSettings#setUseTimestampOnResources and
> PackageResourceReference#getLastModified removed in the trunk breaking some
> of my components which rendered JScript reference from a component package.
> Now URL has timestamp and therefore parts of JScript relying on relative to
> the script positions of assets stopped working.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-3987) setUseTimestampOnResources and PackageResourceReference#getLastModified removed
[
https://issues.apache.org/jira/browse/WICKET-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090456#comment-13090456
]
Peter Ertl commented on WICKET-3987:
Like Martin said, you can use a custom caching strategy.
sample
-
private abstract class CustomResourceCachingStrategy implements
IResourceCachingStrategy
{
private final IResourceCachingStrategy delegate;
public CustomResourceCachingStrategy(IResourceCachingStrategy
delegate)
{
this.delegate = delegate;
}
@Override
public void decorateUrl(ResourceUrl url,
IStaticCacheableResource resource)
{
if (shouldCache(resource))
{
delegate.decorateUrl(url, resource);
}
}
@Override
public void undecorateUrl(ResourceUrl url)
{
delegate.undecorateUrl(url);
}
@Override
public void decorateResponse(AbstractResource.ResourceResponse
response, IStaticCacheableResource resource)
{
if (shouldCache(resource))
{
delegate.decorateResponse(response, resource);
}
}
// override for your needs e.g. by using a marker interface
protected abstract boolean shouldCache(IStaticCacheableResource
resource);
}
and use it like this:
final IResourceCachingStrategy delegate =
getResourceSettings().getCachingStrategy();
getResourceSettings().setCachingStrategy(new
CustomResourceCachingStrategy(delegate));
> setUseTimestampOnResources and PackageResourceReference#getLastModified
> removed
> ---
>
> Key: WICKET-3987
> URL: https://issues.apache.org/jira/browse/WICKET-3987
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.5.0
> Environment: 1.5.0 trunk
>Reporter: Konstantin Ignatyev
>Assignee: Peter Ertl
>
> IResourceSettings#setUseTimestampOnResources and
> PackageResourceReference#getLastModified removed in the trunk breaking some
> of my components which rendered JScript reference from a component package.
> Now URL has timestamp and therefore parts of JScript relying on relative to
> the script positions of assets stopped working.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (WICKET-3987) setUseTimestampOnResources and PackageResourceReference#getLastModified removed
[ https://issues.apache.org/jira/browse/WICKET-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl closed WICKET-3987. -- Resolution: Not A Problem Assignee: Peter Ertl > setUseTimestampOnResources and PackageResourceReference#getLastModified > removed > --- > > Key: WICKET-3987 > URL: https://issues.apache.org/jira/browse/WICKET-3987 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.0 > Environment: 1.5.0 trunk >Reporter: Konstantin Ignatyev >Assignee: Peter Ertl > > IResourceSettings#setUseTimestampOnResources and > PackageResourceReference#getLastModified removed in the trunk breaking some > of my components which rendered JScript reference from a component package. > Now URL has timestamp and therefore parts of JScript relying on relative to > the script positions of assets stopped working. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-3987) setUseTimestampOnResources and PackageResourceReference#getLastModified removed
[ https://issues.apache.org/jira/browse/WICKET-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090334#comment-13090334 ] Peter Ertl commented on WICKET-3987: to manually remove the version dependant part of the url you eventually could use: Application#getResourceSettings().getCachingStrategy().undecorateUrl(url) > setUseTimestampOnResources and PackageResourceReference#getLastModified > removed > --- > > Key: WICKET-3987 > URL: https://issues.apache.org/jira/browse/WICKET-3987 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.0 > Environment: 1.5.0 trunk >Reporter: Konstantin Ignatyev > > IResourceSettings#setUseTimestampOnResources and > PackageResourceReference#getLastModified removed in the trunk breaking some > of my components which rendered JScript reference from a component package. > Now URL has timestamp and therefore parts of JScript relying on relative to > the script positions of assets stopped working. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-3987) setUseTimestampOnResources and PackageResourceReference#getLastModified removed
[ https://issues.apache.org/jira/browse/WICKET-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090333#comment-13090333 ] Peter Ertl commented on WICKET-3987: PackageResourceReference#getLastModified() was introduced when adding improved caching support for package resources. Recently there was a refactor (https://issues.apache.org/jira/browse/WICKET-3948) to remove some limitations of this approach. PackageResourceReference#getLastModified() became obsolete and was therefore removed. If you really need lastModified() from within PackageResourceReference you can use this (though it's a little inconvenient): PackageResourceReference reference = /* ... */; PackageResource resource = (PackageResource)reference.getResource(); Time lastModified = resource.getResourceStream().lastModifiedTime(); If we get another release candidate for 1.5 I will remove the need for the type-cast. IResourceSettings#setUseTimestampOnResources() has been replace by a more powerful solution. check https://cwiki.apache.org/WICKET/migration-to-wicket-15.html#MigrationtoWicket1.5-getResourceSettings%2528%2529.setAddLastModifiedTimeToResourceReferenceUrl%2528%2529hasbeenreplacedbyIResourceCachingStrategy to get all the details. > setUseTimestampOnResources and PackageResourceReference#getLastModified > removed > --- > > Key: WICKET-3987 > URL: https://issues.apache.org/jira/browse/WICKET-3987 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.0 > Environment: 1.5.0 trunk >Reporter: Konstantin Ignatyev > > IResourceSettings#setUseTimestampOnResources and > PackageResourceReference#getLastModified removed in the trunk breaking some > of my components which rendered JScript reference from a component package. > Now URL has timestamp and therefore parts of JScript relying on relative to > the script positions of assets stopped working. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-3972) wicket:message attribute results in "The component was rendered already" error
[ https://issues.apache.org/jira/browse/WICKET-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13088163#comment-13088163 ] Peter Ertl commented on WICKET-3972: Wow, I was really surprised that just leaving off a single line will do the trick. Impressive! At least I learned a lot more about handlers and resolvers, thanks guys!! :-) > wicket:message attribute results in "The component was rendered already" error > -- > > Key: WICKET-3972 > URL: https://issues.apache.org/jira/browse/WICKET-3972 > Project: Wicket > Issue Type: Bug > Components: wicket-core >Affects Versions: 1.5-RC5.1 > Environment: Linux Ubuntu, Tomcat 6, Java 6 >Reporter: Sergiy Barlabanov >Assignee: Juergen Donnerstag > Fix For: 1.5-RC6 > > Attachments: quickstart.zip, wicket-message-index.patch > > > Seems like there is a problem with generation of tag and component IDs when > using wicket:message as an attribute for tags inside ListView. > The quickstart webapp is attached to this ticket. There are two pages in this > webapp: HomePage with a ListView containing tags with wicket:message > attribute and two tags with wicket:message attribute outside the ListView. If > a user goes to the next page (SecondPage) using the link on HomePage and then > goes back to HomePage using the link on SecondPage, the exception mentioned > in the subject occurs. > Seems that the ID generation for tags and components is wrong: the > ComponentTag-s are cached together with the corresponding Markup and then > reused for later renderings. But the problem is, that those ComponentTag-s > are mutable (at least in case of tags with wicket:message attribute) and > their IDs are changed on every rendering and this produces ID conflicts when > MarkupContainer.renderNext tries to find or create components corresponding > to the tags. > Interesting is, that we can reproduce this bug only in DEVELOPMENT mode. In > DEPLOYMENT mode everything seems to work. The solution would be to make > ComponentTags immutable and do not allow to change them, but to create copies > (there is mutable method in ComponentTag, which is used in some cases). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (WICKET-3972) wicket:message attribute results in "The component was rendered already" error
[
https://issues.apache.org/jira/browse/WICKET-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087414#comment-13087414
]
Peter Ertl edited comment on WICKET-3972 at 8/19/11 12:26 AM:
--
@Jürgen: Thanks for the feedback :-)
I think the problem can be solved by not assigning a temporary component tag id
('_message_attr_') but a permanent one including a counter to the component
tags with 'wicket:message' attribute.
currently we have the situation that 3 component tags with 'wicket:message' are
located in the markup but only two of them get resolved on first render of
HomePage
component tag#1 (id = '_message_attr_') -- invisible since list view is empty,
so WicketMessageTagHandler#resolve() is not invoked and temporary id stays
component tag#2 (id = '_message_attr_3')
component tag#3 (id = '_message_attr_4')
-> go to SecondPage
-> go to HomePage with now visible ListView caused by page parameter
resolve now assigns a permanent id to the first component which will cause an
identifier collision
component tag#1 (id = '_message_attr_4') -> new permanent id assigned, will
refer to component that has been attached to component tag #3 recently
component tag#2 (id = '_message_attr_3') -> since the component tag has a
related component resolve will not be invoked and the old id stays
component tag#3 (id = '_message_attr_4') -> since the component tag has a
related component resolve will not be invoked and the old id stays; wicket will
again render component that has accidentally already been rendered by component
tag #1 and causes the 'component was already rendered' error
new patch included...
was (Author: pete):
@Jürgen: Thanks for the feedback :-)
I think the problem can be solved by not assigning a temporary component tag id
('_message_attr_') to the component tags with 'wicket:message' attribute
currently we have the situation that 3 component tags with 'wicket:message' are
located in the markup but only two of them get resolved on first render of
HomePage
component tag#1 (id = '_message_attr_') -- invisible since list view is empty,
so WicketMessageTagHandler#resolve() is not invoked and temporary id stays
component tag#2 (id = '_message_attr_3')
component tag#3 (id = '_message_attr_4')
-> go to SecondPage
-> go to HomePage with now visible ListView caused by page parameter
resolve now assigns a permanent id to the first component which will cause an
identifier collision
component tag#1 (id = '_message_attr_4') -> new permanent id assigned, will
refer to component that has been attached to component tag #3 recently
component tag#2 (id = '_message_attr_3') -> since the component tag has a
related component resolve will not be invoked and the old id stays
component tag#3 (id = '_message_attr_4') -> since the component tag has a
related component resolve will not be invoked and the old id stays; wicket will
again render component that has accidentally already been rendered by component
tag #1 and causes the 'component was already rendered' error
new patch included...
> wicket:message attribute results in "The component was rendered already" error
> --
>
> Key: WICKET-3972
> URL: https://issues.apache.org/jira/browse/WICKET-3972
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 1.5-RC5.1
> Environment: Linux Ubuntu, Tomcat 6, Java 6
>Reporter: Sergiy Barlabanov
>Assignee: Peter Ertl
> Attachments: quickstart.zip, wicket-message-index.patch
>
>
> Seems like there is a problem with generation of tag and component IDs when
> using wicket:message as an attribute for tags inside ListView.
> The quickstart webapp is attached to this ticket. There are two pages in this
> webapp: HomePage with a ListView containing tags with wicket:message
> attribute and two tags with wicket:message attribute outside the ListView. If
> a user goes to the next page (SecondPage) using the link on HomePage and then
> goes back to HomePage using the link on SecondPage, the exception mentioned
> in the subject occurs.
> Seems that the ID generation for tags and components is wrong: the
> ComponentTag-s are cached together with the corresponding Markup and then
> reused for later renderings. But the problem is, that those ComponentTag-s
> are mutable (at least in case of tags with wicket:message attribute) and
> their IDs are changed on every rendering and this produces ID conflicts when
> MarkupContainer.renderNext tries to find or create components corresponding
> to the tags.
> Interesting is, that we can reproduce this bug only in DEVELOPMENT mode. In
> DEPLOYMENT mode everything seems to work. The solution would be to make
> ComponentTags immutable a
[jira] [Issue Comment Edited] (WICKET-3972) wicket:message attribute results in "The component was rendered already" error
[
https://issues.apache.org/jira/browse/WICKET-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087414#comment-13087414
]
Peter Ertl edited comment on WICKET-3972 at 8/19/11 12:17 AM:
--
@Jürgen: Thanks for the feedback :-)
I think the problem can be solved by not assigning a temporary component tag id
('_message_attr_') to the component tags with 'wicket:message' attribute
currently we have the situation that 3 component tags with 'wicket:message' are
located in the markup but only two of them get resolved on first render of
HomePage
component tag#1 (id = '_message_attr_') -- invisible since list view is empty,
so WicketMessageTagHandler#resolve() is not invoked and temporary id stays
component tag#2 (id = '_message_attr_3')
component tag#3 (id = '_message_attr_4')
-> go to SecondPage
-> go to HomePage with now visible ListView caused by page parameter
resolve now assigns a permanent id to the first component which will cause an
identifier collision
component tag#1 (id = '_message_attr_4') -> new permanent id assigned, will
refer to component that has been attached to component tag #3 recently
component tag#2 (id = '_message_attr_3') -> since the component tag has a
related component resolve will not be invoked and the old id stays
component tag#3 (id = '_message_attr_4') -> since the component tag has a
related component resolve will not be invoked and the old id stays; wicket will
again render component that has accidentally already been rendered by component
tag #1 and causes the 'component was already rendered' error
new patch included...
was (Author: pete):
@Jürgen: Thanks for the feedback :-)
I think the problem can be solved by not temporarily assigning component tag
ids which get resolved later in unpredictable order but by resolving them all
at once. new patch attached...
> wicket:message attribute results in "The component was rendered already" error
> --
>
> Key: WICKET-3972
> URL: https://issues.apache.org/jira/browse/WICKET-3972
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 1.5-RC5.1
> Environment: Linux Ubuntu, Tomcat 6, Java 6
>Reporter: Sergiy Barlabanov
>Assignee: Peter Ertl
> Attachments: quickstart.zip, wicket-message-index.patch
>
>
> Seems like there is a problem with generation of tag and component IDs when
> using wicket:message as an attribute for tags inside ListView.
> The quickstart webapp is attached to this ticket. There are two pages in this
> webapp: HomePage with a ListView containing tags with wicket:message
> attribute and two tags with wicket:message attribute outside the ListView. If
> a user goes to the next page (SecondPage) using the link on HomePage and then
> goes back to HomePage using the link on SecondPage, the exception mentioned
> in the subject occurs.
> Seems that the ID generation for tags and components is wrong: the
> ComponentTag-s are cached together with the corresponding Markup and then
> reused for later renderings. But the problem is, that those ComponentTag-s
> are mutable (at least in case of tags with wicket:message attribute) and
> their IDs are changed on every rendering and this produces ID conflicts when
> MarkupContainer.renderNext tries to find or create components corresponding
> to the tags.
> Interesting is, that we can reproduce this bug only in DEVELOPMENT mode. In
> DEPLOYMENT mode everything seems to work. The solution would be to make
> ComponentTags immutable and do not allow to change them, but to create copies
> (there is mutable method in ComponentTag, which is used in some cases).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-3972) wicket:message attribute results in "The component was rendered already" error
[ https://issues.apache.org/jira/browse/WICKET-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl updated WICKET-3972: --- Attachment: (was: auto-index-inside-markup.patch) > wicket:message attribute results in "The component was rendered already" error > -- > > Key: WICKET-3972 > URL: https://issues.apache.org/jira/browse/WICKET-3972 > Project: Wicket > Issue Type: Bug > Components: wicket-core >Affects Versions: 1.5-RC5.1 > Environment: Linux Ubuntu, Tomcat 6, Java 6 >Reporter: Sergiy Barlabanov >Assignee: Peter Ertl > Attachments: quickstart.zip, wicket-message-index.patch > > > Seems like there is a problem with generation of tag and component IDs when > using wicket:message as an attribute for tags inside ListView. > The quickstart webapp is attached to this ticket. There are two pages in this > webapp: HomePage with a ListView containing tags with wicket:message > attribute and two tags with wicket:message attribute outside the ListView. If > a user goes to the next page (SecondPage) using the link on HomePage and then > goes back to HomePage using the link on SecondPage, the exception mentioned > in the subject occurs. > Seems that the ID generation for tags and components is wrong: the > ComponentTag-s are cached together with the corresponding Markup and then > reused for later renderings. But the problem is, that those ComponentTag-s > are mutable (at least in case of tags with wicket:message attribute) and > their IDs are changed on every rendering and this produces ID conflicts when > MarkupContainer.renderNext tries to find or create components corresponding > to the tags. > Interesting is, that we can reproduce this bug only in DEVELOPMENT mode. In > DEPLOYMENT mode everything seems to work. The solution would be to make > ComponentTags immutable and do not allow to change them, but to create copies > (there is mutable method in ComponentTag, which is used in some cases). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-3972) wicket:message attribute results in "The component was rendered already" error
[ https://issues.apache.org/jira/browse/WICKET-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl updated WICKET-3972: --- Attachment: wicket-message-index.patch > wicket:message attribute results in "The component was rendered already" error > -- > > Key: WICKET-3972 > URL: https://issues.apache.org/jira/browse/WICKET-3972 > Project: Wicket > Issue Type: Bug > Components: wicket-core >Affects Versions: 1.5-RC5.1 > Environment: Linux Ubuntu, Tomcat 6, Java 6 >Reporter: Sergiy Barlabanov >Assignee: Peter Ertl > Attachments: quickstart.zip, wicket-message-index.patch > > > Seems like there is a problem with generation of tag and component IDs when > using wicket:message as an attribute for tags inside ListView. > The quickstart webapp is attached to this ticket. There are two pages in this > webapp: HomePage with a ListView containing tags with wicket:message > attribute and two tags with wicket:message attribute outside the ListView. If > a user goes to the next page (SecondPage) using the link on HomePage and then > goes back to HomePage using the link on SecondPage, the exception mentioned > in the subject occurs. > Seems that the ID generation for tags and components is wrong: the > ComponentTag-s are cached together with the corresponding Markup and then > reused for later renderings. But the problem is, that those ComponentTag-s > are mutable (at least in case of tags with wicket:message attribute) and > their IDs are changed on every rendering and this produces ID conflicts when > MarkupContainer.renderNext tries to find or create components corresponding > to the tags. > Interesting is, that we can reproduce this bug only in DEVELOPMENT mode. In > DEPLOYMENT mode everything seems to work. The solution would be to make > ComponentTags immutable and do not allow to change them, but to create copies > (there is mutable method in ComponentTag, which is used in some cases). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-3972) wicket:message attribute results in "The component was rendered already" error
[ https://issues.apache.org/jira/browse/WICKET-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087414#comment-13087414 ] Peter Ertl commented on WICKET-3972: @Jürgen: Thanks for the feedback :-) I think the problem can be solved by not temporarily assigning component tag ids which get resolved later in unpredictable order but by resolving them all at once. new patch attached... > wicket:message attribute results in "The component was rendered already" error > -- > > Key: WICKET-3972 > URL: https://issues.apache.org/jira/browse/WICKET-3972 > Project: Wicket > Issue Type: Bug > Components: wicket-core >Affects Versions: 1.5-RC5.1 > Environment: Linux Ubuntu, Tomcat 6, Java 6 >Reporter: Sergiy Barlabanov >Assignee: Peter Ertl > Attachments: auto-index-inside-markup.patch, quickstart.zip > > > Seems like there is a problem with generation of tag and component IDs when > using wicket:message as an attribute for tags inside ListView. > The quickstart webapp is attached to this ticket. There are two pages in this > webapp: HomePage with a ListView containing tags with wicket:message > attribute and two tags with wicket:message attribute outside the ListView. If > a user goes to the next page (SecondPage) using the link on HomePage and then > goes back to HomePage using the link on SecondPage, the exception mentioned > in the subject occurs. > Seems that the ID generation for tags and components is wrong: the > ComponentTag-s are cached together with the corresponding Markup and then > reused for later renderings. But the problem is, that those ComponentTag-s > are mutable (at least in case of tags with wicket:message attribute) and > their IDs are changed on every rendering and this produces ID conflicts when > MarkupContainer.renderNext tries to find or create components corresponding > to the tags. > Interesting is, that we can reproduce this bug only in DEVELOPMENT mode. In > DEPLOYMENT mode everything seems to work. The solution would be to make > ComponentTags immutable and do not allow to change them, but to create copies > (there is mutable method in ComponentTag, which is used in some cases). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-3972) wicket:message attribute results in "The component was rendered already" error
[ https://issues.apache.org/jira/browse/WICKET-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087174#comment-13087174 ] Peter Ertl commented on WICKET-3972: For component tags that not necessarily relate to a wicket component (tag id <> component id) we need to place auto index somewhere else but not in page. I will attach a patch which puts the auto index right inside MarkupResourceStream. I think this is the technically right place. However I don't know if this is ugly or the way to solve it, so feedback is welcome... > wicket:message attribute results in "The component was rendered already" error > -- > > Key: WICKET-3972 > URL: https://issues.apache.org/jira/browse/WICKET-3972 > Project: Wicket > Issue Type: Bug > Components: wicket-core >Affects Versions: 1.5-RC5.1 > Environment: Linux Ubuntu, Tomcat 6, Java 6 >Reporter: Sergiy Barlabanov >Assignee: Peter Ertl > Attachments: auto-index-inside-markup.patch, quickstart.zip > > > Seems like there is a problem with generation of tag and component IDs when > using wicket:message as an attribute for tags inside ListView. > The quickstart webapp is attached to this ticket. There are two pages in this > webapp: HomePage with a ListView containing tags with wicket:message > attribute and two tags with wicket:message attribute outside the ListView. If > a user goes to the next page (SecondPage) using the link on HomePage and then > goes back to HomePage using the link on SecondPage, the exception mentioned > in the subject occurs. > Seems that the ID generation for tags and components is wrong: the > ComponentTag-s are cached together with the corresponding Markup and then > reused for later renderings. But the problem is, that those ComponentTag-s > are mutable (at least in case of tags with wicket:message attribute) and > their IDs are changed on every rendering and this produces ID conflicts when > MarkupContainer.renderNext tries to find or create components corresponding > to the tags. > Interesting is, that we can reproduce this bug only in DEVELOPMENT mode. In > DEPLOYMENT mode everything seems to work. The solution would be to make > ComponentTags immutable and do not allow to change them, but to create copies > (there is mutable method in ComponentTag, which is used in some cases). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-3972) wicket:message attribute results in "The component was rendered already" error
[ https://issues.apache.org/jira/browse/WICKET-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl updated WICKET-3972: --- Attachment: auto-index-inside-markup.patch > wicket:message attribute results in "The component was rendered already" error > -- > > Key: WICKET-3972 > URL: https://issues.apache.org/jira/browse/WICKET-3972 > Project: Wicket > Issue Type: Bug > Components: wicket-core >Affects Versions: 1.5-RC5.1 > Environment: Linux Ubuntu, Tomcat 6, Java 6 >Reporter: Sergiy Barlabanov >Assignee: Peter Ertl > Attachments: auto-index-inside-markup.patch, quickstart.zip > > > Seems like there is a problem with generation of tag and component IDs when > using wicket:message as an attribute for tags inside ListView. > The quickstart webapp is attached to this ticket. There are two pages in this > webapp: HomePage with a ListView containing tags with wicket:message > attribute and two tags with wicket:message attribute outside the ListView. If > a user goes to the next page (SecondPage) using the link on HomePage and then > goes back to HomePage using the link on SecondPage, the exception mentioned > in the subject occurs. > Seems that the ID generation for tags and components is wrong: the > ComponentTag-s are cached together with the corresponding Markup and then > reused for later renderings. But the problem is, that those ComponentTag-s > are mutable (at least in case of tags with wicket:message attribute) and > their IDs are changed on every rendering and this produces ID conflicts when > MarkupContainer.renderNext tries to find or create components corresponding > to the tags. > Interesting is, that we can reproduce this bug only in DEVELOPMENT mode. In > DEPLOYMENT mode everything seems to work. The solution would be to make > ComponentTags immutable and do not allow to change them, but to create copies > (there is mutable method in ComponentTag, which is used in some cases). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (WICKET-3972) wicket:message attribute results in "The component was rendered already" error
[ https://issues.apache.org/jira/browse/WICKET-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl reassigned WICKET-3972: -- Assignee: Peter Ertl > wicket:message attribute results in "The component was rendered already" error > -- > > Key: WICKET-3972 > URL: https://issues.apache.org/jira/browse/WICKET-3972 > Project: Wicket > Issue Type: Bug > Components: wicket-core >Affects Versions: 1.5-RC5.1 > Environment: Linux Ubuntu, Tomcat 6, Java 6 >Reporter: Sergiy Barlabanov >Assignee: Peter Ertl > Attachments: auto-index-inside-markup.patch, quickstart.zip > > > Seems like there is a problem with generation of tag and component IDs when > using wicket:message as an attribute for tags inside ListView. > The quickstart webapp is attached to this ticket. There are two pages in this > webapp: HomePage with a ListView containing tags with wicket:message > attribute and two tags with wicket:message attribute outside the ListView. If > a user goes to the next page (SecondPage) using the link on HomePage and then > goes back to HomePage using the link on SecondPage, the exception mentioned > in the subject occurs. > Seems that the ID generation for tags and components is wrong: the > ComponentTag-s are cached together with the corresponding Markup and then > reused for later renderings. But the problem is, that those ComponentTag-s > are mutable (at least in case of tags with wicket:message attribute) and > their IDs are changed on every rendering and this produces ID conflicts when > MarkupContainer.renderNext tries to find or create components corresponding > to the tags. > Interesting is, that we can reproduce this bug only in DEVELOPMENT mode. In > DEPLOYMENT mode everything seems to work. The solution would be to make > ComponentTags immutable and do not allow to change them, but to create copies > (there is mutable method in ComponentTag, which is used in some cases). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-3972) wicket:message attribute results in "The component was rendered already" error
[ https://issues.apache.org/jira/browse/WICKET-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087166#comment-13087166 ] Peter Ertl commented on WICKET-3972: replace above 'component id' with 'tag id' > wicket:message attribute results in "The component was rendered already" error > -- > > Key: WICKET-3972 > URL: https://issues.apache.org/jira/browse/WICKET-3972 > Project: Wicket > Issue Type: Bug > Components: wicket-core >Affects Versions: 1.5-RC5.1 > Environment: Linux Ubuntu, Tomcat 6, Java 6 >Reporter: Sergiy Barlabanov > Attachments: quickstart.zip > > > Seems like there is a problem with generation of tag and component IDs when > using wicket:message as an attribute for tags inside ListView. > The quickstart webapp is attached to this ticket. There are two pages in this > webapp: HomePage with a ListView containing tags with wicket:message > attribute and two tags with wicket:message attribute outside the ListView. If > a user goes to the next page (SecondPage) using the link on HomePage and then > goes back to HomePage using the link on SecondPage, the exception mentioned > in the subject occurs. > Seems that the ID generation for tags and components is wrong: the > ComponentTag-s are cached together with the corresponding Markup and then > reused for later renderings. But the problem is, that those ComponentTag-s > are mutable (at least in case of tags with wicket:message attribute) and > their IDs are changed on every rendering and this produces ID conflicts when > MarkupContainer.renderNext tries to find or create components corresponding > to the tags. > Interesting is, that we can reproduce this bug only in DEVELOPMENT mode. In > DEPLOYMENT mode everything seems to work. The solution would be to make > ComponentTags immutable and do not allow to change them, but to create copies > (there is mutable method in ComponentTag, which is used in some cases). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-3972) wicket:message attribute results in "The component was rendered already" error
[ https://issues.apache.org/jira/browse/WICKET-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087147#comment-13087147 ] Peter Ertl commented on WICKET-3972: Short summary on what I found so far: The problem lies within WicketMessageTagHandler, WicketMessageResolver and the behavior of Page.getAutoIndex(). When rendering HomePage for the 1st time WicketMessageResolver resolves the 'wicket:message' attributes and sets the component id of the affected components to '_message_attr_'. WicketMessageTagHandler will detect all component with '_message_attr_' and add an auto index. The auto index starts with zero when rendering begins and returns unique id's for dynamically creating unique component ids. So after the first render we have the first input tag resolved with id = '_message_attr_4' (the one that causes the crash later). Now we redirect to SecondPage and return. Since the list view will create another tag with 'wicket:message' it will receive ''_message_attr' as temporary component id. Again WicketMessageTagHandler tries to assign an auto index (which starts with zero every new render). In this example it gets index = 4 by chance (unlucky!) which already exists so we get a duplicate component id. The solution is probably to check if a component already exists when creating new component id's with auto index or to keep auto index incrementing over different page id's for the same page (however this will make stateless pages stateful). I keep on investigating... > wicket:message attribute results in "The component was rendered already" error > -- > > Key: WICKET-3972 > URL: https://issues.apache.org/jira/browse/WICKET-3972 > Project: Wicket > Issue Type: Bug > Components: wicket-core >Affects Versions: 1.5-RC5.1 > Environment: Linux Ubuntu, Tomcat 6, Java 6 >Reporter: Sergiy Barlabanov > Attachments: quickstart.zip > > > Seems like there is a problem with generation of tag and component IDs when > using wicket:message as an attribute for tags inside ListView. > The quickstart webapp is attached to this ticket. There are two pages in this > webapp: HomePage with a ListView containing tags with wicket:message > attribute and two tags with wicket:message attribute outside the ListView. If > a user goes to the next page (SecondPage) using the link on HomePage and then > goes back to HomePage using the link on SecondPage, the exception mentioned > in the subject occurs. > Seems that the ID generation for tags and components is wrong: the > ComponentTag-s are cached together with the corresponding Markup and then > reused for later renderings. But the problem is, that those ComponentTag-s > are mutable (at least in case of tags with wicket:message attribute) and > their IDs are changed on every rendering and this produces ID conflicts when > MarkupContainer.renderNext tries to find or create components corresponding > to the tags. > Interesting is, that we can reproduce this bug only in DEVELOPMENT mode. In > DEPLOYMENT mode everything seems to work. The solution would be to make > ComponentTags immutable and do not allow to change them, but to create copies > (there is mutable method in ComponentTag, which is used in some cases). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (WICKET-3948) IResourceCachingStrategy is too much bound to PackageResource, make it more general
[ https://issues.apache.org/jira/browse/WICKET-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ertl closed WICKET-3948. -- Resolution: Fixed Fix Version/s: 1.5-RC6 > IResourceCachingStrategy is too much bound to PackageResource, make it more > general > --- > > Key: WICKET-3948 > URL: https://issues.apache.org/jira/browse/WICKET-3948 > Project: Wicket > Issue Type: Improvement > Components: wicket-core >Affects Versions: 1.5-RC5.1 >Reporter: Peter Ertl >Assignee: Peter Ertl > Fix For: 1.5-RC6 > > Attachments: cache7.patch > > > Somebody recently complained on the wicket userlist that > IResourceCachingStrategy is not very versatile but only useable for > PackageResources. I 100% agree would like to generalize the caching part by > introducing the interface 'ICacheableResourceReference' (instead of referring > to PackageResource). This makes it easy to use caching for other resource > types. Since we are so close to 1.5 I would like to ask first if the patch is > acceptable by you. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-3948) IResourceCachingStrategy is too much bound to PackageResource, make it more general
[ https://issues.apache.org/jira/browse/WICKET-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087134#comment-13087134 ] Peter Ertl commented on WICKET-3948: unless you find any bugs it should be fine :-) I am closing this issue for now but won't bother to reopen it for bugs. > IResourceCachingStrategy is too much bound to PackageResource, make it more > general > --- > > Key: WICKET-3948 > URL: https://issues.apache.org/jira/browse/WICKET-3948 > Project: Wicket > Issue Type: Improvement > Components: wicket-core >Affects Versions: 1.5-RC5.1 >Reporter: Peter Ertl >Assignee: Peter Ertl > Fix For: 1.5-RC6 > > Attachments: cache7.patch > > > Somebody recently complained on the wicket userlist that > IResourceCachingStrategy is not very versatile but only useable for > PackageResources. I 100% agree would like to generalize the caching part by > introducing the interface 'ICacheableResourceReference' (instead of referring > to PackageResource). This makes it easy to use caching for other resource > types. Since we are so close to 1.5 I would like to ask first if the patch is > acceptable by you. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
