You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Sebastian <no...@gmx.net> on 2010/09/29 21:39:01 UTC
Bug in Wicket Push TimerChannelService when used with background
threads
Hi,
there is a problem in the Push TimerChannelService implementation:
Callbacks do not work reliable when they are invoked from non-Web
threads. The "There is no application attached to current thread"
WicketRuntimeException will occur in such a case. The attached patch
fixes this issue.
Regards,
Seb
Re: Bug in Wicket Push TimerChannelService when used with
background threads
Posted by Rodolfo Hansen <kr...@gmail.com>.
Added.
On Fri, 2010-10-01 at 13:14 +0200, Sebastian wrote:
> I just realized that the current session is also bound to the thread
> context. Would it make sense to attach the Session to the background
> thread using the same way we do it for the Application?
>
> E.g.
>
> Session oldSession = Session.exists() ? Session.get() : null;
> Session.set(_session);
> try
> {
> ... invoke...
> }
> finally
> {
> if (oldSession == null) Session.unset();
> else Session.set(oldSession);
> }
>
> Without doing this, the exception IllegalSateException: "You can only
> locate or create sessions in the context of a request cycle" may be thrown.
>
> Seb
>
> On 01.10.2010 00:42, Rodolfo Hansen wrote:
> > On Thu, 2010-09-30 at 23:48 +0200, Sebastian wrote:
> >
> >>> There was an issue in your patch where the application could be left
> >> in the ThreadContext, which was fixed,
> >>
> >> Hi Rodolfo,
> >>
> >> I think you are referring to
> >>
> >> try {
> >> Application.set(_application);
> >> methods[m].invoke(o, parameters);
> >> } finally {
> >> Application.set(originalApplication);
> >> if (originalApplication != null) Application.set(originalApplication);
> >> }
> >>
> >> The problem is if this code is executed in a separate thread the
> >> originalApplication will be null. If you just omit the null check in the
> >> finally clause the setter will throw an IllegalArgumentException. So to
> >> remove the app from the ThreadContext we would have to call
> >> Application.unset() instead:
> >>
> >> if (originalApplication == null) Application.unset();
> >> else Application.set(originalApplication);
> >
> >
> > you are right, although i checked the source for set and didn't see the
> > throw...
> >
> > amended in the 1.4 branches
> >
> >
> >>
> >> Regards,
> >> Seb
> >>
> >>
> >>
> >> On 30.09.2010 23:08, Rodolfo Hansen wrote:
> >>> Hi Sebastian, your patch is in:
> >>>
> >>> trunk (1.5)
> >>> 1.4 branch (future 1.4.13 release)
> >>> and 1.4.12
> >>>
> >>> There was an issue in your patch where the application could be left in
> >>> the ThreadContext, which was fixed,
> >>> as well as a simplification in the trigger function.
> >>>
> >>> On Wed, 2010-09-29 at 21:39 +0200, Sebastian wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> there is a problem in the Push TimerChannelService implementation:
> >>>> Callbacks do not work reliable when they are invoked from non-Web
> >>>> threads. The "There is no application attached to current thread"
> >>>> WicketRuntimeException will occur in such a case. The attached patch
> >>>> fixes this issue.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Seb
>
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
Re: Bug in Wicket Push TimerChannelService when used with background
threads
Posted by Sebastian <no...@gmx.net>.
I just realized that the current session is also bound to the thread
context. Would it make sense to attach the Session to the background
thread using the same way we do it for the Application?
E.g.
Session oldSession = Session.exists() ? Session.get() : null;
Session.set(_session);
try
{
... invoke...
}
finally
{
if (oldSession == null) Session.unset();
else Session.set(oldSession);
}
Without doing this, the exception IllegalSateException: "You can only
locate or create sessions in the context of a request cycle" may be thrown.
Seb
On 01.10.2010 00:42, Rodolfo Hansen wrote:
> On Thu, 2010-09-30 at 23:48 +0200, Sebastian wrote:
>
>>> There was an issue in your patch where the application could be left
>> in the ThreadContext, which was fixed,
>>
>> Hi Rodolfo,
>>
>> I think you are referring to
>>
>> try {
>> Application.set(_application);
>> methods[m].invoke(o, parameters);
>> } finally {
>> Application.set(originalApplication);
>> if (originalApplication != null) Application.set(originalApplication);
>> }
>>
>> The problem is if this code is executed in a separate thread the
>> originalApplication will be null. If you just omit the null check in the
>> finally clause the setter will throw an IllegalArgumentException. So to
>> remove the app from the ThreadContext we would have to call
>> Application.unset() instead:
>>
>> if (originalApplication == null) Application.unset();
>> else Application.set(originalApplication);
>
>
> you are right, although i checked the source for set and didn't see the
> throw...
>
> amended in the 1.4 branches
>
>
>>
>> Regards,
>> Seb
>>
>>
>>
>> On 30.09.2010 23:08, Rodolfo Hansen wrote:
>>> Hi Sebastian, your patch is in:
>>>
>>> trunk (1.5)
>>> 1.4 branch (future 1.4.13 release)
>>> and 1.4.12
>>>
>>> There was an issue in your patch where the application could be left in
>>> the ThreadContext, which was fixed,
>>> as well as a simplification in the trigger function.
>>>
>>> On Wed, 2010-09-29 at 21:39 +0200, Sebastian wrote:
>>>
>>>> Hi,
>>>>
>>>> there is a problem in the Push TimerChannelService implementation:
>>>> Callbacks do not work reliable when they are invoked from non-Web
>>>> threads. The "There is no application attached to current thread"
>>>> WicketRuntimeException will occur in such a case. The attached patch
>>>> fixes this issue.
>>>>
>>>> Regards,
>>>>
>>>> Seb
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Bug in Wicket Push TimerChannelService when used with
background threads
Posted by Rodolfo Hansen <kr...@gmail.com>.
On Thu, 2010-09-30 at 23:48 +0200, Sebastian wrote:
> > There was an issue in your patch where the application could be left
> in the ThreadContext, which was fixed,
>
> Hi Rodolfo,
>
> I think you are referring to
>
> try {
> Application.set(_application);
> methods[m].invoke(o, parameters);
> } finally {
> Application.set(originalApplication);
> if (originalApplication != null) Application.set(originalApplication);
> }
>
> The problem is if this code is executed in a separate thread the
> originalApplication will be null. If you just omit the null check in the
> finally clause the setter will throw an IllegalArgumentException. So to
> remove the app from the ThreadContext we would have to call
> Application.unset() instead:
>
> if (originalApplication == null) Application.unset();
> else Application.set(originalApplication);
you are right, although i checked the source for set and didn't see the
throw...
amended in the 1.4 branches
>
> Regards,
> Seb
>
>
>
> On 30.09.2010 23:08, Rodolfo Hansen wrote:
> > Hi Sebastian, your patch is in:
> >
> > trunk (1.5)
> > 1.4 branch (future 1.4.13 release)
> > and 1.4.12
> >
> > There was an issue in your patch where the application could be left in
> > the ThreadContext, which was fixed,
> > as well as a simplification in the trigger function.
> >
> > On Wed, 2010-09-29 at 21:39 +0200, Sebastian wrote:
> >
> >> Hi,
> >>
> >> there is a problem in the Push TimerChannelService implementation:
> >> Callbacks do not work reliable when they are invoked from non-Web
> >> threads. The "There is no application attached to current thread"
> >> WicketRuntimeException will occur in such a case. The attached patch
> >> fixes this issue.
> >>
> >> Regards,
> >>
> >> Seb
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
Re: Bug in Wicket Push TimerChannelService when used with background
threads
Posted by Sebastian <no...@gmx.net>.
> There was an issue in your patch where the application could be left
in the ThreadContext, which was fixed,
Hi Rodolfo,
I think you are referring to
try {
Application.set(_application);
methods[m].invoke(o, parameters);
} finally {
Application.set(originalApplication);
if (originalApplication != null) Application.set(originalApplication);
}
The problem is if this code is executed in a separate thread the
originalApplication will be null. If you just omit the null check in the
finally clause the setter will throw an IllegalArgumentException. So to
remove the app from the ThreadContext we would have to call
Application.unset() instead:
if (originalApplication == null) Application.unset();
else Application.set(originalApplication);
Regards,
Seb
On 30.09.2010 23:08, Rodolfo Hansen wrote:
> Hi Sebastian, your patch is in:
>
> trunk (1.5)
> 1.4 branch (future 1.4.13 release)
> and 1.4.12
>
> There was an issue in your patch where the application could be left in
> the ThreadContext, which was fixed,
> as well as a simplification in the trigger function.
>
> On Wed, 2010-09-29 at 21:39 +0200, Sebastian wrote:
>
>> Hi,
>>
>> there is a problem in the Push TimerChannelService implementation:
>> Callbacks do not work reliable when they are invoked from non-Web
>> threads. The "There is no application attached to current thread"
>> WicketRuntimeException will occur in such a case. The attached patch
>> fixes this issue.
>>
>> Regards,
>>
>> Seb
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Bug in Wicket Push TimerChannelService when used with
background threads
Posted by Rodolfo Hansen <kr...@gmail.com>.
Hi Sebastian, your patch is in:
trunk (1.5)
1.4 branch (future 1.4.13 release)
and 1.4.12
There was an issue in your patch where the application could be left in
the ThreadContext, which was fixed,
as well as a simplification in the trigger function.
On Wed, 2010-09-29 at 21:39 +0200, Sebastian wrote:
> Hi,
>
> there is a problem in the Push TimerChannelService implementation:
> Callbacks do not work reliable when they are invoked from non-Web
> threads. The "There is no application attached to current thread"
> WicketRuntimeException will occur in such a case. The attached patch
> fixes this issue.
>
> Regards,
>
> Seb
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
Re: Save Data as CSV File
Posted by Peter Karich <pe...@yahoo.de>.
Hi,
this worked for me:
WebResource export = new WebResource() {
@Override
public IResourceStream getResourceStream() {
return new StringResourceStream(getTweetsAsString(), "text/plain");
}
@Override
protected void setHeaders(WebResponse response) {
super.setHeaders(response);
response.setAttachmentHeader("tweets.csv");
}
};
export.setCacheable(false);
add(new ResourceLink("exportCsvLink", export));
Regards,
Peter.
> I have a data table and would like the user to be able to save the data
> locally as a csv file when they click a link or button. The docs for
> DownloadLink state that it will generate a "save as" dialog which is
> exactly what I want, but, it appears to only work with a file that
> already exists. I haven't been able to find any examples of how to use
> it, so I could be wrong about that. I've seen some posts that talk
> about using a DynamicWebResource, but I can't find any complete examples
> on how to generate/download a file.
>
> What is the "best" way to download a file generated programmatically in
> Wicket?
>
> Thanks,Shelli
>
>
--
http://jetwick.com twitter search prototype
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Save Data as CSV File
Posted by Antoine Angenieux <aa...@clinigrid.com>.
You can use the constructor that takes an IModel<File> and pass a LoadableDetachableModel or AbstractReadOnlyModel in which you generate your file. Don't Forget to call setDeleteAfterDowload(true) on your DownloadLink to avoid filling your drive too fast!
I do that all the times and as usually with Wicket it works just fine ;)
Cheers,
Antoine.
--
Antoine Angénieux
Associé
Clinigrid
5, avenue Mozart
75016 Paris, France
+336 60 21 09 18
aangenieux@clinigrid.com
Le 29 sept. 2010 à 21:59, "Shelli Orton" <Sh...@sjrb.ca> a écrit :
> I have a data table and would like the user to be able to save the data
> locally as a csv file when they click a link or button. The docs for
> DownloadLink state that it will generate a "save as" dialog which is
> exactly what I want, but, it appears to only work with a file that
> already exists. I haven't been able to find any examples of how to use
> it, so I could be wrong about that. I've seen some posts that talk
> about using a DynamicWebResource, but I can't find any complete examples
> on how to generate/download a file.
>
> What is the "best" way to download a file generated programmatically in
> Wicket?
>
> Thanks,
> Shelli
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Save Data as CSV File
Posted by Shelli Orton <Sh...@sjrb.ca>.
I have a data table and would like the user to be able to save the data
locally as a csv file when they click a link or button. The docs for
DownloadLink state that it will generate a "save as" dialog which is
exactly what I want, but, it appears to only work with a file that
already exists. I haven't been able to find any examples of how to use
it, so I could be wrong about that. I've seen some posts that talk
about using a DynamicWebResource, but I can't find any complete examples
on how to generate/download a file.
What is the "best" way to download a file generated programmatically in
Wicket?
Thanks,
Shelli
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Bug in Wicket Push TimerChannelService when used with background threads
Posted by Jeremy Thomerson <je...@wickettraining.com>.
On Wed, Sep 29, 2010 at 2:39 PM, Sebastian <no...@gmx.net> wrote:
> Hi,
>
> there is a problem in the Push TimerChannelService implementation:
> Callbacks do not work reliable when they are invoked from non-Web threads.
> The "There is no application attached to current thread"
> WicketRuntimeException will occur in such a case. The attached patch fixes
> this issue.
>
>
This is a WicketStuff project. Request commit permissions for sf.net and
commit the patch.
--
Jeremy Thomerson
http://www.wickettraining.com