[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 wrote:
>
> > 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
-~--~~~~--~~--~--~---
[appengine-java] Re: receiving mail demo
> > > is this right way to read message body? why i am getting same body twice > in two different forms (plain text & html)? because that's what your email client is sending. It's quite normal. > > > > > --~--~-~--~~~---~--~~ 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: receiving mail demo
It's a standard Java Mail task, nothing to do with GAE. Try googling "java mail multipart examples" On Mon, Oct 19, 2009 at 3:03 AM, Prashant wrote: > how do i separate both type msg bodies ? > > > > > --~--~-~--~~~---~--~~ 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=gst&q=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: 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 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 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 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 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
I think the answer is no, and the irony isn't lost. I haven't looked into it, but depending on the length of your strings, you might be able to store multiple substrings and build a query which applies "like %" across all the substrings. There was an article somewhere (or was it a Google IO talk) which talks about the features of set searches On Thu, Oct 22, 2009 at 11:24 PM, Nicholas Albion wrote: > > I don't suppose it's possible to do: > >myString LIKE "%,foo,%" > > I'm surprised that the datastore used by a search engine doesn't have > better support for string searching/comparison... > > > --~--~-~--~~~---~--~~ 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 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 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] 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 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 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: conceptual question: parent Key
Resistance is futile :-) It only enforces referential integrity in that you specify the parent at entity creation time. LLAPI does NOT prevent you subsequently deleting a parent and thus orphaning the child. The main benefit is that the 2 entities formed as a parent/child in this way form an entity group and thus may be involved in an atomic transaction. This is also the downside in that there is a persistence overhead when persisting am entity group. So it depends on your application whether you should manually maintain your own relationships using foreign keys (cheap, but no transactions) or use LLAPI (expensive but supports transactions). If you google this group for "entity group", and also the GAE documentation you will see a lot of discussion. On Thu, Oct 29, 2009 at 11:00 AM, K.Honsali wrote: > > typo: desired issue => desired value > > On 29 oct, 11:58, "K.Honsali" wrote: > > Salaam, > > > > Using the low-level datastore api; > > > > I have some resistance understanding the benefit of instantiating an > > Entity with a parent Key. > > Since I can just set a property , ParentId , with the desired issue. > > > > Does BigTable ensure integrity constraints if I indicate the parent > > Key using the former method? > > > > 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: 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 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 > 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: > > > > > >CachingDatastoreService > > > > com.newatlanta.appengine.datastore.CachingDatastoreService > > > > > >CachingDatastoreService > >/_ah/queue/write-behind-task > > > > > > Then configure the write-behind-task queue in queue.xml (use whatever > > rate you want): > > > > > >write-behind-task > >5/s > > > > > > 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 > 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 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.datastore
[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) > 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 wrote: > >> >> 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: Inequality operator is !=, but can we add <>
On Thu, Nov 5, 2009 at 9:17 PM, Max Ross (Google) > 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) > 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 wrote: > >> On Thu, Nov 5, 2009 at 9:17 PM, Max Ross (Google) < >> maxr+appeng...@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 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) > 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 wrote: > >> 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 > 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 >>> wrote: >>> >>>> On Thu, Nov 5, 2009 at 9:17 PM, Max Ross (Google) < >>>> maxr+appeng...@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: 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 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: 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 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: 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 wrote: > > 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.(HostedModeBase.java:362) >at > com.google.gwt.dev.SwtHostedModeBase.(SwtHostedModeBase.java: > 127) >at com.google.gwt.dev.HostedMode.(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 -~--~~~~--~~--~--~---
