You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Jean-Baptiste Quenot <jb...@apache.org> on 2007/02/22 15:37:14 UTC
Re: Serialization refactoring (Was: svn commit: r508062)
* ehillenius@apache.org:
> Author: ehillenius
> Date: Thu Feb 15 10:19:54 2007
> New Revision: 508062
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=508062
> Log:
>
> damnit Johan I told you NOT to turn this thing on by default! We
> just had a nice error on our production system. Thanks. DO NOT
> TURN THE FRIGGIN' THING ON PLEASE. Instead, just ask people
> (like me) to test and they will surely help out.
Dear Eelco,
Please mind your tone. Anyone depending on the current svn must
be prepared to live a dangerous life. For my projects, I maintain
a local patchset against an older Wicket snapshot, in order to
avoid regression issues, and only integrate a controlled set of
changes. With the code repository, it might happen that things
work one day and are broken the other day. Production systems
definitely don't like that.
That being said, I'm worried by the current refactoring WRT
serialization. When using latest SVN we have a lot of
NotSerializable errors logged in the console. And even when
launching the tests. And strangely enough that happens even
without the custom serialization (WicketObjectOutputStream).
With such refactorings, the hope to have Wicket 1.3 one day seems
to vanish. We discussed to release in January, now it will be at
least March. Why not do those refactorings in trunk, to be able
to release on a fixed schedule and honor the old saying « release
early, release often »?
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: Serialization refactoring (Was: svn commit: r508062)
Posted by Johan Compagner <jc...@gmail.com>.
jpq,
don;t worry about the shouting eelco's does (i don't)
But this is already discussed on the list and the consensus is that it
should be enabled by default in svn.
I will do that again when i finish the proxy problem. (already done for the
large part)
also error reporting is much better already (but can also be improved
ofcourse)
It now reports directly which field of which class it did go wrong:
Page.class->field->Class->field->Class->field (not serializable: Class)
so that should be already much better
If you get not serializeable errors in the log (with normal serialization)
then please look what
classes they are. Are you sure it is not just your own class?
If it is purely wicket (i know one, StringResponse that is or was? a bug
AlMaw?)
Also we have 2 heads at this time
2.0 and 1.3
Currently i think 1.3 is under much heavier development then 2.0.
Because it is a bit more used
And Converters and Validators of 2.0 is also a think people like to see in
1.3
so we also need to do that..
The nice thing is that 1.3 and 2.0 are then streamlined so the transaction
is much easier
johan
On 2/22/07, Jean-Baptiste Quenot <jb...@apache.org> wrote:
>
> * ehillenius@apache.org:
> > Author: ehillenius
> > Date: Thu Feb 15 10:19:54 2007
> > New Revision: 508062
> >
> > URL: http://svn.apache.org/viewvc?view=rev&rev=508062
> > Log:
> >
> > damnit Johan I told you NOT to turn this thing on by default! We
> > just had a nice error on our production system. Thanks. DO NOT
> > TURN THE FRIGGIN' THING ON PLEASE. Instead, just ask people
> > (like me) to test and they will surely help out.
>
> Dear Eelco,
>
> Please mind your tone. Anyone depending on the current svn must
> be prepared to live a dangerous life. For my projects, I maintain
> a local patchset against an older Wicket snapshot, in order to
> avoid regression issues, and only integrate a controlled set of
> changes. With the code repository, it might happen that things
> work one day and are broken the other day. Production systems
> definitely don't like that.
>
> That being said, I'm worried by the current refactoring WRT
> serialization. When using latest SVN we have a lot of
> NotSerializable errors logged in the console. And even when
> launching the tests. And strangely enough that happens even
> without the custom serialization (WicketObjectOutputStream).
>
> With such refactorings, the hope to have Wicket 1.3 one day seems
> to vanish. We discussed to release in January, now it will be at
> least March. Why not do those refactorings in trunk, to be able
> to release on a fixed schedule and honor the old saying «release
> early, release often»?
> --
> Jean-Baptiste Quenot
> aka John Banana Qwerty
> http://caraldi.com/jbq/
>
Re: Serialization refactoring (Was: svn commit: r508062)
Posted by Eelco Hillenius <ee...@gmail.com>.
> Please mind your tone.
I thought I was being relatively sweet :)
> Anyone depending on the current svn must
> be prepared to live a dangerous life.
True to some extend. But don't forget that as core committers we
*should* try to eat our own dogfood but at the same time, my employer
is not very happy with me/ us deploying versions of the app we're
working on with obvious problems in them. But my main grieve here is
that I was very much against turning it on, and told so twice, while
it was just turned on again without further discussion. In such cases
- if there are conflicting opinions - we should have a vote
immediately to have clear what the consensus is (though we should
never have votes just to nail someone's balls in public).
Eelco
Re: Serialization refactoring (Was: svn commit: r508062)
Posted by Igor Vaynberg <ig...@gmail.com>.
the biggest thing holding up the release are a few missing iclas, working
on that now.
-igor
On 2/22/07, Jean-Baptiste Quenot <jb...@apache.org> wrote:
>
> * ehillenius@apache.org:
> > Author: ehillenius
> > Date: Thu Feb 15 10:19:54 2007
> > New Revision: 508062
> >
> > URL: http://svn.apache.org/viewvc?view=rev&rev=508062
> > Log:
> >
> > damnit Johan I told you NOT to turn this thing on by default! We
> > just had a nice error on our production system. Thanks. DO NOT
> > TURN THE FRIGGIN' THING ON PLEASE. Instead, just ask people
> > (like me) to test and they will surely help out.
>
> Dear Eelco,
>
> Please mind your tone. Anyone depending on the current svn must
> be prepared to live a dangerous life. For my projects, I maintain
> a local patchset against an older Wicket snapshot, in order to
> avoid regression issues, and only integrate a controlled set of
> changes. With the code repository, it might happen that things
> work one day and are broken the other day. Production systems
> definitely don't like that.
>
> That being said, I'm worried by the current refactoring WRT
> serialization. When using latest SVN we have a lot of
> NotSerializable errors logged in the console. And even when
> launching the tests. And strangely enough that happens even
> without the custom serialization (WicketObjectOutputStream).
>
> With such refactorings, the hope to have Wicket 1.3 one day seems
> to vanish. We discussed to release in January, now it will be at
> least March. Why not do those refactorings in trunk, to be able
> to release on a fixed schedule and honor the old saying «release
> early, release often»?
> --
> Jean-Baptiste Quenot
> aka John Banana Qwerty
> http://caraldi.com/jbq/
>