Re: Re: Google App Engine and Wicket
On 20:59, Eelco Hillenius wrote:
It's probably a good idea to have a specialized implementation of
ISessionStore for App Engine that uses whatever makes sense with App
Engine for medium term storage ('cause that's what it is... short term
storage is the current page, which is typically local memory, and
older pages are used for the duration of the session, and typically
just keeping the last few in memory suffices.
I tried to get started with an implementation of ISessionStore for the
app engine. However, I would rather opt for the Memcache Service [1]
instead of the datastore due to performance and quota issues. The
MemcacheService provided by GAE is in effect a JCache implementation.
Regarding a Memcache-based implementation, there rise the following
questions for me (please take into account that I am rather a
wicket-beginner):
1) Should the implementation be a specialization of ISessionStore or
rather IPageStore?
1a) In case of ISessionStore, is it enough to implement the
MemcacheSessionStore like the HTTPSessionStore, but instead of putting
things into the HTTPSession, they will be put in the Memcache?
1b) In case of IPageStore, does it make sense to adopt some principles
of the DiskPageStore (and basically switch the file-based saving to a
cache-based saving)?
2) I digged a bit through the mailing list: Would an implementation such
as 1a) affect the back/forward button behavior of the browser?
Thanks in advance for your thoughts.
andr
[1] http://code.google.com/appengine/docs/java/memcache/
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Re: Google App Engine and Wicket
Hi,
The Terracotta SecondLevelCacheSessionStore does not contain any Terracotta
specific implementation or dependencies, and should work fine on AppEngine
(I haven't tested it though).
All it is is an implementation of IPageStore, where the pages are serialized
to byte arrays (like the disk store), and then these byte arrays are stored
in the http session, rather than on disk. I have attached the file in this
thread so you dont need to dig around in the terracotta svn repo.
to use it do this in your application class:
@Override
public ISessionStore newSessionStore() {
return new SecondLevelCacheSessionStore(this, new
TerracottaPageStore(100));
}
the 100 is the number of versions of pages you want to keep, and can be
customized as you feel appropriate.
http://www.nabble.com/file/p25973504/TerracottaPageStore.java
TerracottaPageStore.java
Regards - Richard Wilkinson
Developer,
jWeekend: OO Java Technologies - Development and Training
http://jWeekend.com
-
http://richard-wilkinson.co.uk My blog: http://richard-wilkinson.co.uk
--
View this message in context:
http://www.nabble.com/Google-App-Engine-and-Wicket-tp23001592p25973504.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: Google App Engine and Wicket
On 20.10.2009 13:30, richardwilko wrote:
Hi,
The Terracotta SecondLevelCacheSessionStore does not contain any Terracotta
specific implementation or dependencies, and should work fine on AppEngine
(I haven't tested it though).
All it is is an implementation of IPageStore, where the pages are serialized
to byte arrays (like the disk store), and then these byte arrays are stored
in the http session, rather than on disk. I have attached the file in this
thread so you dont need to dig around in the terracotta svn repo.
to use it do this in your application class:
@Override
public ISessionStore newSessionStore() {
return new SecondLevelCacheSessionStore(this, new
TerracottaPageStore(100));
}
the 100 is the number of versions of pages you want to keep, and can be
customized as you feel appropriate.
Richard,
thanks a lot for providing the source to me. This is indeed a valuable
starting point.
I just want to make sure that there can't be any copyright issues when I
modify the code due to the copyright statement in the header?
regards,
andr
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Google App Engine and Wicket
andr,
From Wikipedia [1]:
The Apache License does not require modified versions of the software to be
distributed using the same license nor even that it be distributed as
free/open-source software. The Apache license only requires that a notice is
kept informing recipients that Apache licensed code has been used. Thus, in
contrast to copyleft licenses, recipients of modified versions of Apache
licensed code do not necessarily also get the above freedoms. Or considering
the situation from the Apache licensees perspective, they receive the
freedom to use the code in any way they want, including using it in closed
source products (cf Paragraph 4).
So basically you can do what you want with it, so long as you leave the
notice intact. You can read more about the Apache 2 licence on the
internet, I am by no means an expert.
However, if you make any improvements to the code, and are in a position to
do so, then contributing it back would be most welcome :)
[1] http://en.wikipedia.org/wiki/Apache_License
Thanks,
Richard
A. Maza wrote:
On 20.10.2009 13:30, richardwilko wrote:
Hi,
The Terracotta SecondLevelCacheSessionStore does not contain any
Terracotta
specific implementation or dependencies, and should work fine on
AppEngine
(I haven't tested it though).
All it is is an implementation of IPageStore, where the pages are
serialized
to byte arrays (like the disk store), and then these byte arrays are
stored
in the http session, rather than on disk. I have attached the file in
this
thread so you dont need to dig around in the terracotta svn repo.
to use it do this in your application class:
@Override
public ISessionStore newSessionStore() {
return new SecondLevelCacheSessionStore(this, new
TerracottaPageStore(100));
}
the 100 is the number of versions of pages you want to keep, and can be
customized as you feel appropriate.
Richard,
thanks a lot for providing the source to me. This is indeed a valuable
starting point.
I just want to make sure that there can't be any copyright issues when I
modify the code due to the copyright statement in the header?
regards,
andr
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
http://richard-wilkinson.co.uk My blog: http://richard-wilkinson.co.uk
--
View this message in context:
http://www.nabble.com/Google-App-Engine-and-Wicket-tp23001592p25974145.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: Google App Engine and Wicket
Oh, sorry I just realized that it has the terracotta licence header on it,
had I realized i would have removed it. That's because the version of the
file i had to hand was from the terracotta forge svn repo, and code in there
has to have their licence.
Originally it was Apache 2 licensed and I would treat it as such.
Sorry for the confusion,
Richard
A. MaOhza wrote:
On 20.10.2009 13:30, richardwilko wrote:
Hi,
The Terracotta SecondLevelCacheSessionStore does not contain any
Terracotta
specific implementation or dependencies, and should work fine on
AppEngine
(I haven't tested it though).
All it is is an implementation of IPageStore, where the pages are
serialized
to byte arrays (like the disk store), and then these byte arrays are
stored
in the http session, rather than on disk. I have attached the file in
this
thread so you dont need to dig around in the terracotta svn repo.
to use it do this in your application class:
@Override
public ISessionStore newSessionStore() {
return new SecondLevelCacheSessionStore(this, new
TerracottaPageStore(100));
}
the 100 is the number of versions of pages you want to keep, and can be
customized as you feel appropriate.
Richard,
thanks a lot for providing the source to me. This is indeed a valuable
starting point.
I just want to make sure that there can't be any copyright issues when I
modify the code due to the copyright statement in the header?
regards,
andr
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
http://richard-wilkinson.co.uk My blog: http://richard-wilkinson.co.uk
--
View this message in context:
http://www.nabble.com/Google-App-Engine-and-Wicket-tp23001592p25974473.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: Google App Engine and Wicket
On 20.10.2009 14:48, richardwilko wrote: Oh, sorry I just realized that it has the terracotta licence header on it, had I realized i would have removed it. That's because the version of the file i had to hand was from the terracotta forge svn repo, and code in there has to have their licence. Originally it was Apache 2 licensed and I would treat it as such. Therefore I was asking. Thanks for the clarification. I will post a modified version of the pagestore impl for GAE Memcache to the list as soon as I have it ready. Thanks and regards, andr - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Google App Engine and Wicket
Here's a minor point that tripped me up. I have my WicketFilter mapped to a given path: filter-mapping filter-nameWicketFilter/filter-name url-pattern/evansforlv/*/url-pattern /filter-mapping And then when I start up my local app and browse to localhost:8080/evansforlv I get redirected by Jetty to localhost:8080/evansforlv/ with a trailing /. GAE is not so kind. You must add the trailing / to your url or you will simply get a blank page. Since you are never sent to the WicketFilter nothing is logged. It's just a silent failure. Cheers, Scott On Mon, May 11, 2009 at 11:26 AM, Juha Palomäkijuha.palom...@gmail.com wrote: File uploads seem to be causing some problems. On Wicket uploaded files are first written to some temporary file and on AppEngine this is obviously not possible. I haven't yet investigated if it is easy to change this behavior in Wicket. Another option might be to write a separate servlet for just handling the uploads, http://code.google.com/appengine/kb/java.html#fileforms Br, Juha On Sat, Apr 11, 2009 at 5:15 PM, Matthew Welch matt...@welchkin.net wrote: I've been experimenting a bit with Google App Engine and Wicket and things seemed to work fairly well once I turned off the ModificationWatcher. However, I realized that my simple tests were all stateless and that once stateful, Wicket would use the DiskPageStore to write some files, which is not allowed in the App Engine sandbox. Sure enough, once I added some stateful pages, I started seeing exceptions related to the DiskPageStore. I'm a neophyte when it comes to the deep down Wicket internals so I'm not sure what my other options might be. In a post Matej Knopp said, * DiskPageStore*'s purpose is to store serialized pages on disk in order to allow access to previous page versions and also to conserve session memory usage. This leads me to believe that using the sassion for storing this information isn't a preferred approach. What about the App Engine's datastore (an abstration on BigTable)? That seems like it might be too slow to adequately serve this need, but I'm not sure. A thread on Wicket/Terracotta integration ended up with an alternative SecondLevelCacheSessionStore but I'm not sure if that is only usable with Terracotta or if it might might sense in other situations. Any other options? Also, looking forward, with the knoledge that writing giles and spawning new threads are not allowed in the App Engine sandbox, are there any other items I should be onl the lookout for in Wicket that might make it a poor choice for this situation? Matt - 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
Re: Google App Engine and Wicket
I've followed with interest all the wicket on GAE threads I can, and these all seem to address necessary minor tweaks to get it set up, but the one big thing I haven't seen much discussion on is the BigTable storage system, since we wouldn't be able to use MySQL. Maybe that's the whole point for some folks looking for high scalability, but from my perspective, I'm more interested in the idea of a free turnkey(ish) Java hosting environment. I'd like to be able to resell my wicket app (it's a fundraising auction system designed for nonprofits) to lots of tiny churches or other nonprofit organizations - they typically have no IT experience, so bypassing the hosting concerns could be a big win. Plus, the system would be ultra low traffic by google standards especially (maybe 8 concurrent users tops per org during peak demand!). Right now it's 'incubated' as an old underpowered Windows 2000 server running Jetty sitting in a closet at my church, where the business class ISP licence agreement legally permits it. Seems like quite a leap to be considering GAE, but if it's free and folks trust the availability and I can easily configure it for each additional client, that could work out pretty well for me. But of course my system is all heavily SQL oriented - seems like this would be a pretty fundamental rewrite for me to go to BigTable, and I was wondering if any other wicket developers were also attracted to this type of system, for these or other reasons, or whether I should just shell out for some shared hosting blades and go for it? Thanks, -- Jim On Sun, Apr 12, 2009 at 2:15 PM, Maarten Bosteels mbosteels@gmail.comwrote: Good news: http://groups.google.com/group/google-appengine-java/msg/f50bbb131dc524c1 quote HttpSessions will work out of the box if you enable them in your appengine-web.xml. We do not guarantee that all requests for the same session go to the same JVM, but persistence of sessions is managed behind the scenes with the datastore and memcache. You are, of course, free to use the memcache and/or datastore API's directly if you want more control. /quote Maarten On Sun, Apr 12, 2009 at 4:18 PM, Adriano dos Santos Fernandes adrian...@uol.com.br wrote: Maarten Bosteels wrote: But AFAIK GAE doesn't use/guarantee sticky sessions, so I am afraid you can't rely on local memory. App Engine uses multiple web servers to run your application, and automatically adjusts the number of servers it is using to handle requests reliably. A given request may be routed to any server, and it may not be the same server that handled a previous request from the same user. http://code.google.com/appengine/docs/java/runtime.html#Requests_and_Servlets It would be interesting to test the performance of an ISessionStore backed by the App Engine datastore. FYI, I've put a app. with a static variable counter (just a static, not in session). And since two days there, the counter is maintained. So I guess they solution uses something like Terracotta. BTW, they web server is Jetty. Adriano - 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
Re: Google App Engine and Wicket
You can get a dedicated server at GoDaddy for under $100 per month. I've had one running Java / Wicket apps with an uptime of around two years now. With your very small load, you could also use redwoodvirtual and use a Linux Virtual Server for $20 or $40. I also had a server with them running for a couple of consecutive years. I think you're overengineering something that definitely doesn't need it. -- Jeremy Thomerson http://www.wickettraining.com On Mon, May 11, 2009 at 12:03 PM, Jim Pinkham pinkh...@gmail.com wrote: I've followed with interest all the wicket on GAE threads I can, and these all seem to address necessary minor tweaks to get it set up, but the one big thing I haven't seen much discussion on is the BigTable storage system, since we wouldn't be able to use MySQL. Maybe that's the whole point for some folks looking for high scalability, but from my perspective, I'm more interested in the idea of a free turnkey(ish) Java hosting environment. I'd like to be able to resell my wicket app (it's a fundraising auction system designed for nonprofits) to lots of tiny churches or other nonprofit organizations - they typically have no IT experience, so bypassing the hosting concerns could be a big win. Plus, the system would be ultra low traffic by google standards especially (maybe 8 concurrent users tops per org during peak demand!). Right now it's 'incubated' as an old underpowered Windows 2000 server running Jetty sitting in a closet at my church, where the business class ISP licence agreement legally permits it. Seems like quite a leap to be considering GAE, but if it's free and folks trust the availability and I can easily configure it for each additional client, that could work out pretty well for me. But of course my system is all heavily SQL oriented - seems like this would be a pretty fundamental rewrite for me to go to BigTable, and I was wondering if any other wicket developers were also attracted to this type of system, for these or other reasons, or whether I should just shell out for some shared hosting blades and go for it? Thanks, -- Jim On Sun, Apr 12, 2009 at 2:15 PM, Maarten Bosteels mbosteels@gmail.comwrote: Good news: http://groups.google.com/group/google-appengine-java/msg/f50bbb131dc524c1 quote HttpSessions will work out of the box if you enable them in your appengine-web.xml. We do not guarantee that all requests for the same session go to the same JVM, but persistence of sessions is managed behind the scenes with the datastore and memcache. You are, of course, free to use the memcache and/or datastore API's directly if you want more control. /quote Maarten On Sun, Apr 12, 2009 at 4:18 PM, Adriano dos Santos Fernandes adrian...@uol.com.br wrote: Maarten Bosteels wrote: But AFAIK GAE doesn't use/guarantee sticky sessions, so I am afraid you can't rely on local memory. App Engine uses multiple web servers to run your application, and automatically adjusts the number of servers it is using to handle requests reliably. A given request may be routed to any server, and it may not be the same server that handled a previous request from the same user. http://code.google.com/appengine/docs/java/runtime.html#Requests_and_Servlets It would be interesting to test the performance of an ISessionStore backed by the App Engine datastore. FYI, I've put a app. with a static variable counter (just a static, not in session). And since two days there, the counter is maintained. So I guess they solution uses something like Terracotta. BTW, they web server is Jetty. Adriano - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Google App Engine and Wicket
File uploads seem to be causing some problems. On Wicket uploaded files are first written to some temporary file and on AppEngine this is obviously not possible. I haven't yet investigated if it is easy to change this behavior in Wicket. Another option might be to write a separate servlet for just handling the uploads, http://code.google.com/appengine/kb/java.html#fileforms Br, Juha On Sat, Apr 11, 2009 at 5:15 PM, Matthew Welch matt...@welchkin.net wrote: I've been experimenting a bit with Google App Engine and Wicket and things seemed to work fairly well once I turned off the ModificationWatcher. However, I realized that my simple tests were all stateless and that once stateful, Wicket would use the DiskPageStore to write some files, which is not allowed in the App Engine sandbox. Sure enough, once I added some stateful pages, I started seeing exceptions related to the DiskPageStore. I'm a neophyte when it comes to the deep down Wicket internals so I'm not sure what my other options might be. In a post Matej Knopp said, * DiskPageStore*'s purpose is to store serialized pages on disk in order to allow access to previous page versions and also to conserve session memory usage. This leads me to believe that using the sassion for storing this information isn't a preferred approach. What about the App Engine's datastore (an abstration on BigTable)? That seems like it might be too slow to adequately serve this need, but I'm not sure. A thread on Wicket/Terracotta integration ended up with an alternative SecondLevelCacheSessionStore but I'm not sure if that is only usable with Terracotta or if it might might sense in other situations. Any other options? Also, looking forward, with the knoledge that writing giles and spawning new threads are not allowed in the App Engine sandbox, are there any other items I should be onl the lookout for in Wicket that might make it a poor choice for this situation? Matt - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Google App Engine and Wicket
Both articles avoid the DiskPageStore problem by using the HttpSessionStore,
however if you do a search through the mailing list archives for
HttpSessionStore you'll find numerous references to problems in using it in
the long term and especially in a real, production application, so I don't
think that's a good long term solution, so my original question still
stands. Is there an alternative or is Wicket perhaps not well suited for use
in the App Engine.
It's probably a good idea to have a specialized implementation of
ISessionStore for App Engine that uses whatever makes sense with App
Engine for medium term storage ('cause that's what it is... short term
storage is the current page, which is typically local memory, and
older pages are used for the duration of the session, and typically
just keeping the last few in memory suffices.
Eelco
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Google App Engine and Wicket
Maarten Bosteels wrote: But AFAIK GAE doesn't use/guarantee sticky sessions, so I am afraid you can't rely on local memory. App Engine uses multiple web servers to run your application, and automatically adjusts the number of servers it is using to handle requests reliably. A given request may be routed to any server, and it may not be the same server that handled a previous request from the same user. http://code.google.com/appengine/docs/java/runtime.html#Requests_and_Servlets It would be interesting to test the performance of an ISessionStore backed by the App Engine datastore. FYI, I've put a app. with a static variable counter (just a static, not in session). And since two days there, the counter is maintained. So I guess they solution uses something like Terracotta. BTW, they web server is Jetty. Adriano - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Google App Engine and Wicket
Good news: http://groups.google.com/group/google-appengine-java/msg/f50bbb131dc524c1 quote HttpSessions will work out of the box if you enable them in your appengine-web.xml. We do not guarantee that all requests for the same session go to the same JVM, but persistence of sessions is managed behind the scenes with the datastore and memcache. You are, of course, free to use the memcache and/or datastore API's directly if you want more control. /quote Maarten On Sun, Apr 12, 2009 at 4:18 PM, Adriano dos Santos Fernandes adrian...@uol.com.br wrote: Maarten Bosteels wrote: But AFAIK GAE doesn't use/guarantee sticky sessions, so I am afraid you can't rely on local memory. App Engine uses multiple web servers to run your application, and automatically adjusts the number of servers it is using to handle requests reliably. A given request may be routed to any server, and it may not be the same server that handled a previous request from the same user. http://code.google.com/appengine/docs/java/runtime.html#Requests_and_Servlets It would be interesting to test the performance of an ISessionStore backed by the App Engine datastore. FYI, I've put a app. with a static variable counter (just a static, not in session). And since two days there, the counter is maintained. So I guess they solution uses something like Terracotta. BTW, they web server is Jetty. Adriano - 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
Google App Engine and Wicket
I've been experimenting a bit with Google App Engine and Wicket and things seemed to work fairly well once I turned off the ModificationWatcher. However, I realized that my simple tests were all stateless and that once stateful, Wicket would use the DiskPageStore to write some files, which is not allowed in the App Engine sandbox. Sure enough, once I added some stateful pages, I started seeing exceptions related to the DiskPageStore. I'm a neophyte when it comes to the deep down Wicket internals so I'm not sure what my other options might be. In a post Matej Knopp said, * DiskPageStore*'s purpose is to store serialized pages on disk in order to allow access to previous page versions and also to conserve session memory usage. This leads me to believe that using the sassion for storing this information isn't a preferred approach. What about the App Engine's datastore (an abstration on BigTable)? That seems like it might be too slow to adequately serve this need, but I'm not sure. A thread on Wicket/Terracotta integration ended up with an alternative SecondLevelCacheSessionStore but I'm not sure if that is only usable with Terracotta or if it might might sense in other situations. Any other options? Also, looking forward, with the knoledge that writing giles and spawning new threads are not allowed in the App Engine sandbox, are there any other items I should be onl the lookout for in Wicket that might make it a poor choice for this situation? Matt
Re: Google App Engine and Wicket
Here are a couple of pointers regarding Wicket on GAE: http://www.danwalmsley.com/2009/04/08/apache-wicket-on-google-app-engine-for-java/ On Sat, Apr 11, 2009 at 6:15 PM, Matthew Welch matt...@welchkin.net wrote: I've been experimenting a bit with Google App Engine and Wicket and things seemed to work fairly well once I turned off the ModificationWatcher. However, I realized that my simple tests were all stateless and that once stateful, Wicket would use the DiskPageStore to write some files, which is not allowed in the App Engine sandbox. Sure enough, once I added some stateful pages, I started seeing exceptions related to the DiskPageStore. I'm a neophyte when it comes to the deep down Wicket internals so I'm not sure what my other options might be. In a post Matej Knopp said, * DiskPageStore*'s purpose is to store serialized pages on disk in order to allow access to previous page versions and also to conserve session memory usage. This leads me to believe that using the sassion for storing this information isn't a preferred approach. What about the App Engine's datastore (an abstration on BigTable)? That seems like it might be too slow to adequately serve this need, but I'm not sure. A thread on Wicket/Terracotta integration ended up with an alternative SecondLevelCacheSessionStore but I'm not sure if that is only usable with Terracotta or if it might might sense in other situations. Any other options? Also, looking forward, with the knoledge that writing giles and spawning new threads are not allowed in the App Engine sandbox, are there any other items I should be onl the lookout for in Wicket that might make it a poor choice for this situation? Matt -- sp - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Google App Engine and Wicket
Here's another article about Wicket and GAE on DZone: http://www.dzone.com/links/rss/wicket_on_google_app_engine.html On Sat, Apr 11, 2009 at 8:22 AM, Sergey Podatelev brightnesslev...@gmail.com wrote: Here are a couple of pointers regarding Wicket on GAE: http://www.danwalmsley.com/2009/04/08/apache-wicket-on-google-app-engine-for-java/ On Sat, Apr 11, 2009 at 6:15 PM, Matthew Welch matt...@welchkin.net wrote: I've been experimenting a bit with Google App Engine and Wicket and things seemed to work fairly well once I turned off the ModificationWatcher. However, I realized that my simple tests were all stateless and that once stateful, Wicket would use the DiskPageStore to write some files, which is not allowed in the App Engine sandbox. Sure enough, once I added some stateful pages, I started seeing exceptions related to the DiskPageStore. I'm a neophyte when it comes to the deep down Wicket internals so I'm not sure what my other options might be. In a post Matej Knopp said, * DiskPageStore*'s purpose is to store serialized pages on disk in order to allow access to previous page versions and also to conserve session memory usage. This leads me to believe that using the sassion for storing this information isn't a preferred approach. What about the App Engine's datastore (an abstration on BigTable)? That seems like it might be too slow to adequately serve this need, but I'm not sure. A thread on Wicket/Terracotta integration ended up with an alternative SecondLevelCacheSessionStore but I'm not sure if that is only usable with Terracotta or if it might might sense in other situations. Any other options? Also, looking forward, with the knoledge that writing giles and spawning new threads are not allowed in the App Engine sandbox, are there any other items I should be onl the lookout for in Wicket that might make it a poor choice for this situation? Matt -- sp - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Google App Engine and Wicket
Both articles avoid the DiskPageStore problem by using the HttpSessionStore, however if you do a search through the mailing list archives for HttpSessionStore you'll find numerous references to problems in using it in the long term and especially in a real, production application, so I don't think that's a good long term solution, so my original question still stands. Is there an alternative or is Wicket perhaps not well suited for use in the App Engine. Matt ptrthomas wrote: Here's another article about Wicket and GAE on DZone: http://www.dzone.com/links/rss/wicket_on_google_app_engine.html On Sat, Apr 11, 2009 at 8:22 AM, Sergey Podatelev brightnesslev...@gmail.com wrote: Here are a couple of pointers regarding Wicket on GAE: http://www.danwalmsley.com/2009/04/08/apache-wicket-on-google-app-engine-for-java/ On Sat, Apr 11, 2009 at 6:15 PM, Matthew Welch matt...@welchkin.net wrote: I've been experimenting a bit with Google App Engine and Wicket and things seemed to work fairly well once I turned off the ModificationWatcher. However, I realized that my simple tests were all stateless and that once stateful, Wicket would use the DiskPageStore to write some files, which is not allowed in the App Engine sandbox. Sure enough, once I added some stateful pages, I started seeing exceptions related to the DiskPageStore. I'm a neophyte when it comes to the deep down Wicket internals so I'm not sure what my other options might be. In a post Matej Knopp said, * DiskPageStore*'s purpose is to store serialized pages on disk in order to allow access to previous page versions and also to conserve session memory usage. This leads me to believe that using the sassion for storing this information isn't a preferred approach. What about the App Engine's datastore (an abstration on BigTable)? That seems like it might be too slow to adequately serve this need, but I'm not sure. A thread on Wicket/Terracotta integration ended up with an alternative SecondLevelCacheSessionStore but I'm not sure if that is only usable with Terracotta or if it might might sense in other situations. Any other options? Also, looking forward, with the knoledge that writing giles and spawning new threads are not allowed in the App Engine sandbox, are there any other items I should be onl the lookout for in Wicket that might make it a poor choice for this situation? Matt -- sp - 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://www.nabble.com/Google-App-Engine-and-Wicket-tp23001592p23007684.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
