Re: Making Wicket Fully Compatible with Google App Engine
Away for long time, but now back with great news. (Hey Jeremy! Eelco! Martijn!) Like I've tweeted a few minutes ago, I've implemented a BigTableGAEPageStore for Wicket so we can advance another step further full compatibility with Google App Engine. The project can be seen at http://code.google.com/p/gawcket It is a fork of wicket-gae-template with a modified Guestbook to not use LoadableDetachableModel and the BigTableGAEPageStore. With this said, you can go to http://gawcket.appspot.com and test it. Submit the form a few times and then modify the URL to reference an older version. You can check this video on YouTube to see how data is being stored at GAE's Datastore: http://youtu.be/ObvA9ao8U2Q I just hope I've done everything correctly on this implementation. So I ask the experts to take a look, and more important: to try it on your apps that run on more than one CPU at GAE. Thank you, Long live Wicket!! Bruno Borges www.brunoborges.com.br +55 21 76727099 The glory of great men should always be measured by the means they have used to acquire it. - Francois de La Rochefoucauld On Tue, Sep 21, 2010 at 3:01 PM, Rodolfo Hansen kry...@gmail.com wrote: There is also an archetype I wrote that works with the maven-gae-plugin mvn archetype:generate -DarchetypeGroupId=net.kindleit -DarchetypeArtifactId=gae-archetype-wicket -DarchetypeVersion=0.7.1 \ -DgroupId=com.myapp.test -DartifactId=testapp On Tue, 2010-09-21 at 13:40 +0200, Ernesto Reinaldo Barreiro wrote: There is already a GAE template project somewhere on goggle code [1]. Would it make sense to try to contact the author and join forces with other GAE users? Cheers, Ernesto 1-http://code.google.com/p/wicket-gae-template/ On Tue, Sep 21, 2010 at 1:19 PM, nino martinez wael nino.martinez.w...@gmail.com wrote: It would make perfect sense for me if there appeared a wicketstuff project(subclasses necessary for compability with GAE) for this along with an example project.. 2010/9/20 Jeremy Thomerson jer...@wickettraining.com: On Mon, Sep 20, 2010 at 1:18 PM, tetsuo ronald.tet...@gmail.com wrote: An auto-detected GAE-specific mode in Wicket core? I don't think this is a good idea... I agree that this shouldn't go in core, but I think if someone like Clint has the motivation to do so, I'd love to see a project that provides out-of-the-box GAE support. This might make it easier for newbs to get something deployed to play with. This could potentially be done as a standalone project that provides subclasses to WebApplication, etc, with the default implementations switched out to GAE-compatible classes, configured correctly, etc. Or, it could be a git clone of 1.4 and 1.5 (trunk) that keeps current with the vendor (us, official Wicket), but adds in their custom changes to make it GAE compatible. Why not use Jira sub tasks? I think this is the way to go - create a master make GAE compatible version task and subtasks for each individual thing. There should be a differentiation made between ones that can be accepted in core and those that can't. For example, we (probably) won't be accepting a WebApplication subclass specific to GAE. But, we could accept some changes that need to be made to make it compatible with, or easier to make compatible with, GAE. For example, I'd love to see a task for kill the use of stupid TreeModel in 1.5 (and, really, any java.awt / javax.swing usage in core). But, this would be better discussed as a separate thread. -- Jeremy Thomerson http://www.wickettraining.com
Re: Making Wicket Fully Compatible with Google App Engine
It would make perfect sense for me if there appeared a wicketstuff project(subclasses necessary for compability with GAE) for this along with an example project.. 2010/9/20 Jeremy Thomerson jer...@wickettraining.com: On Mon, Sep 20, 2010 at 1:18 PM, tetsuo ronald.tet...@gmail.com wrote: An auto-detected GAE-specific mode in Wicket core? I don't think this is a good idea... I agree that this shouldn't go in core, but I think if someone like Clint has the motivation to do so, I'd love to see a project that provides out-of-the-box GAE support. This might make it easier for newbs to get something deployed to play with. This could potentially be done as a standalone project that provides subclasses to WebApplication, etc, with the default implementations switched out to GAE-compatible classes, configured correctly, etc. Or, it could be a git clone of 1.4 and 1.5 (trunk) that keeps current with the vendor (us, official Wicket), but adds in their custom changes to make it GAE compatible. Why not use Jira sub tasks? I think this is the way to go - create a master make GAE compatible version task and subtasks for each individual thing. There should be a differentiation made between ones that can be accepted in core and those that can't. For example, we (probably) won't be accepting a WebApplication subclass specific to GAE. But, we could accept some changes that need to be made to make it compatible with, or easier to make compatible with, GAE. For example, I'd love to see a task for kill the use of stupid TreeModel in 1.5 (and, really, any java.awt / javax.swing usage in core). But, this would be better discussed as a separate thread. -- Jeremy Thomerson http://www.wickettraining.com
Re: Making Wicket Fully Compatible with Google App Engine
Thanks for all the responses. I've gone ahead and created https://issues.apache.org/jira/browse/WICKET-3064 to track the overall GAE Compatibility state. Currently to get Wicket to run on GAE the process is: 1) Make your project with Wicket 2) Google around grab some code trust it 3) Deploy to App Engine 4) Profit! (Kidding) My goal is to remove step 2. I'm not saying that Wicket should instantly work with GAE, but just that if it fails, that Wicket itself will help you get it up and running. (Helpful error messages, minor internal changes, etc.) Eclipse is telling me that there are 99 errors to fix. Just some initial tracking down looks like 1/3rd are file access items that shouldn't be changed in Wicket. A bunch of issues with the javax.swing.* and java.awt.* libraries. And a few other minor changes. The workspace where I'm trying to break Wicket on GAE is http://wicketexamples.appspot.com. Let me know if you want to view the logs and contribute. Regarding creating a separate project in Wicket-Stuff or a template, I'm open to those ideas, but the changes I'm mainly looking at couldn't be done in a separate project. Like Jeremy said: its time java.awt and java.swing were eliminated! -Clint Checketts
Re: Making Wicket Fully Compatible with Google App Engine
Why not prefix all issue titles with something like [GAE] problem description ? This should be easy to filter or lookup Am 20.09.2010 um 14:43 schrieb Clint Checketts: There is a 'Will it play in app engine' page that tracks libraries that are compatible with Google App Engine (aka GAE): http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1 Correctly, Wicket is listed as Semi-Compatible. As a project I've been looking through the Wicket codebase locating the pieces that need to change to make it fully compatible. Does it make sense to have a master Jira that tracks the overall 'compatible with GAE' state while making individual issues for the specific changes that reference back to the master issue? Thanks, -Clint Checketts
Re: Making Wicket Fully Compatible with Google App Engine
Sure I could take whichever approach the core team prefers. A bonus of having a master issue is once it gets resolved that the release notes will specifically mark that it is compatible with GAE. On Mon, Sep 20, 2010 at 7:52 AM, Peter Ertl pe...@gmx.org wrote: Why not prefix all issue titles with something like [GAE] problem description ? This should be easy to filter or lookup Am 20.09.2010 um 14:43 schrieb Clint Checketts: There is a 'Will it play in app engine' page that tracks libraries that are compatible with Google App Engine (aka GAE): http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1 Correctly, Wicket is listed as Semi-Compatible. As a project I've been looking through the Wicket codebase locating the pieces that need to change to make it fully compatible. Does it make sense to have a master Jira that tracks the overall 'compatible with GAE' state while making individual issues for the specific changes that reference back to the master issue? Thanks, -Clint Checketts
Re: Making Wicket Fully Compatible with Google App Engine
Jira supports tags right? On Sep 20, 2010 8:55 AM, Clint Checketts checke...@gmail.com wrote: Sure I could take whichever approach the core team prefers. A bonus of having a master issue is once it gets resolved that the release notes will specifically mark that it is compatible with GAE. On Mon, Sep 20, 2010 at 7:52 AM, Peter Ertl pe...@gmx.org wrote: Why not prefix all issue titles with something like [GAE] problem description ? This should be easy to filter or lookup Am 20.09.2010 um 14:43 schrieb Clint Checketts: There is a 'Will it play in app engine' page that tracks libraries that are compatible with Google App Engine (aka GAE): http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1 Correctly, Wicket is listed as Semi-Compatible. As a project I've been looking through the Wicket codebase locating the pieces that need to change to make it fully compatible. Does it make sense to have a master Jira that tracks the overall 'compatible with GAE' state while making individual issues for the specific changes that reference back to the master issue? Thanks, -Clint Checketts
Re: Making Wicket Fully Compatible with Google App Engine
I think Wicket is listed as semi-compatible because it requires some customization (override some methods, change some configuration) to make it work, not because its internals are inherently incompatible to GAE, or because it has some incompatible visual components. Such customization are simply disabling resource polling, enabling sessions and persisting the session store in the HttpSession, and those shouldn't change, since the defaults shoud target to the plain-old Java web application, not GAE. Some things could be done to improve GAE support, such as eliminating javax.swing dependencies (from the Tree component), but I think nothing one could do would change the classification from semi-compatible to compatible in that listing. Unless, of course, GAE turns to be the main target for Wicket (which I don't think is the case). my 2c, Tetsuo On Mon, Sep 20, 2010 at 9:52 AM, Peter Ertl pe...@gmx.org wrote: Why not prefix all issue titles with something like [GAE] problem description ? This should be easy to filter or lookup Am 20.09.2010 um 14:43 schrieb Clint Checketts: There is a 'Will it play in app engine' page that tracks libraries that are compatible with Google App Engine (aka GAE): http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1 Correctly, Wicket is listed as Semi-Compatible. As a project I've been looking through the Wicket codebase locating the pieces that need to change to make it fully compatible. Does it make sense to have a master Jira that tracks the overall 'compatible with GAE' state while making individual issues for the specific changes that reference back to the master issue? Thanks, -Clint Checketts
Re: Making Wicket Fully Compatible with Google App Engine
...and those shouldn't change, since the defaults shoud target... ...I think nothing one could do would change the classification from semi-compatible to compatible... Sure you can, the defaults could change automatically by detecting that GAE is the container. Regards, Erik. Op 20-09-10 15:05, tetsuo wrote: I think Wicket is listed as semi-compatible because it requires some customization (override some methods, change some configuration) to make it work, not because its internals are inherently incompatible to GAE, or because it has some incompatible visual components. Such customization are simply disabling resource polling, enabling sessions and persisting the session store in the HttpSession, and those shouldn't change, since the defaults shoud target to the plain-old Java web application, not GAE. Some things could be done to improve GAE support, such as eliminating javax.swing dependencies (from the Tree component), but I think nothing one could do would change the classification from semi-compatible to compatible in that listing. Unless, of course, GAE turns to be the main target for Wicket (which I don't think is the case). my 2c, Tetsuo -- Sent from my SMTP compliant software Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: Making Wicket Fully Compatible with Google App Engine
An auto-detected GAE-specific mode in Wicket core? I don't think this is a good idea... On Mon, Sep 20, 2010 at 3:07 PM, Erik van Oosten e.vanoos...@grons.nlwrote: ...and those shouldn't change, since the defaults shoud target... ...I think nothing one could do would change the classification from semi-compatible to compatible... Sure you can, the defaults could change automatically by detecting that GAE is the container. Regards, Erik. Op 20-09-10 15:05, tetsuo wrote: I think Wicket is listed as semi-compatible because it requires some customization (override some methods, change some configuration) to make it work, not because its internals are inherently incompatible to GAE, or because it has some incompatible visual components. Such customization are simply disabling resource polling, enabling sessions and persisting the session store in the HttpSession, and those shouldn't change, since the defaults shoud target to the plain-old Java web application, not GAE. Some things could be done to improve GAE support, such as eliminating javax.swing dependencies (from the Tree component), but I think nothing one could do would change the classification from semi-compatible to compatible in that listing. Unless, of course, GAE turns to be the main target for Wicket (which I don't think is the case). my 2c, Tetsuo -- Sent from my SMTP compliant software Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: Making Wicket Fully Compatible with Google App Engine
On Mon, Sep 20, 2010 at 1:18 PM, tetsuo ronald.tet...@gmail.com wrote: An auto-detected GAE-specific mode in Wicket core? I don't think this is a good idea... I agree that this shouldn't go in core, but I think if someone like Clint has the motivation to do so, I'd love to see a project that provides out-of-the-box GAE support. This might make it easier for newbs to get something deployed to play with. This could potentially be done as a standalone project that provides subclasses to WebApplication, etc, with the default implementations switched out to GAE-compatible classes, configured correctly, etc. Or, it could be a git clone of 1.4 and 1.5 (trunk) that keeps current with the vendor (us, official Wicket), but adds in their custom changes to make it GAE compatible. Why not use Jira sub tasks? I think this is the way to go - create a master make GAE compatible version task and subtasks for each individual thing. There should be a differentiation made between ones that can be accepted in core and those that can't. For example, we (probably) won't be accepting a WebApplication subclass specific to GAE. But, we could accept some changes that need to be made to make it compatible with, or easier to make compatible with, GAE. For example, I'd love to see a task for kill the use of stupid TreeModel in 1.5 (and, really, any java.awt / javax.swing usage in core). But, this would be better discussed as a separate thread. -- Jeremy Thomerson http://www.wickettraining.com
