wicket/databinder bug? No session currently bound...

2009-01-19 Thread rmorrisey

Short story:
I think I found a wicket or databinder bug.

I'm getting an error when rehydrating a databinder page from the
DiskPageStore. I am posting it on both the wicket mailing list and the
databinder forum, because I'm not sure which it belongs to.

Long story:

Let me give the error and the (abbreviated) stack trace, and explain what I
found from debugging:

ERROR [2009-01-19 15:09:02,040] RequestCycle.logRuntimeException():1435 - No
session currently bound to execution context
org.hibernate.HibernateException: No session currently bound to execution
context
at
org.hibernate.context.ManagedSessionContext.currentSession(ManagedSessionContext.java:50)
at
org.hibernate.impl.SessionFactoryImpl.getCurrentSession(SessionFactoryImpl.java:544)
at
net.databinder.DataStaticService.getHibernateSession(DataStaticService.java:77)
at
net.databinder.models.HibernateObjectModel.load(HibernateObjectModel.java:264)
at
net.databinder.models.LoadableWritableModel.getObject(LoadableWritableModel.java:53)
at
com.csc.aims.wicket.models.AbstractObjectModel.getObject(AbstractObjectModel.java:57)
at
com.csc.aims.wicket.models.AbstractObjectModel.getObject(AbstractObjectModel.java:1)
at
net.databinder.models.HibernateObjectModel.hashCode(HibernateObjectModel.java:353)
at java.util.HashMap.hash(HashMap.java:264)
at java.util.HashMap.putForCreate(HashMap.java:407)
at java.util.HashMap.readObject(HashMap.java:1014)
at sun.reflect.GeneratedMethodAccessor215.invoke(Unknown Source)
...
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)
at
org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:448)
at
org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1229)
...

The gist is that deserializing the page causes HOM's hashCode() to be
called, which loads the model object. This happens during the RESOLVE_TARGET
step of request cycle processing, before the response target and page
information are set! Databinder's
DataConversationRequestCycle.dataSessionRequested(Object) is not able to get
the page, because the page is still being loaded. It returns from
DataConversationRequestCycle ln. 82 without ever calling
openHibernateSession. The HOM then tries to load using the existing session
and fails.

In my particular scenario, I am triggering two ajax events, then submitting
the page before they finish. The first ajax event complets, then the submit
- then the error is thrown by the second ajax event, before it gets to the
process and respond step.

Our wicket version is 1.3 snapshot revision 694703 (close to 1.3.5?) with
minor patches. We are using databinder 1.1.2.

-- 
View this message in context: 
http://www.nabble.com/wicket-databinder-bug--No-session-currently-bound...-tp21551210p21551210.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: Closing ModalWindow using javascript:window.close()

2008-10-09 Thread rmorrisey

RG,

I think that you can use top.window.close() if you are trying to close the
entire page. window.close() probably isn't working because ModalWindow uses
an IFRAME if I remember correctly.

If you want to close only the ModalWindow and not the entire window, I would
take a look at how it's done in ModalWindow.closeCurrent(AjaxRequestTarget).

HTH,
Russell


nanotech wrote:
 
 Hi,
 
 In my project there is a modal window.In event of WicketRuntimeException
 it goes to custom Internal Error page. That Page has a button which
 overrides onComponetTag method and  attaches javascript:window.close()
 with onclick event. So that user can close the modal window.(I don't
 want user to use [X] button in right top corner so I have hidden that
 button through CSS). The problem is this [javascript:window.close() ] does
 not close modal window but it does work in regaular page.(i.e. if
 execption occurs on a regualr page then after the request is forwarded to
 Custom Internal error page then user is able to click on close button and
 the browser window closes.)
 
 Can some one please suggest me how to achieve this is modal window.
 
 Thanks,
 RG   
 

-- 
View this message in context: 
http://www.nabble.com/Closing-ModalWindow-using-javascript%3Awindow.close%28%29-tp19860774p19908897.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]



Patch for ModalWindow?

2008-10-06 Thread rmorrisey

wicket 1.3.4
I have a small addition to ModalWindow that I think would be useful as a
patch. Please tell me what you think.

The idea is hook in an IAjaxCallDecorator on the WindowClosedCallback
request (before WindowClosedCallback.onClose() finished and repaints the
page containing the ModalWindow). It does this by letting the user set an
IAjaxCallDecorator on the ModalWindow itself, which is then used when the
WindowClosedBehavior is rendered.

In our system we use a ModalWindow to pick items that will be displayed on
the page. The ModalWindow takes a couple of seconds to repaint the
containing page after it is closed (this is the ajax request where
WindowClosedCallback.onClose() is called). The call decorator can do
something before WindowClosedCallback.onClose() finishes, like displaying a
wicket ajax indicator icon.

http://www.nabble.com/file/p19849489/ModalWindow.java ModalWindow.java 

-- 
View this message in context: 
http://www.nabble.com/Patch-for-ModalWindow--tp19849489p19849489.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]



Sequence of wicket (ajax) requests

2008-10-01 Thread rmorrisey

Is it possible for two request cycles to be running on the server
concurrently against the same page/wicket session (including ajax requests)?
I was thinking that wicket forces the requests to be processed sequentially
(so that the two request cycles can't be handled at the same time), but it
seems like this is not the case
-- 
View this message in context: 
http://www.nabble.com/Sequence-of-wicket-%28ajax%29-requests-tp19763696p19763696.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]



Re: Sequence of wicket (ajax) requests

2008-10-01 Thread rmorrisey

Igor, Matej, thanks for the replies -

I would like to guarantee that only one request cycle is running at a time
(for a given wicket session). Is it possible for me to tweak wicket to
expanded the part that is synchronized to encompass the RequestCycle's
onEndRequest?


igor.vaynberg wrote:
 
 there can be two request cycles running, sure
 
 it is only the part that accesses and mutates the page is synchronized
 for higher throughput
 
 -igor
 
 On Wed, Oct 1, 2008 at 9:02 AM, rmorrisey [EMAIL PROTECTED] wrote:

 Is it possible for two request cycles to be running on the server
 concurrently against the same page/wicket session (including ajax
 requests)?
 I was thinking that wicket forces the requests to be processed
 sequentially
 (so that the two request cycles can't be handled at the same time), but
 it
 seems like this is not the case
 --
 View this message in context:
 http://www.nabble.com/Sequence-of-wicket-%28ajax%29-requests-tp19763696p19763696.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]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Sequence-of-wicket-%28ajax%29-requests-tp19763696p19764365.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]



Re: Sequence of wicket (ajax) requests

2008-10-01 Thread rmorrisey

Igor,

I was thinking about doing it with onBeginRequest(), something like:
AIMSSession session = (AIMSSession)getSession();
synchronized (session) {
try {
//Wait for my turn
while (session.hasActiveRequest()) {
session.wait();
}
//My turn
session.setActiveRequest(true);
}
catch (InterruptedException e) {
getLog().error(Interrupted waiting for 
request synch, e);
}
}

and in onEndRequest:
AIMSSession session = (AIMSSession)getSession();
synchronized (session) {
session.setActiveRequest(false);
session.notify();
}

however I got worried that if there is some error and onEndRequest is never
called, my thread will be stuck endlessly. I looked at how wicket
synchronizes the mutator parts; it looks like it does:
RequestCycle.steps()
   RequestCycle.step()
WebRequestCycleProcessor.resolve()
  synchronized(requestCycle.getSession())
  ...
   RequestCycle.detach()
RequestCycle.onEndRequest()

I thought that if I could promote the synchronized() block up to
RequestCycle.steps() it would be the safest solution. Does this seem like it
makes sense?:

private final void steps()
{
synchronized (getSession())
{
try/finally...
}
}

I am testing it out (by placing my custom RequestCycle.java earlier in my
classpath) and it seems to work OK. Can you think of any issues with this
approach? and if not is it possible to open up the final or provide some
other mechanism so that I don't have to duplicate RequestCycle in full?


igor.vaynberg wrote:
 
 sure, in onbeginrequest of your request cycle sync on session
 
 -igor
 
 On Wed, Oct 1, 2008 at 9:34 AM, rmorrisey [EMAIL PROTECTED] wrote:

 Igor, Matej, thanks for the replies -

 I would like to guarantee that only one request cycle is running at a
 time
 (for a given wicket session). Is it possible for me to tweak wicket to
 expanded the part that is synchronized to encompass the RequestCycle's
 onEndRequest?


 igor.vaynberg wrote:

 there can be two request cycles running, sure

 it is only the part that accesses and mutates the page is synchronized
 for higher throughput

 -igor

 On Wed, Oct 1, 2008 at 9:02 AM, rmorrisey [EMAIL PROTECTED] wrote:

 Is it possible for two request cycles to be running on the server
 concurrently against the same page/wicket session (including ajax
 requests)?
 I was thinking that wicket forces the requests to be processed
 sequentially
 (so that the two request cycles can't be handled at the same time), but
 it
 seems like this is not the case
 --
 View this message in context:
 http://www.nabble.com/Sequence-of-wicket-%28ajax%29-requests-tp19763696p19763696.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]




 --
 View this message in context:
 http://www.nabble.com/Sequence-of-wicket-%28ajax%29-requests-tp19763696p19764365.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]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Sequence-of-wicket-%28ajax%29-requests-tp19763696p19767653.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]



Re: session jumping?

2008-08-22 Thread rmorrisey

I'm working on the same project as Chuck, trying to help debug the session
jumping. Here's a little more information:
-Upgrading to 1.3.4 did not fix the issue
-The session ID seems to be constant according to whichever PC initiated the
request
-A few example cases where we've seen the error:
1)
Server is started
A logs in
B logs in (while A is logging in/loading homepage)  B sees A's homepage

2)
Server is started
A logs in
B logs in
A and B hit a couple different pages simultaneously
B logs out (while A is loading a slow lazy-loading page)
A clicks Logout   //logout link fires setResponsePage(Page, parameters)
A gets a page expired error instead of logging out normally and returning to
login screen

It's not easy to reproduce the problem consistently, but it seems to happen
relatively often with multiple concurrent users from different PCs.

We will keep trying!
Thanks,
Russell


Johan Compagner wrote:
 
 do you really see the same httpsession instance?
 or just the wicket session instance?
 
 Can you print out the session ids?
 
 But first upgrade to 1.3.4:
 
 The Apache Wicket team is proud to announce the availability of the fourth
 maintenance release: Apache Wicket 1.3.4. A lot of bugs have been squashed
 and
 several improvements implemented. Two noteworthy bugs have been squashed:
 
- cross session leakage due to a dangling thread local in exceptional
circumstances
- memory leak in localizer (WICKET-1667)
 
 johan
 
 
 
 On Fri, Aug 15, 2008 at 4:29 PM, ChuckDeal [EMAIL PROTECTED] wrote:
 

 Wicket 1.3.3

 I am going to attempt to describe what I have experienced in the hopes
 that
 a core dev can point me in the right direction.

 The background:  We previously had a complete JSP system in place.  We
 decided to use the Wicket framework, but could not convert the entire
 system
 at once, so the foundation is now wicket with a few of its pieces in
 Wicket,
 but much of the legacy system is accessed thorugh a technique the Al Maw
 posted whereby the legacy url is captured then redirected into a Wicket
 page
 hosting an IFrame, which then loads the original URL.  All of the pure
 Wicket pages are mounted using the HybridUrlCodingStrategy, except for
 the
 Wicket page that acts as the legacy interface, which is the standard
 BookmarkablePageRequestTargetUCS.  We use the wicket-auth module for
 authentication (with Databinder), so the user (user_id) is stored in the
 WebSession.

 The problem:  It seems that when two users enter the system, there is a
 scenario where the second user becomes the first user.  Both users
 login
 through a Wicket Page, which deposits them on a wicket page.  If user1 go
 to
 a legacy URL, then the next wicket page that user2 visits changes to
 user1's
 session.  This can be observed because we display the logged in user on
 each
 page and the name changes.

 My working theory is that it has something to do with loading a
 serialized
 page from disk.  We are using JDK serialization and the std
 SecondLevelCache/DiskPageStore session store.  Can a dev verify that the
 Session is serialized with a Page?  How on earth is one user loading
 another's serialized Page from disk?  Has anyone experienced this?  How
 can
 I prevent this?  Obviously, this is a serious issue for us because this
 defeats user security.

 Chuck
 --
 View this message in context:
 http://www.nabble.com/session-%22jumping%22--tp18999615p18999615.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]


 
 

-- 
View this message in context: 
http://www.nabble.com/session-%22jumping%22--tp18999615p19117723.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]