RE: Attempting to establish session for static resources in Wicket 6
Ah excellent! Thanks Sven. I was thinking about the creation of a simple test to be added to the test suite that would override WebApplication#newSession and then make a request for a static resource and then throw an exception if newSession gets called. This would help trap any future regression of this issue. > >Hi Chris, > >as already written, these are temporary sessions that should do no harm. > >Nevertheless I've added a check into >RestartResponseAtInterceptPageException#InterceptData (which probes >every request to be able to restore post parameters from before an >intercept page) whether a session exists: > > public static InterceptData get() > { >- return Session.get().getMetaData(key); >+ if (Session.exists()) >+ { >+ return Session.get().getMetaData(key); >+ } >+ return null; > } > >Your particular stacktrace below should no longer trigger the creation >of a session now. > >Sven > > >On 12/23/2012 02:05 PM, Chris Colman wrote: >> A while ago when working with Wicket 1.5 we raised issue 4334 that dealt >> with the problem of jsessoin ID's being present in static resource URLs >> for the initial request and this issue was fixed. >> >> Not requiring jsession ID in the URL meant there was no reason to ever >> establish a session during requests for static resources i.e. >> WebApplication#newSession was never called for static resource requests. >> This worked very well but we've just discovered that in Wicket 6, even >> though the URLs for static resources do not contain jsessionIDs there is >> some code that is calling getSession - unnecessarily we believe (we hope >> =] ). >> >> Is there any reason why WebApplicatoin#newSession is called when no >> session is required to service the static request? If not it would be >> great if that call could be avoided. >> >> Calling WebApplication#newSession on static resources becomes a problem >> when you employ OpenSessionInView/OpenPersistenceManagerInView by using >> a filter to wrap all Wicket requests within the context of an open >> persistence session/manager. To optimize performance we use an 'ignore >> list' that avoids wrapping the request if it is for a resource that >> starts with a particular pattern (eg., /wicket/resource,/robots.txt) >> >> We override WebApplication#newSession and do some fancy things whenever >> a new session is established - this is intended for non static resource >> requests. Some of this code assumes that there is an OpenSessionInView - >> which fails in the case of static resources because their URLs are part >> of the ignore list and so the request was not wrapped within an open >> persistence session/manager. >> >> I was hoping that Wicket 6 could be fixed to avoid the call to >> newSession like Wicket 1.5 did after the resolution of 4334. >> >> Here's a stack trace of a call that is servicing a request for a wicket >> static resource: >> >> 2012/12/23 23:16:24.607 ERROR - DefaultExceptionMapper - unexpected >> exception when handling another exception: null >> java.lang.NullPointerException >> at >> com.sas.av.model.context.EServerContext.establishSiteVisitorForCrawler(E >> ServerContext.java:3055) >> at >> com.sas.av.model.context.EServerContext.initSession(EServerContext.java: >> 3585) >> at >> com.sas.av.ui.wicket.templates.WicketModelExposerApplication.newSession( >> WicketModelExposerApplication.java:148) >> at >> org.apache.wicket.Application.fetchCreateAndSetSession(Application.java: >> 1557) >> at org.apache.wicket.Session.get(Session.java:152) >> at >> org.apache.wicket.RestartResponseAtInterceptPageException$InterceptData. >> get(RestartResponseAtInterceptPageException.java:146) >> at >> org.apache.wicket.RestartResponseAtInterceptPageException$1.matchedData( >> RestartResponseAtInterceptPageException.java:211) >> at >> org.apache.wicket.RestartResponseAtInterceptPageException$1.getCompatibi >> lityScore(RestartResponseAtInterceptPageException.java:179) >> at >> org.apache.wicket.request.mapper.CompoundRequestMapper.mapRequest(Compou >> ndRequestMapper.java:138) >> at >> org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(Reque >> stCycle.java:183) >> at >> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle >> .java:208) >> at >> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(Req >> uestCycle.java:282) >> at >> org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketF >> ilter.java:244) >> at >> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter >> .java:188) >> at >> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilt
RE: Attempting to establish session for static resources in Wicket 6
>I don't remember quite well how it used to work with 1.5, but looking at >your stacktrace I see you used some kind of redirection policy that >involves class RestartResponseAtInterceptPageException. I had the same reaction when I first saw the redirect but I can assure you that we're not doing any redirect. In fact I put a break point on the constructor of RestartResponseAtInterceptPageException but none are instantiated during this execution. No instance of RestartResponseAtInterceptPageExtension is created but rather an anonymous instance of an inner class defined within that class, an instance of IRequestMapper, is being used. When attempting to service a request for a static resource the following loop is executed and at some stage 'mapper', the iteration variable, becomes an instance of: org.apache.wicket.RestartResponseAtInterceptPageException$1 for (IRequestMapper mapper : mappers) { int score = mapper.getCompatibilityScore(request); list.add(new MapperWithScore(mapper, score)); } The anonymouse, inner class instance is defined as: static IRequestMapper MAPPER = new IRequestMapper() { @Override public int getCompatibilityScore(Request request) { return matchedData(request) != null ? Integer.MAX_VALUE : 0; } @Override public Url mapHandler(IRequestHandler requestHandler) { return null; } @Override public IRequestHandler mapRequest(Request request) { InterceptData data = matchedData(request); if (data != null) { if (data.postParameters.isEmpty() == false && request.getPostParameters() instanceof IWritableRequestParameters) { IWritableRequestParameters parameters = (IWritableRequestParameters)request.getPostParameters(); parameters.reset(); for (String s : data.postParameters.keySet()) { parameters.setParameterValues(s, data.postParameters.get(s)); } } InterceptData.clear(); } return null; } private InterceptData matchedData(Request request) { InterceptData data = InterceptData.get(); if (data != null && data.originalUrl.equals(request.getOriginalUrl())) { return data; } return null; } }; > This class needs to build a permanent session as you can see in its method >InterceptData.set: I'm not sure why it's going to all this effort to respond to a request for a static resource. I guess at this point it's trying to exhaust all possibilities that the request is for a page before it assumes that it is a resource. The one thing I'm pretty sure of is that it is in no way necessary for Wicket to establish a session to serve a static resource. Wicket 1.5 was able to achieve this and I think Wicket 6 should be able to also. > >public static void set() > { > Session session = Session.get(); > session.bind(); > >So the creation of a new session is not a question of static resources, >but rather a consequence of RestartResponseAtInterceptPageException. >But as I said I don't remember if 1.5 works differently. >> A while ago when working with Wicket 1.5 we raised issue 4334 that dealt >> with the problem of jsessoin ID's being present in static resource URLs >> for the initial request and this issue was fixed. >> >> Not requiring jsession ID in the URL meant there was no reason to ever >> establish a session during requests for static resources i.e. >> WebApplication#newSession was never called for static resource requests. >> This worked very well but we've just discovered that in Wicket 6, even >> though the URLs for static resources do not contain jsessionIDs there is >> some code that is calling getSession - unnecessarily we believe (we hope >> =] ). >> >> Is there any reason why WebApplicatoin#newSession is called when no >> session is required to service the static request? If not it would be >> great if that call could be avoided. >> >> Calling WebApplication#newSession on static resources becomes a problem >> when you employ OpenSessionInView/OpenPersistenceManagerInView by using >> a filter to wrap all Wicket requests with
Re: Attempting to establish session for static resources in Wicket 6
Hi Chris, as already written, these are temporary sessions that should do no harm. Nevertheless I've added a check into RestartResponseAtInterceptPageException#InterceptData (which probes every request to be able to restore post parameters from before an intercept page) whether a session exists: public static InterceptData get() { - return Session.get().getMetaData(key); + if (Session.exists()) + { + return Session.get().getMetaData(key); + } + return null; } Your particular stacktrace below should no longer trigger the creation of a session now. Sven On 12/23/2012 02:05 PM, Chris Colman wrote: A while ago when working with Wicket 1.5 we raised issue 4334 that dealt with the problem of jsessoin ID's being present in static resource URLs for the initial request and this issue was fixed. Not requiring jsession ID in the URL meant there was no reason to ever establish a session during requests for static resources i.e. WebApplication#newSession was never called for static resource requests. This worked very well but we've just discovered that in Wicket 6, even though the URLs for static resources do not contain jsessionIDs there is some code that is calling getSession - unnecessarily we believe (we hope =] ). Is there any reason why WebApplicatoin#newSession is called when no session is required to service the static request? If not it would be great if that call could be avoided. Calling WebApplication#newSession on static resources becomes a problem when you employ OpenSessionInView/OpenPersistenceManagerInView by using a filter to wrap all Wicket requests within the context of an open persistence session/manager. To optimize performance we use an 'ignore list' that avoids wrapping the request if it is for a resource that starts with a particular pattern (eg., /wicket/resource,/robots.txt) We override WebApplication#newSession and do some fancy things whenever a new session is established - this is intended for non static resource requests. Some of this code assumes that there is an OpenSessionInView - which fails in the case of static resources because their URLs are part of the ignore list and so the request was not wrapped within an open persistence session/manager. I was hoping that Wicket 6 could be fixed to avoid the call to newSession like Wicket 1.5 did after the resolution of 4334. Here's a stack trace of a call that is servicing a request for a wicket static resource: 2012/12/23 23:16:24.607 ERROR - DefaultExceptionMapper - unexpected exception when handling another exception: null java.lang.NullPointerException at com.sas.av.model.context.EServerContext.establishSiteVisitorForCrawler(E ServerContext.java:3055) at com.sas.av.model.context.EServerContext.initSession(EServerContext.java: 3585) at com.sas.av.ui.wicket.templates.WicketModelExposerApplication.newSession( WicketModelExposerApplication.java:148) at org.apache.wicket.Application.fetchCreateAndSetSession(Application.java: 1557) at org.apache.wicket.Session.get(Session.java:152) at org.apache.wicket.RestartResponseAtInterceptPageException$InterceptData. get(RestartResponseAtInterceptPageException.java:146) at org.apache.wicket.RestartResponseAtInterceptPageException$1.matchedData( RestartResponseAtInterceptPageException.java:211) at org.apache.wicket.RestartResponseAtInterceptPageException$1.getCompatibi lityScore(RestartResponseAtInterceptPageException.java:179) at org.apache.wicket.request.mapper.CompoundRequestMapper.mapRequest(Compou ndRequestMapper.java:138) at org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(Reque stCycle.java:183) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle .java:208) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(Req uestCycle.java:282) at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketF ilter.java:244) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter .java:188) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java: 267) at com.sas.av.ui.wicket.templates.original.PagebloomFilter.doFilter(Pageblo omFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica tionFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt erChain.java:206) at com.sas.av.model.context.UrlRedirectorFilter.doFilter(UrlRedirectorFilte r.java:93) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica tionFilterChain.java:
Re: Parsing company id from url
Hi Josh, LocaleFirstMapper from wicket-examples seems like something you're looking for, it reads the locale from the first url segment. Sven On 12/23/2012 10:33 PM, jchappelle wrote: I'm hoping this will be an easy question to answer for the wicket gurus out there. I'm developing an app that will have pages specific to companies. They will be able to configure styles and logos and all the pages will be branded for their company. The root url looks like http://server/app. I'm going to have an Apache web server proxy in front of it that looks like http://yourcompany that will proxy to the backing tomcat instance. My problem is that I'm not sure how to formulate a URL that wicket can use to parse the institution id. I was thinking that I could proxy http://company1 to http://server/app/1 and http://company2 to http://server/app/2. I'm not sure if this is a best practice for this situation but it seems reasonable. *Question* How do I parse this kind of parameter from within wicket? IRequestMapper? *Note* Some pages will be secured requiring the user to log in, and other pages will be publicly accessible. Thanks for your time. Josh -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Parsing-company-id-from-url-tp4655029.html Sent from the Users forum 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Parsing company id from url
I'm hoping this will be an easy question to answer for the wicket gurus out there. I'm developing an app that will have pages specific to companies. They will be able to configure styles and logos and all the pages will be branded for their company. The root url looks like http://server/app. I'm going to have an Apache web server proxy in front of it that looks like http://yourcompany that will proxy to the backing tomcat instance. My problem is that I'm not sure how to formulate a URL that wicket can use to parse the institution id. I was thinking that I could proxy http://company1 to http://server/app/1 and http://company2 to http://server/app/2. I'm not sure if this is a best practice for this situation but it seems reasonable. *Question* How do I parse this kind of parameter from within wicket? IRequestMapper? *Note* Some pages will be secured requiring the user to log in, and other pages will be publicly accessible. Thanks for your time. Josh -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Parsing-company-id-from-url-tp4655029.html Sent from the Users forum 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
A little Christmas present
We (Olaf Siefart and me) have prepared a little christmas present for you. It's a small Wicket application showcasing different approaches to doing asynchronous loading in Wicket (WebSockets, HeartBeat, ...). We built it for our company developer conference and afterward decided to open source it. Get it at: https://github.com/osiefart/wicket-christmas Have a look, enjoy the snow fall and have a Merry Christmas. Olaf and Jochen jochen.ma...@senacor.com olaf.sief...@senacor.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Attempting to establish session for static resources in Wicket 6
I don't remember quite well how it used to work with 1.5, but looking at your stacktrace I see you used some kind of redirection policy that involves class RestartResponseAtInterceptPageException. This class needs to build a permanent session as you can see in its method InterceptData.set: public static void set() { Session session = Session.get(); session.bind(); So the creation of a new session is not a question of static resources, but rather a consequence of RestartResponseAtInterceptPageException. But as I said I don't remember if 1.5 works differently. A while ago when working with Wicket 1.5 we raised issue 4334 that dealt with the problem of jsessoin ID's being present in static resource URLs for the initial request and this issue was fixed. Not requiring jsession ID in the URL meant there was no reason to ever establish a session during requests for static resources i.e. WebApplication#newSession was never called for static resource requests. This worked very well but we've just discovered that in Wicket 6, even though the URLs for static resources do not contain jsessionIDs there is some code that is calling getSession - unnecessarily we believe (we hope =] ). Is there any reason why WebApplicatoin#newSession is called when no session is required to service the static request? If not it would be great if that call could be avoided. Calling WebApplication#newSession on static resources becomes a problem when you employ OpenSessionInView/OpenPersistenceManagerInView by using a filter to wrap all Wicket requests within the context of an open persistence session/manager. To optimize performance we use an 'ignore list' that avoids wrapping the request if it is for a resource that starts with a particular pattern (eg., /wicket/resource,/robots.txt) We override WebApplication#newSession and do some fancy things whenever a new session is established - this is intended for non static resource requests. Some of this code assumes that there is an OpenSessionInView - which fails in the case of static resources because their URLs are part of the ignore list and so the request was not wrapped within an open persistence session/manager. I was hoping that Wicket 6 could be fixed to avoid the call to newSession like Wicket 1.5 did after the resolution of 4334. Here's a stack trace of a call that is servicing a request for a wicket static resource: 2012/12/23 23:16:24.607 ERROR - DefaultExceptionMapper - unexpected exception when handling another exception: null java.lang.NullPointerException at com.sas.av.model.context.EServerContext.establishSiteVisitorForCrawler(E ServerContext.java:3055) at com.sas.av.model.context.EServerContext.initSession(EServerContext.java: 3585) at com.sas.av.ui.wicket.templates.WicketModelExposerApplication.newSession( WicketModelExposerApplication.java:148) at org.apache.wicket.Application.fetchCreateAndSetSession(Application.java: 1557) at org.apache.wicket.Session.get(Session.java:152) at org.apache.wicket.RestartResponseAtInterceptPageException$InterceptData. get(RestartResponseAtInterceptPageException.java:146) at org.apache.wicket.RestartResponseAtInterceptPageException$1.matchedData( RestartResponseAtInterceptPageException.java:211) at org.apache.wicket.RestartResponseAtInterceptPageException$1.getCompatibi lityScore(RestartResponseAtInterceptPageException.java:179) at org.apache.wicket.request.mapper.CompoundRequestMapper.mapRequest(Compou ndRequestMapper.java:138) at org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(Reque stCycle.java:183) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle .java:208) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(Req uestCycle.java:282) at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketF ilter.java:244) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter .java:188) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java: 267) at com.sas.av.ui.wicket.templates.original.PagebloomFilter.doFilter(Pageblo omFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica tionFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt erChain.java:206) at com.sas.av.model.context.UrlRedirectorFilter.doFilter(UrlRedirectorFilte r.java:93) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica tionFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt erChain.java:206) at com.sas.framework.expojo.servlet.ExpojoServletFilter.doFilter(ExpojoSer
Re: JPA annotations
Hi, I really don't understand your question. You want to know how to get jpa-annotations to work. Well, you just need to get hold of an entitymanager. If you ask me, go with spring, it's easier than jee or even Guice. Regards Martin -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/JPA-annotations-tp4655001p4655025.html Sent from the Users forum 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: JPA annotations
check http://jeff-schwartz.blogspot.nl/2011/03/java-ee6-wicket.html its a good series of articles about using Java EE and wicket I Haven't Lost My Mind - It's Backed Up On Disk Somewhere On Fri, Dec 21, 2012 at 1:30 PM, Lucio Crusca wrote: > Hello *, > > I've started this short thread on the tomEE users ml: > > http://markmail.org/message/3asqvvptnkieknq5 > > The final answer sounds to me like "if you want to use resources injection > through JPA annotations in a wicket application, your best bet is Java-EE- > Inject" > > https://github.com/wicketstuff/core/wiki/Java-EE-Inject > > which in turn states that: > > "With JavaEE Inject you can use in your wicket components three > annotations: > @EJB, @PersistenceUnit, @Resource". > > What about @Entity, @Table, @Id, @GeneratedValue and friends? > > What's the simplest way to use JPA annotations and dependency injection > threreof in a wicket application? > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >