Re: How to implement session validation?
Haulyn, The wicket in action book has all the explanations and code you need for this. Dealing with cookies is an implementation detail that wicket and the servlet container take care of for you. From your perspective, all you need to worry about is whether the session is authenticated or not, and whether a particular page or component requires either signed in, or admin only access. You could look at the javadoc for authorisedwebapplication but I can't recommend the book highly enough. Martijn and Eelco seem to have anticipated all the common questions people would ask. There are also a couple of wicketstuff projects that provide security frameworks for wicket. HTH Adrian On Thu, Oct 8, 2009 at 7:19 PM, Haulyn R. Jason saharab...@gmail.comwrote: Hi, I read some articles to find how to use session validation to protect my application.
Re: Wicket + Hibernate without Spring for lazy loading
Google for a wicket london weekend presentation and follow up blog on loading jpa entity managers on demand. There have also been various posts relating to using the open session in view Hibernate filter. The JPA blog entry uses the requestcycle to prepare a thread local. The first call to use it creates the entity manager and keeps it in the thread local. The request cycle end request and exception methods handle the cleanup and close. Very brief description but if you google for the topics above it is all very well explained. HTH Adrian On Mon, Oct 5, 2009 at 6:22 PM, Petr Fejfar petr.fej...@gmail.com wrote: On Mon, Oct 5, 2009 at 5:12 AM, Jeffrey Schneller jeffrey.schnel...@envisa.com wrote: I really don't want to bloat my code to implement Spring but if it is the only way to do it then I will. When I've started learning of Wicket few month ago, my position was the similiar: I'd like to avoid stuff like Maven, Spring etc... I found out Databinder as well and tried it. But I was not able to make it running with Hibernate, just with HSQLDB. So we've decided to continue with Spring, Maven... We've increased our overhead little bit, but once we define beans, we do not care about them any more. There was only one pitfall: manually invoking injection of non-visual components. After few month I must say that Spring seems to be the least problematic part of our projects. Petr - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket cuts off posted data
Gatos, How is it possible to enlarge allowed posted data? No idea of your platform so it's difficult to be say exactly. However, assuming you are on tomcat then maxPostSize is what you want ( http://tomcat.apache.org/tomcat-5.5-doc/config/http.html). As mentioned by the other respondents, are you sure its a POST? The 2MB default for Tomcat is still a butt load of text unless people are sending XML documents via a post or similar. HTH Adrian Auckland, NZ
Re: Application Destroy
Joshua, Do you mean destroyed or undeployed? You can override onDestroy() in your Wicket Application class and this will be triggered when your wicket application is stopped as part of being undeployed. But if it were stopped then undeployed I'm not sure how you could be notified of the undeploy event. I think the onDestory() event is the boundary of your application and you won't know about anything beyond that from a wicket perspective. You could also go outside the wicket application with a context listener but again that is a context destroyed event, not an undeploy event. Regards, Adrian Auckland, NZ On Sun, Jul 19, 2009 at 11:43 AM, Joshua Martin josmar52...@gmail.comwrote: Is there a method I can override for when the Wicket Web Application is undeployed? -- _ Joshua S. Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Dirty read/edit problem.
You probably also want to use a session listener to clear any left over locks when a session is destroyed. If you are storing the locks in the db it would be a good idea to use an app listener to clear the lock table on startup. Adrian, Auckland, NZ On Wed, Jun 24, 2009 at 4:37 AM, satar starl...@gmail.com wrote: Thanks for the responses. I feel a little more confident that there isn't something magical already out there to handle this particular problem domain. I do want pessimistic locking as I want to inform the user that someone else is already thinking and in progress of changing something BEFORE they try to change it themselves, and it is very possible for two peeps to attempt edit on the same item. I am also using mySQL not Oracle and wouldn't probably want to rely on a database specific implementation if I could avoid it. As of now, I have created a lock table in memory at the app layer and it sounds like a reasonable approach based on my query from fellow colleges on this forum -- Steve -- View this message in context: http://www.nabble.com/Dirty-read-edit-problem.-tp24157057p24167367.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: File upload without writing to temp file (on Google App Engine)
On Sun, Jun 21, 2009 at 7:18 AM, Joe Fawzy joewic...@gmail.com wrote: Hi split it into small chunks and store each as a blob in datastore entity Joe On Sat, Jun 20, 2009 at 1:44 PM, Dolejs Vlastimil ster...@atlas.cz wrote: Hi, I´m trying write wicket application for Google App Engine. App Engine has some restrictions, one of them is, that you can´t work with filesystem. I´m trying upload images with FileUploadField, but i get AccessControlException. Looking through source code i found there is DiskFileItemFactory, which puts large files (over 10kB) to temp files. Is there any way to redirect all data storing to memory? I also found, if I upload small file (smaller than 10kB) - DiskFileItemFactory store it in memory, but there is some FileCleaner class which cleans temp files and spawns new Thread (which is also restricted in App Engine). So it fails again on AccessControlException. Have you anybody solved problems with file uploads on App Engine? Thanks
Re: page load timer
Milliseconds according to WIA Cheers, Adrian On 6/13/09, Igor Vaynberg igor.vaynb...@gmail.com wrote: dont remember offhand, look in the source. -igor On Fri, Jun 12, 2009 at 9:29 AM, Steve Swinsburgs.swinsb...@lancaster.ac.uk wrote: Thats the one I was after. A question though, what units are the measurements displayed in? time/totaltime in milliseconds, session size in bytes? thanks, Steve - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
Frank, Regarding your question (without joining the IOC holy-war), your experience seems odd. The wicket rad project has examples of this approach and from memory there are some slides from a wicket presentation in London on the same thing floating about so I think we can conclude it is a common approach. I actually like this approach and given that the wicket guys gave us the request cycle and such an easy way to implement our own, it seems a very wicket way to handle the problem as long as it fits your use case (all transactions inside the request). A couple of general thoughts - apologies if these are too basic. - Are you sure your Entity manager is being opened correctly and set in the threadlocal in onBeginRequest. If you are putting it in there correctly, the only way it is coming out is if you take it out. - Any chance the same entity manager is getting closed somewhere else in the code. - Are you setting your entity manager on the threadlocal during onBeginRequest by putting it on or relying on the inititalvalue for the threadlocal. This is only called once per thread on the first get. As threads are re-used, only the first requestcycle using a thread will call this. - Are you over-riding onRuntimeException as well as onEndRequest and handling the threadlocal cleanup in both places. - Leaving entity managers lying around doesn't seem ideal. I think it is better to clean them up and rely on pooling. Using dbcp with Apache openJpa gives a spectacular speedup. As above, apologies if this is all too basic, just brain dumping before bed time. Cheers, Adrian, Auckland, NZ. On Tue, Jun 9, 2009 at 11:48 PM, Frank Tegtmeyer f...@fte.to wrote: Well when it comes to EntityManagers be sure to close, commit and clear your threadlocal instance after your service request cycle. Exactly that didn't work for me. I checked for open transactions, closed them, closed the EntityManager and even released it by setting the ThreadLocal variable to null. Although I created a new EntityManager in onBeginRequest() I constantly got errors during form processing because of not existing EntityManager. I solved this by leaving EntityManager there after the request and checking for its existence at the begin of the request. Any ideas about this? Regards, Frank - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JPA EntityManager storage
I try to keep my UI logic, my business logic, and my persistence strategy separate. Putting the EntityManager in the Request means you have to pass the Request around into your business logic layer. By putting it in a ThreadLocal, the UI and business layers can be blissfully unaware of its existance. BTW I use Spring's OpenEntityManagerInViewFilter for this. Works very well. If you are using a ThreadLocal it is worth reading this.. http://www.javaspecialists.eu/archive/Issue164.html as it covers issues of ThreadLocal and garbage collection. HTH Adrian