[jira] Commented: (WICKET-3215) AutoCompleteTextField does not work in an iframe under IE 6, 7 or 8
[ https://issues.apache.org/jira/browse/WICKET-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966025#action_12966025 ] Martin Grigorov commented on WICKET-3215: - Please provide a quickstart application that reproduces the problem. AutoCompleteTextField does not work in an iframe under IE 6, 7 or 8 --- Key: WICKET-3215 URL: https://issues.apache.org/jira/browse/WICKET-3215 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.4.11, 1.4.12, 1.4.13, 1.4.14 Environment: Windows Server 2003 Reporter: Robert Csok The code that has been integrated in version 1.4.11 to fix issue WICKET-2279 forces the cursor of an AutoCompleteTextField to do a carriage return after each typed in char when the application runs in an iframe and IE 6, 7 or 8 is used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1041315 - in /wicket/trunk: ./ archetypes/quickstart/ testing/wicket-threadtest/ wicket-auth-roles/ wicket-datetime/ wicket-devutils/ wicket-examples/ wicket-extensions/ wicket-guice/ wic
Author: pete Date: Thu Dec 2 09:26:57 2010 New Revision: 1041315 URL: http://svn.apache.org/viewvc?rev=1041315view=rev Log: add IDEA project files to svn ignore properties Modified: wicket/trunk/ (props changed) wicket/trunk/archetypes/quickstart/ (props changed) wicket/trunk/testing/wicket-threadtest/ (props changed) wicket/trunk/wicket/ (props changed) wicket/trunk/wicket-auth-roles/ (props changed) wicket/trunk/wicket-datetime/ (props changed) wicket/trunk/wicket-devutils/ (props changed) wicket/trunk/wicket-examples/ (props changed) wicket/trunk/wicket-extensions/ (props changed) wicket/trunk/wicket-guice/ (props changed) wicket/trunk/wicket-ioc/ (props changed) wicket/trunk/wicket-jmx/ (props changed) wicket/trunk/wicket-objectssizeof-agent/ (props changed) wicket/trunk/wicket-request/ (props changed) wicket/trunk/wicket-spring/ (props changed) wicket/trunk/wicket-util/ (props changed) wicket/trunk/wicket-velocity/ (props changed) Propchange: wicket/trunk/ -- --- svn:ignore (original) +++ svn:ignore Thu Dec 2 09:26:57 2010 @@ -2,3 +2,8 @@ target .metadata .project velocity.log +*.iml +*.ipr +*.iws +.idea +classes Propchange: wicket/trunk/archetypes/quickstart/ -- --- svn:ignore (original) +++ svn:ignore Thu Dec 2 09:26:57 2010 @@ -1,5 +1,4 @@ target - .classpath - .project +*.iml Propchange: wicket/trunk/testing/wicket-threadtest/ -- --- svn:ignore (original) +++ svn:ignore Thu Dec 2 09:26:57 2010 @@ -1,3 +1,4 @@ .classpath .project target +*.iml Propchange: wicket/trunk/wicket/ -- --- svn:ignore (original) +++ svn:ignore Thu Dec 2 09:26:57 2010 @@ -13,3 +13,4 @@ sessions bin .classpath-e .externalToolBuilders +*.iml Propchange: wicket/trunk/wicket-auth-roles/ -- --- svn:ignore (original) +++ svn:ignore Thu Dec 2 09:26:57 2010 @@ -4,3 +4,4 @@ target *.log .wtpmodules sessions +*.iml Propchange: wicket/trunk/wicket-datetime/ -- --- svn:ignore (original) +++ svn:ignore Thu Dec 2 09:26:57 2010 @@ -1,3 +1,4 @@ .classpath .project target +*.iml Propchange: wicket/trunk/wicket-devutils/ -- --- svn:ignore (original) +++ svn:ignore Thu Dec 2 09:26:57 2010 @@ -2,3 +2,4 @@ .project target .settings +*.iml Propchange: wicket/trunk/wicket-examples/ -- --- svn:ignore (original) +++ svn:ignore Thu Dec 2 09:26:57 2010 @@ -11,5 +11,5 @@ velocity.log *.backup deploy.sh sessions - +*.iml velocity.log.1 Propchange: wicket/trunk/wicket-extensions/ -- --- svn:ignore (original) +++ svn:ignore Thu Dec 2 09:26:57 2010 @@ -12,3 +12,4 @@ cdapp.script velocity.log build *.backup +*.iml Propchange: wicket/trunk/wicket-guice/ -- --- svn:ignore (original) +++ svn:ignore Thu Dec 2 09:26:57 2010 @@ -1,3 +1,4 @@ target .classpath .project +*.iml Propchange: wicket/trunk/wicket-ioc/ -- --- svn:ignore (original) +++ svn:ignore Thu Dec 2 09:26:57 2010 @@ -1,3 +1,4 @@ target .classpath .project +*.iml Propchange: wicket/trunk/wicket-jmx/ -- --- svn:ignore (original) +++ svn:ignore Thu Dec 2 09:26:57 2010 @@ -1,3 +1,4 @@ .classpath .project target +*.iml Propchange: wicket/trunk/wicket-objectssizeof-agent/ -- --- svn:ignore (original) +++ svn:ignore Thu Dec 2 09:26:57 2010 @@ -1,3 +1,4 @@ .classpath .project target +*.iml Propchange: wicket/trunk/wicket-request/ -- --- svn:ignore (original) +++ svn:ignore Thu Dec 2 09:26:57 2010 @@ -1,3 +1,4 @@ target .classpath .project +*.iml Propchange: wicket/trunk/wicket-spring/ -- --- svn:ignore (original) +++ svn:ignore Thu Dec 2 09:26:57 2010 @@ -4,3 +4,4 @@ target *.log cobertura.ser .wtpmodules +*.iml Propchange: wicket/trunk/wicket-util/ -- --- svn:ignore (original) +++ svn:ignore Thu Dec 2 09:26:57 2010 @@ -1,3 +1,4 @@
[jira] Created: (WICKET-3216) Url Page Parameters are coming null when mounted a page with IndexedParamUrlCodingStrategy
Url Page Parameters are coming null when mounted a page with IndexedParamUrlCodingStrategy -- Key: WICKET-3216 URL: https://issues.apache.org/jira/browse/WICKET-3216 Project: Wicket Issue Type: Bug Components: wicket Environment: Windows Xp Reporter: shashi Hi My application was developed in wicket 1.3.1 and i am using IndexedParamUrlCodingStrategy to mount the book markable page in my application class setFriendlyUrls() method like this this.mount(new IndexedParamUrlCodingStrategy(/trainexception,TrainExceptionsPage.class)); and my train exception page has overload constructor with page parametrs as argument when i type the url as http://localhost:8080/itm/secure/jas/trainexception?suiFunctionCommand=tesuiCommandLine=tesuiFunctionTLA=NGTsuiFunctionName=Exceptions%20%28TE%29 and hit enter constructor with out page parameters are getting called and when i debug and see the page parameters are coming a s null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3215) AutoCompleteTextField does not work in an iframe under IE 6, 7 or 8
[ https://issues.apache.org/jira/browse/WICKET-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Csok updated WICKET-3215: Attachment: HomePage.java HomePage.html iframe.html AutoCompleteTextField does not work in an iframe under IE 6, 7 or 8 --- Key: WICKET-3215 URL: https://issues.apache.org/jira/browse/WICKET-3215 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.4.11, 1.4.12, 1.4.13, 1.4.14 Environment: Windows Server 2003 Reporter: Robert Csok Attachments: HomePage.html, HomePage.java, iframe.html The code that has been integrated in version 1.4.11 to fix issue WICKET-2279 forces the cursor of an AutoCompleteTextField to do a carriage return after each typed in char when the application runs in an iframe and IE 6, 7 or 8 is used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3216) Url Page Parameters are coming null when mounted a page with IndexedParamUrlCodingStrategy
[
https://issues.apache.org/jira/browse/WICKET-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shashi updated WICKET-3216:
---
Description:
Hi
My application was developed in wicket 1.3.1 and i am using
IndexedParamUrlCodingStrategy to mount the book markable page in my application
class setFriendlyUrls() method like this
this.mount(new
IndexedParamUrlCodingStrategy(/trainexception,TrainExceptionsPage.class));
and my train exception page has overload constructor with page parametrs as
argument when i type the url as
http://localhost:8080/itm/secure/jas/trainexception?suiFunctionCommand=tesuiCommandLine=tesuiFunctionTLA=NGTsuiFunctionName=Exceptions%20%28TE%29
and hit enter constructor with out page parameters are getting called and when
i debug and see the page parameters are coming a s null.
my observation is in deCodeParameters method urlFragment is coming as blank
string.
if (urlFragment.startsWith(/))
{
urlFragment = urlFragment.substring(1);
}
if (urlFragment.length() 0 urlFragment.endsWith(/))
{
urlFragment = urlFragment.substring(0,
urlFragment.length() - 1);
}
if (urlFragment.length() 0)
{
String[] parts = urlFragment.split(/);
for (int i = 0; i parts.length; i++)
{
if
(WebRequestCodingStrategy.PAGEMAP.equals(parts[i]))
{
i++;
params.put(WebRequestCodingStrategy.PAGEMAP, WebRequestCodingStrategy
.decodePageMapName(urlDecode(parts[i])));
}
else if
(WebRequestCodingStrategy.INTERFACE_PARAMETER_NAME.equals(parts[i]))
{
i++;
params.put(WebRequestCodingStrategy.INTERFACE_PARAMETER_NAME,
urlDecode(parts[i]));
}
else
{
params.put(String.valueOf(i),
urlDecode(parts[i]));
}
}
}
so all the below conditions are getting falied and emplty paramers are returned.
but when i put a debug point i saw that the underlying array in urlFragment
string us having the values but the string is empty.this is puzzling me.
was:
Hi
My application was developed in wicket 1.3.1 and i am using
IndexedParamUrlCodingStrategy to mount the book markable page in my application
class setFriendlyUrls() method like this
this.mount(new
IndexedParamUrlCodingStrategy(/trainexception,TrainExceptionsPage.class));
and my train exception page has overload constructor with page parametrs as
argument when i type the url as
http://localhost:8080/itm/secure/jas/trainexception?suiFunctionCommand=tesuiCommandLine=tesuiFunctionTLA=NGTsuiFunctionName=Exceptions%20%28TE%29
and hit enter constructor with out page parameters are getting called and when
i debug and see the page parameters are coming a s null.
Url Page Parameters are coming null when mounted a page with
IndexedParamUrlCodingStrategy
--
Key: WICKET-3216
URL: https://issues.apache.org/jira/browse/WICKET-3216
Project: Wicket
Issue Type: Bug
Components: wicket
Environment: Windows Xp
Reporter: shashi
Fix For: 1.4.15, 1.5-M4
Hi
My application was developed in wicket 1.3.1 and i am using
IndexedParamUrlCodingStrategy to mount the book markable page in my
application class setFriendlyUrls() method like this
this.mount(new
IndexedParamUrlCodingStrategy(/trainexception,TrainExceptionsPage.class));
and my train exception page has overload constructor with page parametrs as
argument when i type the url as
http://localhost:8080/itm/secure/jas/trainexception?suiFunctionCommand=tesuiCommandLine=tesuiFunctionTLA=NGTsuiFunctionName=Exceptions%20%28TE%29
and hit enter constructor with out page parameters are getting called and
when i debug and see the page parameters are coming a s null.
my observation is in deCodeParameters method urlFragment is coming as blank
string.
if (urlFragment.startsWith(/))
{
urlFragment = urlFragment.substring(1);
}
if (urlFragment.length() 0 urlFragment.endsWith(/))
{
urlFragment =
svn commit: r1041340 - in /wicket/trunk: wicket-util/src/main/java/org/apache/wicket/util/lang/Bytes.java wicket/src/test/java/org/apache/wicket/util/lang/BytesTest.java
Author: mgrigorov
Date: Thu Dec 2 11:56:00 2010
New Revision: 1041340
URL: http://svn.apache.org/viewvc?rev=1041340view=rev
Log:
Remove support for negative values in Bytes
Modified:
wicket/trunk/wicket-util/src/main/java/org/apache/wicket/util/lang/Bytes.java
wicket/trunk/wicket/src/test/java/org/apache/wicket/util/lang/BytesTest.java
Modified:
wicket/trunk/wicket-util/src/main/java/org/apache/wicket/util/lang/Bytes.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket-util/src/main/java/org/apache/wicket/util/lang/Bytes.java?rev=1041340r1=1041339r2=1041340view=diff
==
---
wicket/trunk/wicket-util/src/main/java/org/apache/wicket/util/lang/Bytes.java
(original)
+++
wicket/trunk/wicket-util/src/main/java/org/apache/wicket/util/lang/Bytes.java
Thu Dec 2 11:56:00 2010
@@ -105,6 +105,11 @@ public final class Bytes extends LongVal
private Bytes(final long bytes)
{
super(bytes);
+
+ if (bytes 0)
+ {
+ throw new IllegalArgumentException('bytes' cannot be
negative.);
+ }
}
/**
@@ -379,34 +384,27 @@ public final class Bytes extends LongVal
*/
public String toString(final Locale locale)
{
- if (value = 0)
+ if (terabytes() = 1.0)
{
- if (terabytes() = 1.0)
- {
- return unitString(terabytes(), T, locale);
- }
-
- if (gigabytes() = 1.0)
- {
- return unitString(gigabytes(), G, locale);
- }
-
- if (megabytes() = 1.0)
- {
- return unitString(megabytes(), M, locale);
- }
+ return unitString(terabytes(), T, locale);
+ }
- if (kilobytes() = 1.0)
- {
- return unitString(kilobytes(), K, locale);
- }
+ if (gigabytes() = 1.0)
+ {
+ return unitString(gigabytes(), G, locale);
+ }
- return Long.toString(value) + bytes;
+ if (megabytes() = 1.0)
+ {
+ return unitString(megabytes(), M, locale);
}
- else
+
+ if (kilobytes() = 1.0)
{
- return N/A;
+ return unitString(kilobytes(), K, locale);
}
+
+ return Long.toString(value) + bytes;
}
/**
Modified:
wicket/trunk/wicket/src/test/java/org/apache/wicket/util/lang/BytesTest.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/test/java/org/apache/wicket/util/lang/BytesTest.java?rev=1041340r1=1041339r2=1041340view=diff
==
---
wicket/trunk/wicket/src/test/java/org/apache/wicket/util/lang/BytesTest.java
(original)
+++
wicket/trunk/wicket/src/test/java/org/apache/wicket/util/lang/BytesTest.java
Thu Dec 2 11:56:00 2010
@@ -143,8 +143,23 @@ public class BytesTest extends TestCase
assertEquals(1G, Bytes.bytes(1024 * 1024 * 1024L).toString());
assertEquals(1T, Bytes.bytes(1024 * 1024 * 1024 *
1024L).toString());
assertEquals(1.5K, Bytes.bytes(1024 * 1.5).toString());
- assertEquals(N/A, Bytes.bytes(-1).toString());
assertEquals(1 bytes, Bytes.bytes(1).toString(Locale.GERMAN));
}
+
+ /**
+* Negative values are not supported
+*/
+ public void testNegative()
+ {
+ try
+ {
+ Bytes.bytes(-1);
+ fail(Bytes should not support negative values!);
+ }
+ catch (IllegalArgumentException iax)
+ {
+ ;
+ }
+ }
}
svn commit: r1041341 - /wicket/trunk/wicket-util/src/main/java/org/apache/wicket/util/resource/FileResourceStream.java
Author: mgrigorov
Date: Thu Dec 2 11:57:50 2010
New Revision: 1041341
URL: http://svn.apache.org/viewvc?rev=1041341view=rev
Log:
Implement properly IResourceStream#length() - if the length is unknown then
return 'null'.
Modified:
wicket/trunk/wicket-util/src/main/java/org/apache/wicket/util/resource/FileResourceStream.java
Modified:
wicket/trunk/wicket-util/src/main/java/org/apache/wicket/util/resource/FileResourceStream.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket-util/src/main/java/org/apache/wicket/util/resource/FileResourceStream.java?rev=1041341r1=1041340r2=1041341view=diff
==
---
wicket/trunk/wicket-util/src/main/java/org/apache/wicket/util/resource/FileResourceStream.java
(original)
+++
wicket/trunk/wicket-util/src/main/java/org/apache/wicket/util/resource/FileResourceStream.java
Thu Dec 2 11:57:50 2010
@@ -160,7 +160,7 @@ public class FileResourceStream extends
{
return Bytes.bytes(file.length());
}
- return Bytes.bytes(0);
+ return null;
}
/**
svn commit: r1041345 - /wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/YuiLib.java
Author: mgrigorov
Date: Thu Dec 2 12:13:01 2010
New Revision: 1041345
URL: http://svn.apache.org/viewvc?rev=1041345view=rev
Log:
WICKET-3213 YuiLib private constructor but implements IClusterable and has
serialVersionUID
No need to be Serializable. There is no state
Modified:
wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/YuiLib.java
Modified:
wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/YuiLib.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/YuiLib.java?rev=1041345r1=1041344r2=1041345view=diff
==
---
wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/YuiLib.java
(original)
+++
wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/YuiLib.java
Thu Dec 2 12:13:01 2010
@@ -17,7 +17,6 @@
package org.apache.wicket.extensions.yui;
import org.apache.wicket.Application;
-import org.apache.wicket.IClusterable;
import org.apache.wicket.markup.html.IHeaderResponse;
import org.apache.wicket.request.resource.CompressedResourceReference;
import org.apache.wicket.request.resource.ResourceReference;
@@ -31,10 +30,8 @@ import org.apache.wicket.request.resourc
*
* @author eelcohillenius
*/
-public final class YuiLib implements IClusterable
+public final class YuiLib
{
- private static final long serialVersionUID = 1L;
-
private static ResourceReference YUILOADER;
/**
@@ -53,7 +50,7 @@ public final class YuiLib implements ICl
{
if (YUILOADER == null)
{
-StringBuilder sb = new StringBuilder();
+ StringBuilder sb = new StringBuilder();
sb.append(yuiloader);
if (Application.get().usesDeploymentConfig())
{
[jira] Resolved: (WICKET-3213) YuiLib private constructor but implements IClusterable and has serialVersionUID
[ https://issues.apache.org/jira/browse/WICKET-3213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Grigorov resolved WICKET-3213. - Resolution: Fixed Fix Version/s: 1.5-M4 Fixed with r1041345 YuiLib private constructor but implements IClusterable and has serialVersionUID --- Key: WICKET-3213 URL: https://issues.apache.org/jira/browse/WICKET-3213 Project: Wicket Issue Type: Bug Components: wicket-datetime Affects Versions: 1.5-M3 Environment: all Reporter: Richard Emberson Priority: Trivial Fix For: 1.5-M4 YuiLib has no non-static methods and private constructor but implements IClusterable and has a serialVersionUID. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WICKET-3213) YuiLib private constructor but implements IClusterable and has serialVersionUID
[ https://issues.apache.org/jira/browse/WICKET-3213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Grigorov reassigned WICKET-3213: --- Assignee: Martin Grigorov YuiLib private constructor but implements IClusterable and has serialVersionUID --- Key: WICKET-3213 URL: https://issues.apache.org/jira/browse/WICKET-3213 Project: Wicket Issue Type: Bug Components: wicket-datetime Affects Versions: 1.5-M3 Environment: all Reporter: Richard Emberson Assignee: Martin Grigorov Priority: Trivial Fix For: 1.5-M4 YuiLib has no non-static methods and private constructor but implements IClusterable and has a serialVersionUID. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1041456 - /wicket/trunk/wicket/src/test/java/org/apache/wicket/util/tester/WicketTesterSessionInvalidateTest.java
Author: mgrigorov
Date: Thu Dec 2 17:03:50 2010
New Revision: 1041456
URL: http://svn.apache.org/viewvc?rev=1041456view=rev
Log:
WICKET-3212 WicketTester can't create new sessions
Add unit test for session invalidation with WicketTester
Added:
wicket/trunk/wicket/src/test/java/org/apache/wicket/util/tester/WicketTesterSessionInvalidateTest.java
(with props)
Added:
wicket/trunk/wicket/src/test/java/org/apache/wicket/util/tester/WicketTesterSessionInvalidateTest.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/test/java/org/apache/wicket/util/tester/WicketTesterSessionInvalidateTest.java?rev=1041456view=auto
==
---
wicket/trunk/wicket/src/test/java/org/apache/wicket/util/tester/WicketTesterSessionInvalidateTest.java
(added)
+++
wicket/trunk/wicket/src/test/java/org/apache/wicket/util/tester/WicketTesterSessionInvalidateTest.java
Thu Dec 2 17:03:50 2010
@@ -0,0 +1,82 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the License); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.wicket.util.tester;
+
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.assertNull;
+
+import org.apache.wicket.MarkupContainer;
+import org.apache.wicket.markup.IMarkupResourceStreamProvider;
+import org.apache.wicket.markup.html.WebPage;
+import org.apache.wicket.markup.html.link.Link;
+import org.apache.wicket.request.mapper.parameter.PageParameters;
+import org.apache.wicket.util.resource.IResourceStream;
+import org.apache.wicket.util.resource.StringResourceStream;
+import org.junit.Test;
+
+public class WicketTesterSessionInvalidateTest
+{
+
+ /**
+* https://issues.apache.org/jira/browse/WICKET-3212
+*/
+ @Test
+ public void sessionInvalidate()
+ {
+ WicketTester tester = new WicketTester();
+
+ tester.startPage(MyPage.class);
+
+ assertNull(tester.getSession().getStyle());
+
+ tester.getSession().setStyle(style1);
+
+ assertEquals(style1, tester.getSession().getStyle());
+
+ // invalidate the session
+ tester.clickLink(link);
+
+ assertNull(tester.getSession().getStyle());
+ }
+
+ public static class MyPage extends WebPage implements
IMarkupResourceStreamProvider
+ {
+
+ public MyPage(PageParameters pageParameters)
+ {
+ super(pageParameters);
+
+ add(new LinkVoid(link)
+ {
+
+ @Override
+ public void onClick()
+ {
+ getSession().invalidate();
+ }
+
+ });
+ }
+
+ public IResourceStream getMarkupResourceStream(MarkupContainer
container,
+ Class? containerClass)
+ {
+ return new StringResourceStream(
+ htmlbodya
wicket:id='link'link/a/body/html);
+ }
+ }
+}
Propchange:
wicket/trunk/wicket/src/test/java/org/apache/wicket/util/tester/WicketTesterSessionInvalidateTest.java
--
svn:eol-style = native
[jira] Created: (WICKET-3217) DatesPage test LocaleDropDownChoice getObject calls getSelectedLocale(), does not use result
DatesPage test LocaleDropDownChoice getObject calls getSelectedLocale(), does
not use result
Key: WICKET-3217
URL: https://issues.apache.org/jira/browse/WICKET-3217
Project: Wicket
Issue Type: Bug
Components: wicket-datetime
Affects Versions: 1.5-M3
Environment: all
Reporter: Richard Emberson
Priority: Trivial
In the DatesPage test, the LocaleDropDownChoice.getObject() method calls
getSelectedLocale() but does not use the result:
public ListLocale getObject()
{
getSelectedLocale();
ListLocale locales = new ArrayListLocale(LOCALES);
Collections.sort(locales, new ComparatorLocale()
{
public int compare(Locale o1, Locale o2)
{
return o1.getDisplayName(selectedLocale).compareTo(
o2.getDisplayName(selectedLocale));
}
});
return locales;
}
I would guess that the call getSelectedLocale() could be removed
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3218) Component#onInitialize is broken for Pages
[ https://issues.apache.org/jira/browse/WICKET-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl-Eric Menzel updated WICKET-3218: - Attachment: 0001-added-page-onpageinitialize.patch A patch against Wicket 1.4.14 that does what I outlined in the bug description. Includes appropriate test cases. Component#onInitialize is broken for Pages -- Key: WICKET-3218 URL: https://issues.apache.org/jira/browse/WICKET-3218 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4.14 Reporter: Carl-Eric Menzel Attachments: 0001-added-page-onpageinitialize.patch As first mentioned at http://mail-archives.apache.org/mod_mbox/wicket-dev/201012.mbox/%3c1291238699.1749.1408166...@webmail.messagingengine.com%3e , I think the current (Wicket 1.4.14) implementation of Component#onInitialize is broken for Pages. Pages get initialized as soon as the first component is added, which is correct. But this usually happens within the constructor of the page, which means that the page object isn't fully initialized yet. The entire point of having onInitialize, however, is to be able to do further work once all constructors have run. See https://github.com/duesenklipper/wicket-oninitialize for a quickstart that demonstrates the problem. Pedro Santos suggested in the above thread to just switch the entire object construction to onInitialize. I don't think this is a good idea, because 1) it is completely counter-intuitive 2) it is not always realistic to have an entire class hierarchy not using the constructor just because a subclass somewhere might want to use onInitialize 3) it is inconsistent with onInitialize behavior for all other (non-Page) components. Here I can easily mix work in the constructor with onInitialize. I propose the following patch: - override onInitialize in Page and make it final, so Pages can't use this any more. This should not cause any unnecessary breaking, since currently it's not working for pages anyway. - introduce Page#onPageInitialize to provide a safe alternative to onInitialize - make a special case for Page in Component's beforeRender to fire Page#onPageInitialize if necessary Yes, this is a bit of special casing for Page, but there's quite a lot of that needed for Page anyway. I think the impact of this should be minimal. My page includes documentation and a new testcase that verifies the new behavior. I modified the old ComponentInitializationTest to reflect the fact that Page doesn't get onInitialize any more. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1041520 - in /wicket/trunk: wicket-util/src/test/java/org/apache/wicket/util/lang/ wicket-util/src/test/java/org/apache/wicket/util/lang/BytesTest.java wicket/src/test/java/org/apache/wic
Author: mgrigorov Date: Thu Dec 2 18:45:14 2010 New Revision: 1041520 URL: http://svn.apache.org/viewvc?rev=1041520view=rev Log: Move BytesTest in wicket-util project where Bytes class is noticed-by: Peter Major Added: wicket/trunk/wicket-util/src/test/java/org/apache/wicket/util/lang/ wicket/trunk/wicket-util/src/test/java/org/apache/wicket/util/lang/BytesTest.java (contents, props changed) - copied, changed from r1041479, wicket/trunk/wicket/src/test/java/org/apache/wicket/util/lang/BytesTest.java Removed: wicket/trunk/wicket/src/test/java/org/apache/wicket/util/lang/BytesTest.java Copied: wicket/trunk/wicket-util/src/test/java/org/apache/wicket/util/lang/BytesTest.java (from r1041479, wicket/trunk/wicket/src/test/java/org/apache/wicket/util/lang/BytesTest.java) URL: http://svn.apache.org/viewvc/wicket/trunk/wicket-util/src/test/java/org/apache/wicket/util/lang/BytesTest.java?p2=wicket/trunk/wicket-util/src/test/java/org/apache/wicket/util/lang/BytesTest.javap1=wicket/trunk/wicket/src/test/java/org/apache/wicket/util/lang/BytesTest.javar1=1041479r2=1041520rev=1041520view=diff == (empty) Propchange: wicket/trunk/wicket-util/src/test/java/org/apache/wicket/util/lang/BytesTest.java -- svn:eol-style = native Propchange: wicket/trunk/wicket-util/src/test/java/org/apache/wicket/util/lang/BytesTest.java -- svn:keywords = Author Date Id Revision
[jira] Assigned: (WICKET-3215) AutoCompleteTextField does not work in an iframe under IE 6, 7 or 8
[ https://issues.apache.org/jira/browse/WICKET-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pedro Santos reassigned WICKET-3215: Assignee: Pedro Santos AutoCompleteTextField does not work in an iframe under IE 6, 7 or 8 --- Key: WICKET-3215 URL: https://issues.apache.org/jira/browse/WICKET-3215 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.4.11, 1.4.12, 1.4.13, 1.4.14 Environment: Windows Server 2003 Reporter: Robert Csok Assignee: Pedro Santos Attachments: HomePage.html, HomePage.java, iframe.html The code that has been integrated in version 1.4.11 to fix issue WICKET-2279 forces the cursor of an AutoCompleteTextField to do a carriage return after each typed in char when the application runs in an iframe and IE 6, 7 or 8 is used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3215) AutoCompleteTextField does not work in an iframe under IE 6, 7 or 8
[ https://issues.apache.org/jira/browse/WICKET-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966252#action_12966252 ] Pedro Santos commented on WICKET-3215: -- I will try to fix this restoring the cursor position on text field there are some info about at: http://www.quirksmode.org/dom/range_intro.html AutoCompleteTextField does not work in an iframe under IE 6, 7 or 8 --- Key: WICKET-3215 URL: https://issues.apache.org/jira/browse/WICKET-3215 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.4.11, 1.4.12, 1.4.13, 1.4.14 Environment: Windows Server 2003 Reporter: Robert Csok Assignee: Pedro Santos Attachments: HomePage.html, HomePage.java, iframe.html The code that has been integrated in version 1.4.11 to fix issue WICKET-2279 forces the cursor of an AutoCompleteTextField to do a carriage return after each typed in char when the application runs in an iframe and IE 6, 7 or 8 is used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1041559 - in /wicket/trunk/wicket/src: main/java/org/apache/wicket/util/resource/UrlResourceStream.java test/java/org/apache/wicket/util/resource/UrlResourceStreamTest.java
Author: mgrigorov
Date: Thu Dec 2 20:04:35 2010
New Revision: 1041559
URL: http://svn.apache.org/viewvc?rev=1041559view=rev
Log:
WICKET-3176 URLResourceStream loads target content twice.
Make URLResourceStream lazy - it will make the connection to the resource on
first read and will cache the results.
A new connection is being made only for refreshing the last modification time.
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/util/resource/UrlResourceStream.java
wicket/trunk/wicket/src/test/java/org/apache/wicket/util/resource/UrlResourceStreamTest.java
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/util/resource/UrlResourceStream.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/util/resource/UrlResourceStream.java?rev=1041559r1=1041558r2=1041559view=diff
==
---
wicket/trunk/wicket/src/main/java/org/apache/wicket/util/resource/UrlResourceStream.java
(original)
+++
wicket/trunk/wicket/src/main/java/org/apache/wicket/util/resource/UrlResourceStream.java
Thu Dec 2 20:04:35 2010
@@ -49,8 +49,10 @@ public class UrlResourceStream extends A
/** Logging. */
private static final Logger log =
LoggerFactory.getLogger(UrlResourceStream.class);
- /** Resource stream. */
- private transient InputStream inputStream;
+ /**
+* The meta data for this stream. Lazy loaded on demand.
+*/
+ private transient StreamData streamData;
/** The URL to this resource. */
private final URL url;
@@ -58,14 +60,23 @@ public class UrlResourceStream extends A
/** the handle to the file if it is a file resource */
private File file;
- /** Length of stream. */
- private Bytes contentLength;
+ /**
+* Meta data class for the stream attributes
+*/
+ private static class StreamData
+ {
+ private URLConnection connection;
+
+ /** Length of stream. */
+ private long contentLength;
- /** Content type for stream. */
- private String contentType;
+ /** Content type for stream. */
+ private String contentType;
- /** Last known time the stream was last modified. */
- private long lastModified;
+ /** Last known time the stream was last modified. */
+ private long lastModified;
+
+ }
/**
* Construct.
@@ -78,23 +89,6 @@ public class UrlResourceStream extends A
// save the url
this.url = url;
- // retrieve the content type and length
- URLConnection connection = null;
- try
- {
- connection = url.openConnection();
- contentLength =
Bytes.bytes(connection.getContentLength());
- contentType = connection.getContentType();
- }
- catch (IOException ex)
- {
- throw new IllegalArgumentException(Invalid URL
parameter + url, ex);
- }
- finally
- {
- Connections.closeQuietly(connection);
- }
-
try
{
file = new File(new URI(url.toExternalForm()));
@@ -113,16 +107,69 @@ public class UrlResourceStream extends A
}
/**
+* Lazy loads the stream settings on demand
+*
+* @param initialize
+*a flag indicating whether to load the settings
+* @return the meta data with the stream settings
+*/
+ private StreamData getData(boolean initialize)
+ {
+ if (streamData == null initialize)
+ {
+ streamData = new StreamData();
+
+ try
+ {
+ streamData.connection = url.openConnection();
+ streamData.contentLength =
streamData.connection.getContentLength();
+ streamData.contentType =
streamData.connection.getContentType();
+
+ if (streamData.contentType == null ||
+
streamData.contentType.indexOf(unknown) != -1)
+ {
+ if (Application.exists()
Application.get() instanceof WebApplication)
+ {
+ // TODO Post 1.2: General: For
non webapplication another method
+ // should be implemented
(getMimeType on application?)
+ streamData.contentType =
WebApplication.get()
+
[jira] Resolved: (WICKET-3176) URLResourceStream loads target content twice.
[ https://issues.apache.org/jira/browse/WICKET-3176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Grigorov resolved WICKET-3176. - Resolution: Fixed Fix Version/s: 1.5-M4 Fixed in 1.5 with r1041559. Will not be merged back to 1.4 because this resource stream is quite critical for Wicket internals and we don't want to compromise the stable branch. URLResourceStream loads target content twice. - Key: WICKET-3176 URL: https://issues.apache.org/jira/browse/WICKET-3176 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4.12 Environment: Jetty 7.2, Wicket 1.4.12, Eclipse 3.6 Reporter: Yuen Kaayan Assignee: Martin Grigorov Fix For: 1.5-M4 Attachments: WICKET-3176.patch Original Estimate: 1h Remaining Estimate: 1h In PageA.class, there is an 'Include' component that tries to load http://localhost:8080/page-b. In PageB.class, which is mounted as 'page-b', will print some dummy letters when class is initialized. When web server is requested to load PageA, server console will print the dummy letters twice. That is, one request will print 2 lines of dummy letters. I traced into Include.class, it uses URLResourceStream.class to load the URL. After reading the source, I found this URLResourceStream.class requested the URL twice: 1st in the constructor, 2nd in getInputStream(). Can this be amended to request once to save some bandwith/server time? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-3219) programmatical addition or removal of filters prior to wicket filter request handling
programmatical addition or removal of filters prior to wicket filter request
handling
-
Key: WICKET-3219
URL: https://issues.apache.org/jira/browse/WICKET-3219
Project: Wicket
Issue Type: New Feature
Reporter: Peter Ertl
Assignee: Peter Ertl
Fix For: 1.5-M4
Attachments: filter-extension.patch
[full-working patch included]
I would like to extend WicketFilter so you can add (or remove) standard servlet
filters programatically to it. These will filter the request prior to wicket
using Filter#doChain(). At the end of the filter chain wicket itself will
process the request.
Usually the wicket request handling looks like this:
incoming browser request -
begin WicketFilter#doFilter -
wicket request processing -
end WicketFilter#doFilter -
send response to browser
Now when adding standard java.servlet.Filter instances to the WicketFilter
using something like
--- sample code ---
public class MyApplication extends WebApplication
{
@Override
protected void init()
{
super.init();
XForwardFilter filter = new XForwardFilter(); // transparent
proxy handling behind front-end proxies
try
{
getWicketFilter().addInterceptor(filter);
// getWicketFilter().addInterceptor(filter,
config); // alternate config (e.g. mock filter config since FilterConfig is
just an interface)
}
catch (ServletException e)
{
// standard exception which can be thrown from
javax.servlet.Filter#init(FilterConfig)
log.error(e.getMessage(), e);
}
}
--- EOF sample code ---
the processing will change like that:
incoming browser request -
begin WicketFilter#doFilter -
begin XForwardFilter#doFilter() -
XForwardFilter processing -
chain.doFilter(request,response) -
invoke wicket request processing -
end XForwardFilter#doFilter() -
end WicketFilter#doFilter -
send response to browser
- The filter (= interceptor) will be invoked for the same filter path
WicketFilter is configured
Being able to add filters like this will have the following advantages:
- The filter can be added or removed anytime during the wicket application
lifecycle
- You don't have to touch web.xml ever
- You can specify mock filter configs or alternate filter configs using
(WicketFilter#addInterceptor(filter, alternateFilterConfig))
- Tigher integration of the filter with wicket since the application and
session is already attached to the current thread context (similar to
WicketSessionFilter, but without web.xml fiddling)
- Plugins can add filters without requiring any manual intervention by the
developer, this will make them more powerful
- Filters can be removed thread-safe at runtime
- Low-level request processing is really simple and requests or responses can
be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
- the filter class can not be invalid (filter-class in web.xml) since it's
checked by the compiler
- Eventually migration from pre-wicket application might be easier
Please check the patch to get the whole idea.
Votes and comments are greatly appreciated :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3219) programmatical addition or removal of filters prior to wicket filter request handling
[
https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl updated WICKET-3219:
---
Attachment: filter-extension.patch
programmatical addition or removal of filters prior to wicket filter request
handling
-
Key: WICKET-3219
URL: https://issues.apache.org/jira/browse/WICKET-3219
Project: Wicket
Issue Type: New Feature
Reporter: Peter Ertl
Assignee: Peter Ertl
Fix For: 1.5-M4
Attachments: filter-extension.patch
[full-working patch included]
I would like to extend WicketFilter so you can add (or remove) standard
servlet filters programatically to it. These will filter the request prior
to wicket using Filter#doChain(). At the end of the filter chain wicket
itself will process the request.
Usually the wicket request handling looks like this:
incoming browser request -
begin WicketFilter#doFilter -
wicket request processing -
end WicketFilter#doFilter -
send response to browser
Now when adding standard java.servlet.Filter instances to the WicketFilter
using something like
--- sample code ---
public class MyApplication extends WebApplication
{
@Override
protected void init()
{
super.init();
XForwardFilter filter = new XForwardFilter(); // transparent
proxy handling behind front-end proxies
try
{
getWicketFilter().addInterceptor(filter);
// getWicketFilter().addInterceptor(filter,
config); // alternate config (e.g. mock filter config since FilterConfig is
just an interface)
}
catch (ServletException e)
{
// standard exception which can be thrown from
javax.servlet.Filter#init(FilterConfig)
log.error(e.getMessage(), e);
}
}
--- EOF sample code ---
the processing will change like that:
incoming browser request -
begin WicketFilter#doFilter -
begin XForwardFilter#doFilter() -
XForwardFilter processing -
chain.doFilter(request,response) -
invoke wicket request processing -
end XForwardFilter#doFilter() -
end WicketFilter#doFilter -
send response to browser
- The filter (= interceptor) will be invoked for the same filter path
WicketFilter is configured
Being able to add filters like this will have the following advantages:
- The filter can be added or removed anytime during the wicket application
lifecycle
- You don't have to touch web.xml ever
- You can specify mock filter configs or alternate filter configs using
(WicketFilter#addInterceptor(filter, alternateFilterConfig))
- Tigher integration of the filter with wicket since the application and
session is already attached to the current thread context (similar to
WicketSessionFilter, but without web.xml fiddling)
- Plugins can add filters without requiring any manual intervention by the
developer, this will make them more powerful
- Filters can be removed thread-safe at runtime
- Low-level request processing is really simple and requests or responses can
be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
- the filter class can not be invalid (filter-class in web.xml) since it's
checked by the compiler
- Eventually migration from pre-wicket application might be easier
Please check the patch to get the whole idea.
Votes and comments are greatly appreciated :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3219) programmatical addition or removal of filters prior to wicket filter request handling
[
https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl updated WICKET-3219:
---
Affects Version/s: 1.5-M3
Fix Version/s: (was: 1.5-M4)
programmatical addition or removal of filters prior to wicket filter request
handling
-
Key: WICKET-3219
URL: https://issues.apache.org/jira/browse/WICKET-3219
Project: Wicket
Issue Type: New Feature
Affects Versions: 1.5-M3
Reporter: Peter Ertl
Assignee: Peter Ertl
Attachments: filter-extension.patch
[full-working patch included]
I would like to extend WicketFilter so you can add (or remove) standard
servlet filters programatically to it. These will filter the request prior
to wicket using Filter#doChain(). At the end of the filter chain wicket
itself will process the request.
Usually the wicket request handling looks like this:
incoming browser request -
begin WicketFilter#doFilter -
wicket request processing -
end WicketFilter#doFilter -
send response to browser
Now when adding standard java.servlet.Filter instances to the WicketFilter
using something like
--- sample code ---
public class MyApplication extends WebApplication
{
@Override
protected void init()
{
super.init();
XForwardFilter filter = new XForwardFilter(); // transparent
proxy handling behind front-end proxies
try
{
getWicketFilter().addInterceptor(filter);
// getWicketFilter().addInterceptor(filter,
config); // alternate config (e.g. mock filter config since FilterConfig is
just an interface)
}
catch (ServletException e)
{
// standard exception which can be thrown from
javax.servlet.Filter#init(FilterConfig)
log.error(e.getMessage(), e);
}
}
--- EOF sample code ---
the processing will change like that:
incoming browser request -
begin WicketFilter#doFilter -
begin XForwardFilter#doFilter() -
XForwardFilter processing -
chain.doFilter(request,response) -
invoke wicket request processing -
end XForwardFilter#doFilter() -
end WicketFilter#doFilter -
send response to browser
- The filter (= interceptor) will be invoked for the same filter path
WicketFilter is configured
Being able to add filters like this will have the following advantages:
- The filter can be added or removed anytime during the wicket application
lifecycle
- You don't have to touch web.xml ever
- You can specify mock filter configs or alternate filter configs using
(WicketFilter#addInterceptor(filter, alternateFilterConfig))
- Tigher integration of the filter with wicket since the application and
session is already attached to the current thread context (similar to
WicketSessionFilter, but without web.xml fiddling)
- Plugins can add filters without requiring any manual intervention by the
developer, this will make them more powerful
- Filters can be removed thread-safe at runtime
- Low-level request processing is really simple and requests or responses can
be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
- the filter class can not be invalid (filter-class in web.xml) since it's
checked by the compiler
- Eventually migration from pre-wicket application might be easier
Please check the patch to get the whole idea.
Votes and comments are greatly appreciated :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3219) programmatical addition or removal of filters prior to wicket filter request handling
[
https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl updated WICKET-3219:
---
Description:
[full-working patch included]
I would like to extend WicketFilter so you can add (or remove) standard servlet
filters programatically to it. These will filter the request prior to wicket
using Filter#doChain(). At the end of the filter chain wicket itself will
process the request.
Usually the wicket request handling looks like this:
incoming browser request -
begin WicketFilter#doFilter -
wicket request processing -
end WicketFilter#doFilter -
send response to browser
Now when adding standard java.servlet.Filter instances to the WicketFilter
using something like
--- sample code ---
public class MyApplication extends WebApplication
{
@Override
protected void init()
{
super.init();
XForwardFilter filter = new XForwardFilter(); // transparent proxy handling
behind front-end proxies
try
{
getWicketFilter().addInterceptor(filter);
// getWicketFilter().addInterceptor(filter, config); // alternate config
(e.g. mock filter config since FilterConfig is just an interface)
}
catch (ServletException e)
{
// standard exception thrown from javax.servlet.Filter#init(FilterConfig)
log.error(e.getMessage(), e);
}
}
// ...
}
--- EOF sample code ---
the processing will change like that:
incoming browser request -
begin WicketFilter#doFilter -
begin XForwardFilter#doFilter() -
XForwardFilter processing -
chain.doFilter(request,response) -
invoke wicket request processing -
end XForwardFilter#doFilter() -
end WicketFilter#doFilter -
send response to browser
- The filter (= interceptor) will be invoked for the same filter path
WicketFilter is configured
Being able to add filters like this will have the following advantages:
- The filter can be added or removed anytime during the wicket application
lifecycle
- You don't have to touch web.xml ever
- You can specify mock filter configs or alternate filter configs using
(WicketFilter#addInterceptor(filter, alternateFilterConfig))
- Tigher integration of the filter with wicket since the application and
session is already attached to the current thread context (similar to
WicketSessionFilter, but without web.xml fiddling)
- Plugins can add filters without requiring any manual intervention by the
developer, this will make them more powerful
- Filters can be removed thread-safe at runtime
- Low-level request processing is really simple and requests or responses can
be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
- the filter class can not be invalid (filter-class in web.xml) since it's
checked by the compiler
- Eventually migration from pre-wicket application might be easier
Please check the patch to get the whole idea.
Votes and comments are greatly appreciated :-)
was:
[full-working patch included]
I would like to extend WicketFilter so you can add (or remove) standard servlet
filters programatically to it. These will filter the request prior to wicket
using Filter#doChain(). At the end of the filter chain wicket itself will
process the request.
Usually the wicket request handling looks like this:
incoming browser request -
begin WicketFilter#doFilter -
wicket request processing -
end WicketFilter#doFilter -
send response to browser
Now when adding standard java.servlet.Filter instances to the WicketFilter
using something like
--- sample code ---
public class MyApplication extends WebApplication
{
@Override
protected void init()
{
super.init();
XForwardFilter filter = new XForwardFilter(); // transparent
proxy handling behind front-end proxies
try
{
getWicketFilter().addInterceptor(filter);
// getWicketFilter().addInterceptor(filter,
config); // alternate config (e.g. mock filter config since FilterConfig is
just an interface)
}
catch (ServletException e)
{
// standard exception which can be thrown from
javax.servlet.Filter#init(FilterConfig)
log.error(e.getMessage(), e);
}
}
--- EOF sample code ---
the processing will change like that:
incoming browser request -
begin WicketFilter#doFilter -
begin XForwardFilter#doFilter() -
XForwardFilter processing -
chain.doFilter(request,response) -
invoke wicket request processing -
end XForwardFilter#doFilter() -
end WicketFilter#doFilter -
send response to browser
- The filter (= interceptor) will be invoked for the same filter path
WicketFilter is configured
Being able to add filters like this
[jira] Updated: (WICKET-3219) programmatical addition or removal of filters prior to wicket filter request handling
[
https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl updated WICKET-3219:
---
Description:
[full-working patch included]
I would like to extend WicketFilter so you can add (or remove) standard servlet
filters programatically to it. These will filter the request prior to wicket
using Filter#doChain(). At the end of the filter chain wicket itself will
process the request.
Usually the wicket request handling looks like this:
incoming browser request -
begin WicketFilter#doFilter -
wicket request processing -
end WicketFilter#doFilter -
send response to browser
Now when adding standard java.servlet.Filter instances to the WicketFilter
using something like
--- sample code ---
public class MyApplication extends WebApplication
{
@Override
protected void init()
{
super.init();
XForwardFilter filter = new XForwardFilter(); // transparent proxy handling
behind front-end proxies, implements javax.servlet.Filter
try
{
getWicketFilter().addInterceptor(filter);
// getWicketFilter().addInterceptor(filter, config); // alternate config
(e.g. mock filter config since FilterConfig is just an interface)
}
catch (ServletException e)
{
// standard exception thrown from javax.servlet.Filter#init(FilterConfig)
log.error(e.getMessage(), e);
}
}
// ...
}
--- EOF sample code ---
the processing will change like that:
incoming browser request -
begin WicketFilter#doFilter -
begin XForwardFilter#doFilter() -
XForwardFilter processing -
chain.doFilter(request,response) -
invoke wicket request processing -
end XForwardFilter#doFilter() -
end WicketFilter#doFilter -
send response to browser
- The filter (= interceptor) will be invoked for the same filter path
WicketFilter is configured
Being able to add filters like this will have the following advantages:
- The filter can be added or removed anytime during the wicket application
lifecycle
- You don't have to touch web.xml ever
- You can specify mock filter configs or alternate filter configs using
(WicketFilter#addInterceptor(filter, alternateFilterConfig))
- Tigher integration of the filter with wicket since the application and
session is already attached to the current thread context (similar to
WicketSessionFilter, but without web.xml fiddling)
- Plugins can add filters without requiring any manual intervention by the
developer, this will make them more powerful
- Filters can be removed thread-safe at runtime
- Low-level request processing is really simple and requests or responses can
be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
- the filter class can not be invalid (filter-class in web.xml) since it's
checked by the compiler
- Eventually migration from pre-wicket application might be easier
Please check the patch to get the whole idea.
Votes and comments are greatly appreciated :-)
was:
[full-working patch included]
I would like to extend WicketFilter so you can add (or remove) standard servlet
filters programatically to it. These will filter the request prior to wicket
using Filter#doChain(). At the end of the filter chain wicket itself will
process the request.
Usually the wicket request handling looks like this:
incoming browser request -
begin WicketFilter#doFilter -
wicket request processing -
end WicketFilter#doFilter -
send response to browser
Now when adding standard java.servlet.Filter instances to the WicketFilter
using something like
--- sample code ---
public class MyApplication extends WebApplication
{
@Override
protected void init()
{
super.init();
XForwardFilter filter = new XForwardFilter(); // transparent proxy handling
behind front-end proxies
try
{
getWicketFilter().addInterceptor(filter);
// getWicketFilter().addInterceptor(filter, config); // alternate config
(e.g. mock filter config since FilterConfig is just an interface)
}
catch (ServletException e)
{
// standard exception thrown from javax.servlet.Filter#init(FilterConfig)
log.error(e.getMessage(), e);
}
}
// ...
}
--- EOF sample code ---
the processing will change like that:
incoming browser request -
begin WicketFilter#doFilter -
begin XForwardFilter#doFilter() -
XForwardFilter processing -
chain.doFilter(request,response) -
invoke wicket request processing -
end XForwardFilter#doFilter() -
end WicketFilter#doFilter -
send response to browser
- The filter (= interceptor) will be invoked for the same filter path
WicketFilter is configured
Being able to add filters like this will have the following advantages:
- The filter can be added or removed anytime during the wicket application
lifecycle
- You don't have to touch web.xml
[jira] Updated: (WICKET-3219) programmatical addition or removal of filters prior to wicket filter request handling
[
https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl updated WICKET-3219:
---
Attachment: (was: filter-extension.patch)
programmatical addition or removal of filters prior to wicket filter request
handling
-
Key: WICKET-3219
URL: https://issues.apache.org/jira/browse/WICKET-3219
Project: Wicket
Issue Type: New Feature
Affects Versions: 1.5-M3
Reporter: Peter Ertl
Assignee: Peter Ertl
[full-working patch included]
I would like to extend WicketFilter so you can add (or remove) standard
servlet filters programatically to it. These will filter the request prior
to wicket using Filter#doChain(). At the end of the filter chain wicket
itself will process the request.
Usually the wicket request handling looks like this:
incoming browser request -
begin WicketFilter#doFilter -
wicket request processing -
end WicketFilter#doFilter -
send response to browser
Now when adding standard java.servlet.Filter instances to the WicketFilter
using something like
--- sample code ---
public class MyApplication extends WebApplication
{
@Override
protected void init()
{
super.init();
XForwardFilter filter = new XForwardFilter(); // transparent proxy
handling behind front-end proxies, implements javax.servlet.Filter
try
{
getWicketFilter().addInterceptor(filter);
// getWicketFilter().addInterceptor(filter, config); // alternate
config (e.g. mock filter config since FilterConfig is just an interface)
}
catch (ServletException e)
{
// standard exception thrown from
javax.servlet.Filter#init(FilterConfig)
log.error(e.getMessage(), e);
}
}
// ...
}
--- EOF sample code ---
the processing will change like that:
incoming browser request -
begin WicketFilter#doFilter -
begin XForwardFilter#doFilter() -
XForwardFilter processing -
chain.doFilter(request,response) -
invoke wicket request processing -
end XForwardFilter#doFilter() -
end WicketFilter#doFilter -
send response to browser
- The filter (= interceptor) will be invoked for the same filter path
WicketFilter is configured
Being able to add filters like this will have the following advantages:
- The filter can be added or removed anytime during the wicket application
lifecycle
- You don't have to touch web.xml ever
- You can specify mock filter configs or alternate filter configs using
(WicketFilter#addInterceptor(filter, alternateFilterConfig))
- Tigher integration of the filter with wicket since the application and
session is already attached to the current thread context (similar to
WicketSessionFilter, but without web.xml fiddling)
- Plugins can add filters without requiring any manual intervention by the
developer, this will make them more powerful
- Filters can be removed thread-safe at runtime
- Low-level request processing is really simple and requests or responses can
be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
- the filter class can not be invalid (filter-class in web.xml) since it's
checked by the compiler
- Eventually migration from pre-wicket application might be easier
Please check the patch to get the whole idea.
Votes and comments are greatly appreciated :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3219) programmatical addition or removal of filters prior to wicket filter request handling
[
https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl updated WICKET-3219:
---
Attachment: interceptors.patch
programmatical addition or removal of filters prior to wicket filter request
handling
-
Key: WICKET-3219
URL: https://issues.apache.org/jira/browse/WICKET-3219
Project: Wicket
Issue Type: New Feature
Affects Versions: 1.5-M3
Reporter: Peter Ertl
Assignee: Peter Ertl
Attachments: interceptors.patch
[full-working patch included]
I would like to extend WicketFilter so you can add (or remove) standard
servlet filters programatically to it. These will filter the request prior
to wicket using Filter#doChain(). At the end of the filter chain wicket
itself will process the request.
Usually the wicket request handling looks like this:
incoming browser request -
begin WicketFilter#doFilter -
wicket request processing -
end WicketFilter#doFilter -
send response to browser
Now when adding standard java.servlet.Filter instances to the WicketFilter
using something like
--- sample code ---
public class MyApplication extends WebApplication
{
@Override
protected void init()
{
super.init();
XForwardFilter filter = new XForwardFilter(); // transparent proxy
handling behind front-end proxies, implements javax.servlet.Filter
try
{
getWicketFilter().addInterceptor(filter);
// getWicketFilter().addInterceptor(filter, config); // alternate
config (e.g. mock filter config since FilterConfig is just an interface)
}
catch (ServletException e)
{
// standard exception thrown from
javax.servlet.Filter#init(FilterConfig)
log.error(e.getMessage(), e);
}
}
// ...
}
--- EOF sample code ---
the processing will change like that:
incoming browser request -
begin WicketFilter#doFilter -
begin XForwardFilter#doFilter() -
XForwardFilter processing -
chain.doFilter(request,response) -
invoke wicket request processing -
end XForwardFilter#doFilter() -
end WicketFilter#doFilter -
send response to browser
- The filter (= interceptor) will be invoked for the same filter path
WicketFilter is configured
Being able to add filters like this will have the following advantages:
- The filter can be added or removed anytime during the wicket application
lifecycle
- You don't have to touch web.xml ever
- You can specify mock filter configs or alternate filter configs using
(WicketFilter#addInterceptor(filter, alternateFilterConfig))
- Tigher integration of the filter with wicket since the application and
session is already attached to the current thread context (similar to
WicketSessionFilter, but without web.xml fiddling)
- Plugins can add filters without requiring any manual intervention by the
developer, this will make them more powerful
- Filters can be removed thread-safe at runtime
- Low-level request processing is really simple and requests or responses can
be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
- the filter class can not be invalid (filter-class in web.xml) since it's
checked by the compiler
- Eventually migration from pre-wicket application might be easier
Please check the patch to get the whole idea.
Votes and comments are greatly appreciated :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3219) programmatical add or remove of request filters to intercept requests prior to wicket
[
https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl updated WICKET-3219:
---
Summary: programmatical add or remove of request filters to intercept
requests prior to wicket (was: programmatical addition or removal of filters
prior to wicket filter request handling)
programmatical add or remove of request filters to intercept requests prior
to wicket
-
Key: WICKET-3219
URL: https://issues.apache.org/jira/browse/WICKET-3219
Project: Wicket
Issue Type: New Feature
Affects Versions: 1.5-M3
Reporter: Peter Ertl
Assignee: Peter Ertl
Attachments: interceptors.patch
[full-working patch included]
I would like to extend WicketFilter so you can add (or remove) standard
servlet filters programatically to it. These will filter the request prior
to wicket using Filter#doChain(). At the end of the filter chain wicket
itself will process the request.
Usually the wicket request handling looks like this:
incoming browser request -
begin WicketFilter#doFilter -
wicket request processing -
end WicketFilter#doFilter -
send response to browser
Now when adding standard java.servlet.Filter instances to the WicketFilter
using something like
--- sample code ---
public class MyApplication extends WebApplication
{
@Override
protected void init()
{
super.init();
XForwardFilter filter = new XForwardFilter(); // transparent proxy
handling behind front-end proxies, implements javax.servlet.Filter
try
{
getWicketFilter().addInterceptor(filter);
// getWicketFilter().addInterceptor(filter, config); // alternate
config (e.g. mock filter config since FilterConfig is just an interface)
}
catch (ServletException e)
{
// standard exception thrown from
javax.servlet.Filter#init(FilterConfig)
log.error(e.getMessage(), e);
}
}
// ...
}
--- EOF sample code ---
the processing will change like that:
incoming browser request -
begin WicketFilter#doFilter -
begin XForwardFilter#doFilter() -
XForwardFilter processing -
chain.doFilter(request,response) -
invoke wicket request processing -
end XForwardFilter#doFilter() -
end WicketFilter#doFilter -
send response to browser
- The filter (= interceptor) will be invoked for the same filter path
WicketFilter is configured
Being able to add filters like this will have the following advantages:
- The filter can be added or removed anytime during the wicket application
lifecycle
- You don't have to touch web.xml ever
- You can specify mock filter configs or alternate filter configs using
(WicketFilter#addInterceptor(filter, alternateFilterConfig))
- Tigher integration of the filter with wicket since the application and
session is already attached to the current thread context (similar to
WicketSessionFilter, but without web.xml fiddling)
- Plugins can add filters without requiring any manual intervention by the
developer, this will make them more powerful
- Filters can be removed thread-safe at runtime
- Low-level request processing is really simple and requests or responses can
be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
- the filter class can not be invalid (filter-class in web.xml) since it's
checked by the compiler
- Eventually migration from pre-wicket application might be easier
Please check the patch to get the whole idea.
Votes and comments are greatly appreciated :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3219) programmatical add or remove of request filters to intercept requests prior to wicket
[
https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl updated WICKET-3219:
---
Description:
[full-working patch included]
I would like to extend WicketFilter so you can add (or remove) standard servlet
filters programatically to it. These will filter the request prior to wicket
using Filter#doChain(). At the end of the filter chain wicket itself will
process the request.
Usually the wicket request handling looks like this:
incoming browser request -
begin WicketFilter#doFilter -
wicket request processing -
end WicketFilter#doFilter -
send response to browser
Now when adding standard java.servlet.Filter instances to the WicketFilter
using something like
--- sample code ---
public class MyApplication extends WebApplication
{
@Override
protected void init()
{
super.init();
XForwardFilter filter = new XForwardFilter(); // transparent proxy handling
behind front-end proxies, implements javax.servlet.Filter
try
{
getWicketFilter().addInterceptor(filter);
// getWicketFilter().addInterceptor(filter, config); // alternate config
(e.g. mock filter config since FilterConfig is just an interface)
}
catch (ServletException e)
{
// standard exception thrown from javax.servlet.Filter#init(FilterConfig)
log.error(e.getMessage(), e);
}
}
// ...
}
--- EOF sample code ---
the processing will change like that:
incoming browser request -
begin WicketFilter#doFilter -
begin XForwardFilter#doFilter() -
XForwardFilter processing -
chain.doFilter(request,response) -
invoke wicket request processing -
end XForwardFilter#doFilter() -
end WicketFilter#doFilter -
send response to browser
- The filter (= interceptor) will be invoked for the same filter path
WicketFilter is configured
Being able to add filters like this will have the following advantages:
- The filter can be added or removed anytime during the wicket application
lifecycle
- You don't have to touch web.xml ever
- You can use the large stock of existing servlet filters from other frameworks
without modification (e.g. from spring framework)
- You can specify mock filter configs or alternate filter configs using
(WicketFilter#addInterceptor(filter, alternateFilterConfig))
- Tigher integration of the filter with wicket since the application and
session is already attached to the current thread context (similar to
WicketSessionFilter, but without web.xml fiddling)
- Plugins can add filters without requiring any manual intervention by the
developer, this will make them more powerful
- Filters can be removed thread-safe at runtime
- Low-level request processing is really simple and requests or responses can
be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
- the filter class can not be invalid (filter-class in web.xml) since it's
checked by the compiler
- Eventually migration from pre-wicket application might be easier
Please check the patch to get the whole idea.
Votes and comments are greatly appreciated :-)
was:
[full-working patch included]
I would like to extend WicketFilter so you can add (or remove) standard servlet
filters programatically to it. These will filter the request prior to wicket
using Filter#doChain(). At the end of the filter chain wicket itself will
process the request.
Usually the wicket request handling looks like this:
incoming browser request -
begin WicketFilter#doFilter -
wicket request processing -
end WicketFilter#doFilter -
send response to browser
Now when adding standard java.servlet.Filter instances to the WicketFilter
using something like
--- sample code ---
public class MyApplication extends WebApplication
{
@Override
protected void init()
{
super.init();
XForwardFilter filter = new XForwardFilter(); // transparent proxy handling
behind front-end proxies, implements javax.servlet.Filter
try
{
getWicketFilter().addInterceptor(filter);
// getWicketFilter().addInterceptor(filter, config); // alternate config
(e.g. mock filter config since FilterConfig is just an interface)
}
catch (ServletException e)
{
// standard exception thrown from javax.servlet.Filter#init(FilterConfig)
log.error(e.getMessage(), e);
}
}
// ...
}
--- EOF sample code ---
the processing will change like that:
incoming browser request -
begin WicketFilter#doFilter -
begin XForwardFilter#doFilter() -
XForwardFilter processing -
chain.doFilter(request,response) -
invoke wicket request processing -
end XForwardFilter#doFilter() -
end WicketFilter#doFilter -
send response to browser
- The filter (= interceptor) will be invoked for the same filter path
WicketFilter is configured
Being able to add filters
[jira] Commented: (WICKET-3219) programmatical add or remove of request filters to intercept requests prior to wicket
[
https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966273#action_12966273
]
Juergen Donnerstag commented on WICKET-3219:
That was my first idea as well. I reverted it because in my opinion we don't
need it. WebApplication.newWebRequest(HttpServletRequest) is the place where
you can do all that already. To register a filter simply replace
newWebRequest with you own implementation. Wrap the servletrequest with your
filter, create a new WebRequest with that and your done. Have a look at the
testcase.
programmatical add or remove of request filters to intercept requests prior
to wicket
-
Key: WICKET-3219
URL: https://issues.apache.org/jira/browse/WICKET-3219
Project: Wicket
Issue Type: New Feature
Affects Versions: 1.5-M3
Reporter: Peter Ertl
Assignee: Peter Ertl
Attachments: interceptors.patch
[full-working patch included]
I would like to extend WicketFilter so you can add (or remove) standard
servlet filters programatically to it. These will filter the request prior
to wicket using Filter#doChain(). At the end of the filter chain wicket
itself will process the request.
Usually the wicket request handling looks like this:
incoming browser request -
begin WicketFilter#doFilter -
wicket request processing -
end WicketFilter#doFilter -
send response to browser
Now when adding standard java.servlet.Filter instances to the WicketFilter
using something like
--- sample code ---
public class MyApplication extends WebApplication
{
@Override
protected void init()
{
super.init();
XForwardFilter filter = new XForwardFilter(); // transparent proxy
handling behind front-end proxies, implements javax.servlet.Filter
try
{
getWicketFilter().addInterceptor(filter);
// getWicketFilter().addInterceptor(filter, config); // alternate
config (e.g. mock filter config since FilterConfig is just an interface)
}
catch (ServletException e)
{
// standard exception thrown from
javax.servlet.Filter#init(FilterConfig)
log.error(e.getMessage(), e);
}
}
// ...
}
--- EOF sample code ---
the processing will change like that:
incoming browser request -
begin WicketFilter#doFilter -
begin XForwardFilter#doFilter() -
XForwardFilter processing -
chain.doFilter(request,response) -
invoke wicket request processing -
end XForwardFilter#doFilter() -
end WicketFilter#doFilter -
send response to browser
- The filter (= interceptor) will be invoked for the same filter path
WicketFilter is configured
Being able to add filters like this will have the following advantages:
- The filter can be added or removed anytime during the wicket application
lifecycle
- You don't have to touch web.xml ever
- You can use the large stock of existing servlet filters from other
frameworks without modification (e.g. from spring framework)
- You can specify mock filter configs or alternate filter configs using
(WicketFilter#addInterceptor(filter, alternateFilterConfig))
- Tigher integration of the filter with wicket since the application and
session is already attached to the current thread context (similar to
WicketSessionFilter, but without web.xml fiddling)
- Plugins can add filters without requiring any manual intervention by the
developer, this will make them more powerful
- Filters can be removed thread-safe at runtime
- Low-level request processing is really simple and requests or responses can
be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
- the filter class can not be invalid (filter-class in web.xml) since it's
checked by the compiler
- Eventually migration from pre-wicket application might be easier
Please check the patch to get the whole idea.
Votes and comments are greatly appreciated :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
svn commit: r1041581 - in /wicket/trunk: wicket-util/src/main/java/org/apache/wicket/util/io/ wicket/src/main/java/org/apache/wicket/markup/ wicket/src/main/java/org/apache/wicket/markup/html/ wicket/
Author: jdonnerstag
Date: Thu Dec 2 20:58:51 2010
New Revision: 1041581
URL: http://svn.apache.org/viewvc?rev=1041581view=rev
Log:
- javadoc improvements
- replace some constants with enum
- added basic support for !DOCTYPE .. detection which is needed for HTML5
support
Added:
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/MarkupUtil.java
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/DoctypeExpectedResult_1.html
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/DoctypeExpectedResult_2.html
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/Doctype_1.html
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/Doctype_1.java
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/Doctype_2.html
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/Doctype_2.java
Modified:
wicket/trunk/wicket-util/src/main/java/org/apache/wicket/util/io/XmlReader.java
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/AbstractMarkupParser.java
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/MarkupFactory.java
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/MarkupResourceStream.java
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/TagUtils.java
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/loader/DefaultMarkupLoader.java
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/loader/IMarkupLoader.java
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/loader/InheritedMarkupMarkupLoader.java
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/loader/SimpleMarkupLoader.java
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/parser/IXmlPullParser.java
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/parser/XmlPullParser.java
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/parser/filter/RootMarkupFilter.java
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/WicketNamespaceTest.java
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/parser/XmlPullParserTest.java
Modified:
wicket/trunk/wicket-util/src/main/java/org/apache/wicket/util/io/XmlReader.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket-util/src/main/java/org/apache/wicket/util/io/XmlReader.java?rev=1041581r1=1041580r2=1041581view=diff
==
---
wicket/trunk/wicket-util/src/main/java/org/apache/wicket/util/io/XmlReader.java
(original)
+++
wicket/trunk/wicket-util/src/main/java/org/apache/wicket/util/io/XmlReader.java
Thu Dec 2 20:58:51 2010
@@ -24,8 +24,6 @@ import java.io.Reader;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
-import org.apache.wicket.util.string.AppendingStringBuffer;
-
/**
* This is a simple XmlReader. Its only purpose is to read the xml decl string
from the input and
@@ -46,7 +44,7 @@ public final class XmlReader extends Rea
private String encoding;
/** Null or if found in the markup, the whole ?xml ...? string */
- private String xmlDeclarationString;
+ private CharSequence xmlDeclarationString;
/** The input stream to read the data from */
private final InputStream inputStream;
@@ -87,7 +85,7 @@ public final class XmlReader extends Rea
*
* @return if null, then JVM default
*/
- public String getEncoding()
+ public final String getEncoding()
{
return encoding;
}
@@ -97,7 +95,7 @@ public final class XmlReader extends Rea
*
* @return Null, if not found.
*/
- public String getXmlDeclaration()
+ public final CharSequence getXmlDeclaration()
{
return xmlDeclarationString;
}
@@ -150,7 +148,7 @@ public final class XmlReader extends Rea
*The xmlDecl string
* @return The encoding. Null, if not found
*/
- private final String determineEncoding(final String string)
+ private final String determineEncoding(final CharSequence string)
{
// Does the string match the ?xml .. ? pattern
final Matcher matcher = encodingPattern.matcher(string);
@@ -192,7 +190,7 @@ public final class XmlReader extends Rea
throws IOException
{
// Max one line
- final AppendingStringBuffer pushBack = new
AppendingStringBuffer(readAheadSize);
+ final StringBuilder pushBack = new StringBuilder(readAheadSize);
// The current char from the markup file
int value;
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/AbstractMarkupParser.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/AbstractMarkupParser.java?rev=1041581r1=1041580r2=1041581view=diff
svn commit: r1041595 - /wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/dates/DatesPage.java
Author: pete
Date: Thu Dec 2 21:39:35 2010
New Revision: 1041595
URL: http://svn.apache.org/viewvc?rev=1041595view=rev
Log:
WICKET-3217: removed useless function call
Modified:
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/dates/DatesPage.java
Modified:
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/dates/DatesPage.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/dates/DatesPage.java?rev=1041595r1=1041594r2=1041595view=diff
==
---
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/dates/DatesPage.java
(original)
+++
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/dates/DatesPage.java
Thu Dec 2 21:39:35 2010
@@ -88,7 +88,6 @@ public class DatesPage extends WicketExa
@Override
public ListLocale getObject()
{
- getSelectedLocale();
ListLocale locales = new
ArrayListLocale(LOCALES);
Collections.sort(locales, new
ComparatorLocale()
{
[jira] Closed: (WICKET-3217) DatesPage test LocaleDropDownChoice getObject calls getSelectedLocale(), does not use result
[
https://issues.apache.org/jira/browse/WICKET-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl closed WICKET-3217.
--
Resolution: Fixed
Assignee: Peter Ertl
thanks! fixed in trunk...
DatesPage test LocaleDropDownChoice getObject calls getSelectedLocale(), does
not use result
Key: WICKET-3217
URL: https://issues.apache.org/jira/browse/WICKET-3217
Project: Wicket
Issue Type: Bug
Components: wicket-datetime
Affects Versions: 1.5-M3
Environment: all
Reporter: Richard Emberson
Assignee: Peter Ertl
Priority: Trivial
In the DatesPage test, the LocaleDropDownChoice.getObject() method calls
getSelectedLocale() but does not use the result:
public ListLocale getObject()
{
getSelectedLocale();
ListLocale locales = new ArrayListLocale(LOCALES);
Collections.sort(locales, new ComparatorLocale()
{
public int compare(Locale o1, Locale o2)
{
return o1.getDisplayName(selectedLocale).compareTo(
o2.getDisplayName(selectedLocale));
}
});
return locales;
}
I would guess that the call getSelectedLocale() could be removed
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-3220) WebApplication#getSessionAttributePrefix(final WebRequest request, String filterName) does not use request - so remove it ?!
WebApplication#getSessionAttributePrefix(final WebRequest request, String filterName) does not use request - so remove it ?! Key: WICKET-3220 URL: https://issues.apache.org/jira/browse/WICKET-3220 Project: Wicket Issue Type: Bug Affects Versions: 1.5-M3 Reporter: Peter Ertl since WebApplication: public String getSessionAttributePrefix(final WebRequest request, String filterName) does not use [request] can we remove it? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1041604 - in /wicket/trunk/wicket/src/main/java/org/apache/wicket/session: DefaultPageFactory.java HttpSessionStore.java ISessionStore.java
Author: pete
Date: Thu Dec 2 22:00:16 2010
New Revision: 1041604
URL: http://svn.apache.org/viewvc?rev=1041604view=rev
Log:
javadoc + redundant semicolon
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/session/DefaultPageFactory.java
wicket/trunk/wicket/src/main/java/org/apache/wicket/session/HttpSessionStore.java
wicket/trunk/wicket/src/main/java/org/apache/wicket/session/ISessionStore.java
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/session/DefaultPageFactory.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/session/DefaultPageFactory.java?rev=1041604r1=1041603r2=1041604view=diff
==
---
wicket/trunk/wicket/src/main/java/org/apache/wicket/session/DefaultPageFactory.java
(original)
+++
wicket/trunk/wicket/src/main/java/org/apache/wicket/session/DefaultPageFactory.java
Thu Dec 2 22:00:16 2010
@@ -34,8 +34,8 @@ import org.apache.wicket.util.lang.Gener
/**
* A factory that constructs Pages.
*
- * @see org.apache.wicket.settings.ISessionSettings#setPageFactory(PageFactory)
- * @see PageFactory
+ * @see
org.apache.wicket.settings.ISessionSettings#setPageFactory(org.apache.wicket.IPageFactory)
+ * @see IPageFactory
*
* @author Juergen Donnerstag
* @author Jonathan Locke
@@ -46,7 +46,7 @@ public final class DefaultPageFactory im
private final MapClass?, Constructor? constructorForClass =
Generics.newConcurrentHashMap();
/**
-* @see PageFactory#newPage(Class)
+* @see IPageFactory#newPage(Class)
*/
public final C extends IRequestablePage Page newPage(final ClassC
pageClass)
{
@@ -76,7 +76,7 @@ public final class DefaultPageFactory im
}
/**
-* @see PageFactory#newPage(Class, PageParameters)
+* @see IPageFactory#newPage(Class, PageParameters)
*/
public final C extends IRequestablePage Page newPage(final ClassC
pageClass,
final PageParameters parameters)
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/session/HttpSessionStore.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/session/HttpSessionStore.java?rev=1041604r1=1041603r2=1041604view=diff
==
---
wicket/trunk/wicket/src/main/java/org/apache/wicket/session/HttpSessionStore.java
(original)
+++
wicket/trunk/wicket/src/main/java/org/apache/wicket/session/HttpSessionStore.java
Thu Dec 2 22:00:16 2010
@@ -131,8 +131,7 @@ public class HttpSessionStore implements
}
/**
-* @see
org.apache.wicket.session.ISessionStore#getSessionId(org.apache.org.apache.wicket.request.Request,
-* boolean)
+* @see
org.apache.wicket.session.ISessionStore#getSessionId(org.apache.wicket.request.Request,
boolean)
*/
public String getSessionId(final Request request, final boolean create)
{
@@ -171,7 +170,7 @@ public class HttpSessionStore implements
}
/**
-* @see
org.apache.wicket.session.ISessionStore#lookup(org.apache.org.apache.wicket.request.Request)
+* @see
org.apache.wicket.session.ISessionStore#lookup(org.apache.wicket.request.Request)
*/
public final Session lookup(final Request request)
{
@@ -186,7 +185,7 @@ public class HttpSessionStore implements
/**
* Template method that is called when a session is being bound to the
session store. It is
* called strongbefore/strong the session object itself is added to
this store (which is
-* done by calling {...@link ISessionStore#setAttribute(Request,
String, Object)} with key
+* done by calling {...@link ISessionStore#setAttribute(Request,
String, Serializable)} with key
* {...@link Session#SESSION_ATTRIBUTE_NAME}.
*
* @param request
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/session/ISessionStore.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/session/ISessionStore.java?rev=1041604r1=1041603r2=1041604view=diff
==
---
wicket/trunk/wicket/src/main/java/org/apache/wicket/session/ISessionStore.java
(original)
+++
wicket/trunk/wicket/src/main/java/org/apache/wicket/session/ISessionStore.java
Thu Dec 2 22:00:16 2010
@@ -139,7 +139,7 @@ public interface ISessionStore
* @param sessionId
*/
void sessionUnbound(String sessionId);
- };
+ }
/**
* Registers listener invoked when session is unbound.
[jira] Created: (WICKET-3221) don't use @see upperClass when javadoc inheritance is sufficient
don't use @see upperClass when javadoc inheritance is sufficient Key: WICKET-3221 URL: https://issues.apache.org/jira/browse/WICKET-3221 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.5-M3 Reporter: Peter Ertl I see this all the time: /** * @see java.util.LinkedHashMap#removeEldestEntry(java.util.Map.Entry) */ @Override protected boolean removeEldestEntry(final Map.EntryK, V eldest) The javadoc links to the parent javadoc using @see. This is not required since javadoc inheritance is enabled by default. Unless you want to modify the javadoc from the parent class it's sufficient to just don't declare javadoc at all. less work and better result! @Override protected boolean removeEldestEntry(final Map.EntryK, V eldest) will automatically inherit the javadoc from the method it overrides. Quite often the @see link is broken after refactoring. So the @see generates a lot of unnessecary work (fix links after refactors) and makes javadoc less usable. Shouldn't we just abandon that style of documentation if the parent javadoc is fine for the child? ?? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3221) don't use @see upperClass when javadoc inheritance is sufficient
[
https://issues.apache.org/jira/browse/WICKET-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl updated WICKET-3221:
---
Description:
I see this all the time:
/**
* @see org.apache.wicket.Application#getApplicationKey()
*/
@Override
public final String getApplicationKey()
{
return getName();
}
The javadoc links to the parent javadoc using @see.
This is not required since javadoc inheritance is enabled by default. Unless
you want to modify the javadoc from the parent class it's sufficient to just
don't declare javadoc at all. less work and better result!
@Override
public final String getApplicationKey()
{
return getName();
}
will automatically inherit the javadoc from the method it overrides.
Quite often the @see link is broken after refactoring.
So the @see generates a lot of unnessecary work (fix links after refactors) and
makes javadoc less usable.
Shouldn't we just abandon that style of documentation if the parent javadoc is
fine for the child?
??
was:
I see this all the time:
/**
* @see java.util.LinkedHashMap#removeEldestEntry(java.util.Map.Entry)
*/
@Override
protected boolean removeEldestEntry(final Map.EntryK, V eldest)
The javadoc links to the parent javadoc using @see.
This is not required since javadoc inheritance is enabled by default. Unless
you want to modify the javadoc from the parent class it's sufficient to just
don't declare javadoc at all. less work and better result!
@Override
protected boolean removeEldestEntry(final Map.EntryK, V eldest)
will automatically inherit the javadoc from the method it overrides.
Quite often the @see link is broken after refactoring.
So the @see generates a lot of unnessecary work (fix links after refactors) and
makes javadoc less usable.
Shouldn't we just abandon that style of documentation if the parent javadoc is
fine for the child?
??
don't use @see upperClass when javadoc inheritance is sufficient
Key: WICKET-3221
URL: https://issues.apache.org/jira/browse/WICKET-3221
Project: Wicket
Issue Type: Improvement
Components: wicket
Affects Versions: 1.5-M3
Reporter: Peter Ertl
I see this all the time:
/**
* @see org.apache.wicket.Application#getApplicationKey()
*/
@Override
public final String getApplicationKey()
{
return getName();
}
The javadoc links to the parent javadoc using @see.
This is not required since javadoc inheritance is enabled by default. Unless
you want to modify the javadoc from the parent class it's sufficient to just
don't declare javadoc at all. less work and better result!
@Override
public final String getApplicationKey()
{
return getName();
}
will automatically inherit the javadoc from the method it overrides.
Quite often the @see link is broken after refactoring.
So the @see generates a lot of unnessecary work (fix links after refactors)
and makes javadoc less usable.
Shouldn't we just abandon that style of documentation if the parent javadoc
is fine for the child?
??
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
svn commit: r1041656 - /wicket/branches/wicket-1.4.x/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
Author: pedro
Date: Fri Dec 3 00:39:51 2010
New Revision: 1041656
URL: http://svn.apache.org/viewvc?rev=1041656view=rev
Log:
hack for a focus issue in IE working for WICKET-2279 and WICKET-3215
Issue: WICKET-3215
Modified:
wicket/branches/wicket-1.4.x/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
Modified:
wicket/branches/wicket-1.4.x/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
URL:
http://svn.apache.org/viewvc/wicket/branches/wicket-1.4.x/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js?rev=1041656r1=1041655r2=1041656view=diff
==
---
wicket/branches/wicket-1.4.x/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
(original)
+++
wicket/branches/wicket-1.4.x/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
Fri Dec 3 00:39:51 2010
@@ -590,14 +590,10 @@ Wicket.AutoComplete=function(elementId,
hideIndicator();
// hack for a focus issue in IE, WICKET-2279
-if(Wicket.Browser.isIE()) {
- Wicket.Focus.refocusLastFocusedComponentAfterResponse =
true;
- var focusedElement = Wicket.$(elementId);
- var temponblur = focusedElement.onblur;
- focusedElement.onblur = null;
- focusedElement.blur();
- setTimeout(function() { focusedElement.onblur =
temponblur;}, 0);
- Wicket.Focus.requestFocus();
+if(Wicket.Browser.isIE()) {
+ var range = document.selection.createRange();
+ if (range != null)
+ range.select();
}
}
[jira] Closed: (WICKET-3215) AutoCompleteTextField does not work in an iframe under IE 6, 7 or 8
[ https://issues.apache.org/jira/browse/WICKET-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pedro Santos closed WICKET-3215. Resolution: Fixed Fix Version/s: 1.4.15 AutoCompleteTextField does not work in an iframe under IE 6, 7 or 8 --- Key: WICKET-3215 URL: https://issues.apache.org/jira/browse/WICKET-3215 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.4.11, 1.4.12, 1.4.13, 1.4.14 Environment: Windows Server 2003 Reporter: Robert Csok Assignee: Pedro Santos Fix For: 1.4.15 Attachments: HomePage.html, HomePage.java, iframe.html The code that has been integrated in version 1.4.11 to fix issue WICKET-2279 forces the cursor of an AutoCompleteTextField to do a carriage return after each typed in char when the application runs in an iframe and IE 6, 7 or 8 is used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3218) Component#onInitialize is broken for Pages
[ https://issues.apache.org/jira/browse/WICKET-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg updated WICKET-3218: -- Attachment: (was: 0001-added-page-onpageinitialize.patch) Component#onInitialize is broken for Pages -- Key: WICKET-3218 URL: https://issues.apache.org/jira/browse/WICKET-3218 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4.14 Reporter: Carl-Eric Menzel As first mentioned at http://mail-archives.apache.org/mod_mbox/wicket-dev/201012.mbox/%3c1291238699.1749.1408166...@webmail.messagingengine.com%3e , I think the current (Wicket 1.4.14) implementation of Component#onInitialize is broken for Pages. Pages get initialized as soon as the first component is added, which is correct. But this usually happens within the constructor of the page, which means that the page object isn't fully initialized yet. The entire point of having onInitialize, however, is to be able to do further work once all constructors have run. See https://github.com/duesenklipper/wicket-oninitialize for a quickstart that demonstrates the problem. Pedro Santos suggested in the above thread to just switch the entire object construction to onInitialize. I don't think this is a good idea, because 1) it is completely counter-intuitive 2) it is not always realistic to have an entire class hierarchy not using the constructor just because a subclass somewhere might want to use onInitialize 3) it is inconsistent with onInitialize behavior for all other (non-Page) components. Here I can easily mix work in the constructor with onInitialize. I propose the following patch: - override onInitialize in Page and make it final, so Pages can't use this any more. This should not cause any unnecessary breaking, since currently it's not working for pages anyway. - introduce Page#onPageInitialize to provide a safe alternative to onInitialize - make a special case for Page in Component's beforeRender to fire Page#onPageInitialize if necessary Yes, this is a bit of special casing for Page, but there's quite a lot of that needed for Page anyway. I think the impact of this should be minimal. My page includes documentation and a new testcase that verifies the new behavior. I modified the old ComponentInitializationTest to reflect the fact that Page doesn't get onInitialize any more. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3218) Component#onInitialize is broken for Pages
[ https://issues.apache.org/jira/browse/WICKET-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966393#action_12966393 ] Igor Vaynberg commented on WICKET-3218: --- removed patch - no good - parent should be initialized before child - patch broke that for pages. Component#onInitialize is broken for Pages -- Key: WICKET-3218 URL: https://issues.apache.org/jira/browse/WICKET-3218 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4.14 Reporter: Carl-Eric Menzel As first mentioned at http://mail-archives.apache.org/mod_mbox/wicket-dev/201012.mbox/%3c1291238699.1749.1408166...@webmail.messagingengine.com%3e , I think the current (Wicket 1.4.14) implementation of Component#onInitialize is broken for Pages. Pages get initialized as soon as the first component is added, which is correct. But this usually happens within the constructor of the page, which means that the page object isn't fully initialized yet. The entire point of having onInitialize, however, is to be able to do further work once all constructors have run. See https://github.com/duesenklipper/wicket-oninitialize for a quickstart that demonstrates the problem. Pedro Santos suggested in the above thread to just switch the entire object construction to onInitialize. I don't think this is a good idea, because 1) it is completely counter-intuitive 2) it is not always realistic to have an entire class hierarchy not using the constructor just because a subclass somewhere might want to use onInitialize 3) it is inconsistent with onInitialize behavior for all other (non-Page) components. Here I can easily mix work in the constructor with onInitialize. I propose the following patch: - override onInitialize in Page and make it final, so Pages can't use this any more. This should not cause any unnecessary breaking, since currently it's not working for pages anyway. - introduce Page#onPageInitialize to provide a safe alternative to onInitialize - make a special case for Page in Component's beforeRender to fire Page#onPageInitialize if necessary Yes, this is a bit of special casing for Page, but there's quite a lot of that needed for Page anyway. I think the impact of this should be minimal. My page includes documentation and a new testcase that verifies the new behavior. I modified the old ComponentInitializationTest to reflect the fact that Page doesn't get onInitialize any more. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (WICKET-3215) AutoCompleteTextField does not work in an iframe under IE 6, 7 or 8
[ https://issues.apache.org/jira/browse/WICKET-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Grigorov reopened WICKET-3215: - Should be fixed in 1.5 as well. AutoCompleteTextField does not work in an iframe under IE 6, 7 or 8 --- Key: WICKET-3215 URL: https://issues.apache.org/jira/browse/WICKET-3215 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.4.11, 1.4.12, 1.4.13, 1.4.14 Environment: Windows Server 2003 Reporter: Robert Csok Assignee: Pedro Santos Fix For: 1.4.15 Attachments: HomePage.html, HomePage.java, iframe.html The code that has been integrated in version 1.4.11 to fix issue WICKET-2279 forces the cursor of an AutoCompleteTextField to do a carriage return after each typed in char when the application runs in an iframe and IE 6, 7 or 8 is used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
