Re: AjaxFormSubmitBehavior causes serialization issues inside onBeforeRender()
Thanks a lot Igor. That explains it all. I was able to fix it today by using visitChildren(ChildPanel.class, new IVisitorComponent()) instead of visitChildren( new IVisitorComponent()) I guess, else it tries to add teh behaviour to all objects up the hierarchy instead of restricting itself to only the ones on ChildPanel.class Thanks, Allgo -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/AjaxFormSubmitBehavior-causes-serialization-issues-inside-onBeforeRender-tp2328509p2329578.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
AjaxFormSubmitBehavior causes serialization issues inside onBeforeRender()
) at org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:392) at org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:615) at org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:538) at org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:615) at org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:538) at org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:615) at org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:538) at org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:392) at org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:615) at org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:538) at org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:392) at org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:615) at org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:538) at org.apache.wicket.util.io.SerializableChecker.writeObjectOverride(SerializableChecker.java:684) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:298) at org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory$2.writeObjectOverride(IObjectStreamFactory.java:129) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:298) at org.apache.wicket.util.lang.Objects.objectToByteArray(Objects.java:1124) at org.apache.wicket.protocol.http.pagestore.AbstractPageStore.serializePage(AbstractPageStore.java:203) at org.apache.wicket.protocol.http.pagestore.DiskPageStore.storePage(DiskPageStore.java:840) at org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.put(SecondLevelCacheSessionStore.java:332) at org.apache.wicket.Session.requestDetached(Session.java:1400) at org.apache.wicket.RequestCycle.detach(RequestCycle.java:1176) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1454) at org.apache.wicket.RequestCycle.request(RequestCycle.java:545) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:312) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) at java.lang.Thread.run(Thread.java:595) Caused by: java.io.NotSerializableException: com.mycompany.test.calendar.ChildPanel$7 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1375) However when I add the AjaxFormSubmitBehaviour to individual form components and comment out the onBeforeRender it works fine without any errors.. any clue guys? Cheers, Allgo -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/AjaxFormSubmitBehavior-causes-serialization-issues-inside-onBeforeRender-tp2328509p2328509.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
Extract DNS web-url from Wicket request
Hi all, I am trying to find a solution to the following situation - We have a server architecture where, all requests to say the url https://my-server-one.com first hits a Apache webserver in the front end. Apache then uses Mod-proxy to forward the request over a firewall to our internal server where a Wicket 1.3.7 application hosted in Jboss. say that server has an IP 192.168.100.100. What mod proxy in apache does is it redirects any request it gets for https://my-server-one.com to 192.168.100.100 over the default port 80. Now from within my application I am trying to retrieve the Http request object and try to extract out the actual DNS name i.e. my-server-one.com. However didnt have much success with it. Is it at all possible to do so? Or after a Apache redirect the request object actually loses the actual DNS url that the client had actually hit on the browser. Have tried getPath(), get Url() etc standard metods on the getRequest() object.. but in vain. Any one tried that before? The reason is we want to host 2 urls https://my-server-one.com and https://my-server-two.com and both should point to same internal application on 192.168.100.100. Now teh application should be intelligent enough to load different CSS files based on which url was tried. Please help and oblige. Thanks in advance! Allgo -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Extract-DNS-web-url-from-Wicket-request-tp2068948p2068948.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: Extract DNS web-url from Wicket request
Got the solution..
log.info(x-forwarded-host
-+getWebRequestCycle().getWebRequest().getHttpServletRequest().getHeader(x-forwarded-host));
if(getWebRequestCycle().getWebRequest().getHttpServletRequest().getHeader(x-forwarded-host).equals(my-server-one)){
add(HeaderContributor.forCss(ApplicationBasePage.class,
ServerOneApplication.css));
}
x-forwarded-host Header actually contains that information.
Thanks guys. Hopefully it will help someone later
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Extract-DNS-web-url-from-Wicket-request-tp2068948p2069072.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: Wicket session not threadsafe?
Hi,
The wicket version is 1.3. Sorry should have mentioned that.
As such the User A, after he logs on is getting assigned the Account object
of User B. And after soem logs we can see that User B had logged on a while
before. Hence that Accoutn object was definitely fetched a whiel before. I
did see a few threads which say Hibernate may eb a culprit but am not sure
thats the case here.
Please do let me know if you need any more info.
Thanks,
SSP
Martijn Dashorst wrote:
A wicket version number would be helpful...
Martijn
On Fri, Jan 8, 2010 at 12:17 PM, Soumya soumya_...@yahoo.co.in wrote:
Hi all,
I am fairly a newbie in wicket and would appreciate your help!
I
have a wicket application which are used on Live by more than 500
users. Now the problem which has arisen is - say User A logs on - he is
able to view details of User B. It has happened for different users and
I am trying to dig the real reason.
Here is my code details -
1) I use Hibernate to fetch 'Account' objects from backend passing on the
username/password.
2) I use
MyAppSession extends WebSession
{
private Account account;
public InboundSession(Request request)
{
super(request);
}
public void setAccount(Account account)
{
this.account = account;
}
public Account getAccount()
{
return account;
}
public boolean isUserLoggedIn()
{
return account !=null;
}
}
So
effectively I check if the Account object in session is null or not and
accordingly decide whether a user is logged in or not.
2) In Login class I pass on the username/password to HibernateAccountDao
and fetch the Account object.
Account account = accountDao.getAccount(username, password)
MyAppSession session = (MyAppSession )getSession();
session.setAccount(account);
setResponsePage(Home.class);
So effectively I fetch the accout object using hibernate and store it in
wicket session.
But I am not sure how these account objects are getting mixed up between
users.
Please can someone lead me to the route cause of the issue?
Thanks in advance!
SSP
The INTERNET now has a personality. YOURS! See your Yahoo! Homepage.
http://in.yahoo.com/
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://old.nabble.com/Wicket-session-not-threadsafe--tp27074491p27075050.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: Wicket session not threadsafe?
1.3.0-beta3 actually. Copied it from the Manifest file
Martijn Dashorst wrote:
1.3.0?
Martijn
On Fri, Jan 8, 2010 at 1:12 PM, allgo soumya_...@yahoo.co.in wrote:
Hi,
The wicket version is 1.3. Sorry should have mentioned that.
As such the User A, after he logs on is getting assigned the Account
object
of User B. And after soem logs we can see that User B had logged on a
while
before. Hence that Accoutn object was definitely fetched a whiel before.
I
did see a few threads which say Hibernate may eb a culprit but am not
sure
thats the case here.
Please do let me know if you need any more info.
Thanks,
SSP
Martijn Dashorst wrote:
A wicket version number would be helpful...
Martijn
On Fri, Jan 8, 2010 at 12:17 PM, Soumya soumya_...@yahoo.co.in wrote:
Hi all,
I am fairly a newbie in wicket and would appreciate your help!
I
have a wicket application which are used on Live by more than 500
users. Now the problem which has arisen is - say User A logs on - he is
able to view details of User B. It has happened for different users and
I am trying to dig the real reason.
Here is my code details -
1) I use Hibernate to fetch 'Account' objects from backend passing on
the
username/password.
2) I use
MyAppSession extends WebSession
{
private Account account;
public InboundSession(Request request)
{
super(request);
}
public void setAccount(Account account)
{
this.account = account;
}
public Account getAccount()
{
return account;
}
public boolean isUserLoggedIn()
{
return account !=null;
}
}
So
effectively I check if the Account object in session is null or not and
accordingly decide whether a user is logged in or not.
2) In Login class I pass on the username/password to
HibernateAccountDao
and fetch the Account object.
Account account = accountDao.getAccount(username, password)
MyAppSession session = (MyAppSession )getSession();
session.setAccount(account);
setResponsePage(Home.class);
So effectively I fetch the accout object using hibernate and store it
in
wicket session.
But I am not sure how these account objects are getting mixed up
between
users.
Please can someone lead me to the route cause of the issue?
Thanks in advance!
SSP
The INTERNET now has a personality. YOURS! See your Yahoo!
Homepage.
http://in.yahoo.com/
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://old.nabble.com/Wicket-session-not-threadsafe--tp27074491p27075050.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
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://old.nabble.com/Wicket-session-not-threadsafe--tp27074491p27075144.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: Wicket session not threadsafe?
unfortunately it is extremely difficult to reproduce in dev. Have tried it a
lot. but the issue seems to happen vaer rare in a multi-user env. Thing is
though ti happens rarely... it is a client facing issue and data integrity
as promised is challenged.
Steve Swinsburg-3 wrote:
The first thing to do would be to reproduce the issue in a dev
environment, then try upgrading that environment to 1.3.7 and see if that
solves the problem. There shouldn't be any API breaks in the 1.3 series so
this should be a simple POM dependency version update.
It might also be your Hibernate implementation caching and returning the
wrong object as well.
Steve
On 08/01/2010, at 11:21 PM, allgo wrote:
1.3.0-beta3 actually. Copied it from the Manifest file
Martijn Dashorst wrote:
1.3.0?
Martijn
On Fri, Jan 8, 2010 at 1:12 PM, allgo soumya_...@yahoo.co.in wrote:
Hi,
The wicket version is 1.3. Sorry should have mentioned that.
As such the User A, after he logs on is getting assigned the Account
object
of User B. And after soem logs we can see that User B had logged on a
while
before. Hence that Accoutn object was definitely fetched a whiel
before.
I
did see a few threads which say Hibernate may eb a culprit but am not
sure
thats the case here.
Please do let me know if you need any more info.
Thanks,
SSP
Martijn Dashorst wrote:
A wicket version number would be helpful...
Martijn
On Fri, Jan 8, 2010 at 12:17 PM, Soumya soumya_...@yahoo.co.in
wrote:
Hi all,
I am fairly a newbie in wicket and would appreciate your help!
I
have a wicket application which are used on Live by more than 500
users. Now the problem which has arisen is - say User A logs on - he
is
able to view details of User B. It has happened for different users
and
I am trying to dig the real reason.
Here is my code details -
1) I use Hibernate to fetch 'Account' objects from backend passing on
the
username/password.
2) I use
MyAppSession extends WebSession
{
private Account account;
public InboundSession(Request request)
{
super(request);
}
public void setAccount(Account account)
{
this.account = account;
}
public Account getAccount()
{
return account;
}
public boolean isUserLoggedIn()
{
return account !=null;
}
}
So
effectively I check if the Account object in session is null or not
and
accordingly decide whether a user is logged in or not.
2) In Login class I pass on the username/password to
HibernateAccountDao
and fetch the Account object.
Account account = accountDao.getAccount(username, password)
MyAppSession session = (MyAppSession )getSession();
session.setAccount(account);
setResponsePage(Home.class);
So effectively I fetch the accout object using hibernate and store it
in
wicket session.
But I am not sure how these account objects are getting mixed up
between
users.
Please can someone lead me to the route cause of the issue?
Thanks in advance!
SSP
The INTERNET now has a personality. YOURS! See your Yahoo!
Homepage.
http://in.yahoo.com/
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://old.nabble.com/Wicket-session-not-threadsafe--tp27074491p27075050.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
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://old.nabble.com/Wicket-session-not-threadsafe--tp27074491p27075144.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
--
View this message in context:
http://old.nabble.com/Wicket-session-not-threadsafe--tp27074491p27075321.html
Sent from the Wicket - User mailing list archive at Nabble.com
Re: Wicket session not threadsafe?
ok will do.
But just a question to the experts - have you heard of this issue before?
I went through the links below
http://old.nabble.com/Storing-user-entity-in-session--tt22113666.html#a22113666
http://old.nabble.com/Wicket-Session-and-threading-tt14595666.html#a14599963
and apparently storing hibernate session object in wicket session was
causing similar issues.
Am doing the same and could this be one possible reason.
I will try an upgrade, but unfortunately as I told I had tried for long to
replicate this is dev but in vain. Only way could be to release in Live and
test. But that would need quite a bit of convincing of my superiors (which
is a bit tricky for a junior developer like me - the application had been
coded and released 2 yrs back and no upgrade doen since those developers
left !! :-) ). But worth a shot.
If it is a hibernate issue I can store the account Id instead of teh Account
object itself in wicket session and do a minor release.
I will try an upgrade for 1.3.7 in the mean time in dev and see if I need
any code / API changes.
Regards,
Soumya
Martijn Dashorst wrote:
Seriously... *BETA*? upgrade and then come back if things are still wrong.
Martijn
On Fri, Jan 8, 2010 at 1:21 PM, allgo soumya_...@yahoo.co.in wrote:
1.3.0-beta3 actually. Copied it from the Manifest file
Martijn Dashorst wrote:
1.3.0?
Martijn
On Fri, Jan 8, 2010 at 1:12 PM, allgo soumya_...@yahoo.co.in wrote:
Hi,
The wicket version is 1.3. Sorry should have mentioned that.
As such the User A, after he logs on is getting assigned the Account
object
of User B. And after soem logs we can see that User B had logged on a
while
before. Hence that Accoutn object was definitely fetched a whiel
before.
I
did see a few threads which say Hibernate may eb a culprit but am not
sure
thats the case here.
Please do let me know if you need any more info.
Thanks,
SSP
Martijn Dashorst wrote:
A wicket version number would be helpful...
Martijn
On Fri, Jan 8, 2010 at 12:17 PM, Soumya soumya_...@yahoo.co.in
wrote:
Hi all,
I am fairly a newbie in wicket and would appreciate your help!
I
have a wicket application which are used on Live by more than 500
users. Now the problem which has arisen is - say User A logs on - he
is
able to view details of User B. It has happened for different users
and
I am trying to dig the real reason.
Here is my code details -
1) I use Hibernate to fetch 'Account' objects from backend passing on
the
username/password.
2) I use
MyAppSession extends WebSession
{
private Account account;
public InboundSession(Request request)
{
super(request);
}
public void setAccount(Account account)
{
this.account = account;
}
public Account getAccount()
{
return account;
}
public boolean isUserLoggedIn()
{
return account !=null;
}
}
So
effectively I check if the Account object in session is null or not
and
accordingly decide whether a user is logged in or not.
2) In Login class I pass on the username/password to
HibernateAccountDao
and fetch the Account object.
Account account = accountDao.getAccount(username, password)
MyAppSession session = (MyAppSession )getSession();
session.setAccount(account);
setResponsePage(Home.class);
So effectively I fetch the accout object using hibernate and store it
in
wicket session.
But I am not sure how these account objects are getting mixed up
between
users.
Please can someone lead me to the route cause of the issue?
Thanks in advance!
SSP
The INTERNET now has a personality. YOURS! See your Yahoo!
Homepage.
http://in.yahoo.com/
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://old.nabble.com/Wicket-session-not-threadsafe--tp27074491p27075050.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
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://old.nabble.com/Wicket-session-not-threadsafe--tp27074491p27075144.html
RE: Wicket session not threadsafe?
Hi Berin,
No the users are all from different companies and no way there woudl be
caching of their side. User A belongs to a client X say working in New York
, while User B may be of client Y working in texas.
It doesnt happen in test environment. but then that is not a multi-user
environment in true sense of teh word. As hardly 3-4 people test it and we
never got into that situation. For live however there are 500+ users using
it everyday.
no-cache entry? I am bit sketchy on this one. Can you give an example?
Thanks for ur help.
Loritsch, Berin C. wrote:
The session object is bound to the HttpSession, so it is as safe as Tomcat
or whatever servlet container is running your application.
Here are some things to consider that have bit me in the butt, and have
nothing to do with your local setup:
* Is that happening locally in your test environment?
* Does your client have caching proxies? (do they even know?)
* Do your response headers have the no-cache entries?
What might be happening is the first person to log in through the caching
proxy gets their information cached by the proxy. The second person comes
in and sees it. Typically the problem has to do with poorly configured
proxy servers and they don't properly distinguish the pages with the cache
control headers you supply. The only way around it is to turn off client
caching completely.
-Original Message-
From: Soumya [mailto:soumya_...@yahoo.co.in]
Sent: Friday, January 08, 2010 6:18 AM
To: users@wicket.apache.org
Subject: Wicket session not threadsafe?
Hi all,
I am fairly a newbie in wicket and would appreciate your help!
I
have a wicket application which are used on Live by more than 500
users. Now the problem which has arisen is - say User A logs on - he is
able to view details of User B. It has happened for different users and
I am trying to dig the real reason.
Here is my code details -
1) I use Hibernate to fetch 'Account' objects from backend passing on the
username/password.
2) I use
MyAppSession extends WebSession
{
private Account account;
public InboundSession(Request request)
{
super(request);
}
public void setAccount(Account account)
{
this.account = account;
}
public Account getAccount()
{
return account;
}
public boolean isUserLoggedIn()
{
return account !=null;
}
}
So
effectively I check if the Account object in session is null or not and
accordingly decide whether a user is logged in or not.
2) In Login class I pass on the username/password to HibernateAccountDao
and fetch the Account object.
Account account = accountDao.getAccount(username, password)
MyAppSession session = (MyAppSession )getSession();
session.setAccount(account);
setResponsePage(Home.class);
So effectively I fetch the accout object using hibernate and store it in
wicket session.
But I am not sure how these account objects are getting mixed up between
users.
Please can someone lead me to the route cause of the issue?
Thanks in advance!
SSP
The INTERNET now has a personality. YOURS! See your Yahoo! Homepage.
http://in.yahoo.com/
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://old.nabble.com/Wicket-session-not-threadsafe--tp27074491p27076126.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: Wicket session not threadsafe?
Thanks a Ton Martijn and Berin!
I will soon try an upgrade to 1.3.4 and try it out.
Once again my sincere thanks to you all for your speedy help!
Martijn Dashorst wrote:
the fix was a by-product of this issue:
https://issues.apache.org/jira/browse/WICKET-1409
So yes, upgrading to 1.3.4 or newer will fix your issue. Go convince
your management and tell them that it helps to keep up-to-date with
open source products because we tend to fix things (at no cost for
that matter!)
Martijn
On Fri, Jan 8, 2010 at 3:17 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
1.3.4 fixed this issue
From the release notes [1]:
* cross session leakage due to a dangling thread local in exceptional
circumstances
* memory leak in localizer (WICKET-1667)
Martijn
[1] http://wicket.apache.org/news.html#News-ApacheWicket1.3.4released%21
On Fri, Jan 8, 2010 at 2:56 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
There has been a session leak somewhere in 1.3 iirc. This has to do
with the thread locals that store Session, RequestCycle and
Application during a request not being removed correctly.
Martijn
On Fri, Jan 8, 2010 at 2:38 PM, allgo soumya_...@yahoo.co.in wrote:
ok will do.
But just a question to the experts - have you heard of this issue
before?
I went through the links below
http://old.nabble.com/Storing-user-entity-in-session--tt22113666.html#a22113666
http://old.nabble.com/Wicket-Session-and-threading-tt14595666.html#a14599963
and apparently storing hibernate session object in wicket session was
causing similar issues.
Am doing the same and could this be one possible reason.
I will try an upgrade, but unfortunately as I told I had tried for long
to
replicate this is dev but in vain. Only way could be to release in Live
and
test. But that would need quite a bit of convincing of my superiors
(which
is a bit tricky for a junior developer like me - the application had
been
coded and released 2 yrs back and no upgrade doen since those
developers
left !! :-) ). But worth a shot.
If it is a hibernate issue I can store the account Id instead of teh
Account
object itself in wicket session and do a minor release.
I will try an upgrade for 1.3.7 in the mean time in dev and see if I
need
any code / API changes.
Regards,
Soumya
Martijn Dashorst wrote:
Seriously... *BETA*? upgrade and then come back if things are still
wrong.
Martijn
On Fri, Jan 8, 2010 at 1:21 PM, allgo soumya_...@yahoo.co.in wrote:
1.3.0-beta3 actually. Copied it from the Manifest file
Martijn Dashorst wrote:
1.3.0?
Martijn
On Fri, Jan 8, 2010 at 1:12 PM, allgo soumya_...@yahoo.co.in
wrote:
Hi,
The wicket version is 1.3. Sorry should have mentioned that.
As such the User A, after he logs on is getting assigned the
Account
object
of User B. And after soem logs we can see that User B had logged on
a
while
before. Hence that Accoutn object was definitely fetched a whiel
before.
I
did see a few threads which say Hibernate may eb a culprit but am
not
sure
thats the case here.
Please do let me know if you need any more info.
Thanks,
SSP
Martijn Dashorst wrote:
A wicket version number would be helpful...
Martijn
On Fri, Jan 8, 2010 at 12:17 PM, Soumya soumya_...@yahoo.co.in
wrote:
Hi all,
I am fairly a newbie in wicket and would appreciate your help!
I
have a wicket application which are used on Live by more than 500
users. Now the problem which has arisen is - say User A logs on -
he
is
able to view details of User B. It has happened for different
users
and
I am trying to dig the real reason.
Here is my code details -
1) I use Hibernate to fetch 'Account' objects from backend
passing on
the
username/password.
2) I use
MyAppSession extends WebSession
{
private Account account;
public InboundSession(Request request)
{
super(request);
}
public void setAccount(Account account)
{
this.account = account;
}
public Account getAccount()
{
return account;
}
public boolean isUserLoggedIn()
{
return account !=null;
}
}
So
effectively I check if the Account object in session is null or
not
and
accordingly decide whether a user is logged in or not.
2) In Login class I pass on the username/password to
HibernateAccountDao
and fetch the Account object.
Account account = accountDao.getAccount(username, password)
MyAppSession session = (MyAppSession )getSession();
session.setAccount(account);
setResponsePage(Home.class);
So effectively I fetch the accout object using hibernate and
store it
in
wicket session.
But I am not sure how these account objects are getting mixed up
between
users.
Please can someone lead me to the route cause of the issue?
Thanks in advance!
SSP
The INTERNET now has a personality. YOURS! See your Yahoo!
Homepage.
http://in.yahoo.com/
--
Become a Wicket expert, learn from
