I already moved o.a.w.util.time.* to -util earlier today.
On Thu, Jul 7, 2011 at 8:25 PM, Igor Vaynberg wrote:
> no. knock yourself out.
>
> -igor
>
> On Thu, Jul 7, 2011 at 11:20 AM, Sven Meier wrote:
>> Hi all,
>>
>> I just wanted to move o.a.w.util.time.* related tests from wicket-core into
>
no. knock yourself out.
-igor
On Thu, Jul 7, 2011 at 11:20 AM, Sven Meier wrote:
> Hi all,
>
> I just wanted to move o.a.w.util.time.* related tests from wicket-core into
> wicket-util. But apparently there are many more tests (e.g. StringListTest)
> located in the 'wrong' wicket module.
>
> Any
Hi all,
I just wanted to move o.a.w.util.time.* related tests from wicket-core
into wicket-util. But apparently there are many more tests (e.g.
StringListTest) located in the 'wrong' wicket module.
Any reason against moving all these tests?
Thanks
Sven
sometimes code wants to block until something is deleted. so we should
probably have
deleteSynchronously(file, duration max)
and deleteAsynchronously(file)
-igor
On Thu, Jul 7, 2011 at 8:58 AM, Martin Grigorov wrote:
> the reason to fail is what bothers me.
> if the current process has no perm
the reason to fail is what bothers me.
if the current process has no permissions to delete this file then
this delete operation will "block" forever
even if we try N attempts to delete the file/folder then trying to
delete a folder with hundreds of files will slow down again
or you mean : try N ti
alternatively, if we do not recurse we can just do what it does now,
when any file in folders fails - wait 100ms and try to delete the
folder again.
-igor
On Thu, Jul 7, 2011 at 8:38 AM, Martin Grigorov wrote:
> This is something like org.apache.wicket.util.file.FileCleaningTracker
> which is us
well, this class is one of those that we copied from commons-upload.
I prefer to not add custom logic in it.
But with custom org.apache.wicket.util.file.FileDeleteStrategy it will work.
On Thu, Jul 7, 2011 at 5:45 PM, Igor Vaynberg wrote:
> unfortunately? you do have commit privs right? :)
>
> -
unfortunately? you do have commit privs right? :)
-igor
On Thu, Jul 7, 2011 at 8:38 AM, Martin Grigorov wrote:
> This is something like org.apache.wicket.util.file.FileCleaningTracker
> which is used to delete the uploaded files, but unfortunately it
> doesn't support folders as well.
>
> On Thu
This is something like org.apache.wicket.util.file.FileCleaningTracker
which is used to delete the uploaded files, but unfortunately it
doesn't support folders as well.
On Thu, Jul 7, 2011 at 5:31 PM, Igor Vaynberg wrote:
> have a background daemon thread handles this. it will queue up files
> th
have a background daemon thread handles this. it will queue up files
that cannot be deleted and keep trying in the background.
if the folder is passed in and any file in it fails to be deleted
queue the folder itself again, not the individual files - ie do not
make the call to delete subfolders an
martin, i have set up the sample code locally and added the feedback message in
onSubmit.
it works in safari.
that proofs that something must be wrong with my code.
thanks for your help.
--
ulf schneider
+49 163 2505164
u...@datenlabor.net
blog: http://allesagil.net
datenlabor gmbh
sitz: paderbo
then you can either run the examples locally and confirm, or create a
quickstart that reproduces the issue and attach it to Jira...
On Thu, Jul 7, 2011 at 1:38 PM, ulf schneider wrote:
> martin, i'm not sure about that.
> the feedback panel is being updated in the onSubmit of the button, that's
On Thu, Jul 7, 2011 at 1:30 PM, Peter Ertl wrote:
> If someone calls Files#remove(File) with a folder I would throw an
> IllegalArgumentException but not just erase the whole folde. People could see
> a potential similarity between java.io.File#delete() and Files#remove() and
> be very surprise
martin, i'm not sure about that.
the feedback panel is being updated in the onSubmit of the button, that's right.
but the AjaxFormValidatingBehavior is updating the feedback panel either. so
when the form is filled correctly, the feedback messages will disappear before
the onSubmit of the button
If someone calls Files#remove(File) with a folder I would throw an
IllegalArgumentException but not just erase the whole folde. People could see a
potential similarity between java.io.File#delete() and Files#remove() and be
very surprised when this method suddenly erases a folder with 2 file
The feedback is updated in onSubmit().
So you can try:
- submit with invalid data so you see the error
- submit with valid data so you see that the feedback disappears (i.e.
onSubmit() is called)
On Thu, Jul 7, 2011 at 1:08 PM, ulf schneider wrote:
> martin, now i can reach all three adresses.
>
martin, now i can reach all three adresses.
when i try to submit without filling in the form, i do get a feedback message
that some input is needed (for both submits, the ajax and non-ajax). this is
working in safari for all three web pages.
but i'm not sure: as the form validation fails, i thi
I can open them without any problems.
Here is another setup of 1.5 -
http://www.wicket-library.com/wicket-examples/ajax/form
I don't have Safari on my Linux machine, otherwise I'd test it myself.
On Thu, Jul 7, 2011 at 12:46 PM, ulf schneider wrote:
> i will check that, but currently i do get a
i will check that, but currently i do get a "service temporarily unavailable"
for both adresses.
--
ulf schneider
+49 163 2505164
u...@datenlabor.net
blog: http://allesagil.net
datenlabor gmbh
sitz: paderborn, hrb 8819
geschäftsführer: ulf schneider
http://datenlabor.net
stop starting and start
Do you reproduce it at http://wicketstuff.org/wicket14/ajax/form ?
If yes then please create a ticket.
Please check as well http://wicketstuff.org/wicket/ajax/form - this is
Wicket 1.5
On Thu, Jul 7, 2011 at 12:35 PM, ulf schneider wrote:
> dear developers,
> do you have an indication that the a
dear developers,
do you have an indication that the ajax submit with AjaxButton and
AjaxSubmitLink is not working in safari 5.0.5? i am using wicket 1.4.17 and in
safari the onSubmit(AjaxRequestTarget target, Form form) is not being called.
i have cross-checked with chrome, camino, firefox and o
Hi,
Related to https://issues.apache.org/jira/browse/WICKET-3875 I want to
discuss the behavior of Files#remove(File).
In 1.4.x this method tries java.io.File#delete() and if this doesn't
succeed then it calls System.gc(), waits for 100ms and tries again.
According to the javadoc of the method th
22 matches
Mail list logo
