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 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 > > 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 : > > >> On Mon, Sep 20, 2010 at 1:18 PM, tetsuo > 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
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 > 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 : > >> On Mon, Sep 20, 2010 at 1:18 PM, tetsuo 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
There is another one in Kenai: http://kenai.com/projects/wicketgae Haven't used it so can't say how good / complete it is. There's also many blog posts like this one: http://stronglytypedblog.blogspot.com/2009/04/wicket-on-google-app-engine.html It would be great to have one blessed and almost official implementation than half a dozen scattered individual efforts. Besides an example, it would be nice to have a quickstart. Cheers, Daniel Ernesto Reinaldo Barreiro-4 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/ > > -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Making-Wicket-Fully-Compatible-with-Google-App-Engine-tp2546933p2549276.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.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
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 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 : >> On Mon, Sep 20, 2010 at 1:18 PM, tetsuo 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 : > On Mon, Sep 20, 2010 at 1:18 PM, tetsuo 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
On Mon, Sep 20, 2010 at 1:18 PM, tetsuo 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
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 wrote: > > ...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
...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
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 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" 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 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
On 20/09/2010 09:52, Peter Ertl wrote: Why not prefix all issue titles with something like [GAE] problem description ? This should be easy to filter or lookup Why not use Jira sub tasks? Adriano
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 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
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
