Hi Thorsten,
> As well I really only need to render within one and the same thread
> one after another,
that should work.
> is it safe to render recursively using ComponentRenderer within
> one and the same thread?
I assume you mean 'consecutively'? Yes, see above.
Have fun
Sven
On
As solution I can see using HttpServletRequestWrapper instead of dealing
directly with the HttpServletRequest passed by the container.
This way we can provide custom implementation of HttpServletRequestWrapper
that overrides javax.servlet.ServletRequestWrapper.getCharacterEncoding()
and if
I found my problem in the end. There was an object that wasn't able to be
correctly serialized (a JFreeChart object), which threw an error that, due
to some mistake on my logging configuration I was hiding.
Anyway, once I fixed the serialization problem, now everything is being
correctly
Building a sample to show the problem has been harder than I thought.
Because on all bare-bones applications that I tried to build, the URLs end
up being different (the counter on the interface seems to be working). What
could make my larger application not increment the
are all the urls really exactly the same?
is your pagesettings.automaticmultiwindowsupport enabled?
-igor
On Thu, Aug 14, 2008 at 10:30 AM, Michel Goldstein
[EMAIL PROTECTED] wrote:
Hi,
I have an application that generates different reports based on what the
user selects. The report
Q: are all the urls really exactly the same?
Yes, they are exactly the same
Q: is your pagesettings.automaticmultiwindowsupport enabled?
Interesting. I didn't know of such setting. But I did change it in the
application, adding:
getPageSettings().setAutomaticMultiWindowSupport(true);
but I'm
I read a different thread that is going on right now about preventing image
caching by using a NonCachingImage instead Image and seeing that it adds a
random reference to the image, I thought it might help on my problem too.
And, as far as I can tell, it actually did solve my problem too.
Should
Spoke too soon... Unfortunately the problem still seems to be there even
after I've added the NonCachingImage. This furthers the confirmation that
it's not browser caching issue, but a resource sharing problem.
Any ideas would be greatly appreciated.
Thanks,
Michel
On Thu, Aug 14, 2008 at 1:18
On Thu, 14 Aug 2008, Michel Goldstein wrote:
Spoke too soon... Unfortunately the problem still seems to be there even
after I've added the NonCachingImage. This furthers the confirmation that
it's not browser caching issue, but a resource sharing problem.
From where does the image data come
As I mentioned, I basically used what was in the twiki about JFreeChart
integration. I'll build a simple example of the problem and send it out
sometime tomorrow (USA Pacific time).
Thanks,
Michel
On Thu, Aug 14, 2008 at 7:59 PM, Timo Rantalaiho [EMAIL PROTECTED]wrote:
On Thu, 14 Aug 2008,
(BTW I am assuming that since each component has a parent that sharing is
NOT allowed)
--
From: Joel Halbert [EMAIL PROTECTED]
Sent: Friday, June 20, 2008 9:29 AM
To: users@wicket.apache.org
Subject: Is it safe to share static components across
no
On Fri, Jun 20, 2008 at 10:29 AM, Joel Halbert [EMAIL PROTECTED] wrote:
Hi,
Is it threadsafe and wicket safe to share static Components across multiple
instances of a Page (as well as across request threads) in wicket?
Say for example I have a BookmarkablePageLink that takes no dynamic
to be shared across threads. Creating a new
instance of the link for every page would be the correct approach.
-Original Message-
From: Joel Halbert [mailto:[EMAIL PROTECTED]
Sent: Friday, June 20, 2008 4:31 AM
To: users@wicket.apache.org
Subject: Re: Is it safe to share static components across
What would you like to detach?
What is inside that card object? I guess thats a temp storage object
of shopping items?
Do remenber that getting the card object from the session isnt thread
safe! (mutating it can be done from more then one thread if different
pagemaps and so on are used)
On
ok, and if the session isn't thread safe, where do I store my temporal data?
2008/1/21, Johan Compagner [EMAIL PROTECTED]:
The session. Because the property exp is used when you ask for the value
On 1/21/08, Martijn Lindhout [EMAIL PROTECTED] wrote:
you're right. It contains a
you're right. It contains a shoppingcart. What is stored in the
propertymodel, the session? Or the result of evaluating the expression
s.cart - session.getCart().
And if the session isn't thread safe, where do I store my temporal data?
2008/1/21, Johan Compagner [EMAIL PROTECTED]:
What would
The session. Because the property exp is used when you ask for the value
On 1/21/08, Martijn Lindhout [EMAIL PROTECTED] wrote:
you're right. It contains a shoppingcart. What is stored in the
propertymodel, the session? Or the result of evaluating the expression
s.cart - session.getCart().
custom request cycle?
2008/1/21, Martijn Dashorst [EMAIL PROTECTED]:
Typically a custom request cycle for the actual object and store the key
for
getting access to the object in the session.
If the cart is not a hibernate entity, but something really transient, I
don't think there is any
On Jan 21, 2008 1:51 AM, Martijn Lindhout [EMAIL PROTECTED] wrote:
ok, and if the session isn't thread safe, where do I store my temporal data?
I think the session is a fine storage option for a shopping cart. Just
synchronize the cart itself and you're fine. Or don't; it's rather
unlikely you
19 matches
Mail list logo
