Re: svn commit: r485536 - /incubator/wicket/trunk/wicket/src/main/java/wicket/Resource.java
* [EMAIL PROTECTED]:
Author: ehillenius
Date: Sun Dec 10 23:19:58 2006
New Revision: 485536
URL: http://svn.apache.org/viewvc?view=revrev=485536
Log:
WICKET-155
Modified:
incubator/wicket/trunk/wicket/src/main/java/wicket/Resource.java
Modified: incubator/wicket/trunk/wicket/src/main/java/wicket/Resource.java
URL:
http://svn.apache.org/viewvc/incubator/wicket/trunk/wicket/src/main/java/wicket/Resource.java?view=diffrev=485536r1=485535r2=485536
==
--- incubator/wicket/trunk/wicket/src/main/java/wicket/Resource.java
(original)
+++ incubator/wicket/trunk/wicket/src/main/java/wicket/Resource.java Sun Dec
10 23:19:58 2006
@@ -18,6 +18,7 @@
import java.io.OutputStream;
import java.net.SocketException;
+import java.sql.SQLException;
import java.util.Map;
import org.apache.commons.logging.Log;
@@ -254,26 +255,32 @@
boolean ignoreException = false;
while (throwable != null)
{
- if (throwable instanceof SocketException)
+ if (throwable instanceof SQLException)
+ {
+ break; // leave false and quit loop
+ }
+ else if (throwable instanceof SocketException)
Hi Eelco,
I didn't necessarily follow the whole debate, but I wonder why you
have to catch an SQLException in Wicket code! Do you assume the
Wicket application retrieves data from an SQL database?
FWIW here is the code used in Cocoon, it's another half-baked hack
that also analyzes the error message:
// Check if the client aborted the connection
if (e instanceof SocketException) {
if (e.getMessage().indexOf(reset) -1
|| e.getMessage().indexOf(aborted) -1
|| e.getMessage().indexOf(connection abort) -1) {
throw new ConnectionResetException(Connection reset by peer,
e);
}
} else if (e instanceof IOException) {
// Tomcat5 wraps SocketException into ClientAbortException which
extends IOException.
if (e.getClass().getName().endsWith(ClientAbortException)) {
throw new ConnectionResetException(Connection reset by peer,
e);
}
}
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Last change required for reloading classes
Hi, The code to reload classes is already in Wicket branch 1.x, but there's a (hopefully) last fix to apply. Could one of you please have a look at: https://issues.apache.org/jira/secure/attachment/12346428/20061205-wicket-1.x-ReloadingClassLoader * Use ArrayList instead of HashSet for the patterns to keep the order in which they were added * Add methods includePattern() and excludePattern() * Set default patterns in the static block Thanks in advance, -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: Last change required for reloading classes
Sure, done. The issue is still open. I'm still not convinced we should ship the reloading filter tbh. As it only works with quite a few ifs and buts, I'd rather see the reloading filter (and class locator) to be part of wicket-extensions or maybe as a WIKI article or such. Though I'm fine with the patches that provide the basis for it to work (like setting the context loader etc) So far I think only Johan and I have looked at it, but before we decide on whether this should be part of Wicket core/ extensions or not, I think more people should look at it and give their opinions. My concern is not that this isn't useable - in fact I think many people will find it great - but I am afraid that if we officially support it, people *will* expect it to work for all occasions, and when it doesn't they would expect us to provide answers, fixes and so on. Personally, I'm not sure if I'm ready to do that. That said, I think the aim is great, and if there are improvements possible still and/ or other developers think it is a great addition we can certainly keep it in the pipe-line. Eelco On 12/11/06, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: Hi, The code to reload classes is already in Wicket branch 1.x, but there's a (hopefully) last fix to apply. Could one of you please have a look at: https://issues.apache.org/jira/secure/attachment/12346428/20061205-wicket-1.x-ReloadingClassLoader * Use ArrayList instead of HashSet for the patterns to keep the order in which they were added * Add methods includePattern() and excludePattern() * Set default patterns in the static block Thanks in advance, -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: Last change required for reloading classes
* Eelco Hillenius: As it only works with quite a few ifs and buts, It works great with the wicket-examples and all Wicket applications, but it's true that things get more complicated when using a component manager like Spring, because then you need to have proper separation between the presentation layer and the business model. In this case we could provide a FAQ entry like: « Why do I get a ClassCastException when turning on ReloadingWicketFilter » and explain how to solve the issue by fiddling with the include/exclude patterns. So far I think only Johan and I have looked at it, but before we decide on whether this should be part of Wicket core/ extensions or not, I think more people should look at it and give their opinions. You're right, I invite every Wicket developer and all users that can afford to checkout the code to test this feature, to have more feedback and ensure it works smoothly. My concern is not that this isn't useable - in fact I think many people will find it great - but I am afraid that if we officially support it, people *will* expect it to work for all occasions, and when it doesn't they would expect us to provide answers, fixes and so on. Personally, I'm not sure if I'm ready to do that. I'd be glad to maintain the code and provide support for it, FWIW. Cheers, -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: Last change required for reloading classes
On 12/11/06, Eelco Hillenius [EMAIL PROTECTED] wrote: Sure, done. The issue is still open. I'm still not convinced we should ship the reloading filter tbh. As it only works with quite a few ifs and buts, I'd rather see the reloading filter (and class locator) to be part of wicket-extensions or maybe as a WIKI article or such. Though I'm fine with the patches that provide the basis for it to work (like setting the context loader etc) Hi, I've played a bit with the reloading filter and find it great; obviously supporting it in all possible environments is an hard work, but I'd like it to be part of the project (in wicket-extensions or, why not, a new wicket-reloading-filter package) BTW, is the reloading filter portable to Wicket-2.0? do you see any problem in using it with w-2.0? -- Filippo
Re: VOTE: focus on popups by default in Wicket 1.2.x
On 11/12/06, Eelco Hillenius [EMAIL PROTECTED] wrote: [ ] sure put it in 1.2.x [ X] nah, people can do it themselves, let's not worry about it My feeling is that at this point, we should be actively avoiding a new 1.2 release and not adding things. On this specific point, surely existing developments on 1.2 would either not care, or will already have coded a work-around, whereas new developments could use 1.3 if they really want it in core /Gwyn -- Download Wicket 1.2.3 now! - http://wicketframework.org
Re: Re: VOTE: focus on popups by default in Wicket 1.2.x
+0 I think discussing the benefits of not applying this patch to 1.2.4 will cost more than the actual act. Eelco thinks it is worth his time to apply the patch, otherwise he wouldn't have proposed the vote. The whole point of requiring a vote is to remove the automatic knee jerk to apply backports to all 3 branches. Martijn On 12/11/06, Gwyn Evans [EMAIL PROTECTED] wrote: On 11/12/06, Eelco Hillenius [EMAIL PROTECTED] wrote: [ ] sure put it in 1.2.x [ X] nah, people can do it themselves, let's not worry about it My feeling is that at this point, we should be actively avoiding a new 1.2 release and not adding things. On this specific point, surely existing developments on 1.2 would either not care, or will already have coded a work-around, whereas new developments could use 1.3 if they really want it in core /Gwyn -- Download Wicket 1.2.3 now! - http://wicketframework.org -- Vote for Wicket at the http://www.thebeststuffintheworld.com/vote_for/wicket Wicket 1.2.3 is as easy as 1-2-3. Download Wicket now! http://wicketframework.org
AjaxFormComponentUpdatingBehavior.onEvent behaviour
We now have this:
protected final void onEvent(final AjaxRequestTarget target)
{
final FormComponent formComponent = getFormComponent();
boolean callOnUpdate = true;
try
{
formComponent.inputChanged();
formComponent.validate();
if (formComponent.hasErrorMessage())
{
formComponent.invalid();
onError(target, null);
}
else
{
formComponent.valid();
formComponent.updateModel();
}
}
catch (RuntimeException e)
{
callOnUpdate = false;
onError(target, e);
}
if (callOnUpdate)
{
onUpdate(target);
}
}
why is onUpdate(target) also called when onError is also called (if it has
errormessages)
shouldn't it be:
protected final void onEvent(final AjaxRequestTarget target)
{
final FormComponent formComponent = getFormComponent();
boolean callOnUpdate = true;
try
{
formComponent.inputChanged();
formComponent.validate();
if (formComponent.hasErrorMessage())
{
formComponent.invalid();
callOnUpdate = false;
onError(target, null);
}
else
{
formComponent.valid();
formComponent.updateModel();
}
}
catch (RuntimeException e)
{
callOnUpdate = false;
onError(target, e);
}
if (callOnUpdate)
{
onUpdate(target);
}
}
or (but then onError is called when onUpdate fails)
protected final void onEvent(final AjaxRequestTarget target)
{
final FormComponent formComponent = getFormComponent();
try
{
formComponent.inputChanged();
formComponent.validate();
if (formComponent.hasErrorMessage())
{
formComponent.invalid();
onError(target, null);
}
else
{
formComponent.valid();
formComponent.updateModel();
onUpdate(target);
}
}
catch (RuntimeException e)
{
callOnUpdate = false;
onError(target, e);
}
}
johan
Re: Last change required for reloading classes
if it doesnt work 100% of the time then imho it shouldnt be in the core, i think it should go into a separate module or extensions. -igor On 12/11/06, Eelco Hillenius [EMAIL PROTECTED] wrote: Sure, done. The issue is still open. I'm still not convinced we should ship the reloading filter tbh. As it only works with quite a few ifs and buts, I'd rather see the reloading filter (and class locator) to be part of wicket-extensions or maybe as a WIKI article or such. Though I'm fine with the patches that provide the basis for it to work (like setting the context loader etc) So far I think only Johan and I have looked at it, but before we decide on whether this should be part of Wicket core/ extensions or not, I think more people should look at it and give their opinions. My concern is not that this isn't useable - in fact I think many people will find it great - but I am afraid that if we officially support it, people *will* expect it to work for all occasions, and when it doesn't they would expect us to provide answers, fixes and so on. Personally, I'm not sure if I'm ready to do that. That said, I think the aim is great, and if there are improvements possible still and/ or other developers think it is a great addition we can certainly keep it in the pipe-line. Eelco On 12/11/06, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: Hi, The code to reload classes is already in Wicket branch 1.x, but there's a (hopefully) last fix to apply. Could one of you please have a look at: https://issues.apache.org/jira/secure/attachment/12346428/20061205-wicket-1.x-ReloadingClassLoader * Use ArrayList instead of HashSet for the patterns to keep the order in which they were added * Add methods includePattern() and excludePattern() * Set default patterns in the static block Thanks in advance, -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: AjaxFormComponentUpdatingBehavior.onEvent behaviour
i think that was legacy behavior because onError() did not always exist.
feel free to fix it, in 1.3 we can make the break
-igor
On 12/11/06, Johan Compagner [EMAIL PROTECTED] wrote:
We now have this:
protected final void onEvent(final AjaxRequestTarget target)
{
final FormComponent formComponent = getFormComponent();
boolean callOnUpdate = true;
try
{
formComponent.inputChanged();
formComponent.validate();
if (formComponent.hasErrorMessage())
{
formComponent.invalid();
onError(target, null);
}
else
{
formComponent.valid();
formComponent.updateModel();
}
}
catch (RuntimeException e)
{
callOnUpdate = false;
onError(target, e);
}
if (callOnUpdate)
{
onUpdate(target);
}
}
why is onUpdate(target) also called when onError is also called (if it has
errormessages)
shouldn't it be:
protected final void onEvent(final AjaxRequestTarget target)
{
final FormComponent formComponent = getFormComponent();
boolean callOnUpdate = true;
try
{
formComponent.inputChanged();
formComponent.validate();
if (formComponent.hasErrorMessage())
{
formComponent.invalid();
callOnUpdate = false;
onError(target, null);
}
else
{
formComponent.valid();
formComponent.updateModel();
}
}
catch (RuntimeException e)
{
callOnUpdate = false;
onError(target, e);
}
if (callOnUpdate)
{
onUpdate(target);
}
}
or (but then onError is called when onUpdate fails)
protected final void onEvent(final AjaxRequestTarget target)
{
final FormComponent formComponent = getFormComponent();
try
{
formComponent.inputChanged();
formComponent.validate();
if (formComponent.hasErrorMessage())
{
formComponent.invalid();
onError(target, null);
}
else
{
formComponent.valid();
formComponent.updateModel();
onUpdate(target);
}
}
catch (RuntimeException e)
{
callOnUpdate = false;
onError(target, e);
}
}
johan
Wicket site v2.0
Vincent delivered, and came up with a nice follow up to the previous design. http://issues.apache.org/jira/secure/attachment/12346927/wicket_v2.png Any feedback on this one? Can we move forward and rework http://cwiki.apache.org/WICKETxSITE using this design? Martijn -- Vote for Wicket at the http://www.thebeststuffintheworld.com/vote_for/wicket Wicket 1.2.3 is as easy as 1-2-3. Download Wicket now! http://wicketframework.org
Re: Wicket site v2.0
Uhh the previous was nice but this one is really cool. +1 from me :) Frank On 12/11/06, Martijn Dashorst [EMAIL PROTECTED] wrote: Vincent delivered, and came up with a nice follow up to the previous design. http://issues.apache.org/jira/secure/attachment/12346927/wicket_v2.png Any feedback on this one? Can we move forward and rework http://cwiki.apache.org/WICKETxSITE using this design? Martijn -- Vote for Wicket at the http://www.thebeststuffintheworld.com/vote_for/wicket Wicket 1.2.3 is as easy as 1-2-3. Download Wicket now! http://wicketframework.org
Re: Last change required for reloading classes
BTW, is the reloading filter portable to Wicket-2.0? do you see any problem in using it with w-2.0? I first wanted the implementation stable enough before we port the changes to 2.0. There need to be a couple of tweaks before that filter can be used, but not big things. Eelco
Re: Wicket site v2.0
Nice - go for it. /Gwyn On 11/12/06, Martijn Dashorst [EMAIL PROTECTED] wrote: Vincent delivered, and came up with a nice follow up to the previous design. http://issues.apache.org/jira/secure/attachment/12346927/wicket_v2.png Any feedback on this one? Can we move forward and rework http://cwiki.apache.org/WICKETxSITE using this design? Martijn -- Vote for Wicket at the http://www.thebeststuffintheworld.com/vote_for/wicket Wicket 1.2.3 is as easy as 1-2-3. Download Wicket now! http://wicketframework.org -- Download Wicket 1.2.3 now! - http://wicketframework.org
Re: Wicket site v2.0
Martijn Dashorst wrote: Vincent delivered, and came up with a nice follow up to the previous design. http://issues.apache.org/jira/secure/attachment/12346927/wicket_v2.png Any feedback on this one? Can we move forward and rework http://cwiki.apache.org/WICKETxSITE using this design? Martijn +1, I like -Matej -- get professional wicket training and consultation http://www.wicket-support.com
Re: Wicket site v2.0
Very nice +1 - Paolo On 12/11/06, Martijn Dashorst [EMAIL PROTECTED] wrote: Vincent delivered, and came up with a nice follow up to the previous design. http://issues.apache.org/jira/secure/attachment/12346927/wicket_v2.png Any feedback on this one? Can we move forward and rework http://cwiki.apache.org/WICKETxSITE using this design? Martijn -- Vote for Wicket at the http://www.thebeststuffintheworld.com/vote_for/wicket Wicket 1.2.3 is as easy as 1-2-3. Download Wicket now! http://wicketframework.org
