Did you try to set correct permissions for temp files in config?
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Problems-with-wicket-serialization-tp4668414p4668556.html
Sent from the Users forum mailing list archive at Nabble.com
Hi,
I have an application using Wicket 1.5.10 and I'm having problems with the
serialization of FileUpload component. The problem is that the FileUpload
creates a temporary file in the temp directory and when the wicket
deserializes the page, if file (*temp directory*) no exists the following
exce
Michael,
This is extremely helpful. Thanks for the detailed explanation!
Mike
-Original Message-
From: Michael Mosmann [mailto:mich...@mosmann.de]
Sent: Wednesday, August 21, 2013 11:53 PM
To: users@wicket.apache.org
Subject: Re: Wicket serialization concerns
Am 21.08.13 01:01
Am 21.08.13 01:01, schrieb Michael Chandler:
.. will expose me to a serialization error unless I put it in a Wicket model.
Am I correct about this?
There is nothing special about the serialization in Wicket. Wicket uses
the default Java serialization. So every field not marked as transient
w
On Tue, 20 Aug 2013 23:01:29 +
Michael Chandler wrote:
> I'm led to believe that creating a
> reference to any of my domain classes within a Wicket component (as a
> field or in a method implementation) will expose me to a
> serialization error unless I put it in a Wicket model. Am I correct
I could use some input from some of the more experienced Wicket users out
there. I'm having a hard time fully understanding when to worry about Wicket
attempting to serialize domain model objects, resulting in serialization
warnings/errors in the logs. I had been under the impression that if I
the push service does not directly keep references, this happens because
of the usage of anonymous classes created within the components, e.g.
callbacks, eventlisteners, e.g.:
final Label label = new Label("label","");
final IPushTarget pushTarget = getTimerPushService().installPush(this);
bac
sounds wrong, no one should be keeping references to components
-igor
On Fri, Oct 1, 2010 at 3:32 PM, Sebastian wrote:
> hi,
>
> on a local copy of Wicket I now temporarily modified the
> SecondLevelCacheSessionStore class and always have the
> SecondLevelCachePageMap.getLastPage() method return
hi,
on a local copy of Wicket I now temporarily modified the
SecondLevelCacheSessionStore class and always have the
SecondLevelCachePageMap.getLastPage() method return null. This enforces
that a freshly deserialized page object instance is used on each request.
The reason why I am doing this
wicket already tests serialization for you in dev mode
-igor
On Fri, Oct 1, 2010 at 5:37 AM, Sebastian wrote:
> Hi,
>
> is it possible to configure a wicket app in a way that definitely will use
> page serialization/deserializion on each request and will not hold any
> page/component instanc
Hi,
is it possible to configure a wicket app in a way that definitely will
use page serialization/deserializion on each request and will not hold
any page/component instances between requests in memory? I'd like to use
this during development time to test some aspects of my wicket components.
Am 18.05.2010 23:40, schrieb Christoph Grün:
I am using Wicket 1.4.8 with Guice 1.0 and Warp Persist/Hibernate.
When injecting DAOs directly into Wicket components, it works fine (I inject
the DAO Interface). However, I would like to inject them, next to other
objects, also in classes that do so
either use the wicket-guice module to inject into wicket pages, or
something like salve.googlecode.com to do the injection for you.
-igor
On Tue, May 18, 2010 at 2:40 PM, Christoph Grün wrote:
> Hi all,
>
>
>
> I am using Wicket 1.4.8 with Guice 1.0 and Warp Persist/Hibernate.
>
> When injecting
Hi all,
I am using Wicket 1.4.8 with Guice 1.0 and Warp Persist/Hibernate.
When injecting DAOs directly into Wicket components, it works fine (I inject
the DAO Interface). However, I would like to inject them, next to other
objects, also in classes that do some business logic. Those classes ar
This has been discussed before (of course) and this is on purpose. If
you reload old pages your users will probably wonder what's going on
(they are not used to this behavior), and secondly there is a
performance hit with no business benefit.
However, you should feel free to change these defau
btw, gere is an interesting point, where IE and Firefox differ from each
other. If you click the back-button of Firefox the page does not reload but
is loaded from cache.
http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/
maybe cache-control should be
> Wicket stores
> 1. the page,
> 2. component hierarchy,
> 3. and associated models (the state) in the page store."
>
> By "only the serialized form of the page hierarchy is stored.", you mean the
> first two things?
The page == component hierarchy and associated models are part of it
because the
y "only the serialized form of the page hierarchy is stored.", you mean the
first two things?
Regards,
David
--- On Sun, 2/21/10, Erik van Oosten wrote:
> From: Erik van Oosten
> Subject: Re: Questions about how wicket serialization works
> To: users@wicket.apache.org
> Date
Answers below...
David Chang wrote:
I am reading the book Wicket in Action. Page 88 about serializing models says:
"At the end of the request, after the markup has been sent to the browser, Wicket
stores the page, component hierarchy, and associated models (the state) in the page
store."
Do
I am reading the book Wicket in Action. Page 88 about serializing models says:
"At the end of the request, after the markup has been sent to the browser,
Wicket stores the page, component hierarchy, and associated models (the state)
in the page store."
Does "Wicket stores the page" means Wicke
considering you should be using LDM models and so you do not have
direct references to entities - no.
-igor
On Tue, Jun 2, 2009 at 1:26 PM, tubin gen wrote:
> I am thinking of using byte code instrumentation for lazy loading of
> properties , I use hibernate entities as model for most of my page
I am thinking of using byte code instrumentation for lazy loading of
properties , I use hibernate entities as model for most of my pages and
wonderingbyte code instrumentation will cause any issues for
serialization ?
--
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
>
--
View this message in context:
http://www.nabble.com/Wick
Hi Ernesto,
Thanks.
Just one question why not use buddy class-loading techniques to
"solve" serialization problem?
Simple: at least for now, this is a non-standard extension for Eclipse/
Equinox. :-)
I am aware of some proposals to modify the OSGi spec, but as far as I
know, that's not
..@wicket.apache.org
>
>
>
--
View this message in context:
http://www.nabble.com/Wicket-serialization-problems-for-OSGi-users-tp22653816p22655758.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
I know there have been a few people inquiring about this from time to
time.
I write about my experiences here, in the hope that this is helpful:
http://bioscene.blogspot.com/2009/03/serialization-in-osgi.html
Cheers,
=David
---
26 matches
Mail list logo