Currently use of Solr or Lucene is not fully supported on Google App Engine, there are hacks around the issue but none seems perfect.
If I setup the Solr server via a cloud offering somewhere else, run the main site and application on GAE but use the Solr server for search functionalities, can anyone see any problems doing doing it this way?
The current (version 1.4.1) implementation of SolrJ (the Solr client for Java) doesn't work on GAE due to some external dependencies (mainly Apache Commons HTTP client). There are a few other gotchas, see this thread.
You can either contribute to the efforts towards a more portable SolrJ, or code directly against the Solr HTTP interface with the standard GAE HTTP client.
Related
Hey does anyone know why Google Cloud Endpoints for Go-lang isn't in the standard environment on Google App Engine? It's only seemed to be officially supported/documented for Python / Java.
Is it because
A) Cloud Endpoints is coming to Golang soon / someday.
B) Cloud Endpoints isn't so great, so it's not going to be implemented in Golang.
C) Something else.
There's this "non-standard" lib https://github.com/GoogleCloudPlatform/go-endpoints but it hasn't been updated in 9 months.
I'm trying to choose between Python and Golang for a GAE project, and this lack of support for Cloud Endpoints is giving me pause.
Thanks in advance.
Product manager Dan Ciruli answered this on the google-appengine-go mailing list :
There are two primary reasons, and the second is a byproduct of the
first. We've had much less uptake on the Endpoints Go framework --
perhaps because, in the words of a developer I spoke to, "Go just
isn't a 'framework' language." Unlike, Java, Python (and, say, Node),
most developers using Go don't use a framework for writing an API
backend.
And, at least partially because of that, we aren't staffed on the
Endpoints team to build and support a framework in Go.
He added:
All hope is not lost. You can put a Go API behind Endpoints today on
GAE Flex or Container Engine (without framework) using the Extensible
Server Proxy. And later this year, we should be able to get the ESP
deployed in GAE standard environment, you'll get the full power there,
too.
We are currently running a combined AppEngine / GCE app and thus far have kept all of our datastore access on the AppEngine side of things. Now we are exploring also allowing our GCE instance to make some queries into the (shared) datastore. To start, I'm trying to figure out how to run things locally. What we have so far:
A Go devappserver running
A Go standalone binary that wants to issues queries to the devappserver datastore.
We installed ('go get') google-api-go-client/datastore/v1beta2 so that we can use an API instead of issuing direct HTTP calls. However we are definitely willing to issue direct HTTP calls if this API library won't work in development.
We have service accounts set up (we already access GCS from GCE) but I doubt that's relevant for running locally...
I've seen some docs but they (a) only talk about Python & Java, and (b) discuss connecting to the (standalone) development datastore server, as opposed to the datastore embedded in AppEngine's devappserver (if those are even different?). There is also the following answer here on StackOverflow, but again it discusses connecting to the standalone development datastore server:
How to connect to the local google cloud Datastore db?
Any pointers would be much appreciated!
Ian
Currently this is not possible in the development environment for several reasons. The Google Cloud Datastore tool (gcd.sh) uses the java development server. However when developing go for App Engine you use the python development server, which has different underlying storage. There is a bug to track this issue on the github page.
You can still develop a Google Cloud Datastore application in go however there are many bugs in the current go client library. Unfortunately, the development server does not currently support the JSON API, which the go library uses (see the note at the top of the page).
Update: I wanted to make sure proppy's comment was seen as part of the answer. His suggestion does provide a way to use the protocol version of the API, which is probably more stable than the go client library above. It could also let you use the gcd.sh tool to test this in the development server. You will have to craft the HTTP requests yourself though, and you won't be able to share the data in the datastore between your application and the Cloud Datastore in development. However it is definitely a good workaround and lets you use the Cloud Datastore API, which as it develops will be easier to work with than other workarounds.
From proppy:
Note that you can still use Cloud Datastore Protobuf HTTP API with Go. The protobuf definition is available on GitHub, you can compile it to Go code using the Go protobuf compiler plugin and then send POST HTTP requests to /datastore/{version}/datasets/{datasetId}/{method}.
If the use case from your "GO" app server is straight forward enough, you may want to implement access by using an API call to your GAE service (perhaps extending the service to receive the API calls).
This has the added benefit of only having to make changes in one place if your datastore definitions or functions change.
I started building a web application and made it runnable with an embedded Jetty server. I then decided to try out Apache CXF (which I have never used before) to provide either a SOAP/XML or a REST/JSON interface (haven't decided which yet). Now I am slightly confused by the various posts / docs I have read.
I understand that CXF actually provides (using Jetty internally) its own endpoints that can be published. Is that correct? But it looks like it can also be bundled and deployed into existing web containers (eg Tomcat, and therefore I assume also Jetty) - is this also correct?
If both of these are correct, what are the pros / cons / gotchas of using the CXF Jetty endpoints out-of-the-box as opposed to using a separate container (especially if the separate container is also embedded Jetty)?
It really depends on your application and deployment strategy. Jetty is a lightweight, embedded application server that you can use to run your own web-server. If you choose Apache Tomcat or JBoss or any other application server your application will be likely packaged as a WAR and deployed. The difference is , in Jetty your application controls the container whereas with others its the other way around. Regardless of the choice of application server , CXF endpoints are designed to work with any container supporting JAX-RS or JAX-WS specifications.
Note: You don't need Jetty if you are going to deploy it on Tomcat or other containers.
I'm developing a Google App Enigne application that uses some REST services and offers in turn web services. I'm using the GAE Eclipse plugin. I have 2 questions:
What is the best JAX-RS library to use with GAE nowadays? I'd like to use Jersey because I understand is the most "standard" library (isn't it?), but I could use any in principle... I've been looking for documentation, but I've only found some samples in blogs that only work with old versions of Jersey, etc...
For the web services I have to offer, I thought of using JAX-RS as well, but now I'm not sure if it's the best option...
You can use Jersey 1.5. You can see all frameworks that will play on GAE at http://code.google.com/p/googleappengine/wiki/WillItPlayInJava
But GAE has realized on version 1.7.5 as experimental service Endpoints which in term are rest service. Check https://developers.google.com/appengine/docs/java/endpoints/
For web service I don't know if you mean soap service..JAX-RS is the specification for rest service, instead you should use JAX-WS I don't try the compatibility with this specification.
After a little research on this subject, I've found out that the best way to offer web services from Google App Engine is using Google Cloud Endpoints, which is still an experimental technology but as far as I've tried, it works well. Furthermore it is very well integrated with GAE and the Google Plugin for Eclipse.
To cosume REST services from Google App Engine, I've opted for using just Java build-in HTTP client library as explained here. I don't know if it's the best way, but it is very simple and you avoid compatibility problems that could arise between GAE and JAX-RS APIs such as Jersey.
In order to work with JSON in GAE (very useful for RESTful services), I'm using Google's gson, which is a Java library that can be used to convert Java Objects into their JSON representation and vice-versa.
Currently i try to connect (via JPA/Datanucleus) with an application, hosted by Google App Engine, to the database service of database.com (Salesforce)
After many hours of reading and trying, i could not find any solution.
So, is it even possible??
Some Information....
Database.com provides JPA: http://forcedotcom.github.com/java-sdk/jpa-provider, but i could not found any sdk on this side, but i found a jar-file hosted by grepcode http://grepcode.com/snapshot/repo1.maven.org/maven2/com.force.sdk/force-jpa/22.0.7-BETA/ - Possibly there is currently no official release ...
The problem is that this SDK from Salesforce needs datanucleus 2.0, but Google App Engine includes only datanucleus 1.1.5. So i try to update theses libaries and found this.... code.google.com/p/datanucleus-appengine/ . I tried a few hours to replace the old libaries and to use the newer, but unsuccessfully. The error was that eclipse could not find some libaries, because the newer libaries, provided by the side above, have different package structure -
I am thankful for any help...
Kotake
The official release of the JPA provider is available on Maven Central:
http://search.maven.org/remotecontent?filepath=com/force/sdk/force-jpa/22.0.7-BETA/force-jpa-22.0.7-BETA.jar
The external connection restriction won't be a limiting factor because the JPA adapter connects to Database.com over https using a SOAP API.
I can't speak to the challenges around getting DN 2.0 running on GAE. Perhaps GAE support can help with that?
As stated here in the App Engine docs, you cannot make direct connections to external servers from GAE (except over http or https using the app engine specific url APIs). You will need to find some other way to get data out of your remote database.
This link describes how to solve your problem:
How to use Force.com Database SDK on Google APP Engine
(He has updated the Saleforce SDK source code to allow it to work without problem on GAE.)