Hi,
Thank you for your suggestion. I have no time to look at this earlier,
but Wicket 1.3.0-rc2 is out now and after upgrade the error message I
have has changed to:
java.lang.IllegalStateException: spring application context locator
returned null
at
org.apache.wicket.spring.SpringBeanLocator.getSpringContext(SpringBeanLocator.java:180)
at
org.apache.wicket.spring.SpringBeanLocator.locateProxyTarget(SpringBeanLocator.java:162)
at
org.apache.wicket.proxy.LazyInitProxyFactory$JdkHandler.invoke(LazyInitProxyFactory.java:412)
at org.apache.wicket.proxy.$Proxy82.getAction(Unknown Source)
So it seems there is a problem with deserialization of spring
application context locator. I have used my own locator implementation
(OsgiSpringContextLocator). There is one locator created for each
application context and there was a map of locators and app contexts.
Locator reference was the key in this map (very, very bad thing :)):
private static Map<OsgiSpringContextLocator, ApplicationContext>
applicationContexts = new HashMap<OsgiSpringContextLocator,
ApplicationContext>();
I have changed this now to:
public class OsgiSpringContextLocator implements ISpringContextLocator {
private static Map<Integer, ApplicationContext> applicationContexts
= new HashMap<Integer, ApplicationContext>();
private static int appContextCounter = 0;
private Integer appContextId;
OsgiSpringContextLocator(ApplicationContext applicationContext) {
appContextCounter++;
appContextId = new Integer(appContextCounter);
applicationContexts.put(appContextId, applicationContext);
}
public ApplicationContext getSpringContext() {
ApplicationContext result = applicationContexts.get(appContextId);
return result;
}
}
So each appCtxt has its own unique index (appContextId) which is
stored in locator, so locator is able to find a proper appCtxt by this
id (even after deserialization)
This is a quick fix that works, maybe in the future I will implement
this in a more elegant way ;).
Daniel
On Nov 26, 2007 3:33 PM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
> Yep, I've seen though before.
>
> It's probably a ClassNotFoundException on deserialization which gets
> eaten by ObjectInputStream (there's a bug report at Sun for this). To be
> sure you can debug trapping on ClassNotFoundException (caught and
> uncaught) when this problem occurs.
>
> However, since it's in a page you can easily fix this one: either
> upgrade to trunk and implement your own IClassResolver and register it
> with the application, or write your own IObjectStreamFactory
> implementation and register it with the Objects class.
>
> In either case, have a look at the DefaultObjectStreamFactory to see how
> to write a hook to look up classes in an ObjectInputStream
> implementation (resolveClass method).
>
> Regards,
> Sebastiaan
>
>
> Daniel Stoch wrote:
> > Hi,
> >
> > You have written: "This causes problems with session
> > serialization/deserialization in an OSGI environment." I don't know is
> > it a related problem, but I have the following situation (of course
> > app is running in OSGi environment):
> > I have a page with DataView displaying products list with images. Each
> > product has AjaxLink, when I click this link product should be
> > selected (highlighted). But sometimes after click I have an error with
> > serialization:
> >
> > Root cause:
> > java.io.StreamCorruptedException: invalid type code: 01
> > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1356)
> > at
> > java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1945)
> > at
> > java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1869)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
