you can register a shared resource and build a url for it. inside shared resource you can simply call Session.get() to get to wicket session.
see application.getsharedresources(); alternatively you can extend WicketSessionFilter which will also allow you to perform Session.get() -igor On 8/21/07, Thomas Singer <[EMAIL PROTECTED]> wrote: > > Disclaimer: I'm not experienced with filters or wicket resources. > > Is it possible to create a (shared) wicket resource which can be > "filtered", > so it only is accessible when the right flag is set in OurWebSession? > > Or would you suggest to write an own javax.servlet.Filter which does this > flag-check and redirects internally to a hidden location which then is > send > to the client by Tomcat when the right flag is set? > > Thanks in advance. > > -- > Best regards, > Thomas Singer > _____________ > SyntEvo GmbH > Brunnfeld 11 > 83404 Ainring > Germany > www.syntevo.com > > > Igor Vaynberg wrote: > > On 8/21/07, Thomas Singer <[EMAIL PROTECTED]> wrote: > >> Hi Igor, > >> > >>> yep, DownloadLinks will block because requests to the same page are > >>> serialized. > >> Sorry, I don't understand, why links to downloadable resources should > be > >> blocking or serialized. Usually downloads are the larger parts of an > >> application and hence should never lock the application. > > > > > > because this is how this component is designed to work. if you dont like > it > > you can build your own that doesnt block. > > > >> to work around it register a shared resource or create a servlet that > can > >>> stream the file (resoureces in wicket are not serialized), then create > a > >>> link component that can build a download url. > >> Well, I guess, we can't use a servlet, because wicket is registered to > >> "/*", so it will get everything. > > > > > > wicket is a filter, so even though it is mapped to /* it will let urls > that > > are not wicket urls pass through. how do you think it lets you download > > static images... > > so if you map your wicket filter on /* and the servlet on /download and > yo > > have no "download" mount in wicket the filter will let /download/* > requests > > go to the servlet. > > > > -igor > > > > > > Could you please give some more hints > >> about shared resources? I've tried to search > >> http://cwiki.apache.org/WICKET/ without luck. > >> > >> Alternatively, is it possible to complete shut off the serialization > >> (which seems to cause this and maybe even other blocking problems)? > >> > >> -- > >> Best regards > >> Thomas Singer > >> _____________ > >> SyntEvo GmbH > >> Brunnfeld 11 > >> 83404 Ainring > >> Germany > >> > >> > >> Igor Vaynberg wrote: > >>> yep, DownloadLinks will block because requests to the same page are > >>> serialized. > >>> > >>> to work around it register a shared resource or create a servlet that > >> can > >>> stream the file (resoureces in wicket are not serialized), then create > a > >>> link component that can build a download url. > >>> > >>> -igor > >>> > >>> > >>> On 8/20/07, Thomas Singer <[EMAIL PROTECTED]> wrote: > >>>> Hi, > >>>> > >>>> We are using Wicket 1.3 beta 2 running in Tomcat and have a couple of > >>>> DownloadLinks on a page (created with 'new DownloadPage(parameters)') > >> for > >>>> larger files (a couple of MB). I open different tabs of the same page > >> in > >>>> Opera and click these download links, so the downloads should happen > in > >>>> parallel. Unfortunately, the web-application seems to hang until the > >>>> previous files were completely downloaded. Even normal pages do not > >> show > >>>> up. > >>>> > >>>> This does not happen for other websites (so our internet connection > >>>> couldn't > >>>> be the reason) and not for the same project with > >>>> old-JSP-/Servlet-technology > >>>> at a different server running in the same version of Tomcat. > >>>> > >>>> Is this a known problem? How to work around? > >>>> > >>>> -- > >>>> Best regards, > >>>> Thomas Singer > >>>> _____________ > >>>> Syy____ntEvo GmbH > >>>> Brunnfeld 11 > >>>> 83404 Ainring > >>>> Germany > >>>> www.syntevo.com > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>> For additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>>> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
