passing 0 instead of -1 is definitely not the solution. This can
result in wrong page version set to other page references. I wish you
could provide a quickstart that reproduces the problem. It looks like
a bug in wicket but so far I'm not able to reproduce this behavior.
-Matej
On Fri, Apr 4, 2008 at 9:01 PM, Daniel Wu <[EMAIL PROTECTED]> wrote:
> I think I've found the solution for my StreamCorruptedException problem.
> Inside the org.apache.wicket.Page, there is a constant LATEST_VERSION which
> value is -1. In my application, the versionNumber passed as parameter to
> the method getVersion(final int versionNumber) inside Page is never -1, the
> initial versionNumber of a page is always 0. When this versionNumber is
> different from 0, the versionManager object inside Page is not null, so the
> flow goes to the else block inside the getVersion() method.
>
> If LATEST_VERSION is -1, the flow of my application is always going to the
> if block below, never to else block, as my versionNumber is always >= 0, so
> depending on the versionNumber, no page will be recovered, which was leading
> to the StreamCorruptedException, maybe because wicket was trying to
> de-serialize the wrong version of my page.
>
> if (versionNumber != LATEST_VERSION) {
> page = versionManager.getVersion(versionNumber);
> }
> else {
> page = versionManager.getVersion(getCurrentVersionNumber());
> }
>
> I've changed LATEST_VERSION value to 0, and now my application works
> perfectly. Are these assumptions correct? Does anytime versionNumber assumes
> the -1 value?
>
>
>
> On Thu, Apr 3, 2008 at 8:43 PM, Daniel Wu <[EMAIL PROTECTED]> wrote:
>
> > I debugged my application and it really doesn't have a
> > ClassNotFoundException eaten by ObjectInputStream. I compared the flow of
> > two screens of my application, one that works and another that doesn't:
> >
> > 1) The line 298 of SecondLevelCacheSessionStore =>
> > getLastPage().getVersion(versionNumber) is returning the correct page,
> > because inside the getVersion() method, the versionManager object is null.
> > In this case, the screen that I'm testing works perfectly.
> >
> > 2) For the screen that throws the StackOverFlow and
> > StreamCorruptedException, for some reason the versionManager object is not
> > null, and it returns a null page object.
> >
> > Another strange thing is that after the line 393 of Objects.java => return
> > ois.readObject(); => while debugging it using Eclipse, after this method
> > call the flow goes straight to the line 363 of AbstractPageStore.java,
> > without entering the finally block. So, an infinite loop starts, causing
> the
> > StackOverflow.
> >
> > During the tab switch of the screen that works, the line 393 of
> > Objects.java is never reached, meaning that this screen was not serialized,
> > right? This code is only reached during a tab switch of the screen that
> > throws StackOverFlow exception.
> >
> > What defines if a page should be serialized/deserialized? Does anyone know
> > what could be causing these problems?
> >
> >
> > On Wed, Apr 2, 2008 at 7:28 PM, Daniel Stoch <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Hi,
> > >
> > > It seems that this could be an OSGi related issue. We have the similar
> > > problem in our applications.
> > > You can look at the thread: Wicket + OSGI + Session (november 2007).
> > > Then Sebastiaan gave me a tip that this can be ClassNotFoundException:
> > >
> > > "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)."
> > >
> > >
> > > Inside OSGI environment each bundle has its own class loader, so this
> > > could leeds to problem when you try to use in your app a class defined in
> > > another bundle.
> > > I've solved this problem by implementing my own IClassResolver. The
> > > default Wicket DefaultClassResolver is a final class, so we must make a
> copy
> > > of it and make a little change at the end of resolveClass method.
> > >
> > > The default implementation (DefaultClassResolver):
> > >
> > > synchronized (classes)
> > > {
> > > ClassLoader loader =
> > > Thread.currentThread().getContextClassLoader();
> > > if (loader == null)
> > > {
> > > loader =
> > > DefaultClassResolver.class.getClassLoader();
> > > }
> > > clazz = loader.loadClass(classname);
> > > }
> > >
> > > When there is a ClassLoader attached to the current thread as context
> > > class loader, then Wicket uses it. The problem is under OSGi, that the
> > > related class (with classname) can be located inside another bundle and
> can
> > > be loaded by another class loader, not this from current thread. So
> > > DefaultClassResolver fails to find this class. The solution is to try in
> > > such situation use the class loader which loads DefaultClassResolver
> class
> > > (= which loads all Wicket classes). In our CustomClassResolver this block
> > > was changed to something like this:
> > >
> > > synchronized (classes) {
> > > ClassLoader loader =
> > > Thread.currentThread().getContextClassLoader();
> > > if (loader == null) {
> > > loader =
> > > DefaultClassResolver.class.getClassLoader();
> > > clazz = loader.loadClass(classname);
> > > } else {
> > > try {
> > > clazz = loader.loadClass(classname);
> > > } catch (ClassNotFoundException e) {
> > > loader =
> > > DefaultClassResolver.class.getClassLoader();
> > > clazz = loader.loadClass(classname);
> > > }
> > > }
> > > }
> > >
> > > Then in your Application class init() method add the following line:
> > > getApplicationSettings().setClassResolver(new CustomClassResolver());
> > >
> > > But there is a one assumption, that bundle with Wicket classes (you
> > > probably have a Wicket bundled somehow in your app, don't you? :)),
> should
> > > have a dynamic import for all classes which can be located in many
> different
> > > bundles:
> > > DynamicImport-Package: *
> > >
> > > Maybe such change could be done in Wicket core (in DefaultClassResolver
> > > class)?
> > >
> > > --
> > > Daniel Stoch
> > >
> > >
> > > On 2008-03-29, at 22:22, Daniel Wu wrote:
> > >
> > > >
> > > > I've updated my wicket application to Wicket 1.3.2, but now, when I
> > > > try to
> > > > switch between my application tabs (my tabs extend
> > > > org.apache.wicket.extensions.markup.html.tabs.AbstractTab) I'm getting
> > > > this
> > > > error:
> > > >
> > > > ERROR RequestCycle () - Could not deserialize object using
> > > >
> > > >
> `org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory`
> > > > object factory
> > > > java.lang.RuntimeException: Could not deserialize object using
> > > >
> > > >
> `org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory`
> > > > object factory
> > > > at
> > > > org.apache.wicket.util.lang.Objects.byteArrayToObject(Objects.java:411)
> > > > at
> > > >
> > > >
> org.apache.wicket.protocol.http.pagestore.AbstractPageStore.deserializePage(AbstractPageStore.java:228)
> > > > at
> > > >
> > > >
> org.apache.wicket.protocol.http.pagestore.DiskPageStore.getPage(DiskPageStore.java:706)
> > > > at
> > > >
> > > >
> org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.get(SecondLevelCacheSessionStore.java:311)
> > > > at org.apache.wicket.Session.getPage(Session.java:751)
> > > > ...
> > > > Caused by: java.io.StreamCorruptedException: invalid type code: 29
> > > > at java.io.ObjectInputStream.readObject0(Unknown Source)
> > > > at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
> > > > at java.io.ObjectInputStream.readSerialData(Unknown Source)
> > > > at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
> > > > at java.io.ObjectInputStream.readObject0(Unknown Source)
> > > > at java.io.ObjectInputStream.readObject(Unknown Source)
> > > > at
> > > > org.apache.wicket.util.lang.Objects.byteArrayToObject(Objects.java:393)
> > > >
> > > > I've already downloaded and used the latest wicket 1.3 snapshot, which
> > > > was
> > > > suggested to me here: https://issues.apache.org/jira/browse/WICKET-1445
> > > > ,
> > > > but I'm still having this error.
> > > >
> > > > I'm still using an old release of wicket-extensions. Since I updated
> > > > to
> > > > wicket 1.3, I'm also having this warning:
> > > >
> > > > WARN AbstractTextComponent () - Couldn't resolve model type of
> > > > Model:classname=[...], please set the type yourself.
> > > >
> > > > Could any of these be related to the Serialization error? Does anyone
> > > > have
> > > > any idea of what is causing it?
> > > >
> > > > Daniel
> > > >
> > > > --
> > > > View this message in context: http://www.nabble.com/
> > > >
> java.io.StreamCorruptedException%3A-invalid-type-code%3A-29-tp16374745p16374745.html
> > > > Sent from the Wicket - User mailing list archive at Nabble.com.
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>
--
Resizable and reorderable grid components.
http://www.inmethod.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
