[appengine-java] Eclipse/Ant/SDK best practice
I do all my development in Eclipse, and then use ant for automated test and building my distros. Whenever there is a new G plugin for eclipes, I tend to have to download the SDKs twice; Once as part of the eclipse plugin and then a second time so I can include them in the classpaths in my ant scripts. Is this normal? or is there a better way to share SDKs between Eclipse and Ant also ... what are people's experiences with Helios and Google so far? I'm keen to upgrade from Galileo but don't have much slack time in the event of stuff not working -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Re: gae log console
I log to xmpp and it works really well. I find the standard log viewer with its foreign timestamps almost unusable for debugging. On Dec 11, 6:07 pm, Ikai L (Google) ika...@google.com wrote: I was just thinking about this. You might be able to do something by creating your own wrapped logger and integrating it with the XMPP service, though I am pretty sure this will send you over quota pretty quickly. On Fri, Dec 11, 2009 at 10:06 AM, Ikai L (Google) ika...@google.com wrote: Ah, tailing in real time (or semi real time). This isn't currently possible. You might want to write something up and create a feature request for it:http://code.google.com/p/googleappengine/issues/list On Thu, Dec 10, 2009 at 7:18 PM, asianCoolz second.co...@gmail.comwrote: its only copy the log to local pc. can it append so that i look like i use tail -f each time got new records in the log? -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.comgoogle-appengine-java%2B unsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en. -- Ikai Lan Developer Programs Engineer, Google App Engine -- Ikai Lan Developer Programs Engineer, Google App Engine -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Preventing GWT compile during deployment
How do I stop the GAE Deploy process from doing a GWT compile? -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=.
[appengine-java] Re: Problem with gdata services
Check out http://code.google.com/intl/zh-HK/appengine/kb/java.html#googledata and http://code.google.com/p/gdata-java-client/issues/detail?id=122 On Nov 11, 2:39 pm, Josh joshua.t.gr...@gmail.com wrote: The JAR files are being included in my build. The first time I run the app, I get this error: HTTP ERROR: 500 INTERNAL_SERVER_ERROR RequestURI=/view Caused by: java.lang.ExceptionInInitializerError at com.google.gdata.client.http.GoogleGDataRequest $Factory.createRequest(GoogleGDataRequest.java:73) at com.google.gdata.client.http.HttpGDataRequest$Factory.getRequest (HttpGDataRequest.java:162) at com.google.gdata.client.http.HttpGDataRequest$Factory.getRequest (HttpGDataRequest.java:168) at com.google.gdata.client.Service.createRequest(Service.java:713) at com.google.gdata.client.GoogleService.createRequest (GoogleService.java:535) at com.google.gdata.client.Service.createFeedRequest(Service.java: 1174) at com.google.gdata.client.Service.getFeed(Service.java:994) at com.google.gdata.client.GoogleService.getFeed(GoogleService.java: 662) at com.google.gdata.client.Service.query(Service.java:1155) at com.google.gdata.client.Service.query(Service.java:1096) at contacts.ViewContacts.doGet(ViewContacts.java:53) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java: 487) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter (ServletHandler.java:1093) at com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter (TransactionCleanupFilter.java:43) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter (ServletHandler.java:1084) at com.google.appengine.tools.development.StaticFileFilter.doFilter (StaticFileFilter.java:121) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter (ServletHandler.java:1084) at org.mortbay.jetty.servlet.ServletHandler.handle (ServletHandler.java:360) at org.mortbay.jetty.security.SecurityHandler.handle (SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle (SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle (ContextHandler.java:712) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java: 405) at com.google.apphosting.utils.jetty.DevAppEngineWebAppContext.handle (DevAppEngineWebAppContext.java:54) at org.mortbay.jetty.handler.HandlerWrapper.handle (HandlerWrapper.java:139) at com.google.appengine.tools.development.JettyContainerService $ApiProxyHandler.handle(JettyContainerService.java:342) at org.mortbay.jetty.handler.HandlerWrapper.handle (HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:313) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java: 506) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete (HttpConnection.java:830) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381) at org.mortbay.io.nio.SelectChannelEndPoint.run (SelectChannelEndPoint.java:396) at org.mortbay.thread.BoundedThreadPool$PoolThread.run (BoundedThreadPool.java:442) Caused by: java.security.AccessControlException: access denied (java.net.NetPermission getCookieHandler) at java.security.AccessControlContext.checkPermission (AccessControlContext.java:323) at java.security.AccessController.checkPermission (AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java: 532) at com.google.appengine.tools.development.DevAppServerFactory $CustomSecurityManager.checkPermission(DevAppServerFactory.java:151) at java.net.CookieHandler.getDefault(CookieHandler.java:58) at com.google.gdata.client.http.GoogleGDataRequest $GoogleCookieHandler.(GoogleGDataRequest.java:316) at com.google.gdata.client.http.GoogleGDataRequest $GoogleCookieHandler.(GoogleGDataRequest.java:305) at com.google.gdata.client.http.GoogleGDataRequest. (GoogleGDataRequest.java:408) ... 36 more Caused by: java.security.AccessControlException: access denied (java.net.NetPermission getCookieHandler) at java.security.AccessControlContext.checkPermission (AccessControlContext.java:323) at java.security.AccessController.checkPermission (AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java: 532) at com.google.appengine.tools.development.DevAppServerFactory
[appengine-java] Re: AppEngine Java stability concerns
+1 It's critical that the GAE team take these concerns on board. The two selling points of GAE are performance and reliability, yet thanks to the aggressive unloading of idle instances and the constant glitches of the GAE infrastructure, GAE is dramatically underperforming against expectations and of course the competition. As an IT manager, my observation is this really needs a team dedicating to the systemic problems that GAE currently faces. For example, where is the sandbox in which developers can test their apps against new releases? Where is a list of infrastructure problems/ exceptions and how each one should be dealt with? I'm sure the answer is that the nature of the bigtable/google infrastructure makes it hard to conceive a sandbox. Well somebody needs to focus on what needs to be done to achieve one. Just pretend for a moment that Steve Ballmer and the entire M$ competitive marketing dept. is monitoring this thread. Optimistically yours Roy PS. @Jerome. Throughput and response times are the 2 competing faces of performance. To achieve high throughput through a system, you sacrifice response time, and vice versa. I'm actually fairly confident that the GAE infrastructure can provide the throughput and the Google IO talk about the Whitehouse thingy shows that. What GAE can't seem to provide is reliably good response times, so much so that apps fall foul of the 30 second timeout. On Nov 9, 6:10 pm, James H james.hollier...@gmail.com wrote: Jerome, I am concerned about uptime and throughput too. Are there any GAE sites that boast large volume yet? It would be reassuring to see stats on such sites that prove the price/performance viability of GAE. How much traffic are you seeing and at what price and performance? On Nov 4, 2:21 pm, Rusty Wright rwright.li...@gmail.com wrote: Could you have an automated message (monthly, weekly, whatever) that's posted to the GAE groups that informs people about this downtime notify group? Max Ross (Google) wrote: Hi Jerome, There is planned maintenance going on right now. I'd strongly encourage you to subscribe to the App Engine Downtime Notify group where you can learn about these things in advance: http://groups.google.com/group/google-appengine-downtime-notify Thanks, Max On Tue, Nov 3, 2009 at 6:18 PM, Jerome jerome.mou...@gmail.com mailto:jerome.mou...@gmail.com wrote: Hello, Our app has been running on AppEngine Java for 2 months. We are now ramping up on traffic and have enabled the billing feature. We are seeing on a daily basis short (1-2 minutes) outages. Most of the time, this is on the datastore, but these short outages sometimes affect other areas as well, like for instance serving static content. Today, we are seeing a data store in anomaly. This has been going on for over an our now: Uncaught exception from servlet com.google.apphosting.api.ApiProxy$CapabilityDisabledException: The API call datastore_v3.Put() is temporarily unavailable. We are completely dead in the water... My 2 questions are: - how/where can we report short outages that are usually not reflected on the AppEngine system status? - what is the AppEngine team plan to ensure a reliable service Jerome- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---
[appengine-java] Re: the question in ubuntu9.10 and eclipse 3.5
The clue is libstdc++.so.5: cannot open shared object file: No such file or directory Try googling this along with apt-get. 9.10 switched from stdc5 to stdc6, so you need to install the legacy stdc5 package. It's a common problem with 9.10 and nothing to do with Eclipse or GAE On Mon, Nov 9, 2009 at 5:08 AM, Iqbal Yusuf Dipu iqbalyusufd...@gmail.comwrote: I'm a total newbi as far as Ubuntu/Linux is concern. I'm using Ubuntu 9.10, Eclipse 3.5 and having the problem as mentioned above even though I've set my environment as export GDK_NATIVE_WINDOWS=1 ** Unable to load Mozilla for hosted mode ** java.lang.UnsatisfiedLinkError: /home/iyusuf/bin/packages/eclipse3.5/ plugins/com.google.gwt.eclipse.sdkbundle.linux_1.7.1.v200909221731/gwt- linux-1.7.1/mozilla-1.7.12/libxpcom.so: libstdc++.so.5: cannot open shared object file: No such file or directory at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1778) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1674) at java.lang.Runtime.load0(Runtime.java:770) at java.lang.System.load(System.java:1003) at com.google.gwt.dev.shell.moz.MozillaInstall.load (MozillaInstall.java:190) at com.google.gwt.dev.BootStrapPlatform.initHostedMode (BootStrapPlatform.java:53) at com.google.gwt.dev.HostedModeBase.init(HostedModeBase.java:362) at com.google.gwt.dev.SwtHostedModeBase.init(SwtHostedModeBase.java: 127) at com.google.gwt.dev.HostedMode.init(HostedMode.java:271) at com.google.gwt.dev.HostedMode.main(HostedMode.java:230) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---
[appengine-java] Re: Recommendations for GWT +GAE
I think you'll get better answers in the GWT group http://groups.google.com/group/google-web-toolkit?hl=en On Sat, Nov 7, 2009 at 7:25 PM, Vik vik@gmail.com wrote: Hie I am a newbie in GWT and so very much confused for what to use for desigining my ui. I mean should i use the widgets comes with GWT or other open source libs available. Few things: 1. Please suggest which is compatible with GAE as my APP is gonna be on GAE only. 2. Right now I do not have very high-fi or a super cool UI requirements but definitely then one which has great widgets and does not easily break GAE free app file limits will be great for me to start with. Please advise Thankx and Regards Vik Founder www.sakshum.com www.sakshum.blogspot.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---
[appengine-java] Re: How can I change the temp dir when gae try deploying,
symbolic link? It might be worth raising an issue, requesting that the temp files be pushed down one level. Thus /tmp/appengine/stuff, instead of the current /tmp/stuff. That would make it easier for you to relocate using a symlink, and also help me tidy up my /tmp directory :-) On Fri, Nov 6, 2009 at 3:16 PM, magic.yang zju...@gmail.com wrote: When I run ...appcfg.cmd update warlocation, there is not enough disk for store the temp data, and run into java.io.IOException, How can I change the temp dir when updating app to GAE, or any other choice for solve this problem? advanced thanks! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---
[appengine-java] Re: Inequality operator is !=, but can we add
On Thu, Nov 5, 2009 at 9:17 PM, Max Ross (Google) maxr+appeng...@google.commaxr%2bappeng...@google.com wrote: The next SDK (1.2.8) is working its way through QA right now so hopefully it will be available in the next week or two. Please can we get a bit more notice on the changes and the make-live date than we did with 1.2.6 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---
[appengine-java] Re: Inequality operator is !=, but can we add
1.2.6 broke a few items based on the posts in this group and was implemented with no prior notice. Had we known what the changes were, and were given a couple of day's notice, we could have been monitoring our live apps and reviewing our code for incompatibilities, implemented some contingencies, downloaded the new SDK and locally regression tested our apps, etc. As it happened, the first that many of us knew of any problems was when live users complained to us. We then waste a bunch of time looking for problems, only to subsequently learn that a new SDK/API had been deployed. So my concern is operational rather than around any design/development decisions. I'm not asking for a firm date, just a couple of day's notice Having said that a roadmap would be extremely welcome :-) best Roy On Fri, Nov 6, 2009 at 3:36 AM, Max Ross (Google) maxr+appeng...@google.commaxr%2bappeng...@google.com wrote: Hi Roy, I don't have a firm date to give you on the next release because we're going to test it until we're satisfied with the quality. The release will be backwards compatible with the current release. What sorts of decisions are you looking to make based on the release date? Maybe there's some other way I can help you with them. Max On Thu, Nov 5, 2009 at 6:09 PM, Roy Smith roy.smith@googlemail.comwrote: On Thu, Nov 5, 2009 at 9:17 PM, Max Ross (Google) maxr+appeng...@google.com maxr%2bappeng...@google.com wrote: The next SDK (1.2.8) is working its way through QA right now so hopefully it will be available in the next week or two. Please can we get a bit more notice on the changes and the make-live date than we did with 1.2.6 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---
[appengine-java] Re: GWT Vs JQuery
Horses for courses. Do you know Javascript? Does GWT-RPC work for you, or do you prefer REST, DWR or your home-grown c-s protocol? Will you be using other APIs such as Gdata? Do you require any particular widgets from either GWT or Jquery? ...the list goes on GAE is agnostic. The biggest issue you will face with either approach is authentication. Right now GAE authentication is a pretty blunt instrument. On Fri, Nov 6, 2009 at 3:56 AM, Vik vik@gmail.com wrote: Hie My App is currently writen and hosted on GAE which used conventional MVC1 pattern and using jsps for views layer. I am looking forward to enhance the UI layer. So which one is more recommended GWT or JQuery or anything else that works with GAE? Thankx and Regards Vik Founder www.sakshum.com www.sakshum.blogspot.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---
[appengine-java] Re: Inequality operator is !=, but can we add
Thx for taking the issue on board. I have seen the roadmap page, but ideally I'd like the next level of detail in terms of planned releases and feature sets. Think Trac milestones. Of course these things change, but we can live with that. As an example, I'm currently wrestling with authentication. I can't decide whether I need to roll my own, or do you guys have anything in the pipeline to natively support OAUTH, or OpenId. Honestly I love your notifications so promise never to tune them out :-) Pre-releasing the SDK with deploy-disabled seems a pretty easy thing to do. If it's only advertised here, along with some release notes, a couple of days before live, that would help us and possibly help you with your regression testing. On Fri, Nov 6, 2009 at 4:02 AM, Max Ross (Google) maxr+appeng...@google.commaxr%2bappeng...@google.com wrote: Have you seen this? http://code.google.com/appengine/docs/roadmap.html I understand the operational difficulties you're describing. Ideally we would have a way to let early adopters try out the new runtime before we roll it out to all our servers, thus giving us the opportunity to learn about incompatibilities before they became widespread. We've talked about this quite a bit but we don't have anything coming in the near term. As for notification of new server-side deployments, the reality is that we push new code into production all the time. The vast majority of the time nobody notices because we didn't break anything and we didn't introduce any user visible features. If we sent out notifications every time we did this I'm pretty sure you would tune these notifications out within a week or two. Still, if you're running a real service with real users it makes sense that you would want to know about periods of increased risk ahead of time. I'm just not sure how we would identify those for you. The trick with a new SDK is that we can't release it until we've updated our servers with new code that is prepared to handle the new SDK, and by that time, if we've goofed and introduced an incompatibility, your app has already run into it. I suppose we could make the SDK available ahead of time in some form where it can only be run locally, but I can imagine it being pretty confusing to have an SDK that is only half-functional. What do you think? Max On Thu, Nov 5, 2009 at 7:44 PM, Roy Smith roy.smith@googlemail.comwrote: 1.2.6 broke a few items based on the posts in this group and was implemented with no prior notice. Had we known what the changes were, and were given a couple of day's notice, we could have been monitoring our live apps and reviewing our code for incompatibilities, implemented some contingencies, downloaded the new SDK and locally regression tested our apps, etc. As it happened, the first that many of us knew of any problems was when live users complained to us. We then waste a bunch of time looking for problems, only to subsequently learn that a new SDK/API had been deployed. So my concern is operational rather than around any design/development decisions. I'm not asking for a firm date, just a couple of day's notice Having said that a roadmap would be extremely welcome :-) best Roy On Fri, Nov 6, 2009 at 3:36 AM, Max Ross (Google) maxr+appeng...@google.com maxr%2bappeng...@google.com wrote: Hi Roy, I don't have a firm date to give you on the next release because we're going to test it until we're satisfied with the quality. The release will be backwards compatible with the current release. What sorts of decisions are you looking to make based on the release date? Maybe there's some other way I can help you with them. Max On Thu, Nov 5, 2009 at 6:09 PM, Roy Smith roy.smith@googlemail.comwrote: On Thu, Nov 5, 2009 at 9:17 PM, Max Ross (Google) maxr+appeng...@google.com maxr%2bappeng...@google.com wrote: The next SDK (1.2.8) is working its way through QA right now so hopefully it will be available in the next week or two. Please can we get a bit more notice on the changes and the make-live date than we did with 1.2.6 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---
[appengine-java] Timeout using GData API
Recently I've started getting timeouts fetching a spreadsheet using the Gdata API library. How do I increase the timeout? Stack trace follows:- java.io.IOException: Timeout while fetching: http://spreadsheets.google.com/feeds/worksheets/tPigPq5454wZIlYT_Vy7jY-ewerb2XQ/private/full/defaultjava.io.IOException: Timeout while fetching: http://spreadsheets.google.com/feeds/worksheets/tPigPqwZIlYT_Vy7jY-b2XQ/private/full/default com.google.appengine.api.urlfetch.URLFetchServiceImpl.handleApplicationException (URLFetchServiceImpl.java:69) com.google.appengine.api.urlfetch.URLFetchServiceImpl.fetch (URLFetchServiceImpl.java:42) com.google.apphosting.utils.security.urlfetch.URLFetchServiceStreamHandler $Connection.fetchResponse(URLFetchServiceStreamHandler.java:408) com.google.apphosting.utils.security.urlfetch.URLFetchServiceStreamHandler $Connection.getInputStream(URLFetchServiceStreamHandler.java:290) com.google.apphosting.utils.security.urlfetch.URLFetchServiceStreamHandler $Connection.getResponseCode(URLFetchServiceStreamHandler.java:131) com.google.gdata.client.http.HttpGDataRequest.checkResponse (HttpGDataRequest.java:535) com.google.gdata.client.http.HttpGDataRequest.execute (HttpGDataRequest.java:515) com.google.gdata.client.http.GoogleGDataRequest.execute (GoogleGDataRequest.java:515) com.google.gdata.client.Service.getEntry(Service.java:1270) com.google.gdata.client.GoogleService.getEntry(GoogleService.java:567) com.google.gdata.client.Service.getEntry(Service.java:1196) com.google.gdata.data.spreadsheet.SpreadsheetEntry.getDefaultWorksheet (SpreadsheetEntry.java:143) couk.cleverthinking.cc.server.google.GoogleDoc.fetchSpreadsheetContents (GoogleDoc.java:225) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---
[appengine-java] Recommended scope for DatastoreService
Should I be creating a DatastoreService for each session, or are they inexpensive enough that I can have one for each Kind? I realise that for transactions, the latter doesn't work. A related question is how threadsafe is an instance of DatastoreService? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---
[appengine-java] Re: Recommended scope for DatastoreService
Hi Max Thx for the answer, especially the correction on the transaction implementation. The solution I'd arrived at is to use Guice to instantiate my DsS with a scope of @RequestScoped. Do you see any problems with that approach? best Roy On Wed, Nov 4, 2009 at 7:02 PM, Max Ross (Google) maxr+appeng...@google.commaxr%2bappeng...@google.com wrote: A DatastoreService instance is extremely lightweight so feel free to create them as-needed. In addition, transactions are not tied to a specific DatastoreService instance but rather to the thread that started the transaction. Finally, assume that all classes in the api are _not_ threadsafe unless explicitly documented otherwise. Hope this helps, Max On Wed, Nov 4, 2009 at 4:35 AM, Roy roy.sm...@cleverthinking.co.ukwrote: Should I be creating a DatastoreService for each session, or are they inexpensive enough that I can have one for each Kind? I realise that for transactions, the latter doesn't work. A related question is how threadsafe is an instance of DatastoreService? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---
[appengine-java] Re: SimpleDS: an alternative for Datastore persistence
Hi Vince Thanks for sharing. I've modified my persistence framework to incorporate your class and it works very well. kind regards Roy On Mon, Nov 2, 2009 at 8:15 PM, Vince Bonfanti vbonfa...@gmail.com wrote: P.S. Because of issue 2097 (http://code.google.com/p/googleappengine/issues/detail?id=2097), the write-behind task doesn't work on the development server, so it always defaults to write-through (which is a nice test of the watchdog mechanism). The write-behind task works fine on the production servers. On Mon, Nov 2, 2009 at 3:12 PM, Vince Bonfanti vbonfa...@gmail.com wrote: You might be interested in my CachingDatastoreService class: http://code.google.com/p/gaevfs/source/browse/trunk/src/com/newatlanta/appengine/datastore/CachingDatastoreService.java It has the following features: - Implements the com.google.appengine.api.datastore.DatastoreService, so it's a plug-in replacement for the standard implementation. - Automatically caches entities in memcache for datastore reads and writes. - Has a write-behind option (the default) that queues all datastore writes as background tasks (except for transactions, which are always write-through directly to the datastore). - A watchdog task makes sure the write-behind task is always available. - If the write-behind task isn't available, defaults to write-through to insure no loss of data. - Supports configurable expiration of memcache entities (the default is no expiration). In order to use the CachingDatastoreService, first configure the write-behind task in web.xml: servlet servlet-nameCachingDatastoreService/servlet-name servlet-classcom.newatlanta.appengine.datastore.CachingDatastoreService/servlet-class /servlet servlet-mapping servlet-nameCachingDatastoreService/servlet-name url-pattern/_ah/queue/write-behind-task/url-pattern /servlet-mapping Then configure the write-behind-task queue in queue.xml (use whatever rate you want): queue namewrite-behind-task/name rate5/s/rate /queue Then replace the following code: DatastoreService ds = DatastoreServiceFactory().getDatastoreService(); with this code, and then use the DatastoreService methods as you normally would: DatastoreService ds = new CachingDatastoreService(); The default CachingDatastoreService constructor enables the CacheOptions.WRITE_BEHIND option and sets the expiration to null (no expiration). There are additional constructors that allow you to specify CacheOptions.WRITE_THROUGH and/or specify a memcache expiration value. Vince On Mon, Nov 2, 2009 at 2:21 PM, Stakka henrik.lindqv...@gmail.com wrote: One feature I see useful for a layer atop the Low-Level API is asynchronization. Since you'll never know how much time a Low-Level API call will take it should automatically create Tasks for them, writes atleast. On Oct 22, 10:37 am, Nacho Coloma icol...@gmail.com wrote: Hi all, We have been developing a persistence framework for the AppEngine Datastore based on the raw DatastoreService API. For our (simple) persistence case, both JDO and JPA were a bit overkill as we were spending a significant amount of time jumping through hoops to make our application roll, but at the same time the Datastore API was a too low-level solution to be usable. So we reinvented our wheel. In two days. SimpleDS is a light wrapper around the DatastoreService APIs that provide a simple interface for java persistent classes. It does not include fancy stuff or any super features, it's just the DatastoreService ported to a world where Java entities can be persisted directly (using a subset of JPA annotations). This is _not_ a JPA/JDO replacement, and will never be. But we have been using it for some weeks and are quite happy with it. Any kind of feedback from the AppEngine community would be welcome. Before calling the typical but we already have JPA/JDO! argument, please notice the following: * There are lots of considerations in a relational database that do not apply to AppEngine. This allows a specific solution to be simplified big time. Just see the depth of your typical stack trace to understand what I am talking about. * Solutions can be designed for specific cases that are common practice in AppEngine but do not apply to a relational database. See, for example, saving entities with a parent instance. * Transactions also behave a bit differently, where a one size fits all approach would probably not be the best solution. To better ilustrate with an example, these are some typical tasks performed with SimpleDS: Retrieve instance: FooBar bar = entityManager.get(key); Transform from Google Datastore Entity to java and viceversa: Entity entity = entityManager.datastoreToJava(bar); Save generating a primary key, with a parent
[appengine-java] Re: Servlet widgets - an alternative to GWT or servlet dispatch jsp paradigm
Have a look at Apache Click On Fri, Oct 23, 2009 at 1:01 PM, Tor adm...@toolboxsystems.com wrote: I'm very pleased with the Google Web Toolkit (GWT) and it would very nice to adopt the same way of building html code user interfaces in servlets in GAE - as an alternative to the servlet dispatching jsp paradigm. In short - from inside servlet doPost (or doGet) method - it would be nice to add widgets like panels, buttons ... and basic html (with attributes and parameters) - to the document before written to the response. - a GWT-clone creating html code directly to the servlet response instead of GWT creating javascript in the server that creates html in the browser. Any tips to java html-widget libraries? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---
[appengine-java] Re: Gadget Hosting on App Engine
I think this is more likely to be a gadget issue than an appengine issue. Check the gadgets discussion group as a few other people are experiencing the same issue On Sat, Oct 24, 2009 at 3:24 PM, Brian Dorry brian.do...@gmail.com wrote: I have recently been tasked with working on creating a gadget for a project that is hosted on app engine. I am also hosting the gadget specification on app engine. The gadget specification is generated on the server side as it refers back to the application id that the gadget is hosted on (this project may be hosted on multiple IDs), so I suspect that the gadget is subject to the same start up times that application is subject to when it has been inactive for a period of time (I don't know that this has anything to do with the issue I am having). Now to my problems. I have observed the following behavior: 1. After coming back to the mail inbox that I installed the gadget to the gadget has more often that not disappeared from the left side menu. 2. I came back to the mailbox after leaving Firefox open for an extended period of time, and after trying to use my gadget I received a 504 error Unable to retrieve gadget spec Are these related? Does anyone have experience with this issue? The gadget itself is working great hosted on app engine aside from this. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---
[appengine-java] Re: Authentication with Google Apps
For example I'd like my users to enter their u...@mycompany.com email rather than someb...@gmail.com. Is this possible? I have a GAE app defined as public which I can authenticate to using u...@mycompany.com. The rules for when this does and doesn't work seem ill defined. then you need to create a new application-id specifying which domain users can authenticate on your application. Remember you need to get prior approval from Google before you create multiple duplicate applications On Fri, Oct 23, 2009 at 1:34 PM, Mansoor khaja.mans...@gmail.com wrote: At the time of creating an application-id on appengine, you have an option to allow authentication only for users of a particular domain or for all google account users. If you already have the application setup for universal google account authentication, then you need to create a new application-id specifying which domain users can authenticate on your application. On Oct 22, 7:20 pm, sportrider sportri...@gmail.com wrote: I am working to publish a site on App Engine and would like to authenticate users by using their Google Apps email rather than a gmail email. For example I'd like my users to enter their u...@mycompany.com email rather than someb...@gmail.com. Is this possible? I've tried adding mycompany.com to the authDomain argument on userService.createLoginURL(), but this didn't seem to do anything. Many thanks, Chris --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---
[appengine-java] Runtime Exceptions
I read a lot about failures and timeouts from the datastore, but I can't find any documentation and of course the development environment doesn't simulate them. Has anybody compiled a list of the various error states and exceptions that we need to code for? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---
[appengine-java] Re: SimpleDS: an alternative for Datastore persistence
I did more or less the same thing for the same reasons, and with the same happy result.The only difference for me was instead of annotations, I generate my model from an RDBMS. This way I know I can port my app to an RDBMS world should GAE ever go the same way as Google Notebook. On Thu, Oct 22, 2009 at 11:43 AM, Richard richard.wat...@gmail.com wrote: Sounds good. I also think I'll focus much of my attention on the low- level API, so this could be very useful! Regards, Richard On Oct 22, 11:37 am, Nacho Coloma icol...@gmail.com wrote: Hi all, We have been developing a persistence framework for the AppEngine Datastore based on the raw DatastoreService API. For our (simple) persistence case, both JDO and JPA were a bit overkill as we were spending a significant amount of time jumping through hoops to make our application roll, but at the same time the Datastore API was a too low-level solution to be usable. So we reinvented our wheel. In two days. SimpleDS is a light wrapper around the DatastoreService APIs that provide a simple interface for java persistent classes. It does not include fancy stuff or any super features, it's just the DatastoreService ported to a world where Java entities can be persisted directly (using a subset of JPA annotations). This is _not_ a JPA/JDO replacement, and will never be. But we have been using it for some weeks and are quite happy with it. Any kind of feedback from the AppEngine community would be welcome. Before calling the typical but we already have JPA/JDO! argument, please notice the following: * There are lots of considerations in a relational database that do not apply to AppEngine. This allows a specific solution to be simplified big time. Just see the depth of your typical stack trace to understand what I am talking about. * Solutions can be designed for specific cases that are common practice in AppEngine but do not apply to a relational database. See, for example, saving entities with a parent instance. * Transactions also behave a bit differently, where a one size fits all approach would probably not be the best solution. To better ilustrate with an example, these are some typical tasks performed with SimpleDS: Retrieve instance: FooBar bar = entityManager.get(key); Transform from Google Datastore Entity to java and viceversa: Entity entity = entityManager.datastoreToJava(bar); Save generating a primary key, with a parent instance: FooBar bar = new FooBar(); entityManager.put(parentKey, bar); More can be seen here:http://code.google.com/p/simpleds/wiki/SimpleTasks Any discussion about the current API state is welcome. This entire thing was rolled in two days and tested in a couple of weeks so there should be some bugs in between. It is important to keep in mind the current list of limitations: * Only the Key class is a supported primary key. * IN and != are not supported (yet). I have big concerns about supporting this, performance-wise. * Relationships are not supported. You can use Keys and collections of Keys for that purpose. * Transactions are not yet included. We are not yet sure about how to proceed here. As I said, this is not conceived to become a feature-complete JPA replacement, so please don't treat it like that. Best regards, Nacho. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---
[appengine-java] Re: SimpleDS: an alternative for Datastore persistence
My goal wasn't to economise on api _ms so I haven't done any comparisons. afaik, commit is done at an entity level, so I don't monitor individual fields for changes. If I'm wrong then it wouldn't be too difficult to build dirty flags into my DTO setters. My advice to anybody building apps for GAE is to have your own abstraction layer between JDO/JPA/LLAPI so any porting between regimes is painless. This is why I took the approach of modelling my data in an RDBMS and then generating my object data model automatically. At first it sounds like a retrograde step, but the benefit is that my data model is independent of any specific persistence framework (and the design tools are more mature). On Thu, Oct 22, 2009 at 11:37 PM, Peter Liu tinyee...@gmail.com wrote: Awesome! I recently played with the lower level API as well. Some of the features are not available in JDO, like reserving a key before committing a new object. The detach/attach is also problematic when dealing with caching and transaction. I also noticed small JDO objects are much bigger than it needs to be when serialized. Just wondering do you have any performance profiling stats? I also feel like JDO is overkill, but I couldn't justify porting all JDO objects to another simple type without knowing how much cpu_ms it will save. Also, do you keep track of which field is dirty and avoid committing unmodified fields? I believe this is important to minimize api_cpu to avoid unnecessary index updates. On Oct 22, 2:37 am, Nacho Coloma icol...@gmail.com wrote: Hi all, We have been developing a persistence framework for the AppEngine Datastore based on the raw DatastoreService API. For our (simple) persistence case, both JDO and JPA were a bit overkill as we were spending a significant amount of time jumping through hoops to make our application roll, but at the same time the Datastore API was a too low-level solution to be usable. So we reinvented our wheel. In two days. SimpleDS is a light wrapper around the DatastoreService APIs that provide a simple interface for java persistent classes. It does not include fancy stuff or any super features, it's just the DatastoreService ported to a world where Java entities can be persisted directly (using a subset of JPA annotations). This is _not_ a JPA/JDO replacement, and will never be. But we have been using it for some weeks and are quite happy with it. Any kind of feedback from the AppEngine community would be welcome. Before calling the typical but we already have JPA/JDO! argument, please notice the following: * There are lots of considerations in a relational database that do not apply to AppEngine. This allows a specific solution to be simplified big time. Just see the depth of your typical stack trace to understand what I am talking about. * Solutions can be designed for specific cases that are common practice in AppEngine but do not apply to a relational database. See, for example, saving entities with a parent instance. * Transactions also behave a bit differently, where a one size fits all approach would probably not be the best solution. To better ilustrate with an example, these are some typical tasks performed with SimpleDS: Retrieve instance: FooBar bar = entityManager.get(key); Transform from Google Datastore Entity to java and viceversa: Entity entity = entityManager.datastoreToJava(bar); Save generating a primary key, with a parent instance: FooBar bar = new FooBar(); entityManager.put(parentKey, bar); More can be seen here:http://code.google.com/p/simpleds/wiki/SimpleTasks Any discussion about the current API state is welcome. This entire thing was rolled in two days and tested in a couple of weeks so there should be some bugs in between. It is important to keep in mind the current list of limitations: * Only the Key class is a supported primary key. * IN and != are not supported (yet). I have big concerns about supporting this, performance-wise. * Relationships are not supported. You can use Keys and collections of Keys for that purpose. * Transactions are not yet included. We are not yet sure about how to proceed here. As I said, this is not conceived to become a feature-complete JPA replacement, so please don't treat it like that. Best regards, Nacho. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---
[appengine-java] Re: LIKE query workaround for the Low Level API
Answered in this thread http://groups.google.com/group/google-appengine-java/browse_thread/thread/958851cc674d0c70/7403586fae9ffe20?lnk=gstq=startswith#7403586fae9ffe20 On Wed, Oct 21, 2009 at 6:34 PM, George Moschovitis george.moschovi...@gmail.com wrote: Hi, what is the suggested way to emulate an SQL LIKE 'prefix%' query using the low level Datastore API? thanks, George. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---
[appengine-java] Re: JDO vs low level API
I'm about to quit on JPA/JDO after 2 days of pure frustration. The final straw is:- System.out.println(emp.dept name= + emp.getDept().getName ());// throws an NPE vs. System.out.println(emp.dept name= + emp.dto.getDept().getName()); System.out.println(emp.dept name= + emp.getDept().getName()); // now works just fine I can't cope with that much non-deterministic behaviour. fwiw, I have my own ant task to reverse engineer a database schema into JPA, Hibernate, JDO, etc. The approach I'm taking is to do my design using an RDBMS and design tool and then generate a GAE LLAPI DAO layer from the database. That way its fairly easy for me to switch from LLAPI to say JDO in the future (not that I can ever imagine wanting to given my app is dependent on so many GAE features anyway). I'm guessing that an interesting side benefit is that the DTO classes are now RPCable to GWT, unike the annotated JDO/JPA stuff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---
[appengine-java] Re: JDO vs low level API
I realise that non-deterministic is a relative term, and that given enough time, reading, research, etc etc I will be able to determine why adding a println prevents an NPE. My point (and I think of others) is why?. Especially since it's taken me 2 days already that I was supposed to have spent working on business logic, not figuring out why mappedsuperclasses misbehave and whether JPA or JDO is the better option. A GAE app is inherently non-portable to other environments (or at least mine is) so that is of no value. I'm not porting the app. from an existing RDBMS/ORM environment so that isn't a win either. Sure I may have to adjust my code if the datastore API changes, but I can live with that, in fact I'd rather do that than hope that any API changes have been correctly absorbed by the Datanucleus stack. I don't want to appear negative towards Datanucleus, but for my situation it's a sledgehammer to crack a nut On Thu, Sep 24, 2009 at 8:19 AM, datanucleus andy_jeffer...@yahoo.comwrote: The final straw is:- System.out.println(emp.dept name= + emp.getDept().getName ());// throws an NPE So why not address what the difference is in calls to your persistable class ? Nothing is non-deterministic by definition that you have a programming language here and rules are followed (and JDO behaviour is defined in a spec). Pay particular attention to object states and fetch groups (and the DataNucleus docs define all you should need to know around that). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---
