Group items tagged

You don't have to add each class individually to the black list. They are all regex patterns, so just do this: <extend-configuration-property name="rpc.blacklist" value="com.google.gwt.user.client.ui.*Collection"/> In my case I wanted even finer grained control over which collections get included, so I did this: <extend-configuration-property name="rpc.blacklist" value="-.*List"/> <extend-configuration-property name="rpc.blacklist" value="-.*Map"/> <extend-configuration-property name="rpc.blacklist" value="-.*Collection"/> <extend-configuration-property name="rpc.blacklist" value="+java.util.HashMap"/> <extend-configuration-property name="rpc.blacklist" value="+java.util.LinkedHashMap"/> <extend-configuration-property name="rpc.blacklist" value="+java.util.ArrayList"/>

 * Implements background tasks for * <a href="http://code.google.com/appengine/docs/java/overview.html">Google App * Engine for Java</a>, based on the * <a href="http://code.google.com/appengine/articles/deferred.html">Python 'deferred' * library</a>; simplifies use of the <a href="http://code.google.com/appengine/docs/java/taskqueue/overview.html"> * Task Queue Java API</a> by automatically handling the serialization and * deserializtion of complex task arguments.

Right now, when the user removes the GWT/App Engine nature from the project, if they have a SDK container on their build path, it is collapsed into its individual jars, and they are added to the classpath. In some cases, users do not expect this behavior (for example, if they mistakingly added the wrong nature).

Please support the ability to server static files from the runtime based on regex patterns similar to the current Python runtime. Currently the only way to simulate this functionality is with a servlet. This is not ideal peformance, as evidenced by existing special handling of static files. The most compelling use case is for versioning static files with the app's version ID so that browsers can maximally cache static files without experiencing stale caches later when the app is updated.

You have three options at the moment, when it comes to a 'multi-tenant' app such as you describe: You can have a single app that your customers add to their domains. Your app will have a single datastore, but you can use the Host header to determine which customer is accessing the app, and segregate the datastore entries based on that. Easy to deploy and upgrade Easy for customers to install Users have to have Google accounts, not Apps accounts, to log in. You can deploy a fresh app instance for each customer. Harder to deploy and upgrade More customer involvement required to install Provides firm separation of data Users can log in with their Apps credentials You can work with Google to create a new Apps Marketplace app All the benefits of point 1 and 2, above Requires Google involvement No certain release date yet