Thanks, that worked! I had though of something like that but the WebResource does not give you access to a request cycle. I had forgotten that I can just call RequestCycle.get(). Also I noticed the strangest thing while implementing it. Let's say I have the following query string:
?order=1234&autoPrint=false Whenever I get the PageParameters from the request cycle and try to retrieve a parameter (say, "order") it gives me the memory reference for the string instead of the string itself. For example it gives me "[Ljava.lang.String;@1b4d41e" instead of "1234". The same thing happens if I call requestCycle.getRequest().getParameterMap().get("order") But if I call requestCycle.getRequest().getParameter("order") it works fine. It's not really a big problem because I can just call the method that works, but, out of curiosity, any idea why this happens? Denis Souza -----Original Message----- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: terça-feira, 14 de setembro de 2010 14:22 To: users@wicket.apache.org Subject: Re: Safe URL for a dynamic resource you can read the parameters off the url yourself, requestcycle.getrequest()... -igor On Tue, Sep 14, 2010 at 10:08 AM, Denis Souza <denis.so...@gmail.com> wrote: > Hi, > > > > I'm trying to display a PDF file inside an IFRAME. To do that, I need a url > to place on the IFRAME's "src" attribute. > My idea is to create a shared resource and mount a url to it so I can > reference it easily. Since the PDF file is generated on-the-fly, I can also > pass a parameter through this url to determine the file's contents. > > However, I'm concerned about how safe it would be to do this. To add the > shared resource I have to produce a single WebResource object. This would be > fine if the call to getResourceStream would also pass along the parameters > that have been set, but the parameters are retrieved though a call to > getParameters. That means that the setParameters method must be called by > Wicket sometime before the call to getResourceStream is made. > > > > My question is: How can I be sure that multiple simultaneous requests won't > have concurrency problems in this scenario? > > Could there be a better way to do this? > > > > Thanks in advance, > > Denis Souza > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org