Firstly, I'd like to know how to find this out for myself next time. If not, then can somebody tell me?
The reason I want to know is because I want to use the #JsonIdentityInfo annotation on my Cloud Endpoints entities to deal with recursive serialization, but it doesn't compile. I guess this would mean it's some Jackson version less than 2.0.
You should not use repackaged libs - they are for internal GAE use only. They are not part of official API and can change at any time.
Include your own Jackson jar in your project.
Like Peter says, include your own Jackson jar. Make your code use this Jackson library. GAE will use their repackaged JSON parser or whatever they change it to (even not necessarily Jackson). That is of no concern to your project. GAE has no reason to look for Jackson annotations on your Entity classes - only your source code should tell only your Jackson jar to do that.
Related
Is there a way to get any Apache Camel component "metadata" using Java code, like the list of options and other parameters and their types? I think some automatic help builder was mentioned somewhere that might be of use for this task without using reflection.
A way to get the registered components of all types (including data formats and languages) with java code is also sought. Thanks
Yeah take a look at the camel-catalog JAR which includes all such details. This JAR is what the tooling uses such as some of the Maven tooling itself, or IDE plugs for IntelliJ or Eclipse etc. The JAR has both Java API and metadata files embedded in the JAR you can load.
At runtime you can also access this catalog via RuntimeCamelCatalog which you can access via CamelContext. The runtime catalog is a little bit more limited than CamelCatalog as it has a view of what actually is available at runtime in the current Camel application.
Also I cover this in my book Camel in Action 2nd edition where there is a full chapter devoted on Camel tooling and how to build custom tooling etc.
This is what I've found so far
http://camel.apache.org/componentconfiguration.html
I'm looking for an efficient way to generate API documentation in a readable format, from the generated files from Cloud Endpoint (Java). The generated files are either:
- my_api.api
- my_api*.discovery
Something that looks like this:
- https://github.com/kevinrenskers/raml2html#example-output
Swagger, API blueprint and RAML are all nice options, but don't seem adapt well to endpoint generated API descriptor files.
What methods are you using?
Unfortunately we (Apiary) do not actually offer any code generation tool at the moment for API Blueprint.
If you are looking for a way how to generate a description of your API from the code then API Blueprint isn't probably the best choice as we believe it should represent the contract between everybody involved in the API design lifecycle. This is also the reason why we have built the testing tool – Dredd – https://github.com/apiaryio/dredd
With Dredd you can test your API implementation is matching to your blueprint. It wouldn't make much sense if the blueprint would be generated from the implementation.
Hope it clarifies.
I want to define some globals and load some modules (i.e. valid version of django) before any code is executed in app engine.
Is it any file in app engine where I can define startup code/configuration?
I think about Python language but other languages suggestion is also welcome.
Have a look at this doc. https://developers.google.com/appengine/docs/python/tools/appengineconfig appengine_config.py is loaded before any of your code.
In addition to what the docs say, you can pretty much do anything. Manipulate sys.path, import, monkey patch stuff.
For Python 2.7, if you want to load a specific version of Django, call that version out in app.yaml as noted here Django is one of the many supported third-party libraries.
An other way might be to use warmup requests. This is run on the request made in order to initialize a new server. It could be useful if you have a lot of thing to do and don't want the first request on a new server to stall... On the other hand, warmup requests can be sent even without finally using the new instance, so if you do have a lot of things to do you might end up using more instance hours. Check the documentation for more info.
Is it possible to run a protorpc based service outside of GAE? I see that there is a project hosted at http://code.google.com/p/google-protorpc/ but it seems to depend on the GAE. The documentation is VERY vague on this point, does anyone have a clear answer?
Thanks!
Yes. The source code available at http://code.google.com/p/google-protorpc/source/browse/ includes all of the necessary libraries (minus protobufs itself, which you can download from the Google Developers site), and contains examples both for AppEngine and for a generic WSGI server.
The protorpc library itself is server-agnostic.
After messing around with this quite a bit, I have determined that ProtoRPC currently has dependencies on the google app engine. It is possible to rip the libraries you need out of the sdk, but you will have to change the protorpc source to not import from relative paths. All in all, it is not worth the hassle, either use the GAE, or don't use protorpc until it can stand on its own.
Thanks.
We have a library with very complex logic implemented in C. It has a command line interface with not too complex string-based arguments. In order to access this, we would like to wrap the library so that it can be accessed with simple XML RPC or even straightforward HTTP POST calls.
Having some experience with Java, my first idea would be
Wrap the library in JNI/JNA
Use a thin WS stack and a servlet engine
Proxy requests through Apache to the servlet engine
I believe there should already be something simple that could be used, so I am posting this question here. A solution has the following requirements
It should be deployable to a current linux distribution, preferrably already available via package management
It should integrate with a standard web server (as in my example Apache)
Small changes to the library's interface should be manageable
End-to-end (HTTP-WS-library-WS-HTTP) the solution should not incur too much overhead, but reliability is very important
Alternatively to the JNI/JNA proposal, I think in the C# world it should not be too difficult to write a web service and call this unmanaged code module, but I hope someone can give me some pointers that are feasible in regards to the requirements.
If you're going with web services, perhaps Soaplab would be useful. It's basically a tool to wrap existing command line applications in SOAP web services. The web services it generates look a bit weird but it is quite a popular way to make something like this work.
Creating an apache module is quite easy and since your familiar with xmlrpc you should check out mod-xmlrpc2. You can easily add your C code to this apache module and have a running xmlrpc server in minutes
I think you may also publish it as a SOAP based web service. gSoap can be used to provide the service interface out of the library. Have you explored gSOAP? See http://www.cs.fsu.edu/~engelen/soap.html
Regards,
Kangkan
Depends what technology you're comfortable with, what you already have installed and working on your servers, and what your load requirements are.
How about raw CGI? Assuming the C code is stateless between requests, you can do this without modifying the library at all. Write a simple script which pulls the request parameters out of the CGI environment, perhaps sanitises the input, calls the library via the command-line interface, and packages the result into whatever HTTP response you want. Then configure Apache to dispatch the relevant URL(s) to this script. Python, for example, has library support for XML-RPC, and so does every other scripting language used on the web.
Servlets sound like overkill, but for instance if you want multiple requests per CGI process instantiation, and don't feel like getting involved in Apache configuration, then it might be easiest to stick with what you know.
I'm doing a similar thing with C++ at the moment. In my case, I'm writing a PHP module to allow PHP scripts to access the logic in my C++ library.
I can then use whatever format I want to allow the rest of the world to see it - initially it will just be through a PHP web application but I'll also be developing an XML-RPC interface.
If you're going down the JNI route, check out SWIG.
http://www.swig.org/Doc1.3/Java.html
Assuming you have headers to project bindings with, swig is pretty easy to work with.