Is it safe to share static components across multiple page instances and request threads?
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 PageParameter arguments, can I create this as a static class member and share it across all instances of the Page on which it is used? (instead if creating a new instance for each new page). Rgs, Joel
Re: Is it safe to share static components across multiple page instances and request threads?
(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 multiple page instances and request threads? 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 PageParameter arguments, can I create this as a static class member and share it across all instances of the Page on which it is used? (instead if creating a new instance for each new page). Rgs, Joel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it safe to share static components across multiple page instances and request threads?
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 PageParameter arguments, can I create this as a static class member and share it across all instances of the Page on which it is used? (instead if creating a new instance for each new page). Rgs, Joel -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is it safe to share static components across multiple page instances and request threads?
My guess would be no, since the object hierarchy of a page is a fundamental aspect of Wicket. I don't think that instances of Wicket Component objects are meant to be thread-safe and shared between different Component trees. There is all kinds of mutable data in Component that is not meant 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 multiple page instances and request threads? (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 multiple page instances and request threads? 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 PageParameter arguments, can I create this as a static class member and share it across all instances of the Page on which it is used? (instead if creating a new instance for each new page). Rgs, Joel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
