I've experienced the exact same problem. You'll get this a lot when working
with ajax components. I've also reported this issue to the wicket 2 jira. If
you add if(versionManger != null) prior to the versionManager call you'll be
fine but that's probably an ugly hack. But it seem to work til they'
normally ajax shouldn't make a new version but in 1.3 we have also an ajax
version number beside the page version number.
But that the moment page.versionManager is set to null the flag should be
false at that time.
But if you have a quick test that exposes this null pointer please make an
issue
Line #601 in Page.java is the only place where versionManager gets set
back to null from what I can tell..
// If we went all the way back to the
original page
if (page != null &&
page.getCurrentVersionNumber() == 0)
this is very strange because as far as i know that flag is only set inside
that if:
if (!getFlag(FLAG_NEW_VERSION)) <-- this may return false?
{
// if we have no version manager
if (versionManager == null)
{
I ran this through my debugger, and my assumptions where correct. The
FLAG_NEW_VERSION flag is set while versionManager is null. I'm, looking
around and can't figure out the exact conditions that would cause this.
Any thoughts?
Aaron
Aaron Hiniker wrote:
> Yeah, I know. But I'm not messing wi
Yeah, I know. But I'm not messing with any versioning settings (this is
just out-of-the-box ajax components and the like), so really there
shouldn't be any of these issues, correct? Here's mayTrackChangesFor()
method, I've added a comment regarding my thoughts as to what is causing
this:
pri
But if it is null then you could have a problem that things should be
versioned but arent..
So adding null checks is not the fix.
johan
On 3/2/07, Aaron HIniker <[EMAIL PROTECTED]> wrote:
That's why I was pointing at mayTrackChangesFor().. I looked at the
method and I can't see a loophole,
That's why I was pointing at mayTrackChangesFor().. I looked at the
method and I can't see a loophole, but there must be one to generate an
NPE, correct?
When I implemented the not-null check, I noticed exceptions still being
thrown from 2 other methods (if you search Page.java for versionManager
That is because the mayTrackChangesFor() method should only return true
when it makes a version manager. Why is that not the case?
If that method returns true the version manager can't be null because the
version info must be tracked.
johan
On 3/1/07, Aaron Hiniker <[EMAIL PROTECTED]> wrote:
I pulled the latest from trunk. And I am getting this NPE:
16:30:14,543 ERROR [STDERR] java.lang.NullPointerException
16:30:14,544 ERROR [STDERR] at
wicket.Page.componentStateChanging(Page.java:327)
16:30:14,545 ERROR [STDERR] at
wicket.Component.addStateChange(Component.java:2553)
16:30:
it would be helpful to know the version
-igor
On 2/14/07, Aaron HIniker <[EMAIL PROTECTED]> wrote:
When doing an ajax update on a MarkupContainer containing a listview.. I
am replacing the listview model before the update:
java.lang.NullPointerException
at wicket.Page.componentStateC
On Wed, 14 Feb 2007, Aaron HIniker wrote:
> When doing an ajax update on a MarkupContainer containing a listview.. I
> am replacing the listview model before the update:
To update a ListView with ajax, I just manipulate its list
instead of replacing the whole model. To make removals work,
I recrea
I apologize if this gets sent twice.. my ISP smtp server is acting up.
When doing an ajax update on a MarkupContainer containing a listview.. I
am replacing the listview model before the update:
java.lang.NullPointerException
at wicket.Page.componentStateChanging(Page.java:327)
a
When doing an ajax update on a MarkupContainer containing a listview.. I
am replacing the listview model before the update:
java.lang.NullPointerException
at wicket.Page.componentStateChanging(Page.java:327)
at wicket.Component.addStateChange(Component.java:2551)
at wicket.
14 matches
Mail list logo
