Re: Problems with wicket serialization
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. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Problems with wicket serialization
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 exception occurs: https://gist.github.com/anonymous/c33ee20df9c68b118459 This problem only occurs when multiple browser tabs are open. Suggestions of how to solve? best, Laécio.
Re: Wicket serialization concerns
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
will be serialized. As Martin said: watch out for non static inner
classes or anon classes because you can not see the field which is
created for any reference to something from the outer scope.
To put your stuff behind a model has a benefit: if wicket is done with
your page (response is written to the client) it will throw away
anything changeable from your models. In your case the list of the
entries from your database is flushed from memory.
I would not recommend to put long living data into your components
(which then must be serialize-able). You should put something like this
into a cache.
You can put everything needed to load you date from somewhere into an model.
public class Customers extends LoadableDetachableModelListCustomer {
@SpringBean
CustomersDao dao;
public Customers() {
Injector.get().inject(this);
}
public ListCustomer load() {
return dao.allCustomers();
}
}
This way your component must not deal with anything else .. it will use
model which provides the data:)
Michael:)
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wicket serialization concerns
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, 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 will be
serialized. As Martin said: watch out for non static inner classes or anon
classes because you can not see the field which is created for any reference to
something from the outer scope.
To put your stuff behind a model has a benefit: if wicket is done with your
page (response is written to the client) it will throw away anything changeable
from your models. In your case the list of the entries from your database is
flushed from memory.
I would not recommend to put long living data into your components (which then
must be serialize-able). You should put something like this into a cache.
You can put everything needed to load you date from somewhere into an model.
public class Customers extends LoadableDetachableModelListCustomer {
@SpringBean
CustomersDao dao;
public Customers() {
Injector.get().inject(this);
}
public ListCustomer load() {
return dao.allCustomers();
}
}
This way your component must not deal with anything else .. it will use model
which provides the data:)
Michael:)
-
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
Wicket serialization concerns
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 had an object as a field in a Wicket component, I needed to be on alert for serialization issues. So, if I have an object as a field, I make it a LoadableDetachableModel. In cases where I need to load in a wired object, I make use of the handy @SpringBean annotation. Otherwise, I assumed I was in the clear but I'm seeing now that's not the case. In a method within a webpage component, I'm creating a List collection of domain objects for use in a form's DropDownChoice component. Unless I put that list in a LoadableDetachableModel, I will get a serialization error. 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 about this? Thanks! Mike Chandler
Re: Wicket serialization concerns
On Tue, 20 Aug 2013 23:01:29 + Michael Chandler michael.chand...@onassignment.com 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 about this? Basically yes. Any non-transient field in your Component will be serialized. That includes final local variables or final method/constructor parameters if you reference those from within an inner class. That will make the compiler generate a hidden field to keep that reference for the inner class. Carl-Eric - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Wicket Serialization
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. regards, seb - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Serialization
wicket already tests serialization for you in dev mode -igor On Fri, Oct 1, 2010 at 5:37 AM, Sebastian nospam...@gmx.net 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 instances between requests in memory? I'd like to use this during development time to test some aspects of my wicket components. regards, seb - 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
Re: Wicket Serialization
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 is that e.g. the wicketstuff wicket-push projects keeps references to component instances in singleton services, e.g. the TimerPushService. Modifications on these components between requests only work as long wicket will reuse the same object instances on the next request. Since an HTTP session may be serialized by an app server between requests based an some 2nd level caching strategy it is important to simulate this to detect code that relies on specific object references and thus may break in such a case. seb On 01.10.2010 16:43, Igor Vaynberg wrote: wicket already tests serialization for you in dev mode -igor On Fri, Oct 1, 2010 at 5:37 AM, Sebastiannospam...@gmx.net 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 instances between requests in memory? I'd like to use this during development time to test some aspects of my wicket components. regards, seb - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Serialization
sounds wrong, no one should be keeping references to components -igor On Fri, Oct 1, 2010 at 3:32 PM, Sebastian nospam...@gmx.net wrote: 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 is that e.g. the wicketstuff wicket-push projects keeps references to component instances in singleton services, e.g. the TimerPushService. Modifications on these components between requests only work as long wicket will reuse the same object instances on the next request. Since an HTTP session may be serialized by an app server between requests based an some 2nd level caching strategy it is important to simulate this to detect code that relies on specific object references and thus may break in such a case. seb On 01.10.2010 16:43, Igor Vaynberg wrote: wicket already tests serialization for you in dev mode -igor On Fri, Oct 1, 2010 at 5:37 AM, Sebastiannospam...@gmx.net 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 instances between requests in memory? I'd like to use this during development time to test some aspects of my wicket components. regards, seb - 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 - 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
Re: Wicket Serialization
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);
backendService.doStuff(new ProgressListener() {
public void onEventChange(final Event event) {
if (pushTarget.isConnected()) {
label.setDefaultModelObject(event.message);
pushTarget.addComponent(label);
pushTarget.trigger();
}
}
= this will work as long as the current page does not get deserialized
between request. the backendService gets the listener object which in
turn has a reference to the label. as long as one can not enforce during
dev time that pages are really deserialized you have no really chance to
encounter the problem and thus fix it.
On 02.10.2010 00:40, Igor Vaynberg wrote:
sounds wrong, no one should be keeping references to components
-igor
On Fri, Oct 1, 2010 at 3:32 PM, Sebastiannospam...@gmx.net wrote:
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 is that e.g. the wicketstuff wicket-push
projects keeps references to component instances in singleton services, e.g.
the TimerPushService. Modifications on these components between requests
only work as long wicket will reuse the same object instances on the next
request. Since an HTTP session may be serialized by an app server between
requests based an some 2nd level caching strategy it is important to
simulate this to detect code that relies on specific object references and
thus may break in such a case.
seb
On 01.10.2010 16:43, Igor Vaynberg wrote:
wicket already tests serialization for you in dev mode
-igor
On Fri, Oct 1, 2010 at 5:37 AM, Sebastiannospam...@gmx.netwrote:
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.
regards,
seb
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
wicket serialization problem of guice proxies
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 are
themselves injected in Wicket pages.
As these classes are injected in Wicket, Wicket tries to serialize them as
well.
For example I have the class PoiLoader that is injected in a Wicket page.
@Singleton
public class PoiLoader {
private MultimapType, Poi poisRelatedToSpecificTouristType =
ArrayListMultimap.create();
protected IVectorDao daoVector;
private WorkManager workManager;
private MapResource, Poi pois = Maps.newHashMap();
}
In this setting, none of the fields can be serialized and throw an - Error
serializing object class ecgroup.web.pages.RecommenderPage [object=[Page
class = ecgroup.web.pages.RecommenderPage, id = 1, version = 0]]
org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException
.
I need the Warp Persist Workmanager in order to do some data loading /
initialization during Wicket startup. How can I tackle the serialization
problems?
Thanks a lot,
Chris
Re: wicket serialization problem of guice proxies
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 chris...@gmx.at wrote:
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 are
themselves injected in Wicket pages.
As these classes are injected in Wicket, Wicket tries to serialize them as
well.
For example I have the class PoiLoader that is injected in a Wicket page.
@Singleton
public class PoiLoader {
private MultimapType, Poi poisRelatedToSpecificTouristType =
ArrayListMultimap.create();
protected IVectorDao daoVector;
private WorkManager workManager;
private MapResource, Poi pois = Maps.newHashMap();
}
In this setting, none of the fields can be serialized and throw an - Error
serializing object class ecgroup.web.pages.RecommenderPage [object=[Page
class = ecgroup.web.pages.RecommenderPage, id = 1, version = 0]]
org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException
.
I need the Warp Persist Workmanager in order to do some data loading /
initialization during Wicket startup. How can I tackle the serialization
problems?
Thanks a lot,
Chris
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket serialization problem of guice proxies
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 some business logic. Those classes are
themselves injected in Wicket pages.
we use a helper class with
public static void injectMembers(final Object o)
{
Application application = Application.get();
Assert.isNotNull(application, Application is not attached);
Injector injector = getInjector(application);
new GuiceComponentInjector(application, injector).inject(o);
}
to inject into arbritary objects that end up in wicket space.
cu uwe
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Questions about how wicket serialization works
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 changed to: Cache-Control: no-cache, no-store, max-age=0, must-revalidate in org.apache.wicket.markup.html.WebPage.setHeaders(WebResponse) should i open a JIRA? davidqz wrote: My understanding is that when a page is refreshed, each Wicket componet on a page calls its getObject to update content. Does the Back button get the getObject method called too? -- View this message in context: http://old.nabble.com/301-redirect-tp27642826p27684063.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Questions about how wicket serialization works
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 defaults (by overriding setHeaders) for cases where another setting is more appropriate. Regards, Erik. kellerautomat wrote: 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 changed to: Cache-Control: no-cache, no-store, max-age=0, must-revalidate in org.apache.wicket.markup.html.WebPage.setHeaders(WebResponse) should i open a JIRA? -- Send from my SMTP compliant software Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Questions about how wicket serialization works
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 Wicket stores all the page content (markup plus Wicket-inserted content) sent to the the browser? I did an experiement in which there are two clock pages with dynamtic models (same java class and markup, but differnet class/file names). Clicking on a link goes to the second clock page. When I click IE Back button to go back to the first clock page, it always shows the current date/time. How so? Why not showing the previous date/time when the first clock page was loaded? My understanding is that when a page is refreshed, each Wicket componet on a page calls its getObject to update content. Does the Back button get the getObject method called too? What did I miss? Thanks, David - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Questions about how wicket serialization works
Erik, Thanks so much for reply to my questions. No, only the serialized form of the page hierarchy is stored. What do you exactly mean? WiA mentions three things: 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? Regards, David --- On Sun, 2/21/10, Erik van Oosten e.vanoos...@grons.nl wrote: From: Erik van Oosten e.vanoos...@grons.nl Subject: Re: Questions about how wicket serialization works To: users@wicket.apache.org Date: Sunday, February 21, 2010, 3:30 PM 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. Does Wicket stores the page means Wicket stores all the page content (markup plus Wicket-inserted content) sent to the the browser? No, only the serialized form of the page hierarchy is stored. From this all other content can be reloaded (note: markup is only read once and cached when in production mode). I did an experiement in which there are two clock pages with dynamtic models (same java class and markup, but differnet class/file names). Clicking on a link goes to the second clock page. When I click IE Back button to go back to the first clock page, it always shows the current date/time. How so? Why not showing the previous date/time when the first clock page was loaded? When you press the back button, you'll see whatever the browser has cached. My understanding is that when a page is refreshed, each Wicket componet on a page calls its getObject to update content. Does the Back button get the getObject method called too? After using the back button, reload the page, and you'll get the re-rendered content. What did I miss? Thanks, David Regards, Erik. -- Send from my SMTP compliant software Erik van Oosten http://day-to-day-stuff.blogspot.com/ - 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
Re: Questions about how wicket serialization works
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 they are referenced by the components. Eelco - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Questions about how wicket serialization works
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. Does Wicket stores the page means Wicket stores all the page content (markup plus Wicket-inserted content) sent to the the browser? No, only the serialized form of the page hierarchy is stored. From this all other content can be reloaded (note: markup is only read once and cached when in production mode). I did an experiement in which there are two clock pages with dynamtic models (same java class and markup, but differnet class/file names). Clicking on a link goes to the second clock page. When I click IE Back button to go back to the first clock page, it always shows the current date/time. How so? Why not showing the previous date/time when the first clock page was loaded? When you press the back button, you'll see whatever the browser has cached. My understanding is that when a page is refreshed, each Wicket componet on a page calls its getObject to update content. Does the Back button get the getObject method called too? After using the back button, reload the page, and you'll get the re-rendered content. What did I miss? Thanks, David Regards, Erik. -- Send from my SMTP compliant software Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
hibernate lazy loading byte code instrumentation and wicket serialization
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 ?
Re: hibernate lazy loading byte code instrumentation and wicket serialization
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 fachh...@gmail.com wrote: 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 wondering byte 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
Re: Wicket serialization problems for OSGi users
Hi David, Nice post! Just one question why not use buddy class-loading techniques to solve serialization problem? To me this is the same kind of problem you encounter when you have a basic bundle handling Hibernate persistence and you want Hibernate to load classes from a bundle containing your entities. Or am I missing something? Best, Ernesto David Leangen-8 wrote: 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 - 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/Wicket-serialization-problems-for-OSGi-users-tp22653816p22655758.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket serialization problems for OSGi users
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 getting anywhere yet. In any case, I am still pondering over whether or not the framework should even directly serialize those private classes... Haven't yet come to any conclusions. Cheers, =David - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket serialization problems for OSGi users
Hi David, Thank for your answer! Yes, your are right buddy class loading is Equinox proprietary. For me that's not a problem because I tied myself to use equinox. I did so because if you want to deploy in a traditional application sever you will have to use a bridge approach and equinox already provide that bridge. I though the standard already provided a something similar to buddy class-loading (dynamic imports?), or at least that was the answer some-one gave to me on the equinox list. I haven't had the time to check the details myself. For me, buddy-class loading works just fine and I didn't bother too much with the philosophical implications of this. I also need the same trick for things like loading entities, quartz jobs, etc. Cheers, Ernesto David Leangen-8 wrote: 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 getting anywhere yet. In any case, I am still pondering over whether or not the framework should even directly serialize those private classes... Haven't yet come to any conclusions. Cheers, =David - 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/Wicket-serialization-problems-for-OSGi-users-tp22653816p22657119.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Wicket serialization problems for OSGi users
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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
